|
|
Applications -
Automation Business -
Communications -
Engineering Practices -
HMI -
Information Resources -
LinuxPLC Project -
Motion Control -
Open Control -
PCs in Automation -
Plant Networking -
PLCs -
Programming Languages -
Process Control -
Sensors -
Software
Re: New forum topic - Open Control
Feb 14, 2002 5:10 pm, by Bob Pawley
Text :
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
> Hey Bob, thanks for the reply ( again :^} )
>
> 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??
> 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.
> 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, 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.
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.
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.
> 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.
> Maybe the best way for you to reply would be to do the above, but give an
> example of the two plants illustrating the problem of the open source
> solution. I guess I just feel that since the plant is able to say "Use
> this disk as the core OS of the control" in the same way that they tell
> integrators "Use Allen Bradley SLC 5/04 processors as the core processorof
> the control", doesn't having the ability to reuse it endlessly without
> possibility of discontinuation a benefit?
>
> Thanks. Hope to hear back soon!!!!!
>
>
> --Joe Jansen
Reply
Re: New forum topic - Open Control
Feb 19, 2002 12:23 pm, by 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.
Reply
Re: New forum topic - Open Control
Dec 19, 2005 11:45 pm, by Irl Johnson
Hello,
There is another way to bring all your software packages togather, Citect\SCADA.
It works with tags\address\ very easy to learn and do.
Irl Johnson
Reply
Re: New forum topic - Open Control
Feb 19, 2002 12:29 pm, by Bob Welker
<snip>
>>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.
<<
<snip>
Not only that (which is annoying enough) but, and I guess this depends on what version of RSL created the ladder file, but an older version of RSL reading a later version file typically causes my computer to crash.
Which prompts me to wonder ... how hard would it be to preface the file with a data block describing which version created it?
That way, RSL would see immediately that it might not be able to digest the data, and give a relevant error message (i.e. - "Look, Tightwad, Upgrade now to RSL vx.xx. The data file was created with RSL vx.xx, and RSL version y.yy you are now using may cause the computer to crash if I read it").
A question comes to mind as well. Has anybody run into the situation where the latest and greatest version cannot read files created with a previous
version?
Bob
Reply
New forum topic - Open Control
Feb 19, 2002 12:26 pm, by Michael Griffin
My own impression of the reason behind this problem (and it is a serious one) is a bit different from yours. I did some investigation (telephone calls, etc.) for why a certain PLC's software was not able to accept files from versions with trivial differences (no changes which would affect the PLC or the code it received). The conclusion that I reached was that it was due to laziness and stupidity rather than greed and malice.
I spoke to certain people in the company's marketting department, and they
were at least as unhappy about the situation as I was. The story they were receiving from their software developers was that it was all necessary because the PLC used "compiled instead of interpreted code". Since the programming software is dealing with a source code file, this was self evident nonsense. The real reason was more like "I can't be bothered with what customers want, this was easier for me, go away".
I have been getting the impression lately (and not just with this situation) that there has been an influx of programming and software design staff with little or no experience with what customers in industry really need. They've produced some very flashy Windows programs without the functionality or balance of features which existed in their DOS predecessors.
Some of these programs are almost unusable unless you are sitting at a desk with a large monitor and a mouse. I have a hundred tool bars with fancy graphics, but my program is squished down into a tiny corner of my screen when I'm out on the plant floor. Have the people who dream these things up ever used them in real life?
The situation seems to be improving, but I have to wonder why these companies had to learn the same lessons over again which they had apparently forgot from their earlier days.
I found a way of dealing with the file compatability problem on a short term basis though. I was able to export the file in ASCII format, and import it again into the older version. The software had no problems with this - as it obviously shouldn't since it is dealing with identical instructions in either case. So the question arises - why couldn't I do this directly?
--
************************
Michael Griffin
London, Ont. Canada
************************
Reply
Re: New forum topic - Open Control
Feb 17, 2002 1:54 pm, by Michael Griffin
<clip>
> 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 is based on the assumption that "EPROMS don't change". There are two
problems with this argument. The first problem is that if EPROMs can't be changed, then they won't change if you have open source or proprietary software.
The second problem is that a lot of newer proprietary systems are built with flash EPROM. If you use a newer version of programming software (or an integrator or one of his subcontractors does), the programming software may download a new firmware revision into the hardware. It may even do this without telling you what it is doing (you just notice that the program download is taking longer than normal).
Some newer proprietary hardware is being shipped with nothing loaded into the firmware except a simple loader. The version of firmware which ends up in it depends upon what was on the hard drive of the computer used to program it. You could buy two identical pieces of hardware, but end up with different firmware in them when you download your applications.
This of course doesn't deal with the question of new equipment or repairs. If you order a new PLC this year, it isn't going to come with the same firmware as the one you bought a year ago. The manufacturer will likely have fixed bugs and added new features.
Even having conventional EPROMs doesn't guarranty that they are stock parts. We have stuff (not PLCs though) with custom EPROMs. All we had to do was to supply the manufacturer with a spec for the modifications we needed. There is nothing to stop one of your employees from doing the same thing.
Given the above, I am not sure why you feel that buying AB hardware will result in the "fundamental features" of the hardware being identical. You might argue that AB sells very good hardware, but that is another issue (and
another topic) altogether.
> This insures that in my plant's near future I will be protected by
> a warranty, 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.
Your warranty with any control hardware manufacturer will be limited at most to the return of any non-functional hardware or software. They aren't going to "protect" you from any other consequences of changes they make to their product line. It would be unreasonable to expect them to do so.
> 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.
This is training, not open source versus closed. You can hire new employees who have worked with AB's hardware before because there is so much of it already in use elsewhere. However, if AB were to introduce a new product
which was unrelated to any of their existing product lines, your argument would not be valid.
> 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.
Have you had any luck with this? I'm sure a lot of people would like to know where to buy software that works the way it is supposed to. I've spent far too much time and money on the usual kind, and there doesn't seem to be much correlation between the price of the software and the quality of the product.
> 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.
<clip>
I think your last sentence is pretty close to your real reasons. The real issue for you is that you are pretty happy with what you have been getting from AB, and don't feel any compelling reason to change. No doubt you have bigger problems to worry about than any that AB has been giving you.
However, let me ask you a question. If AB introduced a new product that used a Linux operating system, would you consider buying it? If all their new operator interface terminals used "Rockwell Linux" to host the application, would you then switch to a different brand of hardware to avoid it?
--
************************
Michael Griffin
London, Ont. Canada
************************
Reply
|
