Your experience with MODBUS field I/O? (IE, Wago 750)

[Brandon_K]

For whatever reason, I've always been a "sensor straight to the cabinet" kind of guy. It "just works", it's easy to troubleshoot, you never have communications issues, but comes with a list of cons.

I'm at the point where we're designing rooms (we do escape games) that are larger than we've dealt with in the past and M12 cable set lengths are becoming an issue. On top of that, our rooms are becoming increasingly complex which means more sensors, lights, switches etc, so bundles of M12 cables are getting big, requiring more room in the panel, larger wire duct and so on.

I've been looking into remote field I/O. The easiest solution for me would be to use a remote Productivity 2000 rack using the remote CPU, but for numerous reasons this isn't the best solution.

Right now I'm looking at the Protos X line from Automation Direct, both in MODBUS TCP and RTU flavors. I have plenty of background with networks, but for some reason I've never trusted serial or TCP connectivity with PLC's, it's just "wrong" in my head for some reason that I have no basis to feel that way on. I like knowing everything is powered from the panel and I'm not at the mercy of a switch dying or a network config changing, but at the same time, I need to find a better solution than what I'm doing now.

I'm also looking at the ADAM line from Advantech.

This all stemmed from a build we're doing for a client, two motion simulator elevators. Just the indicator panels, buttons and lights for each elevator is 20 inputs and 30 outputs, plus a few prox sensors. I would normally use 8 conductor cables and bulkheads and wire them that way, but even then there has to be a better way.

What is your experience?

 

[Toine]

We have build a factory which from an automation point of view was not overly complex, simple enough to put all control in one PLC. Quite some sensors and motors over long distances though, up to 150m as the bird flies, requiring up to 300m cable lengths. With a few hundred I/O's, this adds up to a freaking huge amount of cable to install if all were wired into one single cabinet. Instead, we set up 18 networked remote I/O's, all connected over ethernet to one Wago PLC, protocol Modbus/TCP.

The network has one central switch in the main cabinet, and several 5 or 8 port switches in different corners of the factory. Small cabinets with Modbus/TCP remote I/O near all the locations that have a lot of I/O's. Works very well, as long as some thought is given to how the network is set up.

In a case like this we use managed switches, not for the typical things like VLAN's and the like, but mainly for facilities like cable checking and being able to monitor the load on different ports in each switch. The ability to monitor the network and check all connections can be a mission critical asset in effective troubleshooting. I have seen a case where one device on the network (not part of the PLC and remote I/O's) caused a broadcast storm, bringing down part of the network and severely cripling the rest. Without a managed switch this is a nightmare to troubleshoot. Even more if you happen to do your troubleshooting not on site, but rather from several thousand miles away.

Furthermore you may want to keep in mind that remote I/O over Modbus/TCP is typically slower than I/O's wired straight to your PLC. If a refresh cycle is 100ms then you would potentially miss input pulses shorter than 100ms. Something to keep in mind when choosing sensors and the things which trigger them. Situations that require short reaction times need either a faster protocol for your remote I/O's, or distributing part of the load to local PLC's anyway.

 

[Brandon_K]

Anyone else have any opinions, thoughts or anything else they want to throw into the hat?

Toine - Thanks for the response, I appreciate it. I had assumed that the response time was slower. Much of this particular job is players pressing buttons, I'll need to see if the average person presses a button long enough to register and not miss the scan.

I understand what you're saying about using a managed switch. For my uses, I don't think it's going to be a requirement. Right now at best I'm coming up with 4 devices on the network. The PLC, a HMI and two remote I/O systems. Until we get into any larger jobs, that would satisfy my needs well. That network will be completely separate from any other network, with the only possibility of interconnection being a connection to an outside network via port forward to access the PLC remotely. I may just throw an EdgeRouter in the cabinet so I can setup a IPSEC VPN and go that route.

 

[Archie]

If you are looking at the Proto X, consider looking at Beckhoff. The Proto X is re-branded from Beckhoff. By going to Beckhoff, you will have much more options of communications and IO and also it may be lower in price.

 

[shooter]

remote I/O with a coupler is always good thinking. I like the WAGO way as it is easy to program and easy to expand.

As this is not critical stuff, i would also check arduino, as its price is very low, however you can make almost anything with it.

 

[danw]

I've used the Acromag 6 or 8 channel I/O-to-Modbus/TCP 900 or XT series I/O modules.

It works OK. Easy to set up with browser or the software/USB cable.

The AI's are not as damped or filtered as typical process analog inputs so it tends to look 'noisy' due to lack of low pass filtering and the option for high sampling rates. But since it can damped/filtered at the receiving end, it's no big deal.

Some have been running 24-7 for 6-7 years now.

 

[Toine]

Brandon, I don't know if 100ms is a performance limit. The amount of data transferred in modbus/tcp is minimal for today's network's capabilities, so from that point of view I would expect significantly faster communication may very well be possible. It just was not needed for the situations where I have worked with large numbers of remote I/O's.

I currently have no time nor hardware available to test this. Perhaps some of the others have worked with faster cycle times.

 

[BobB]

