modbus 6101 error

[Trinity32244]

Looking for advice/help with an issue.  I wrote an applicaton (LV2011) and built it with application builder for a customer. This project is out of the country and was working when I left ( around 2 hour test while I was there).  They are saying that now they are getting a 6101 time out error message after an hour or two of running and they have to close and then re-open the application to re-establish communication.  I am using the modbus library to communicate with 3 station addresses (plc and 2 vfd's).  Everything so far to me is pointing to noise distortion probably happening at the USB to serial converter.  I actually have a USB to RS232 converter then RS232 to RS485 converter attached to a USB port on the project.  The run is very short (less than 20 feet) and I did not use termination resistors at the beginning or end.  I am not to good with networking and am at a loss for what is happening.  I have read up on USB which seems to use 5V levels for communications which is much more suseptable to noise then the 12V levels of RS485.  At my facility when I connect a USB to RS232 converter and do not attach anything to the serial side I get a Modbus error not a general 6101 timeout error.  Now this could be because I am not intializing properly to begin with and they are but not sure and will run some more test with equipment hooked up to get past the initializing function and then simulate dropping the communication ( I think I remember that is also a specific modbus error not general 6101 error).  If that is the case where they are actual modbus visa read/write errors and not a general 6101 error then to me it is sounding like an error at the protocol level (i.e. RS485 or USB) and not at the application protocol level (i.e. modbus).  Excuse me if that terminology is off (not really good with networking and only know enough to be dangerous).  Anyway I am not sure where to go from here so any advice where somebody has seen an issue where it is working for over an hour and then loses communication would be extremely helpful.  Thanks in advance 

[Daniel-H]

Trinity,

Are you doing any noise filtering on this signal since noise might be an issue?

What type of noise are you seeing?

Also this forum post relates to the same error. It appears to be related to the data, however, and not noise.

Daniel

[Trinity32244]

Thank you for the response.  I have seen many forum post for the 6101 error using modbus.  My issue is that everything is working fine for 1 hour sometimes 2 hours with no errors .  Then loses communication (but is random timing and usually after the error first happens it is more like 10-15 minutes between comm errors).  In my mind this means the code is correct and then something happens to cause this issue.  Right now I leaning towards the USB being the issue and I have them going direct from another computer that has a RS232 port.  I have not got the results from the new test without the USB converter variable but will post my findings. In the mean time if anyone has any insight on what could cause the loss of communications after such a long period of working perfectly please let me know.  By the way I have them setting the priority of the applicaiton to "high" from the task manager. 

[Trinity32244]

Got some results and figured I would share to see if anyone has anything further to try.  At this point without the USB->RS232 converter and going directly from a RS232 port on the computer they are getting much better results.  The last test lasted 2 days before recieving the error.  My thinking at this point is that since they still got the error that it is most likely noise (vs. bad usb->RS232 converter) and the USB to Serial converter just failed much sooner and is probably inherent to USB communications in general.  I have an extremely short run but am going to request that they try to install a terminating resistor (120 ohm) for the communications to see if this helps further.  Any input from anyone else that has been in a similar situation with Labview would be extremely helpful.  Thanks

[LV_Pro]

What is required to continue running after the error? I had a problem about a year ago with the USB-Serial port  dropping out (actually it was the motherboard's usb port "glitching") with Windows changing the Comm port assignment after the glitch, causing my program to error. I'll look through my notes to see if this might be related, I was set up for RS-422 and was sending MODBUS commands, but that might be "noise" in resolving the problem.

Ok, here are a couple of my threads (from two years ago, my how time flies) dealling with a similar sounding problem. It is one thread with a link to the other.

[Trinity32244]

Thanks for your reply.  I actually read your threads previously when looking up my issue.  I am trying to get more information from my customer now.  Of course when it failed my customer was not there and the maintenance guy just restarted Windows and the application to get it back up an running and does not remember what was on the screen at the time.  There is also a language barrier I am fighting through but after reading your old posts and some others I wanted to list a few things to see what your thoughts are.  

-My customer mentioned that the incorrect serial communication port was selected for the VISA resource.  I only give my customer this option when the program starts up and then they do not have access to change it later and is required to restart the application to change it.  This could have been a result of the maintenance man trying to restart the application and selecting the wrong port but I did read your post where something similar happened with what you called MAX at the time (not sure what that is but figuring it may have been similar to the VISA resource).

-I do not have any waits in my while loop that is doing the communications that is running in parallel with other code which seems to be an issue for others in the past?  Not sure why (although reading up on this seems to have to do with CPU usage) but the computer is meant to be dedicated to the application at hand so I am fine with as much of the CPU being delegated to the application as possible since they are not suppose to be using the computer for anything else.

-With the change to only RS232->RS485 I am getting at least 2 or 3 days of working performance.  I am new to Labview and using Windows for industrial control but in my experience in the past with regular HMI's and PLC's if the code works for 2 days it will work indefinitely the same way until an outside influence affects it (i.e.. Generator starting up, lightening strike, ect).  For me this just seems like a very long time to work and then stop but again I am not really a fan nor am I used to using Windows.

-Trying to trouble shoot this and using what I have found so far I am logically trying to think about what could be happening (not using the PC itself or Windows in the equation because it adds to many variables):

First Item

-USB converter in the equation was working for upwards of 2 hours and then dropped communication with a 6101 error and could not regain it no matter how many times the user clicked ok.  Basically went the specified timeout period and then throws the error again every time  once it fails.  Also when restarting the application after getting the error results in the program working but fails in significantly less time ( i.e.. 10 minutes).  

First Conclusion

-Trouble shooting tells me that the code I wrote is probably fine and noise eventually distorts the signal beyond repair.  This conclusion may be incorrect as I am used to dedicated hardware (i.e. plc's) that when it works once it works the same way every time.

Second Item

-Taking out the USB converter and use the on board serial port extended working time from 2 hours to 2 days.

Second Conclusion

Again leans toward noise being the culperate since the serial performed much better but still failed.  If it was simply a hardware problem with the USB converter then I would expect the system to run perfectly now and problem solved but since both methods eventually failed it now seems that the problem still exists but the Serial communication handles the problem better than the USB which higher voltage levels of serial communication probably allows for more signal distortion then lower voltage levels of USB.

Anyway figured I would put down in words what I am thinking so that if my thought direction is not correct or I am not considering something that should be considered you may be able to explain to me other influences that need to be taken into account.  Thanks in advance for any help you can provide in corrected my thinking or advice on things to try.  For now on the next failure I plan on getting the time period between start and failure, checking what is required to get communications back (i.e. simply clicking ok on the error or restarting the application), possibly having them install the terminating resistor (120 ohm) at the end point to see how this affects the system.

[Chris-G]

Trinity,

Here is a link to a really good, in-depth article discussing using bias resistors and noise considerations in general. Take a look and maybe it'll at least give you some basic advice as to how you can reduce the noise in your system.

That of course is assuming the source of the problem does lie within the system noise...

Chris G

[subbzz]

Hi,

This is one of the major issue even i experienced dealing with same configuration what you have mentioned. Even i had used a plc and a vfd with usb to serial converter and then 485 converter. After a long fight with setup i cleared that issue by just replacing the communication wiring with shielded cables and with PROPER EARTHING (of course i forgot to connect the earthing wire to VFD which was in multidrop with the plc).

Hope this could help you in your case also...

[Trinity32244]

Thank you very much for the response of similar conditions.  I also am using 4 VFD's in multi-drop and ending with the plc.  I have shielded cables everywhere which are all properly grounded.  I have not got my customer to start the test again yet and have been waiting to post results.  So far it is working fine in 1 day incriments.  Once I get a solid 4+ day test I will post my findings.  I have not installed the termination resistor yet as I do not want to add any more variables until proper results come in from eliminating the USB to Serial Converter.  Dealiing with communications is always a nightmare

[Trinity32244]

Thanks Chris for the link.  That is a great indepth look at electrical noise.  I will save that link for future reading (to much information to obsorb at once)!