|
|
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 19, 2002 12:23 pm, by Joe Jansen/ENGR/HQ/KEMET/US
Text :
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
|