RX3i IC695CPE305 Modbus slave

Here are three Blocks in a Toolchest Drawer which can be copied (Ctrl-Drag-n-Drop)into logic Blocks of an RX3i, CPU374, & CMM321. You should need just one, others may want a different one.
AFAIK they all work but you may need to adjust addresses.

No question is a dumb question yes I am using the latest firmware. I tried it with a 7.75 and the latest 8.15. I don't have another standalone card to try..I did try another CPU with the same results. I chose this for the built in Ethernet and that they have the Modbus capable..(Well so I thought anyway)

I can open channel (connects) put a 1 or 16#0001 in %R02040 and an 8 in %R00301 as it should. I disconnect it puts a 2 in %R00301 and %R02040 remains a 1 or 16#0001 even though it has disconnected.

Click to expand...

The value in %R2040 does not indicate the connected/disconnected status of the Modbus TCP channel. %R2040 is the COMMREQ Status Word. A value of 1 tells you the COMMREQ executed successfully.

The status of Modbus TCP channel 1 is in the seventeenth of the 80 status bits assigned to the Ethernet interface in hardware configuration. Unless you modified the default selection, the status bits will be %I memory. If the CPU was the first module you configured and you accepted the default address assignment, it will be %I0001 - %I0080. Check to see the actual address range configured for your case. The first sixteen status bits relate to the health of the Ethernet interface. The remaining 64 bits, in pairs, relate to the status of each of 32 channels that can be simultaneously open. By that I mean the seventeenth and eighteenth bit relate to channel 1, the nineteenth and twentieth relate to channel 2, etc. When a channel is Modbus TCP, only the first bit of each pair has any meaning. The bottom line in your case is that when the seventeenth status bit is true, channel 1 is open. when false, channel 1 is closed.

Steve I want to thanking you for making things clear. Sometimes my old brain need things spelled out. I come to the conclusion just because something works does not make it right. In my old application for the 9030 I used the 17th bit of the channel status as well as the in4 of the first BLKMOV with is the (%R02040 or 2040 minus 1 2039 of IN4)this worked in the 9030 because when disconnect it (%R02040) would give an error or another number besides 16#0001. Which I used in my application and it worked but it wasn't right. I have done some testing this morning and set up like you explained and it works just fine. You made things clear so I could understand them and I could see why it did or didn't worked. I will edit my application accordingly and it should work just fine for what I need it to do. Thanks again. Here is the working Application for any that need an Example of a RX3I CPE305 or Embed Ethernet Modbus TCP for the open and close channel.

RussB said:

Here are three Blocks in a Toolchest Drawer which can be copied (Ctrl-Drag-n-Drop)into logic Blocks of an RX3i, CPU374, & CMM321. You should need just one, others may want a different one.
AFAIK they all work but you may need to adjust addresses.

Click to expand...

Thanks for those samples. Looking at the RX3i sample, if the open channel command fails (say the Server is not available or some other issue), the read logic will never trigger and the open command will not retrigger and it just stops on rung 10 forever waiting for R01040 to equal 1 (R01040 would likely have returned an error code).

As another issue, what happens if the connection to the server is lost during communications (say the server goes offline after a while). Will the CPU close the channel automatically (which would re-trigger the T00011 coil) or does the read command (R01060) forever return an error code? I followed your logic and I need to setup a system that is unattended and must account for any issues and automatically correct itself to get communications going again.

Russff said:

Thanks for those samples. Looking at the RX3i sample, if the open channel command fails (say the Server is not available or some other issue), the read logic will never trigger and the open command will not retrigger and it just stops on rung 10 forever waiting for R01040 to equal 1 (R01040 would likely have returned an error code).

As another issue, what happens if the connection to the server is lost during communications (say the server goes offline after a while). Will the CPU close the channel automatically (which would re-trigger the T00011 coil) or does the read command (R01060) forever return an error code? I followed your logic and I need to setup a system that is unattended and must account for any issues and automatically correct itself to get communications going again.

Click to expand...

Very astute. This was designed to be a starting point not a turn-key app. Please feel free to add diagnostics as needed. And update the demo once you get it documented and debugged.

I wish I had the equipment to play around with this, but unfortunately I do not, this function is being added into an existing system, so I pretty much need to get it right the first time.

And I'm not sure what the CPU does with the channel once comm. is lost, whether it stays open or the CPU closes it. That will determine how I handle a read/write failure, so it's my second question that is the more critical one and the one I can't figure out the answer to.

Every application is different and one needs to adjust accordingly. I have one application that monitors the status word of the comms and when it times out or drops or whatever the reason when it times out closes the channel and then restarts back to open channel commands. If status is not a 0 or 1 think that is channel open can't remember if anything but starts a timer then one shot to close channel. Many many different ways to do it I think I have my HMI give alarm if not connect for some time also. My gateway will keep adding channels if not closed so only one open channel but multiple connections. I could paste an example but probably not till next week .. regards

I agree there are many ways to do this. The GE manual has 8 pages of possible error codes. So if the read command fails because the channel was somehow closed, one course of action needs to be taken (open the port), but if the error is due to a transient issue, another course need be taken (ignore the error and retry the read).

So not only does an error condition need to be monitored, but the specific error code will determine the correct course of action. This is too low level and prone to not working properly and requiring manual intervention, I may need to find a different way to handle my communications.

Russff said:

I agree there are many ways to do this. The GE manual has 8 pages of possible error codes. So if the read command fails because the channel was somehow closed, one course of action needs to be taken (open the port), but if the error is due to a transient issue, another course need be taken (ignore the error and retry the read).

So not only does an error condition need to be monitored, but the specific error code will determine the correct course of action. This is too low level and prone to not working properly and requiring manual intervention, I may need to find a different way to handle my communications.

Click to expand...

One way I have handled this in the past is to monitor the Status Word and if/when it goes greater than 1 I would 'close' then go back through the open and start the read or write again. If this happened more than 'x' times (usually 3) only then did I cause an operator alarm. But of course you need to know how soon/often the section of logic needs these updates.

So if the read command fails because the channel was somehow closed, one course of action needs to be taken (open the port)

Click to expand...

In hardware configuration for the Ethernet port you specify the starting address of 80 bits of status information about the port. Of these, there are two bits associated with each of the 32 channels that can be simultaneously open. You can monitor the bits associated with the channel you're using to tell whether or not that channel is open. As far as I know the open status of the port is local to the client and not dependent on whether or not the server is responding.