CPU374 Plus communicating with 10-16 remote I/O

[nkakal 0]

We have traditionally always used the I/O modules on the rack to do our I/O (then running multiconductors to panels etc). To save time/money we want to try using some ethernet based distributed I/O. The I/O we have chosen, communicates over Modbus TCP. We will need between 10-14 of these I/O Bus Couplers to get our I/O network covered. My task is to communicate to all the I/O by configuring the 374's ethernet to talk to the modbus devices. I have done some reading on it via the GFK-1541B (for the CMM321) but I found out I can just use the 374's ethernet and skip the CMM321, the GFK 2382 then showed some different ways of doing things and I think I have a general conceptual understanding of a lot of it. Some of the things I am not too familiar with is the channels that it wants to open, and limit me to 16 of. Are these channels also used to communicate to Cimplicity HMI? We are used to reading Inputs and writing outputs on every scan of the PLC, it seems like doing all of that on a comm_req based setup will push my scan time out quite a bit. Does anyone have suggestions or examples that they would be willing to share on how to get all of this stuff setup and running? My I/O couplers should be here early next week, and I want to be ready to start testing response times and other stuff but at this point have little to no idea how to actually talk to them:(

[RussB 22]

Sorry to hear that you already have the I/O coming. Modbus/TCP via Comm_Req is not a very efficient way to do I/O. If you can switch, I HIGHLY recommend using EGD (Ethernet Globa Data) with the CPU374, VersaMax I/O works well for this. Yes, the 16 channels are shared with the HMI or SCADA, you may want to add a CMM321 for this, or maybe two so you can assign 2 or more channels to each I/O node (1-Read, 1-Write Plus Analog?). With 10-14 nodes having a mix of I/O, Comm_Req control is going to be very stressful.

[nkakal 0]

Do you know off hand if the only one comm_req can be pending rule is per channel or per ethernet So if I added in say 2 CMM321's per backplane, could I have 3 comm_reqs pending at a time?

[RussB 22]

Per channel.

[nkakal 0]

Thanks for your input russ, it has guided me to some tasks which I have yet to complete, but understand a little more. I am currently planning on using one channel per I/O device, and just alternating read/write comm_reqs. Error handling might be troublesome but hopefully if I can get over my first hump and just read some I/O! Do CPU firmware versions matter very much in all of this? I have revision GP and unsure to which firmware version I am or or need to be on.

[RussB 22]

It has been my belief that the "latest" firmware is better than the previous, until the project is done and working, then if it is not broke don't try to fix it.

[motioncontroller 0]

Hello, Excerpt from the 1541 manual: ******** Sequencing Communications Requests If the Ethernet Interface receives Command Blocks from the PLC CPU faster than the Interface can process them, the Interface will log an exception event 08, Entry 2=0024H and will log the PLC Fault Table entry: “Backplane Communications with PLC Fault; Lost Request” Only one COMMREQ function per channel can be pending at one time. A COMMREQ function is pending from the time it is initiated in the ladder program until its CRS word has been updated to a non-zero value by the Ethernet Interface. ******** Just some information I have found out in testing this type of a system: I have also found that the modbus TCP/IP devices that I communicate with have the ability to have 3 channels open to them at a time. And for example if you open channel 1 then 2 then 3 and then 4 upon the opening of 4 channel 1 automatically closes and so on. Some people I have spoken to have suggested not to ever close any one channel and just read and write to your hearts content. (i don't like this way) One last interesting thing you may want to test is the time it takes for a COMM_REQ to return successful. I have done this test but cannot quite remember the lengths of time. If I recall correctly my scans run from 3.5-7.8ms and it took on average 10 scans for and open or close, 30 scans for a read or write. The other thing to remember as highlighted in the above statement is that you can have one COMM_REQ per channel pending at a time so you really could have 16 COMM_REQ s pending at once. The best way to sequence these that I have seen is to use the success bit for the modbus function being used. Hopefully this helps a little.

[nkakal 0]

For now my plan is to leave a channel open to each device and alternate reading and writing. After spending a few days trying to get my 374 to use the comm_reqs properly my last resort option, using a CMM321 had to be invoked :(. I am opening channels now properly and reading/writing, the data seems to make sense to me, and I wrote up a simple block that will read the data and when that is complete (CRS = 1) do a read, and then back to a write. I've noticed that when I make a mistake and I get a non zero CRS word error (non zero AND non one), my channel will sometimes close on me. I find this a bit troublesome because I need to write some code to keep re-openning them. Regarding your timing observation I am also interested in seeing what kind of response times we are capable of. This whole project is almost like a proof of concept test for some backwards compatibility issues that may arise in the future, and one of the requirements is a decent I/O scan rate, our target for now is < 100ms for read and write. Writing some basic testing code, it looks like I get an I/O scan of about 20/second or 50ms for a full read/write. This should be ok, but this is in my test project which runs at a 3ms scan time. I wonder what will happen on my real project which runs at a 40-60 ms scan time.

[Steve Bailey 118]

You can force your PLC to run at a fixed scan time. Go online with it. Click on the "Target" menu then select "Online Commands" then "Show Status". Go to the "Sweep" tab and set the "Sweep Mode" to "Constant" at whatever time you want between 5 - 500 mS.

[nkakal 0]

I think we tried this with one of our bigger projects before, and going too much below the 'natura' scan time caused us some real headaches. In general we want it to be as fast as possible, so would changing the sweep to be constant and below the 'natural' scan cause us any issues?

[Steve Bailey 118]

Changing to a fixed scan time that is less than the 'natural' scan time can certainly cause problems. You indicated that your final program's natural scan time would be the range of 50 - 60 milliseconds. I was suggesting forcing your test program's scan time to be longer than its 'natural' time to more closely simulate the real program.

[nkakal 0]

Ah yes, I just did this and it is providing some interesting results, thank you!