Warnings and/or Advice Needed

First some backround, I have been working for my company for 10 years. I do 99% of the PLC/HMI programming, all of our 50+ PLC's are Allen Bradley PLC 5, SLC 500's, and micrologix. All HMI's are Allen Bradley DTAM's and Panelviews. All of our maintenance people have at least some formal PLC training from Rockwell Automation. We have 5 production lines all operating under PLC control and have little or no problems with any of them. We maintain a Rockwell Automation support contract and always have the latest software versions. Starting next year we are going to be installing a new production line that will be computer based, logic for controlling the line will be written in C++, any HMI's applications will be written in Visual Basic. I have LIMITED experience with National Instruments and opto 22 interface hardware and labview software and from what I've seen try and stay as far away from them as possible. Nobody here is trained on C++ or Visual Basic and there are no plans to train anyone.
Now the question: Does anyone have any advice on what I might encounter, problems we may run into, or solutions to offer that may keep me from pulling my hair out till I'm bald? Anyone out there go through a transition like I've described?
Thanks in advance for any replies.

Well I can assure you Opto22 is about as similar to AB as Carrots are to elephants.


Opto runs on a flow chart type code and its pretty much an empty box when you get it, nothing comes 'canned'.
Also it doesnt support online editing.....

I would try and get a complete setup to mess with way up front and find the functional limitations of this new equipment.
Apart from that its just going to be a hard slog until your up to speed.

