GE RX3i Modbus/TCP communication error

I am using a GE RX3i PLC with the IC695ETM001 Ethernet module to communicate via Modbus/TCP to a third-party device (an RMC75E motion controller).

I am using the COMM_REQ instruction to continuously read 32 words of data from the RMC75E, plus occasionally do some writes. The communication is working. The RMC75E reports receiveing a Modbus read request roughly every 15-30 milliseconds.

My problem is that the Comm Request Status word flickers (on the screen) between a value of 1 and 43920 (AB90 in hex). This occurs very often, roughly half the time, with both the reads and writes. The GFK-2224D manual, chapter 8, lists the Comm Request Status error codes, but AB90 is not in the list.

In addition, the occasional writes do not always get through on the first try. I assume this is because of the error.

I am hitting the communications fairly hard with the commreq instruction, but I am waiting for the Comm Request Status to return a 1 before executing it again. Typically, I execute the CommReq instruction on the scan after the Comm Request Status returns a 1. In the case of the occasional write, I execute it on the same scan, but after the Comm Request Status returns a 1.

The manual claims a "Only one COMMREQ function per channel can be pending at a time. A COMMREQ function is pending from the time it is initiated ... to the time its CRS word has been updated to a non-zero value." Hence, my logic should work.

If stop the automatic reads and manually trigger them, the error never occurs.

Any ideas? Do I need longer delays between executions of the commreq? I have attached a picture with the portion of my code that does the reads.

Thanks,
Jacob Paso

Code:

Code AB90 defined on Page 10-21 of GFK-2224C:

"A COMMREQ was discarded because the application program issued the COMMREQ before the COMMREQ status word for the previous COMMREQ was set."

It sounds like you may not be waiting as long as you think you are. Make sure all your COMMREQs are triggered by one-shots and that you're not triggering an unintended COMMREQ.

Edit: You posted the picture while I was typing. The trigger for the COMMREQ should definitely be a one-shot.

Thanks Steve!

Not sure exactly what I did wrong, but I simplified it and rewrote it and it works great! The timing of the requests is more consistent, as I expected.

Jacob

Edit: I did use a one-shot.