TSX Premium MODBUS TCP messaging


Thread Starter


Hi all,

I'm developing a critical application in a TSXP574634M Premium Telemecanique processor (With Unity Pro and native Ethernet port). The Ethernet network contains two PLCs and two PC supervisors with OpenVMS OS.

Both Supervisors are redounded, thus only one supervisor will be active every moment. The PLC application consists of: The PLC sends a MODBUS TCP message using WRITE_VAR function to the first Supervisor making sure that previous WRITE_VAR exchange has finished. If first Supervisor is passive, its Ethernet socket is closed, so it does not answer and WRITE_VAR report is 16#0001 (Timeout). Then, the PLC switches the destination of the message in order to send a message to the other Supervisor changing the WRITE_VAR function parameter called Address (Address of the destination entity of the exchange). Then, the second Supervisor is active and answers the MODBUS Request correctly. Provoking the toggle of both Supervisors, the PLC detects the problem with current Supervisor and switches to the other, and so on.

But, without apparent cause, after a toggle of a Supervisor, sometimes the report of WRITE_VAR sent to the active Supervisor is 16#08FF (i.e. Message Refused / Destination Application error according to Telemecanique technical documents). After that, the PLC tries to send the message to the other Supervisor but it is passive and the WRITE_VAR report is 16#0001 (Timeout). Then, the PLC tries again with active Supervisor and the report is 16#08FF again! this loop never ends and the link between PLC and the active Supervisor is never established.

I used an Ethernet sniffer called ETHEREAL to analyze the Ethernet traffic and I realized that the messages reported as 16#0001 (Timeout) were really sent because appeared in ETHEREAL but the messages reported as 16#08FF did not appear, they did not exit from PLC's Ethernet port. Somehow or other, seemed like WRITE_VAR function did not allow to send a message in that moment. I tried to re-download the project and the application returned to work correctly until another unknown event, then restart the anomaly performance.

I solved the problem updating the PLC Ethernet port firmware. I did dozens of tests with the new Ethernet port firmware and the application became stable. But three weeks later, the problem has appeared again.

Has someone suffered this kind of problem? Does someone know where is the problem and how can I solve it?

Thanks a lot. Gerard.
Hello Gerard,

I can't believe it...

I´m working in a project, and I have the same problem.

I'm using TSX P57 2634M to connect to remote slave devices via Modbus GPRS using READ_VAR and WRITE_VAR, and one or two days alter reset PLC, it stop to work correctly, and the error code is the same as you.

Schneider Spain, don't know how to help me.

Could you solve the problem?

Thank You,

Ricardo Rey
rrey [at] sampol.com

Schneider Italy

You said "the messages reported as 16#08FF did not appear, they did not exit from PLC's Ethernet port". Of course not it is an internal code reporting the message error occurred.

As an application error seems to be the problem, could you send me the program by exporting the application in .xef format?

Anyway, sorry, but I completely don't like this kind of redundancy management. That's could be just because I haven't all information on your Scada system. By the way I wonder why the communication is not managed by the two redundant SCADA (as I understand). In this case you don't need to program any WRITE or READ function.
Did you think about using I/O Scanning service?
Easier, faster....

aggattapauer at gmail com

Thanks for your answer. May be the problem is not the same.

I would try to explain you what happen in my project:

In this project, we have to communicate witch remote stations MOTOROLA MOSCAD, via GPRS Modbus TCP/IP.

Actually there are 9 remote stations.

We program MOTOROLA Moscad to work as Modbus RS-232 Slaves.

Then we install VIOLA GPRS Routers and VIOLA M2M in control centre to manage VODAFONE dynamic IP remote addresses.

To control GPRS traffic we use PREMIUM READ_VAR and WRITE_VAR functions, the TIMEOUT is set to 5 seconds.

Every minute (its depends on the CICLO_LECTURA value), PREMIUM communicate with active remote stations (it depends on ESTACION_X_COM_ACTIVADA is set or not).

If a reset PREMIUM, all active stations communicate OK, but if one station fails, in next communication PREMIUM open a new port to communicate with this station.

One or two days after, one or more station stop communicate OK, the messages reported as 16#12FF, but if I communicate with ModbusPoll, remote station its OK, then if I reset PREMIUM, all stations can communicate OK, and in SNMP window, pots opened are set to “0”.

I hope you understand my English.

I send to your Gmail address .xef application

Do you know the solution of this problem?

Thank you very much,

Ricardo R
Hello again,

I only send new post to know if somewhere who work with Schneider PREMIUM can help me.

I talked with Schneider to define the programming application, but the problem is not solved.

Ricardo R