I don't know if they are going to using Opto 22 or National Instruments equipment, they haven't told use what they are planning to use. In fact, they told us at one planning meeting that they were NOT going to supply us with a copy of the uncompiled source code to even be able to have a chance at being able to figure anything out logic wise. Also we were told that at the first sign of trouble with the production line that we should reboot the computer (production loss while it's rebooting) or if that doesn't work, replace the computers hard drive of which we have purchased a spare and have on hand. Just wondering if others with simular experience could share anything with me.

vettedrivr said:

Starting next year we are going to be installing a new production line that will be computer based, logic for controlling the line will be written in C++, any HMI's applications will be written in Visual Basic. I have LIMITED experience with National Instruments and opto 22 interface hardware and labview software and from what I've seen try and stay as far away from them as possible. Nobody here is trained on C++ or Visual Basic and there are no plans to train anyone.
Now the question: Does anyone have any advice on what I might encounter, problems we may run into, or solutions to offer that may keep me from pulling my hair out till I'm bald? Anyone out there go through a transition like I've described?
Thanks in advance for any replies.

Click to expand...

Why are you getting a new production line with these features if you don't want them?

vettedrivr said:

I don't know if they are going to using Opto 22 or National Instruments equipment, they haven't told use what they are planning to use. In fact, they told us at one planning meeting that they were NOT going to supply us with a copy of the uncompiled source code to even be able to have a chance at being able to figure anything out logic wise. Also we were told that at the first sign of trouble with the production line that we should reboot the computer (production loss while it's rebooting) or if that doesn't work, replace the computers hard drive of which we have purchased a spare and have on hand. Just wondering if others with simular experience could share anything with me.

Click to expand...

RUN AWAY!!!!!!!!!!!!!!!!!!!!!!!

Is this some sort of a corporate mandate that it will be done this way, or is it the vendor telling you how it'll be done?

If it's the vendor telling you, then the cart is driving the horse. You should be telling the vendor how to build your machines -- that it WILL be PLC controlled, that you WILL get both a digital and hardcopy of the programs, etc.

vettedrivr said:

First some backround, I have been working for my company for 10 years. I do 99% of the PLC/HMI programming, all of our 50+ PLC's are Allen Bradley PLC 5, SLC 500's, and micrologix. All HMI's are Allen Bradley DTAM's and Panelviews. All of our maintenance people have at least some formal PLC training from Rockwell Automation. We have 5 production lines all operating under PLC control and have little or no problems with any of them. We maintain a Rockwell Automation support contract and always have the latest software versions. Starting next year we are going to be installing a new production line that will be computer based, logic for controlling the line will be written in C++, any HMI's applications will be written in Visual Basic. I have LIMITED experience with National Instruments and opto 22 interface hardware and labview software and from what I've seen try and stay as far away from them as possible. Nobody here is trained on C++ or Visual Basic and there are no plans to train anyone.
Now the question: Does anyone have any advice on what I might encounter, problems we may run into, or solutions to offer that may keep me from pulling my hair out till I'm bald? Anyone out there go through a transition like I've described?
Thanks in advance for any replies.

Click to expand...

Good luck trying to troubleshoot or maintain the controls or HMI. Probably 99.9% of issues will have to be resolved by the original supplier, and any further updates will have to come from them as well. As long as management is happy to be held ransom by an OEM, then go ahead.

One of the selling points we tell our cutsomers, "We use off the shelf components, and off the shelf HMI or SCADA software, that any PLC integrator, or maintenance staff, can maintain after we leave.."

Sounds great to me. If rebooting it doesn't work then just walk away from it and tell the production manager to call the OEM and cut them a purchase order, no added work for you at all.In reality it probably won't work that way and you'll be expected to fix it and probably won't have a clue what you are doing. If the HMI diagnostics are perfect enough that you never need to see the code then you might be OK, I have yet to work on a mahine that was that good. I know a few around here will argue that theirs are and maybe they are, I've just never had the pleasure of working on one. Unless the company you are dealing with has built a lot of these machines there diagnostics won't be perfect either.

vettedrivr said:

I don't know if they are going to using Opto 22 or National Instruments equipment, they haven't told use what they are planning to use. In fact, they told us at one planning meeting that they were NOT going to supply us with a copy of the uncompiled source code to even be able to have a chance at being able to figure anything out logic wise. Also we were told that at the first sign of trouble with the production line that we should reboot the computer (production loss while it's rebooting) or if that doesn't work, replace the computers hard drive of which we have purchased a spare and have on hand. Just wondering if others with simular experience could share anything with me.

Click to expand...

Oh dear..




This is what you will need...






and plenty of them.


I wonder if the 'intelligent' person making the decisions will take responsibility for it, when it breaks down (of course not).


I bet the vendor is rubbing their hands together with glee at the maintenance contract possibilities.

Origianlly posted by OZEE:

If it's the vendor telling you, then the cart is driving the horse. You should be telling the vendor how to build your machines...

Click to expand...

Just like you tell GM what engine control system you want on your vehicles, right? You can have a vehicle custom made to your specifications. But it won't be at the cost of an off-the-shelf GM model. (Sorry, I don't intend top pick on GM specifically)

It is reasonbable to assume that the machine was originally chosen based on some price/performance evaluation. The machine can do more of what you want for less money. Usually the 'less money' part is because the machine is a cookie-cutter legacy design. The manufacturer has had time to wring every dime out of the design. They also have a great deal of confidence in their software as they software has a large amount of diverse runtime on it. Because of this they tend to be very reluctant to change the machine in any meaningful way. The question is will the price/performance benefit be outweighed by the inability to perform modifications yourself?

We haven't been told what the control system generates for diagnostics and status information. We are all assuming that we need the development software in order to figure out what is wrong with the machine. Is that necessarily true? If the control system is designed to be self-diagnosing then it isn't as big a deal.

I work for a custom machinery OEM. We release everything about our machines to our customers. We make the machines exactly the way the customer wants it. However, we can't compete with the cookie-cutter crowd based strictly on price/performance. So our customers have to constantly weigh whether having it there way justifies the added (sometimes significant) cost. The funny thing is that often the customer often goes with us not because of better performance but simply because they can have it their way even if the set-in-stone way would work just as well. You've got to love human nature.

As to the original post, I buy computers and software every day. I can't substancially modify either. That doesn't mean I won't buy them. Just make sure you are buying from a reputable supplier with a good track record. If this is a ground-up custom design already then I would push much harder for having it your way.

Keith

How it all came about. New (Another) production line needed because business is going great. Our engineers (no engineering degree necessary) looked for an outside company to give us a production line with pie in the sky ideas (RFID, product tracking, ect). Outside vendor says "This is what you need". It needs to be computer based because 1) computers are faster. 2) computers have more memory. 3) computers are cheaper than PLC's. Vendor makes presentation to management. Management buys into it hook, line and sinker. Argument for PLC control and against computer control falls on deaf ears. Yours truely is going to be the one stuck in the middle when this thing goes down.

I guess one of the main benifits of controling your system with PLCs is for reliablity. If you company is not concerned with reliability or production than controlling via computers may be a good idea.
Also some other concerns are that computer software needs upgrading and / or patches. These patches and upgrades are normally done during the night. Who would be using their computers during the middle of the night? AFter some upgrades the computers must be rebooted. This may not be a good idea to reboot the computers at random times. Maybe these upgrades can be scheduled for sometime when the line is shutdown for maintenance.

During our last major upgrade of one of our areas with Control Logix processors, the engineering firm which wrote the logic seemed to think we could treat the controllers and logic as black boxes. Once commissioned, we wouldn't need to touch them or need to change any logic.

It didn't happen quite that way. Luckily our shift personnel are confident with control logic processors.

One of the things I would do if you cannot change their minds is:
Ensure you get the source code for all logic. I would want the initial source code, and as the revisions change you shoud be provided with the latest copy.

Also the expensive PLC's are what keep the process running when the computers running HMI's are being rebooted.

Kim

Kamenges,

To follow your analogy, I am fully able to go to my local GM dealer and spec out a new car, telling them exactly which engine, transmission, seat, sound-system, etc.... that I want -- and they will deliver it that way. Yes, it'll cost a little bit more, but if that's what I want and am willing to pay for it, it's fine.

