J
Joe Jansen/ENGR/HQ/KEMET/US
OK Bob, back at ya!
<grin>
--Joe Jansen
btw: the link in your .sig.... Is that you? Or are you supporting someone else? Just curious. Poked around the site a bit...
-------------------------------------------------
Bob Pawley wrote:
Hi Joe:
This thread is getting a little interesting.
See if I make any sense with the following comments.
Bob Pawley
www.automating-automating.com
250-493-6146
800-573-7703
<snip>
From Bob:
> I still have a question or two tho. Let me try laying this out in 2
> different scenarios, and you can give me a pro/con list of each.
>
> Plant #1: Standardized on Allen Bradly SLC processors 10 years ago.
They
> have the full range from SLC 5/01's and Micro's, all the way up to the
> latest 5/05 processor. Over the years, they used APS, then upgraded
> to
AI
> to do their programming. They never bought into RSLogix, as they had
> no need.....
I have been away from direct involvement with that part of the industry, but I suspect that the software and hardware are still required to be purchased as a package??
Joe Replies:
No. The hardware does have the firmware included, of course, but the programming software is not a bundled purchase. It is 'available' seperately for a mere $1500 to $3000 USD, depending on what peice of hardware it supports. Of course the software for the SLC does not program the PLC 5 series, so to do both puts you out a bit under $5000 USD, and that is for 1 copy of each. If you have a developer and a technician, start coughing up the cash!
This is why the PLC companies now make each version's file format incompatible with the previous version. They will give a story about how it is necessary to provide better functionality, blah blah blah. It is a load of BS, though, since most times the 'new functionality' is a prettied up UI in the software. Parts of the latest RSLogix release I actually wish I could turn off, but cannot (Anyons from RS listening? I want rid of the little 'helper' box that pops up when I am entering instructions mnemonically. ie: I enter EQU and the yellow box pops up that says EQU SourceA SourceB. Problem is that if I am at the bottom of the window, it covers my text entry window, and I cannot see what I am tryiong to type). But I digress............
The reason for the incompatibility is chiefly to make you upgrade and enhance the revenue stream. If they didn't, most people would skip the 'service contract' and jsut keep what they have for many years. By pricing the cost of the service contract, which includes 'free' (note the
finger-quotes) upgrades at just slightly less than the cost of a whole new package, and then insuring that you 'want' to upgrade once a year (so you can still work on your equipment for another year), they insure a steady income for their software division.
Bob Continues:
> Plant #2: Is using Linux / Open source based PC controls. All the
> I/O
is
> based on Modbus/TCP and other TCP/IP friendly I/O. They are running
kernel
> version 2.0 (an older version) and have not upgraded to the latest
kernel,
> as they had no need.....
>
> Ok. Both plants have a standard. They are both running along just
> fine. In plant 1, if an integrator brings in a new machine, they leave
> all the documentation and disk copies in AI compatible files, so the
> plant does not have to upgrade.
Let's separate the two points. Both of your examples allows the user to manipulate the control elements to do whatever needs doing.
AB will not let you add features and change the core elements of their program by yourself. Linux does allow anyone and everyone knowledgeable enough, to change these core features.
Joe gleefully replies:
Yes! That is a big part of my point. Note that linux does not -require- you to do so, but if I want to write a custom function (similar to what Siemens processors let you do, I believe), my AB system 'just says no'. If I have a unique situation that requires a specially modeled PID loop for example, you sure aren't doing it in an AB processor. Conversely, I can write any special functions I need into a L-PLC implementation and it grows as I need it too. Heck, someone may have already written a better one and felt like sharing it (it isn't required tho).
Bob posits:
> In Plant 2, if an integrator brings in a new machine, they implement
> the controls on Red Hat version 6.1, using kernel ver 2.0, as supplied
> to
them
> by the plant, as their core operating system.
>
> (Curt and others: I am not sure if that is the right kernel rev for
> RH6.1, as I am making this example up as I go)
>
> My questions are:
>
> How is plant 2 in any worse shape than plant 1? Don't they have the
> advantage of knowing that they can give the integrator (legally) a
> copy
of
> their core OS to use as the starting point?
If I were the plant operator, the one who purchases the software and pays your wages, I would be more comfortable with AB over Linux. With AB I am assured of a basic standard of software operation that I know will be the same from the time I purchase it 'till I am convinced to purchase an upgrade. This insures that in my plant's near future I will be protected by a warranty,
Joe cannot help but interrupt:
Warranty?! We don't have no stinkin' warranty! (accent intended). Read carefully what you assume is your warranty from Allen Bradley. They warrant that it won't turn into smoke the first time you plug it in. If you plugged it in, and a day later it turned to smoke, it is your problem. I know this *first hand* on several occaisions. And don't assume that they warrant that the application is appropriate for your system. I would like you to show me what warranty you think you have with their stuff....
Bob continues after the interruption:
I will know that one part of my empire has basically the same infrastructure as the other parts, I can send solutions from one plant area to another without worrying if some eager beaver has changed the infrastructure so that it is no longer compatible. I can hire new employees that will know the AB infrastructure, I can transfer employees, with the assurance that they will not need to spend their time and my money determining how the infrastructure is engineered. All this to keep costs and problems down and production constant.
Joe replies:
In the plant(s) I currently work at, we have defined software version control procedures in place for all control software. This includes ladder files, motion controller configurations, touchscreen program files, etc. Nothing is allowed to be modified without a formal (written) description of the changes required by the process engineers. Once the changes are done, process engineering and equipment engineering get together to run an acceptance test. Upon acceptance, the documentation is updated, the new files are archived and distributed to the technicians file areas so they have the required documentation for troubleshooting, etc.
How would any of this change? Having an Open source based system does not require me to allow operators to hack code in their spare time. Just as I cannot go off and write myself an app that will generate huge levels of network traffic, you would simply make the OS code off limits to anyone developing, and handle required exceptions as needed, if needed at all.
Bob continues:
Another point - If I were a plant operator I would not buy software. I would purchase tools, software tools that you were able to use without adding further expense. I would try to purchase tools that you would not need to take apart and then put back together in order to make it work. I would do my best to buy those tools that don't require further time, effort and my money to make them work.
Joe nods and agrees, so Bob continues on:
Linux is a dream come true for the creative techs who want to solve problems effectively, quickly and by putting a little of themselves into the work.
But - until I, as a plant operator (example only), can be satisfied that my concerns outlined above are satisfied, then I will be extremely reluctant to purchase open source.
Joe interjects:
And that, of course, is the wisest thing to do. There will be a time, though, when the current tool set is inadequte. It is already quite often not real elegant. The question comes down to a cost v. benefits. Will you, as the plant operator, be willing to give your developers the -best- tools, or the tools that can be made to work. If you workers need to pound a nail, and all you have ever bought are wrenches, do you get them a hammer, or tell them to turn their wrench sideways?
Bob again:
> If Rockwell decided that the next version of RSLogix would not be able
> to export files in AI format, and the exact same day, Red Hat
> announced that the distrobution disks for 6.1 were no longer available
> to download from their web site, who got the shaft harder? As
> integrators upgrade their software, isn't plant 1 being pushed into
> upgrading their programming software against their will? Plant 2
> already has all the legal software purchased that they need to (1),
> and if they can't support it, they can still get support from many
> other locations.
>
> I would think that the person in charge of the software platform would
> be cracking open a new roll of Tums on that day.
>
> Don't get me wrong, I am not trying to cheerlead for Linux. I guess I
> am just looking for an example of how it is better to use
proprietarysoftware
> as a means of insuring continuity. I have seen myself that most new
> software releases insure that file formats are incompatable, thus
> forcing the upgrade. If the techs at my remote plants are a rev
> behind, they cannot look at my stuff.
If this is happening purposely, rather than a needed method of making the application better, then it is clearly wrong.
Joe:
I addressed this further up. Suffice to re-iterate that Logix changes file format as often to more often than MS word. No net gain to the end user, but you do have to upgrade your software. Funny how that happens every time. And all they can tell you each time is "Well, we didn't anticipate well enough to make the last version expandable. oops." Funny they never learn, tho.
<grin>
--Joe Jansen
btw: the link in your .sig.... Is that you? Or are you supporting someone else? Just curious. Poked around the site a bit...
-------------------------------------------------
Bob Pawley wrote:
Hi Joe:
This thread is getting a little interesting.
See if I make any sense with the following comments.
Bob Pawley
www.automating-automating.com
250-493-6146
800-573-7703
<snip>
From Bob:
> I still have a question or two tho. Let me try laying this out in 2
> different scenarios, and you can give me a pro/con list of each.
>
> Plant #1: Standardized on Allen Bradly SLC processors 10 years ago.
They
> have the full range from SLC 5/01's and Micro's, all the way up to the
> latest 5/05 processor. Over the years, they used APS, then upgraded
> to
AI
> to do their programming. They never bought into RSLogix, as they had
> no need.....
I have been away from direct involvement with that part of the industry, but I suspect that the software and hardware are still required to be purchased as a package??
Joe Replies:
No. The hardware does have the firmware included, of course, but the programming software is not a bundled purchase. It is 'available' seperately for a mere $1500 to $3000 USD, depending on what peice of hardware it supports. Of course the software for the SLC does not program the PLC 5 series, so to do both puts you out a bit under $5000 USD, and that is for 1 copy of each. If you have a developer and a technician, start coughing up the cash!
This is why the PLC companies now make each version's file format incompatible with the previous version. They will give a story about how it is necessary to provide better functionality, blah blah blah. It is a load of BS, though, since most times the 'new functionality' is a prettied up UI in the software. Parts of the latest RSLogix release I actually wish I could turn off, but cannot (Anyons from RS listening? I want rid of the little 'helper' box that pops up when I am entering instructions mnemonically. ie: I enter EQU and the yellow box pops up that says EQU SourceA SourceB. Problem is that if I am at the bottom of the window, it covers my text entry window, and I cannot see what I am tryiong to type). But I digress............
The reason for the incompatibility is chiefly to make you upgrade and enhance the revenue stream. If they didn't, most people would skip the 'service contract' and jsut keep what they have for many years. By pricing the cost of the service contract, which includes 'free' (note the
finger-quotes) upgrades at just slightly less than the cost of a whole new package, and then insuring that you 'want' to upgrade once a year (so you can still work on your equipment for another year), they insure a steady income for their software division.
Bob Continues:
> Plant #2: Is using Linux / Open source based PC controls. All the
> I/O
is
> based on Modbus/TCP and other TCP/IP friendly I/O. They are running
kernel
> version 2.0 (an older version) and have not upgraded to the latest
kernel,
> as they had no need.....
>
> Ok. Both plants have a standard. They are both running along just
> fine. In plant 1, if an integrator brings in a new machine, they leave
> all the documentation and disk copies in AI compatible files, so the
> plant does not have to upgrade.
Let's separate the two points. Both of your examples allows the user to manipulate the control elements to do whatever needs doing.
AB will not let you add features and change the core elements of their program by yourself. Linux does allow anyone and everyone knowledgeable enough, to change these core features.
Joe gleefully replies:
Yes! That is a big part of my point. Note that linux does not -require- you to do so, but if I want to write a custom function (similar to what Siemens processors let you do, I believe), my AB system 'just says no'. If I have a unique situation that requires a specially modeled PID loop for example, you sure aren't doing it in an AB processor. Conversely, I can write any special functions I need into a L-PLC implementation and it grows as I need it too. Heck, someone may have already written a better one and felt like sharing it (it isn't required tho).
Bob posits:
> In Plant 2, if an integrator brings in a new machine, they implement
> the controls on Red Hat version 6.1, using kernel ver 2.0, as supplied
> to
them
> by the plant, as their core operating system.
>
> (Curt and others: I am not sure if that is the right kernel rev for
> RH6.1, as I am making this example up as I go)
>
> My questions are:
>
> How is plant 2 in any worse shape than plant 1? Don't they have the
> advantage of knowing that they can give the integrator (legally) a
> copy
of
> their core OS to use as the starting point?
If I were the plant operator, the one who purchases the software and pays your wages, I would be more comfortable with AB over Linux. With AB I am assured of a basic standard of software operation that I know will be the same from the time I purchase it 'till I am convinced to purchase an upgrade. This insures that in my plant's near future I will be protected by a warranty,
Joe cannot help but interrupt:
Warranty?! We don't have no stinkin' warranty! (accent intended). Read carefully what you assume is your warranty from Allen Bradley. They warrant that it won't turn into smoke the first time you plug it in. If you plugged it in, and a day later it turned to smoke, it is your problem. I know this *first hand* on several occaisions. And don't assume that they warrant that the application is appropriate for your system. I would like you to show me what warranty you think you have with their stuff....
Bob continues after the interruption:
I will know that one part of my empire has basically the same infrastructure as the other parts, I can send solutions from one plant area to another without worrying if some eager beaver has changed the infrastructure so that it is no longer compatible. I can hire new employees that will know the AB infrastructure, I can transfer employees, with the assurance that they will not need to spend their time and my money determining how the infrastructure is engineered. All this to keep costs and problems down and production constant.
Joe replies:
In the plant(s) I currently work at, we have defined software version control procedures in place for all control software. This includes ladder files, motion controller configurations, touchscreen program files, etc. Nothing is allowed to be modified without a formal (written) description of the changes required by the process engineers. Once the changes are done, process engineering and equipment engineering get together to run an acceptance test. Upon acceptance, the documentation is updated, the new files are archived and distributed to the technicians file areas so they have the required documentation for troubleshooting, etc.
How would any of this change? Having an Open source based system does not require me to allow operators to hack code in their spare time. Just as I cannot go off and write myself an app that will generate huge levels of network traffic, you would simply make the OS code off limits to anyone developing, and handle required exceptions as needed, if needed at all.
Bob continues:
Another point - If I were a plant operator I would not buy software. I would purchase tools, software tools that you were able to use without adding further expense. I would try to purchase tools that you would not need to take apart and then put back together in order to make it work. I would do my best to buy those tools that don't require further time, effort and my money to make them work.
Joe nods and agrees, so Bob continues on:
Linux is a dream come true for the creative techs who want to solve problems effectively, quickly and by putting a little of themselves into the work.
But - until I, as a plant operator (example only), can be satisfied that my concerns outlined above are satisfied, then I will be extremely reluctant to purchase open source.
Joe interjects:
And that, of course, is the wisest thing to do. There will be a time, though, when the current tool set is inadequte. It is already quite often not real elegant. The question comes down to a cost v. benefits. Will you, as the plant operator, be willing to give your developers the -best- tools, or the tools that can be made to work. If you workers need to pound a nail, and all you have ever bought are wrenches, do you get them a hammer, or tell them to turn their wrench sideways?
Bob again:
> If Rockwell decided that the next version of RSLogix would not be able
> to export files in AI format, and the exact same day, Red Hat
> announced that the distrobution disks for 6.1 were no longer available
> to download from their web site, who got the shaft harder? As
> integrators upgrade their software, isn't plant 1 being pushed into
> upgrading their programming software against their will? Plant 2
> already has all the legal software purchased that they need to (1),
> and if they can't support it, they can still get support from many
> other locations.
>
> I would think that the person in charge of the software platform would
> be cracking open a new roll of Tums on that day.
>
> Don't get me wrong, I am not trying to cheerlead for Linux. I guess I
> am just looking for an example of how it is better to use
proprietarysoftware
> as a means of insuring continuity. I have seen myself that most new
> software releases insure that file formats are incompatable, thus
> forcing the upgrade. If the techs at my remote plants are a rev
> behind, they cannot look at my stuff.
If this is happening purposely, rather than a needed method of making the application better, then it is clearly wrong.
Joe:
I addressed this further up. Suffice to re-iterate that Logix changes file format as often to more often than MS word. No net gain to the end user, but you do have to upgrade your software. Funny how that happens every time. And all they can tell you each time is "Well, we didn't anticipate well enough to make the last version expandable. oops." Funny they never learn, tho.