Modbus 6101 error

Question

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 

Answer 1

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.