I work on control systems where I have a PLC to handle control functions and a PC running Wonderware acting as an HMI and collecting historical data. Some of my data (tension, temperature, and drive speeds) comes directly into the PC via serial comms (RS232 or RS485, ASCII or Modbus protocol). The rest of my data (air flow, differential pressure) comes in as 4-20ma signals into analog input cards on the PLC. The PC reads this data as integers in the PLC, scales it, and saves it to the database.

I've received a "Request for Quotation" from a potential customer, and they prefer to have all data brought into the PLC. Is this generally preferred? The only experience I've had doing serial comms with a PLC was with Allen-Bradley PLC's. I found their serial interface modules very inflexible and difficult to work with compared to handling serial comms in a PC. I was wondering if it might be easier to do with other brands of PLC's. I suppose I can try to find tension, temperature, and tension controllers that have a 4-20ma output corresponding to the process value. I'm not anxious to do this because I'm already familiar with the controllers that I use and I know they work. I'm leaning towards arguing that in this case, it just doesn't make sense to bring this data into the PLC just to get it into the PC anyway. If anyone has any input or advice, I'd really appreciate it.

Thanks,
Paul

 

I would politely argue the case. Point out the positives of lower developement costs, less time, less hardware costs, ect.

It also would depend on the amount of data and the required logging rate they may have so leave yourself an opening so you do not lose the bid.

David Gulick

 

Dear Paul,

You are right, PLCs are not dataloggers. This must be done by Wonderware InSQL or some equivalent products. The PLC is only a gateway between your field instruments and the logger PC. In the case that you have a huge process area, I strongly advice to use some big capacity CPU, which works like "store and forward" to the PC's database.

My experience is with instruments, which originally was equipped with 4-20 mA transmitter outputs, but we decided to use a more intelligent way. We changed the instrument's transmitter to Profibus-DP communication. From this point not only one data can be read from one device, also you can control it through the bus.

Finally, the Profibus-DP was connected to a Modicon Quantum controller with Profibus-DP master card (you can use also Premium or Siemens S7 controllers with PB-DP extension). All datas were polled by normal Ethernet TCP/IP connection from the controllers into the huge InSQL databases.

Now we can extend easily the instruments networx, because of flexibility of Profibus-DP capabilities and the memory availability and processing speed of the Quantum controllers. Also we made trial with AB, but the Profibus-DP is not their strength, also the RSLINX caused many traffic jam on the Network, because of their "strange" IP protocol, that's why we cancelled this PLC. Not easy to understand their protocols....

Good luck.

 

For me, the only advantage to bring all information to PLC first is in case you want to implement some PLC process logic involving this information. If it is analysis information only, i don't see any advantages...

 

Hello

I guess I always try to use 4-20 mA signals instead of serial data. The main reason is reliability. RS232 is not that reliable and loosing your comm means losing all your data. Once the data are into the PLC, transfer to the supervision is a system feature. As a rule of thumb, we never (well at least we try...) make ouselves what the system does, especially communications. Let the system dot it, it surely loves to do this boring task...

Another reason is that if your customer changes his mind (and I'm pretty sure he will...) and want to use the speed data into the PLC program, you will have to redesign your program. Not a good point... for you as designer. Another reason. We are using an historian to store data on a long term basis. To increase reliability, this is another computer (with a so small price tag for a PC, this is not luxury). So if you loose your connection to the PC used for supervision, you don't lose data...

Finally, we experience some very-hard-to-debug problems when we loaded some PLCs with too much serial comm... So basically I try to avoid this as much as I can and I reserve these comm. for things I cannot do in another way (as, for example, connecting a local HMI).

My two cents

Thierry

 

I actually prefer that the PLC be the coordinator of data. Afterall, the PLC usually controls functions based on the data. The personal computer is purely for supervisory control and/or data acquisition (SCADA) and should not generally be used to control anything, especially if it is critical. If the PC were to fail, the PLC would still function and the process will not have a critical failure. This also makes it a single-point connection to the PC which reduces the drivers, connections, etc. for the PC.

 

PS: You can read devices from the PLC with Modbus, not just the analog 4-20mA inputs.

 

If you really prefer working strictly in a serial environment, there are inexpensive I/O modules that convert 4-20mA to either Modbus 485 or Modbus/TCP. Then everything is serial.

I'd recommend spending what it takes to get isolated inputs on I/O modules or you'll have headaches you wish you didn't.

Sometimes users object to serial because they're electrician's can not troubleshoot it like they can troubleshoot 4-20 with a Fluke meter. But with your expertise with serial comm it's worth the shot.

Bud

 

If your customer sees the Data Acquisition as information needed for control, I can definitely see why they want it in the PLC. As a solid-state device, it garners a larger sense of confidence that a WIN-Tel PC with moving parts and 'delicate' OS structures. Combine that with weak IT departments, and most small to medium sized manufacturing facilities like their production systems relying on solutions just designed for that purpose--some people now call that "Lean Manufacturing" and the only way to revive USA manufacturing. I had a particular customer who used a RS-View32 SCADA combined with a Modicon Quantum PLC. He read Toledo load-cells with the SCADA and passed the information to the PLC for batch control. They added Power Monitoring COMMs (GE-Multilin) to the SCADA PC, which it then conflicted with A|B's RS-Linx OPC driver. Consequently, he lost a complete day of production because the SCADA had to be completely re-installed! To make a long story short, we enabled the ASCII COMMs capability of the Quantum (Toledo), configured ModBus RS-485 ports (Multilin), and installed a WEB-Enabled module that replaced the entire SCADA. The latter is an entirely different conversation because their operators and maintenance guys now control and supervise their system through WEB-Browsers. Just a small example of PLCs equipped with universal serial ports. Ports that that you can PROGRAMMATICALLY take complete control of and generate easy ModBus and/or ASCII communications. Some systems even allow you to do these simultaneously! This might explain your 'issues' with A|B. In danger of stating the obvious, pay attention to your customer 'cause he might be on the right track!!

 

It is a matter of data resolution and stability.

With analog 4-20ma signals and A/D converters you would be lucky to get 12-bit resolution and A/D drift means you have to calibrate often if you wanted any kind of accuracy.

Serial can be 64-bit resolution (size of the data packet) and no A/Ds are involved.

Some people think PLCs are God's gift to control engineers.

Hope this helps,
Warren.
www.pc-pid.com
"the PC-based PID control people"

 

If any of the data you bring into the PC is used for actual control, they would be quite correct in wanting it to be read and acted on by the PLC. That way when Wonderware blue screens, the plant doesn't shut down or blow up. This is certainly to be preferred. If you propose that a Windows box do the actual control, I think you will be at odds with your (wise) customer. If it is only for recording or display purposes, you should be able to make a case. In any case 4-20 ma. would probably be faster to bring up and might even be cheaper than doing a lot of serial comms with a PLC. You would probably have to venture into a multidrop setup as most PLCs don't handle too many individual serial ports. Comms are one of their deficiencies.

Disclaimer: this comes from a staunch proponent of PC control, just not under Windows. All of the PC control projects I've done would be done with PLCs if Windows was the alternative.

Regards

cww

 

Warren you point absolutely does not make a sense. In order to measure analog signal you do need A/D converter.

Serial 64 bits means nothing, it all depends on quality of A/D converter. You can make 64 bit out of 4 bit result if you want it is still 4 bit precision.

 

1) if the PC is getting RS-232 or RS-485 data, it has been converted from a analog signal (either voltage or current) to a digital word or x # of bits - i.e. 8 bit, 16 bit, 32 bit or 64 bit word. The amount of bits do not tell you anything regadring the overall accuracy of the data.

