New forum topic - Open Control

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.
 
M

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
************************
 
<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
 
Yes, Bob, that is a very fair statement of the problem. IMHO, the real issue here is not that Linux is _per se_ so wonderful, but that the proprietary vendors have done such a terrible job of providing quality software, hardware, and support that nearly everybody is angry at them, and would walk if a viable alternative presented itself.

There's lots of other, non-core, stuff here, but that's the basis, yes.

Walt Boyes

---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"

[email protected]
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------
 
C
You are measuring us with their yardstick again. With closed software you have to talk to the authors and bring a Visa card. With Open Source projects the number of folks that can help you out is greatly expanded. And while there is the potential for consulting for the authors, I don't think anyone is depending on your dollars down the road. As the user base expands there will be a community of users that can help each other. It's kinda like this list, you say "how do I do such and such" and other users can help you out. I would say at least in the early stages, there will be a high percentage of users who understand the source as well as the authors. There is no reason not to tell you whatever you want to know. OSS people tend to be eager to help from my experience so far. And the community will be waiting 24x7x365, no credit card needed.

> Open systems are produced on a program today and consult tomorrow model.
> Which is fine. They serve a purpose. For those of us who want to take that
> risk and take the open system as my own. But if I get into trouble and need
> any assistance I have to call the authors where every they may be and pay
> them (sounds like an annuity to me.).

Who has mentioned money?

> Much like hiring the folks at red hat
> to answer my questions about Linux IT technology. This is where I actually
> end up paying for this product. And because the authors do not get paid per
> installation they charge me by the hour. One simple phone call and I can
> exceed the enter cost of a Koyo PLC plus the $500.00 program them all
> software package. The free plc is free if you can get it to work by
> yourself. This is a very large risk to short term (1 month) projects like
> installing production machines.

I have been very impressed with the help I get on OSS projects and I have never been hit up for money, although I did trade a card once to get a driver written. You still don't get it, this is not a business. Most of us have a job we do for money, I do LPLC stuff to accomplish a goal and make the automation world a better place for me and others to work in.

> The Linux RT OS for long term projects like designing a product is awesome.
> But the product designer is still setting up his or her business to take
> tech support calls.
>
> AB, Modicon, GE, Seimens, Automation Direct, all sell logic boxes. There are
> very slight differences between the technologies. But they all have staff
> that backs what they sell. That is the only reason why people buy off the
> shelf PLCs. A free PLC OS cannot stand all by itself to the end user
> market. If people really wanted to make a free PLC they could have bought a
> Z-World controller and programmed the whole thing themselves. Or used open
> DOS with a device net card.

You will have a community that backs you up. And you can back yourself up If it's broken you can fix it. If an executable gets corrupted you can recompile. If software that once worked stops working that should fix it. Hardware problems on PC platforms can be economically fixed by putting the drive in another machine or swapping cards. This is ususally much faster than the commercial alternatives. And no muzak on hold or dialog with someone who asks you how many wires are sticking out the back and tells you you need the latest version.

> On top of it all you have over 100000 sales folks stepping into the design
> meetings every day plugging a product. Having been one I would almost
> guarantee you that the first line out of their mouths will be about the lack
> of tech support for this product.

I agree with this, the loss of control over you scares the hell out of them. But, if you believe everything a salesman says........

The web you say? Who on the web.

The Mat project of course, specifically the users list.

> The people they are selling to do not have vast C programming knowledge and have
> better things on their hands to do then hope someone answers their email for
> free.

Yeah, like hoping you will get a meaningful helpful answer when you pay for it. Instead of "we don't support that version anymore, you need the latest and the 15 in between. What was that Visa number?"

>Finally if the system they selected is not working for their
> application then they go and purchase another one from another vender.
>
> The only thing that can replace the established PLC as a true mass scale
> alternative is another PLC/Automation company.

I think the last thing we need is more functionally identical closed systems.

> So go team FreePLC. Program for us the next gen open logic system. We need
> more competitors. Then maybe someone will box it up and support it with a
> business. I will bet though that after the first 10 calls about how the
> customer hooked up the unit to a 3 phase welding transformer the price will
> go up.

Hardware sales would be enhanced, but I don't see where there would be a software problem.

> Regards all.
>
> Greg Schiller
> Automatica Inc.

Regards

cww
 
M

Michael Griffin

Does that mean 100 systems used in that application, or does it mean 100 systems used anywhere in any application? If the latter (used in any application), then that isn't really very restrictive at all. Virtually any off the shelf product could meet that criteria.

