Created Date: October 23,2019

Created by: Brandon_

To sidebar off of my struggle bus with setting up a Click as an Ethernet IP adapter to use with PxK, there are obviously multiple ways to share data across multiple PLC's. MODBUS, ProNet, EIP, Productivity's own RX/WX instructions. I'm interested to see why you would all choose what method and why. Yes, I realize that some of these protocols are PxK specific, but I thought it might get better traction here in the General forum. I'd love to hear Bob O 's thoughts, but I'm not sure he spends much time in the Productivity subgroup ;)

A few years ago I used a few Click's with a P2K via MODBUS TCP. The Clicks were strictly used as remote IO points, they weren't running any logic. For the most part, it worked fine. I had a cycle setup in the P2K to read and write out to the Clicks. The biggest issue that I had was sometimes button presses would be missed. If memory serves me, it was cycling each instruction every 5ms, a total of 4 instructions, meaning it wouldn't get back to the first for 20ms. This obviously creates a ton of network traffic when you 're polling at that rate.

I 've used the P2-RS CPU's in conjunction with a P2K, which was great. Being able to work with all of the tags directly in one program, without having to rename anything is fantastic and everything is simply handled in the background. No muss no fuss. Unfortunately, a second base, P2-RS CPU, etc is massively overkill for my typical needs where I would need remote IO. Productivity dev's, if you 're listening, *PLEASE* allow P1K's to be used in this fashion for remote IO!

I 've also used Productivity's own RX and WX instructions. This seems to work pretty well. But it has some big drawbacks, mostly that you have to rename the tag from the remote IO (IE, if "DI_Button_1 " is the name of a input on my remote P1K, I have to give it a "local name " of "RDI_Button_1 " or similar). Also, the instruction only supports 15 tags per instruction. At the time, I was completely unaware of how useful arrays can be, so I think I can just copy physical inputs and outputs to some arrays and go that route, but on the flip side I don't particularly love working with arrays in that way. It seems like a lot of work when I could just use a contact or coil directly.

Then we have ProNET, which I 've not worked with at all. It seems MQTT 'esq, as it's a publisher / subscriber model. I'm not sure what it's performance is like in comparison to the other methods.

Ultimately I'm looking to see what the pros and cons are of RX/WX, ProNET and EIP are, especially compared to each other. Mostly, I'll be using it for remote IO. But, I do have a project coming up where I may need to have one PLC act as a data aggregator, from 21 other P1K PLC's on the network. This one could run in to some network traffic issues, as there will also be 21 video displays being fed from a server feeding out HTML5 video streams. I'll worry about that when we get in to semi-scale testing. Worse case, I break the video off on to it's own network or setup LACP between the switches and the server to increase bandwidth. I'm more concerned with overall congestion, versus bandwidth.

Thoughts?

Created Date: October 24,2019

Created by: kewakl

Well said.

Protocol: I have stayed with WX/RX.

Why: Even though I thoroughly do NOT LIKE having to reread a remote project EVERYTIME I need another WX/RX instruction (or make a change to the remote project.)

I got into the P3K before (~V1.4.1.1) the background comms protocols (E/IP, Pronet...) were released. I have had too many problems with other SW/FW versions to test each new version for eastereggs/undocumented show-stopping features. --However we are in the proces of migration testing with a target of 3.5.1.2.

A few 'features ' are listed below. These 'features ' have probably been fixed, but the bitemarks persist.

this

this

this

this

this

this

Created Date: October 24,2019

Created by: MikeN

The way I see it is this:

If your facility has entirely Do-More PLCs, and you need to send data between PLCs not as remoteIO but as just data needing to be shared every half second or so, then use Do-More proprietary protocol with its publish/subscribe method.

If your facility has entirely Productivity PLCs, and you need to send data between PLCs not as remoteIO but as just data needing to be shared every half second or so, then use Productivity proprietary protocol with its publish/subscribe method.

If you have a mix of PLCs, or if you need data every 25-50ms or so then use EtherNet/IP as it is supported by different PLC families and is pretty fast. This can be used for RemoteIO.

If you have a mix of PLCs, and any of them do not support EtherNet/IP but you still need data fast, then use ModbusTCP. EtherNet/IP is slightly faster than ModbusTCP, but Modbus is more universal.

If you dont run any Automation Direct PLCs and you have very new and fast PLCs from other top companies, that you need remoteIO or other data every 10ms or so then use ProfiNet or EtherCat. Both protocols are faster than EhterNet/IP and are guaranteed receive times so are better suited for remoteIO and servo control. Downside is you cannot run them on a standard Ethernet LAN.