Issue with M340 and Modbus

[robyn 0]

Hello, sorry to join with a problem but going through the topics I see many helpful responses and am hoping someone can help me here! I am having difficult creating and sustaining a Modbus/Ethernet/MBP network involving: - A Modicon M340 CPU 2020 - 4 Schneider 7350 Powerlogic transducers connected via Modbus - A TCS EGD module to interface between Ethernet and MBP - A Momentum PLC connected via MBP The M340 requests data from the 4 meters continuously using 4 READ_VAR function blocks. It then analyzes the health data from the meters and stores either the data or 16#FFFF at a designated location to be read from the Station Master, the Momentum PLC. This occurs successfully (data is read from the M340 PLC and written to the Momentum PLC, and SER COM shows a flashing orange LED). However after approximately 35 -75 minutes (it varies) communication on the Modbus stops and, the communication times out with each of the meters, and the data stored becomes 16#FFFF as per the analysis. No Error lights appear ON the PLC LED’s, however the “SER COM” has ceased to flash orange. Unfortunately we are not on site and it is located 2 ½ hours away, so I cannot see what the ERROR report is (if anything) from the READ_VAR command – we were unable to simulate any error report by disconnecting a meter etc – or what the number of “no responses” or bus errors have occurred on the serial link. Are there any settings that may be causing this? At our location we are using the same program and trying to recreate the error; however we only have 2 meters available and thus far after 12 hours we still have communication (SER COM still flashing, minimal bus errors). Thank you for any help.

[rajsiyer 7]

It depends on the way you've used the read_var function to poll the slaves. If you have the code posted here, I'll show how to improve it. IF all 4 read_vars are called simultaneously/continuously, then a time-out on a single slave will disrupt the comms on the other slaves. Best practice is to use a single read_var block and call each slave in turn and capture its data in a separate place. Prior to the read_var call you've to clear the GEST area and re-initialise it with its correct-time out (1 = 100ms) See Here how I've done it. Regards & best wishes, Raj S. Iyer Edited 8 May 2012 by rajsiyer

[robyn 0]

Thank you for the response! I did something similar, and used an integer counter (inc every .5s) to trigger each read_var individually (timeout being .5s). It has been accurately reporting and in service since February.

[iJAF 0]

Are you sure about that a timeout in xxx_var() will disrupt the comms on the other instances running simultaneously ?! Called_every_500msec( read_var_1 ( 192.168.1.1 ); read_var_2 ( 192.168.1.2 ); read_var_3 ( 192.168.1.3 ); read_var_4 ( 192.168.1.4 ); ) Imagine a timeout in read_var_1 for some reason: Will it abort the other 3 instances of read_var ?! Thank you

[rajsiyer 7]

Remember, this topic began with a comms. problem with multiple slaves which stopped comms after a while. What you ask is different but related question. MY answers based on my experience are... 1. If you are talking of multiple slaves on the serial(RS-485) side of the ethernet gateway, failure/timeout of one slave will result in failure to communicate with all other slaves on the SERIAL side of the gateway. This is because the physical line is used /blocked by the time-out slave. other slaves cannot use the 2 wires. 2. In your case, it will NOT happen. This is because all your slaves are on ethernet . Data packets will find their way to the other slaves. Regards, best wishes, Raj S. Iyer

[iJAF 0]

Hello, in your example why are you using this notation " Addr('{1.100}0.0.0.1')" ? Slave address nº1, rack 0,slot 0 and comm channel 0 ? and what about the "{1.100}" part ? Thank you

[rajsiyer 7]

Sure, You've to set up X-Way messaging for Ethernet_1 or whatever connection you've setup under Project/Communications. The syntax of Addr is as defined for X-way messaging. The ADDR(<string>) string argument is different for different situations. It can be written in a number of ways. If you don't require X-way messaging, you can avoid this syntax. The Premium processors do not support Read_VAr on %IWi directly. That is why we use the legacy X-way messaging. Its all there in Unity pro help. For M-340 processors you use ADDM instead of the ADDR instruction. There you can input the IP address of the slaves directly. regards. Raj S. Iyer