LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timeout error (code 6101) for acquisition from MODBUS instrument

I am experiencing a problem which other users have reported, but for which little useful information has been posted:

I am trying to acquire data from an instrument using MODBUS RTU protocol.  The code works as desired for a while, but will intermittently stop executing and give a timeout error, code 6101.  This code seems to be associated with the MB Serial Master Query sub VI.  In the past, I was getting this error as a result of RF noise corrupting the signal in the USB connection to the instrument.  Removing the USB cable from the noisy environment eliminated the problem.  I am now having the problem with an RS 485 line in the noisy environment, which should be very stable in noisy environemnts. 

My question:  is there a coding trick i can use to reconnect in the event that a corrupt signal occurrs (or some other problem which results in the intermittent appearence of the error 6101)?   I've increased the timeout value on the MB Serial Master Query sub vi, but this hasn't helped.  Any input is appreciated.  In case it's useful, I've posted a simple version of code which generates the problem. 

Thanks,

Paul   

Download All
0 Kudos
Message 1 of 15
(16,928 Views)

Are you getting popup error messages for this timeout?  Don't forget to wire up your error wires!  Don't use a shift register but just regular tunnels for the error wire otherwise if an error happens once, it will prevent the modbus read/write from ever executing properly again.

You could put the modbus read in its own loop.  In the event that the timeout error occurs, you have the modbus write/read happen again.  (You may want to put some additional code in there to be able to stop the loop on other conditions as well such as only reattempt the MB WR 2 or 3 times before just returning an error.)

If it's noise, increasing your timeout won't help because if the noise corrupts the message, you will never get a valid message back.  The timeout is only used to provide enough time for the other device to get a valid message, act on it, and respond to it in a reasonable amount of time without the calling program to wait endlessly for a message that may never come such as in your case due to a corrupted transmission.

 

Message 2 of 15
(16,913 Views)

 

Thanks for your input, Ravens Fan.  I am indeed getting a popup error message with the timeout.  I agree that putting the MODBUS read in its own loop would solve the problem.  However, I'm struggling with trying to figure out how to actually do this.  Should I put the read in a case structure or a while loop?  How do I go about looping back to re-execute the read statement?  I think so called "state machine architecture" seems to be where I should be going. Some example code would be greatly appreciated. 

paul  

 

0 Kudos
Message 3 of 15
(16,878 Views)

Attached is what I was talking about.  It retries the MB R/W for 3 times or until there is not an error.  Of course with a 10 second timeout, it will take 30 seconds to return assuming you have a real communication problem rather than something spurious that only affected one MB R/W cycle.

I don't know how this code will fit into your larger project.  A state machine architecture is definitely worth while to look at.  But for the basic read/write intepret the data code you posted here, I didn't see the need for the state machine, so I just added something to allow you to try the read write a few more times in the event of an error.

Message 4 of 15
(16,870 Views)

Ravens Fan, you're AWESOME!  Seriously, this is a huge help.  I had never done anything with error handling previously and was quite stumped.  The code you posted will fit well with my project.  I'll reduce the timeout since it doesn't need to be set at 10 seconds.  Thanks!

Paul 

0 Kudos
Message 5 of 15
(16,865 Views)
I'm glad you like it.Smiley Happy  I think when I've used the MB read/write VI's, I set my timeout to be on the order of 2 seconds.


Message Edited by Ravens Fan on 05-14-2008 04:35 PM
0 Kudos
Message 6 of 15
(16,863 Views)

Hi Ravens Fan, I saw your conversation about timeout error and it helps a lot, but now I´m struggling with another problem. My device is a Eletric Meter, MODBUS RTU, i´m using your program floatingpoint.vi and i can see through  serial inspector program that the connection is happening. I´m also using just one function of MODBUS, 4-read input registers,but in labview the correct value doesn´t appear. The manufacturer of my device send me one table with MODBUS adresses  and their respectives meaning. For example, V1(Voltage-one) have adress (9216)h, 2 registres and 4bytes,  type float, standard IEE-754. I put these parameters in labview,  but i see some numbers that doesn´t make sense! Maybe I need to change some configuration, but i don´t know wich!! Any help will be welcome!!

 

Regards!

 

0 Kudos
Message 7 of 15
(16,459 Views)

9216 hex works out to 37398 decimal.  A 30,000 series register is an input register.  So you would use function code 4 (Read input registers) which sounds like what you are doing   .....  at address of 7397.

 

Is that what you are using?  What kind of data are you seeing and what do you expect to see?  Examples of real data (in hex display) and expected data would help.

 

In my example, I had to swap the order of the two registers before typecasting.  Perhaps that is not necessary for your equipment.

0 Kudos
Message 8 of 15
(16,454 Views)

Hey, sorry for hijacking this thread even though it is very old, but i have the same issue with the timeout error 6101 using modbus, it would be great if you could assist me.

 

Thank you

 

Damien

0 Kudos
Message 9 of 15
(14,113 Views)

Hello Damien129, 

 

To truly diagnose the issue you are experiencing, I would like to ask you to please provide more details in regard to your system and when this error is occurring in your code. However, this link will provide general information on the error (a timeout error that is caused by the failure of the communication between the client and the server), and the probable causes/solutions for this failed communication. 

 

Wes W
Application Engineering
National Instruments
www.ni.com/support
0 Kudos
Message 10 of 15
(14,090 Views)