Jump to content

Vision Series Modbus Communications

Recommended Posts


I have a V570 that is being polled by VTScada via ethernet, and it works GREAT 80% of the time. Connection is great yet sometimes the PLC will just quite responding. You cant ping it. you cant poll it with a utility like MODSCAN. And the only fix i have found is reinitializing the ethernet card, socket 2 init, and modbus IP config block. This will bring the PLC back online the next time it is polled.


Any ideas what could be the issue? 

Thank you!

Link to comment
Share on other sites

  • MVP 2023

Kratmel and Flex questions very pertinent and if none fix, some other points to ponder. 

So you can't access it at all, even with Visilogic simply using Get OPLC Information in Connection?  I'm thus assuming that you have the reinit as part of your coding, initiated by screen, which then resurrects everything?

No VFDs or poorly shielded interference going on?

Is it only on a LAN, or does it involve use of WAN?  And static address there, or dynamic?   If the dropout is occuring around certain times I'd check the router settings.  I once had a forgotten instruction in a router such that when it did an auto-reboot, it upset comms to only the PLC.  Took lots of inspecting settings pages to pick it up, which resulted in much personal grumbling  afterwards.  🙂

cheers, Aus


Link to comment
Share on other sites

Thank you all for your help.


I have sb168 = 1, I left that as is.



The PLC is being polled over a WAN Network about every 2 minutes. I recently found the keep alive settings SI103-106, and set a value of 50 in SI105 I  believe for a couple sites to test with. ( I am using socket 2 as it is standard for modbus communications)



Going through my WAN connection I can still get OPLC information and go online with the PLC (so I know the WAN connection is okay), but no modbus communications seem to make it to the PLC. I watch  the corrosponding SDW and do not see the soclet 2 RXD total session increment ever. 

So my fix was to go online with the PLC and reinitialize the ethernet card, socket 2, and the modbus config block

No other devices such as VFDs or anything that I would guess make a lot of noise.





Link to comment
Share on other sites

  • MVP 2023


1.  Wondering if you are doing polling too quickly, and eventually the requests accumulate to the point of not being able to be handled?  Especially if a retry is needed, you might possibly be exacerbating things by then getting into timing overlaps which might clang things completely.  Perhaps try adding a longer delay b/n requests.  Or...for a very simple initial test....drop the retries back to 1.

2.  Implement an auto reset if a request is not received or handled properly within an appropriate time.  Also attach a count to this reset to show how many time it occurs.  To make it even better, also log time and date.

cheers, Aus

Link to comment
Share on other sites

  • MVP 2023

If you're going through a WAN network there is probably some packet clogging going on and the socket is closing itself.

SI 101 is the packet timeout in units of 100 ms and defaults to a value of 2 (200 ms).

Try setting it to 10.

If that doesn't work, get an old-school Ethernet hub that re-broadcasts all traffic out all ports.  If that's not available see if you can get a managed switch an map two of the ports together so you can observe the traffic between your SCADA software and the PLC.

Then download WireShark and learn how to use it.  I ran into this problem a few years back trying to talk to a V350 using a pair of cellular modems.   You can set up WireShark to only show port 502 transactions.  WireShark timestamps everything to 1 millisecond accuracy.  I found that by sniffing the packets between the Master and the Slave that the Modbus requests were getting through but the PLC closed the socket before answering sometimes.  The delay was about 800 milliseconds in my case.

Gremlin problems like this require a deeper dive into troubleshooting.

Joe T.

Link to comment
Share on other sites


I have my modbus config in the main routine right up at the top. But it is good to know for the future that it should be included in every scan.


I like your ideas to write some traps and debugging tools. That is a great idea and I will certainly try that.


I increased my time in SI103 and I think that has helped. I have not had issues with any sites where I have changed that value. But if one comes up I will try your idea. Hoping not to have to pull wireshark out sniff the packets. Butttt, I suppose this is what makes us the experts.


Thank you all!

Link to comment
Share on other sites

Thought I would come back and provide what seems to have solved the issue.

For reference I am using Socket 2...

When a remote site would go into comm fail, I was able to go online with the V570 and set a value of 50 in SI105. From there I would manually reinitialize my ethernet card, plc name, socket init, and modbus configuration. 

On all sites that I have done this for I have had no further issues.  Hope this helps someone else in the future.

  • Thanks 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...