I would strongly suggest Ethernet IP remote I/O. There are some pretty inexpensive solutions out there. I have been using the Omron I/O - inexpensive and an Ethernet IP coupler required at each location.
Just commissioning a job at the moment and I am not using any standard I/O on the processor at all. Everything is on Ethernet I/O couplers.
In the main panel there is an Omron CJ2M-CPU33 processor which includes an Ethernet IP port, a coupler with 13 x 16 bit digital input cards and 13 x 16 bit digital output cards, another coupler with 2 x 8 channel 4-20ma analogue input cards and 3 x 4 channel 4020ma analogue output cards. In the first remote panel there is a coupler with 2 x 16 bit digital input cards and 2 x 16 bit digital output cards. In the second remote panel there is a coupler with 1 x 16 bit digital input card and 3 x 16 bit digital output cards.
I did specify fibre optic between the first 2 panels as the distance is over 100 metres but the contractor put in short sweep bends and the fibre will not go around the bends - in the concrete poor of course - no other way of getting there. Not sure of the length but definitely over 100 metres. It is working fine.
The whole PLC system cost $16,000.00 AU including a 12" Omron NS touch screen and they are not cheap but have never had a failure - better to spend the dollars and not have to go back and replace a failed screen - most reasonable. I have had quite a few screen failures from some of the 'bigger' brands. Not worth the grief.
once I got my head around setting the network up it was really quite easy and works a treat.
I have not had a look at the turn around time in the Network Configurator but believe it is probably less than 25ms. Will have a look the next time I am on site.

 

[AustralIan]

If you like speed, etherCAT is the fastest control network I know of.

Follow this link if you want to know more than you ever thought you would about industrial networks, albeit from etherCAT themselves.
https://www.ethercat.org/download/documents/Industrial_Ethernet_Technologies.pdf

I had an Ethernet/IP remote node 5 years ago from FESTO that had an update rate of 10ms. It was great, as it had pneumatic valves, including pressure regulators in the same unit as the I/O. Made wiring easier and saved space in the main control cabinet. 10ms was the maximum the remote io would let me set it, but still fast enough.

 

[Brandon_K]

I had a big long reply typed up, went and hung out with my daughter for a bit and came back to Windows applying some updated and auto rebooted my machine.

Anyhow.. It looks like the Protos X, WAGO and Beckhoff field I/O systems all come out of the same factory. They're all identical. Phoenix Contact also has their version which looks very similar, the LED's are different, so I suspect it's just repacked in different plastic.

We stay away from all things Arduino. We used to use them but just entirely to many problems with them, even when we were buying the legit Italian units. To get them "up to snuff" with opto isolated inputs, transistor outputs, etc I can buy a Click and know that it will be rock solid. I can't tell you how many Arduino's we went through that the USB chip would ****. Plug it in, dump a program, test, need to update the program, plug it back in, nothing. Refused to be recognized by any computer. We started buying the Ruggedunio's, similar issues. We just had to many issues with them to consider actually deploying them into a customer facility.

Anyhow, I spoke with Automation Direct today to talk about the Protos X system. The tech there said everyone in tech support hates it. He actually used the word vile. What he recommended was something that I had thought about, but really saw it as a cludgy workaround solution and that was to use a ethernet Click with whatever I/O I needed.

Having never connected two PLC's together via MODBUS TCP before, he helped me through it in less than 5 minutes over the phone. It was super easy to create the Click tags on the Productivity side. Technically you can address the I/O directly on the Click, but he recommended using control bits, so it only took a minute to have C1 > Y1, C2 > Y2, etc etc. I went and grabbed an old network switch and within 15 minutes total I had them talking to each other. I'm polling them at 10ms right now. Ultimately it will be 20ms once I add the second Click. I'm building this all in my dining room in Pittsburgh, I don't get back to the Cleveland shop until next week.

So, I get 40 OUT and 22 IN for just a shade over what the Protos X coupler alone runs. The Beckhoff coupler for those interested is nearly two times the cost as the AD Protos X version. Granted, the Protos X is only available in MODBUS TCP, where the WAGO and Beckhoff versions are available in TwinCAT, Ethernet/IP, etc. But with my initial testing here, MODBUS TCP is going to be just fine for my uses.

I appreciate all of those who chimed in. If this one doesn't pan out well, at least I have other options.

 

[DwSoFt]

One thing to keep in mind with communication remote IO:

if it is a critical shutdown, you may want to have a heartbeat so that if comms fails it shuts you down.

some equipment does this automatically, others you have to roll your own.

 

[g.mccormick]

One thing to keep in mind with communication remote IO:

if it is a critical shutdown, you may want to have a heartbeat so that if comms fails it shuts you down.

some equipment does this automatically, others you have to roll your own.

This is one area where having the Click PLC as the "remote IO" really would shine. On the Click side, if you detect watchdog timeout, then the programing in the click could bring the process/etc down safely.

 

[Brandon_K]

One thing to keep in mind with communication remote IO:

if it is a critical shutdown, you may want to have a heartbeat so that if comms fails it shuts you down.

some equipment does this automatically, others you have to roll your own.

This is great to know about in the event that I ever move into industrial. I'm in the themed attraction industry, right now primarily heavy on the escape room side, so we really don't have any E-stops or anything of the like.

 

[AustralIan]

Further to my previous comments, Modbus TCP is probably the most likely Ethernet protocol to work based on a quick "does it support modbus TCP slave" flick through the instructions.

On others, I have come across the "yes it is protocol X, but it is not supported by your version of the PLC".

 

[PLC GURU]

Ive used Protos X and Click as remote IO with no issues...Both seem very reliable. They are both used in pretty crappy enviroments