I can spec the engine, but not dictate to them how to make the engine. In vettedrivr's example, his system is "the car". He needs to be able to order it so it's most maintainable -- downtime is real $$$$. Just like I would never try to tell GM how to build their engine, I would never try to tell AB how to build their ControlLogix processor. But I can tell them to put in a Duramax diesel instead of a 350 if that's what I need. When I spec out a machine in my current job, I tell the vendor what the PLC will be. If they need to include an adder to give me that PLC, that's fine, but it will be included in the final decision. They will build the machine according to my specs or they won't get the job.

I will grant you this, though... most of the systems that I am buying are all one-off's. Very few cookie-cutters here. But I want as few custom, proprietary control systems as possible. It makes my life soooooooo much easier if I can have COTS (Commercial Off The Shelf) control components -- especially when something lays down and dies in the middle of the night.

Vettedrivr -- unfortunately, this is the kind of decision that ends up being made when the vendors start dealing directly with management instead of engineering/production. I could have just about written your description for you -- been there, done that, got the t-shirt...

SLC_Integrator said:

...Opto runs on a flow chart type code and its pretty much an empty box when you get it, nothing comes 'canned'. Also it doesn't support online editing...

Click to expand...

I assume Labview will be the main control system, not Opto22's PAC's. The Opto22 he mentions is just SSR modules, i.e., dumb I/O racks (look at Opto's Legacy stuff). The National Instruments cards will plug into the PC buss, and talk to the Opto modules.

While I agree with others that the PLC setup you have is better, I'm not that biased against the new setup. National and Labview have a place in the world, and have gotten better over the years.

At least have someone consider Industrial PC's, and UPS.
I doubt that you'll need to get into the C++ or VB code. That's for the networking, recipe editing, data logging, etc.

Your machine control will be under Labview. Learn that part. Labview is a high level language with icons. Another graphical type programming interface. Once you get the feel for it, you'll find it's quite easy to learn.

But OZEE, what if I like the Dodge Cummins turbodiesel better than the Duramax? Then it's not GM doing the change for a $5000 adder. It's Jesse James and the guys at Monster Garage doing it for $50,000. Any given option is only a reasonable option if it is already developed and offered. I'm sure the Cummins would fit in the hole left by the Duramax. But there would be some significant development time in getting everything to fit and interface.

The same is true of control systems. Most general machine control tasks can be done on most any of the existing control platforms. However, if I have the code written, developed and debugged and the electrical design completed for a specific control platform, changing platforms will cost money on several levels.

As you said, if you are willing to pay for the change, that's your choice. And I am all for having it your way. Ultimately the end user has to live with it. However, to infer that the OEM is being unreasonable for not wanting to change platforms is a bit unreasonable in it's own right.

vettedrivr, did the OEM say they wouldn't change control platforms at all or they wouldn't change control platforms and still honor the original price? There is a significant difference between those two stances. Almost anything that can be done in a PC alone can be done with dedicated purpose devices (plcs, motion controllers, etc) with a PC over the top. Maybe you just need to bang on your people internally to pony up some cash to get what you want.

Keith

kamenges said:

But OZEE, what if I like the Dodge Cummins turbodiesel better than the Duramax? Then it's not GM doing the change for a $5000 adder. It's Jesse James and the guys at Monster Garage doing it for $50,000. Any given option is only a reasonable option if it is already developed and offered. I'm sure the Cummins would fit in the hole left by the Duramax. But there would be some significant development time in getting everything to fit and interface.

Click to expand...

If GM won't give me the Cummins, then I call the Dodge dealer who will! If GM won't play my game, they won't get my business... And if I need to call Jesse James, so be it.

The same is true of control systems. Most general machine control tasks can be done on most any of the existing control platforms. However, if I have the code written, developed and debugged and the electrical design completed for a specific control platform, changing platforms will cost money on several levels.

Click to expand...

Custom proprietary hardware in an industrial environment will eventually lead to expensive downtime. I don't know about your environment, but in mine, downtime waiting either for the OEM to show up to fix the problem or for parts to show up will very quickly pay for the adder to get the controls that I want.

...However, to infer that the OEM is being unreasonable for not wanting to change platforms is a bit unreasonable in it's own right.

Click to expand...

I guess that's the beauty of the open market. If I don't want to business with that OEM, then I ~should~ be free to go somewhere else. And if the rest of the market follows me, then said-OEM goes out of business.

vettedrivr, did the OEM say they wouldn't change control platforms at all or they wouldn't change control platforms and still honor the original price? There is a significant difference between those two stances. Almost anything that can be done in a PC alone can be done with dedicated purpose devices (plcs, motion controllers, etc) with a PC over the top. Maybe you just need to bang on your people internally to pony up some cash to get what you want.

Keith

Click to expand...

And FWIW, I'm NOT putting any control on a PC. A Windows-based PC is way to unreliable for a 7/24/365 manufacturing environment.