I am working on a system built in 2015 that has a Fairbanks FB2250 indicator with Anybus CompactCom Modbus-TCP interface - talking to a Mitsubishi L series PLC. Problem is, whenever the PLC switches from Run - Stop - Run, (like during a remote download of the program) the Modbus TCP communication does not restart until I cycle power on the scale. I am working with the Fairbanks folks locally but they are giving me the preverbal blank stare over the phone. I was hoping there was a command I could send from the slave to re start coms?
I am not aware of any reason the Compactcom would stop responding to requests. My initial though is that this is related to the PLC sending the requests. A wireshark between the two devices might shed some light on the issue. Is the PLC still sending the requests? Is it receiving error responses? Is the module still available, does it respond to pings? Does it respond to modbus requests for another master, such as a simulator on your PC?
As for a way to restart the module I would recommend following up with Fairbanks. I Can’t think of an option to reboot the compactcom’s from the network side. Typically, if the module was to run into issues it would alert the host which could then reboot the device. Generally support for embedded devices falls on the manufacturer of the device the ABCC is embedded into as they are configuring and managing the state of the device.
Thanks for the quick reply, I will continue to bother Mitsubishi and Fairbanks.
Update: Turns out my problem was not with initiating the communication, it was with turning it off at the RUN - Stop - Run transition. Revised Code in the PLC with a timeout that watches for the No Data bit in the function block - then resets all bits to their startup state (this happens at power cycle because they are volatile bits) Then re- start the function.
Thanks for the follow up! This should be helpful for other that run into the issue in the future!
I spoke too soon. My solution works 3 times out of 10 Still having some issues with this communication, I am also getting errors during normal operation, all related to the socket portion of the communication. such as -
The target device cannot be found.
TCP connection is disconnected by the target device.
TCP connection is disconnected because of the rejection by Fullpassive side check.
The Specified connection has not completed Open procession
Connection was not established in OPEN processing for TCP connection
- what is the max time you can set the coms timeout for?
2.what is the max time you can set the Process timeout for? this is set to zero and from what I read in the documentation, once this times out, the connection is shut off from the Anybus side and must be restarted.
- where is the port number set .
I am trying to make this communication more robust, as it seems to be operating on the edge of proper function.
You can set the process active timeout with holding register 0x1003 it is a 16 bit number and should have a range from 0x0 to 0xFFFF milliseconds.
The modbus port number is not configurable on the ABCC.
Thanks again for the reply, so the max time the AB module would wait for a modbus message is 65 seconds, and the ethernet port is 502?
Process active timeout is the time the compactcom will allow between messages before it goes into its wait process state.
What you might be looking for would be the Modbus connection timeout. This setting specifies how long a Modbus-TCP connection may be idle before it is closed by the module (default is 60 seconds).
Ok, I can set both of these in the web interface.
As you mentioned, it looks like the Modbus timeout is what I am looking for, and since there is no condition where I would want the scale indicator to stop receiving messages, it looks like I could set this to zero and the system would always be waiting for Modbus requests
The process timeout is already set to zero
Update - Setting the Modbus timeout to zero keeps the connection ready to accept new commands. I can now stop the PLC program for at least 3 minutes (that is as long as I have tested up the this point) and when the PLC goes back to run, the communication restarts without a hitch. Thanks for all your help, you can mark this one as solved.
Great! Glad to hear this is solved!