CLX to Atlas Copco (Modbus) communications

while same flash a value and then return to 0.

Click to expand...

To me that suggests the Prosoft gateway is writing to those addresses and the Atlas Copco is overwriting with new data.

Steve Bailey said:

To me that suggests the Prosoft gateway is writing to those addresses and the Atlas Copco is overwriting with new data.

Click to expand...

Not sure how that's possible considering I only have FC3 (Read registers) assigned to the commands.

I confirmed that this is NOT with the Atlas system because I downloaded a third party modbus program and have been monitoring those same registers and they are rock steady. The prosoft card is where my issues are. Could this be related to the fact that I'm doing MODBUS RTU over TCP/IP?

I did try to write to a register and it never made it to the Atlas.

I should add that I am also reading data from an Acromag analog input module over true MODBUS TCP (502), and I put those values into [520] of the array, and they are not behaving like the other values. I am leaning toward this being an issue with pulling data in over RTU via TCP. I don't see any way to tell the card the difference, other than the port number that is assigned, although this is a response I got from Prosoft several weeks ago when I inquired about the configuration:

There should be no difference in how the module is configured other than using a different server port number than the default 502. By default port 502 will use “native” Modbus/TCP, and any other server port will use RTU-encapsulated Modbus/TCP, which have different packet structures.

Click to expand...

By that, I would assume I have it correct.

I changed two things, which defy logic, but it's working now, and it's steady.

Minimum command delay from 100ms to 0ms.
Polling from 10 (1.0 sec) to 0.

So I basically set it to run FASTER and now it works. This is certainly not the case for other systems, but I'd love to hear Prosoft's take on this.

phuz said:

I changed two things, which defy logic, but it's working now, and it's steady.

Minimum command delay from 100ms to 0ms.
Polling from 10 (1.0 sec) to 0.

So I basically set it to run FASTER and now it works. This is certainly not the case for other systems, but I'd love to hear Prosoft's take on this.

Click to expand...

That does not make any sense. How does changing the poll change the data??

Weird

g.mccormick said:

That does not make any sense. How does changing the poll change the data??

Weird

Click to expand...

I'll let you know tomorrow when they return my call. You know, during "business" hours.