What the "L"? Shifting PLC to PC

"With the right software" is an extremely important caveat.

Several years ago I designed an industrial food processing machine which used several large, powerful and fast hydraulic actuators. The PLC I chose for the controller was based on Windows CE and I remember being very nervous during initial testing because I had seen Windows crash inexplicably hundreds of times. The idea of thousands of pounds of metal being thrashed around with thousands of pounds of force due to Windows crashing was foremost in my mind. The reason I picked this particular controller was that it could be programmed using flowcharts rather than relay ladder logic and we were on a very tight development schedule. In the end it turned out to be very stable and reliable.

But using Windows XP or Vista for an industrial control application ?

I don't consider them reliable enough.

In general, the machine control and securities must be performed by reliable controllers operating simple operating systems. These cannot be hacked easily and cannot be loaded with garbage applications like a PC can. Having no hard drive, these PLC are usually very reliable and last for 10 to 20 years.

The communication between machines should use a dedicated system not accessible to the outside world. The data transiting on this network should be limited to control functions. Industrial grade equipment is a must. This eliminates any PC.

The over all plant data acquisition can be done using PC based equipment in order to take advantage of the communication facility and fancy data handling. It should never be allowed to interfere with plant operation.

" Are you, in fact, considering changing any of you equipment to PC-based automation?"

My answer is YES. In fact i have started doing this 3 years ago, with Windows 2000 os. Nowadays i'm also realising the same things with W-XP with no harm.

The security considerations will continue being important even for the PLC's because they tend to be fully networked and use ethernet in a growing manner.

PLCs have been imagined 'reliable' because they were working in a local, propriatery network, with an embedded and restricted software. Now PLCs are using more powerful cpus -like pentium4- and have began to import the "PC technologies". With another word, they actually begin to be PC in a different package called industrial.

To form a PC controlled system is very straightforward:

Select one of the industrial communication protocols - modbus, canopen, M-bus,...- which suit your needs, use simple or smart io units or PACs capable with this protocol and an interface for io protocols of PC -USB, RS232, wless..etc- that's all. You can write the control software in any language you know best.

Why do you have to dig the proprietary PLC protocols? They are all different with each other if they are coming different brands. On the other hand you can use the io units in a protocol group, even from different brands!

Using PLCs is a 'habit' coming from old days...Is there a habit that's immutable?

regards

f.h.

Well I tend to disagree with the idea of using a PC in place of a PLC or embedded controller.. I designed a lift controller(embedded) from scratch total power consumption in standby 7 watts and jumps to the motor rating during use+20 watts for lights !!! Beat that PC !!! Total wiring was 4 wires down the shaft Beat that PC !!! Security, well unless you cut into the one of the 4 lines and decode my software you got no chance !! Beat that !! Total up time May 2005 call out(s) 0,break downs/Faults (1) faulty contact switch not the controller .. and the controller told me the switch was sticking !!!

Like to see a PC come close to those up times and power consumptions and faults resolutions, PC are for people, not for safety, you just can not beat a system purely designed for a job, PCs do and will have some automation task but I would be very concerned for a task which safety is No1. or low power applications where standby times are long, and therefore reducing power usage is a key goal.

PCs by nature consume hundreds of Watts just looking pretty, and not actually doing anything. So the answer is chosing a PC is the lazy way (possibly cheap setup) way but longevity and stability(ie software drivers) and identical board replacement a few years down the track maybe end up costing !!!

Hi Guest,

You are right with your reply why i have not explain which way i'm using PC in a control.

I never use a PC instead of embedded controller but as HMI, to readjust the parameters or diagnostics or manuell modes ... etc.

Please take a look at the Staying in Control .

Regards

no way can a PC replace a PLC. First, the PLC has all the I/O cards on a secure buss with expansion for hudreds of I/O cards.

Next the PLC is a hardened board with a watchdog timer that the PC doen't have and you'd need to get hold of that. NOW that said, I've used an Intel 386 and up as the chip in a PLC.

I've used a PC as an HMI since 1992. Because you need real time operations with time interupts, windows doesn't cut it, you'll need a version of UNIX. I used QNX.

Lately, with faster computers, you can get close to realtime and run HMI programs on XP.

Hi vicini,

I'm neither authority about HMIs nor a defender of Windows but i'm applying W-2000 as realtime HMI without any harm for a long time, using syncronisation objects of windows. Usage of unix might be more convenient of course but i have not experienced and have no idea.

regards

i'm not the guru either, so I'm echoing my SCADA engineers. Windows depends on events to interupt the CPU to switch tasks. You can do some clock recording functions to try to timestamp events so the database has to have those functions.

With gigahertz chip speeds, you can very small time lags as compare to the 90 megahertz speeds in the 90's

Thank you vicini,

Knowledge is knowledge. Your eng.s must be aware of somethings those i did not experience of. I agree windows depends on events and i have to use functions that create events really. Seems that i can not observe the difference without using a unix-based os.

Best regards