If the former meaning is intended (used in that application), then no system would meet the exempt criteria, as there would always be that first system which must be audited.
The "identical configurations" clause would seem to imply that a major software upgrade (e.g., new OS version) would require re-certification. There could be as much or more difference between successive versions of the same system as there is between alternative systems, so an "upgrade" of a commercial product could not be reasonably exempted until it meets the "100 systems in use" criteria.

I suspect that the criteria you mention is intended to ensure that custom code is audited, and also that new versions of commercial products are avoided until other people have had a chance to find the bugs. Is this the case?


--

************************
Michael Griffin
London, Ont. Canada
************************
 
C
> Open source, Linux in this case, doesn't make an integrator feel as if
> they have been unduly or unnecessarily charged for features added after
> purchase. (I'm not very clear why this is a problem. You as system
> integrators merely pass this cost on to your clients, if they, your
> clients, want these extra features. If you want them, at your direct cost,
> it must be because you think these features will save time and/or effort.
> When I was in the business, software and hardware were fused, what we
> purchased for the project would last for years, regardless what the vendor
> did with that software.)

Or you can do the work and keep the money yourself and your customer will be happy that you are passing much less cost along to them. Taking the vendor out of the equation should mean more money for the integrator.

> One vendor's proprietary software does not play well with others. Linux
> doesn't have this problem, because you can change the infrastructure to
> accommodate mixing of systems.(This may be my answer to the above
> question.)

And you can change or add those little things that the customer decides they want and it's all billable time.

> Both, Linux and proprietary software, allow the user unlimited access to
> the elements that make up the control solutions.

And the user can potentially add elements or write around those roadblocks that appear. It depends on who user is.

> Is this a reasonable summary? If so it appears to me that, other than the
> comfort level of having direct control over the software, exercised or
> not, the real problem I have been hearing is a vendor problem, not
> necessarily a proprietary versus open source problem as such. Except, of
> course for the run time costs.

Pretty much so, except that the flexibility is worth a lot more. It solves a lot of problems that relate to how the business is done now. And the costs can be dramatically lower as many things that sell bridges adapters, basic modules, etc. can be done in software. And you can simply do more and say yes more often.

> Is this a fair statement?

As I said, It's a much more powerful tool for building solutions.

Regards

cww
 
C
I would hope they get just a little madder and help us provide a viable alternative. We can code as time allows and advocate, but the real key to having a viable alternative is for people to accept that this is to their advantage and get beyond "wait and see" to actually making it happen. It clearly can be done, and the objections about support, momentum, installed base and confidence are all easily and obviously evercome by a vibrant and enthusiastic user community. The critical path to this objective can only be met by folks reading this. Nothing on our part can take the place of this community. With enough push, just a little from a lot of people, no roadblock is insurmountable.

Regards

cww
 
Are you also thinking that this thread has gone a different direction than Ken might have thought??

Bob
 
G
The Control.com website describes them as "The company whose goal is to make "open" a reality for industrial control and automation," so I
imagine that Ken and his colleagues are particularly interested in what A-List participants (i.e. the automation marketplace) have to say about the requirements for acceptance of solutions based on Open Source components.

Greg Goodman
Chiron Consulting
 
Greg Schiller:
> The key difference between what is being said about being responsible for
> the system working is they guys who sold me commercial technology are
> doing their best effort to make sure I buy their services again.
...
> They have to much like if I push the FreePLC technology past its window.
> I have to call its authors and pay money to talk.

Of you can call someone else and pay money to talk. Competition (generally) lowers prices. That's an important difference.

Another important difference is that these would be competing on tech support directly. This contrasts with commercial vendors, where tech support is not a profit center and therefore tends to be somewhat poor.

> On top of it all you have over 100000 sales folks stepping into the
> design meetings every day plugging a product. Having been one I would
> almost guarantee you that the first line out of their mouths will be
> about the lack of tech support for this product.
...
> Finally if the system they selected is not working for their application
> then they go and purchase another one from another vender.

They can go and purchase just the support from another vendor. Typically, this will be a much smaller disruption than switching between PLC makers, because the existing investment can continue to be used, both hardware and software.

Obviously, if the whole product ain't working and can't be made to work, they'll have to go through the pain of switching to another PLC vendor. Even there the FreePLC will have an advantage in that interoperability with other vendors is a priority rather than a grudging afterthought.

> So go team FreePLC. Program for us the next gen open logic system. We
> need more competitors. Then maybe someone will box it up and support it
> with a business.

Yup - we hope so.

> I will bet though that after the first 10 calls about how the customer
> hooked up the unit to a 3 phase welding transformer the price will go up.

Not sure how this follows - I've yet to hear of any commercial vendor that would take any action on this beyond adding it to the fortune cookie file.

Replace the hardware, load the same software. No problem.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
I
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
 
Top