Gher.aphelion
Member
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 PLC’s and two PC supervisors with OpenVMS OS.
Both Supervisors are redounded, thus only one supervisor will be active every moment.
The PLC application consists on:
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, it 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.
¿Have someone suffered from this kind of problem?
¿Someone knows where is the problem and how can I solve it?
Thanks a lot.
Gerard.
I’m developing a critical application in a TSXP574634M Premium Telemecanique processor (With Unity Pro and native Ethernet port). The Ethernet network contains two PLC’s and two PC supervisors with OpenVMS OS.
Both Supervisors are redounded, thus only one supervisor will be active every moment.
The PLC application consists on:
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, it 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.
¿Have someone suffered from this kind of problem?
¿Someone knows where is the problem and how can I solve it?
Thanks a lot.
Gerard.
