LV Modbus library 1.2.1 - Error code 6101 (timeout)

[antsundq]

Hi, have you solved the timeout problem yet? Are you able to communicate over the serial lines e.g. in MAX? Could you share some code so that I could get a better picture of the issue and see if I can find something that might be causing the timeout error?

[Woss]

this is a known bug about this modbus library with serial communication and it occurs in MB serial Receive.vi on the frame "Read the slave address of the query to make sure it's for this slave.":
http://gyazo.com/59652125ed9add7ebbb5472d41b54493

here it looks for a byte with the slave adress, however, it will also be triggered if a msg containing a byte equal the slave adress also arrives to the port. the program will then expect a proper response from the slave device, which will never come and it will timeout.

What could be done is to check if the 2nd byte after this slave adress is a function code (1..7, 15, 16). If not, then this byte was not the 1st byte of the response from the slave -> go back to waiting for the response from the slave.

If by any luck that 2nd byte is also a function code, u could also check if byte at port = 0 for more than 3*1000ms/baudrate. if it happens, then the msg was again not the response from the slave -> go back to waiting for the response from the slave

[RavensFan]

I'm sorry, but I don't believe there is a bug in the modbus library on this point.  I've used the library for years and have never had a bug like you describe bite me.  And I'm quite sure after all those years, the value of my slave address (1 of only 256 possibilities) has occurred as part of other data in the serial stream.

[mbr]

Thanks all for help, I found that error appears also during register write, not only when read. The same MB Serial Master Query.vi is used for read/write as polymorphic vi so MB Serial Receive.vi is included in read/write cases.

Anton, at the moment solution is error handling, just ignore timeout errors and retry until operation successful, retry limit=100 and vi timeout is set =100 ms which is normally enough. Program structure is simple; read/write operations inside while loop.

There was also some discussions and cases about asserting/unasserting serial Line RTS State for 1 ms with property nodes?

[Woss]

Hi Ravens,

I might be wrong of course but I came to this conclusion a few years ago after reading this post:
http://forums.ni.com/t5/LabVIEW/Modbus-problems-with-multiple-clients/m-p/1607926#M583484

In the other hand, I never use modbus rtu with labview, only modbus TCP, so I never really looked into it. Good luck.

[smithd]

That post is inaccurate about the solution. I mean the crc=0 check should be accurate most of the time but isn't perfectly reliable for finding the end of a packet. The solution I've seen people use is a combination of waiting for N character times of silence and manually parsing the packet on the fly to determine expected length, things like that.

The truth of the matter is just that RTU is hard to use. Its a protocol without any reliable delimiters. When using a protocol which can't reliably distinguish between me unplugging the serial cable and the end of a well-formed packet, timeouts are a part of life. If you can move to TCP or ASCII code should behave better.

[francoisbeulz]

Bonjour,

Je suis débuté en Modbus c'est pour cela que j'ai regardé de nombreux sujets de discussion sur les forums NI etc.. j'ai donc téléchargé la bibliothèque modbus, j'en ai même téléchargé et essyé 3 différentes, j'ai suivi tous les conseils que j'ai pu lire malheureusement mon programme ne fonctionne pas. Le but est de commniquer avec le controleur de température CAL 9400 afin de lui atribuer un setpoint et un heating rate notamment. Mon Pc portable est relui à lui grace à un adaptateur USB-RS232 et un autre cable RS232 qui fait relais. Aucun des exemples ne marche et j'ai à chaque une erreur différente. Je privilégie plutot l'exemple 3. J'ai donné l'adresse 1 au controleur de température qui est ici le " slave", mon PC étant le "master". Pourtant en entrant l'adresse 1 dans mon programme j'ai l'erreur 6101, alors que si j'entre l'adresse 0 dans mon porgramme il n'y a aucune erreur mais rien ne se passe non plus pour le controleur, quelle que soit l'adresse que je lui ai attribué, je ne comprends, pouvez-vous m'aider s'il vous plait ? sachant qu'il y a trois types de data pour le controleur apparament : 18ni,18E1 et 18O1 je ne sais pas ce que ca signifie.

Vous trouverez ci-joint les trois exemples que j'ai essayé ainsi que la documentation sur le controleur de température et la manière dont on communique avec lui en modbus.

[smithd]

Hi francois,

You might have more luck posting here:

https://forums.ni.com/t5/Discussions-au-sujet-des-autres/bd-p/4170

I can try to help, but I am limited by google translator.

It looks as though you are seeing a timeout error in all three APIs. For serial, this usually means a communications error.

First, make sure your device is configured as address 1 or higher. For modbus, address 0 is a broadcast address (this is why you see no response). I would recommend address 1.

The other setting that causes problems with serial is parity and stop bits. I did a search for your device and found that the data ("18n1" etc) elements are related to these settings. Take a look at page 7, here: http://www.advindsys.com/Manuals/CALManuals/CALgraphixappguide.pdf

I would recommend option 1. The default option (none parity, 1 stop bit) is not valid according to the specification. See page 12 here: http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

"Even parity is required, other modes ( odd parity, no parity ) may also be used. In order to ensure a maximum compatibility with other products, it is recommended to support also No parity mode. The default parity mode must be even parity. Remark : the use of no parity requires 2 stop bits."

Thanks,

Daniel

[francoisbeulz]

Hi, Thank you for help it's working now. I think the problem was the USB-RS232 cable.