2) given today's outstanding advances in A/Ds, you will probably never see the types of errors you mentioned unless you attempting to use the A/D at the very lowest level of resolution, say the last 2 or 3 LSBs. (Unlikely given your applications)

3) Even you wanted to take a 0-5 volt signal and send it serially, you will still have to use a A/D, plus a serail communications device to send the data, you have not addressed the issue of protocol, you have only output a serial data stream.

4) Since your using a front end like Wonderware, the AB will communicate Modbus or even native DH+ to this program, exactly what is the problem?

5) The controllers or PLCs are converting the millivolt, voltage or current signals to a RS-232 or RS-485 data packet and utilize some native WonderWare driver for communications or Modbus protocol.

Besides your already using a PLC to get the other data, what is the big deal???

Regards

Technical Consultants
[email protected]

 

Excuse me, but the analog data must be converted to digital before it is sent out any type of communications port. There are plenty of very fast, high end, 16 bit A/D's out there that can be used to provide 64 bit (multiple word ) data conversions and you lose very little in the way of data resolution. Point is, there is no way to put pure analog data into a serial port without doing a A/D function first.

I also do not know of any off the shelf product that will produce a 64 bit word for a 4-20ma, 0-5 volt or 0-1 millivolt input signal. Though the data packet may be 64 bits, it is not likely it is all data, header, start of frame, end of frame, stop bit, etc. all take up bits in that 64 bit word and most communications protocols work around a 8N1 configuration. Unless your doing all the comms drivers and port configurations yourself your point is well - off the mark.

mjh

 

It is a matter of data resolution and stability.

With analog 4-20ma signals and A/D converters you would be lucky to get 12-bit resolution and A/D drift means you have to calibrate often if you wanted any kind of accuracy.

Serial can be 64-bit resolution (size of the data packet) and no A/Ds are involved.

Some people think PLCs are God's gift to control engineers.

Hope this helps,
Warren
http://www.pc-pid.com
"the PC-based PID control people"

 

If you want to connect multiple serial devices to a PLC, I suggest the Fatek FBs PLC (http://www.fatek.com / http://www.oakes.com.au). It can expand to 4 serial ports (RS232/RS485) in addition to a USB programming port. This would allow you to read data from all the devices. You can use either ASCII protocol, or Modbus Master functions within the PLC to poll the other devices. It is very flexible and is the only PLC I know of with this functionality. Furthermore, there is a free DDE software package that would work well with Wonderware.

 

I've been using Think & Do under Win2000 (PC control) in 4 of our plants for over five years. I've found it to be reliable and cost effective. One of our goals in selecting this package, was our decision to no longer implement proprietary control busses. All of our control takes place over a dedicated ethernet bus. The "Control" bus is seperate and isolated from the "Administrative" bus.

We bring in many "serial" sensors via "Serial over TCP/IP". I've found this to be satisfactory and reliable.

In our applications, I have not found a need to do any A/D conversion with greater accuracy than the 12 bits offered by the less expensive components. 12 bits equals one part in 4095.

John

 

If you are using Fatek PLC, take further advanteges from the existing OPC Server Fatek for this device. Licence costs just 99 EUR and you can configure it for multiple Fatek stations.

Jaromir