Interesting Modbus Library Behavior with RS-485 RTU Serial

[K C]

Your VI runs Ok on my device. 

I started to change your VI and I got an error after 200-500 loops. 

The error occurred in the Write VI but not a time out. See screenshot.

Working on my computer with other things the fault disappeared !?!? (no error after 5000 loops)

Just to get more info, can you try the modified VI ?

I saved it in LV 2020 I believe that is the version you are using. Changed the default values.

Kees

<EDIT>

Same error after 15377 loops.

[rhenderson]

That's some fun loop work you did to clean some of that mess up. The array'ing and indexing is a cleaner way for sure.
Will be testing today on the desk with it. Just downloaded it.

[rhenderson]

Some quick testing after I changed the parity back to Even. Saw you had it at None. My devices needed it at Even.

***Edit - I'll spy on these lines as well with the logic analyzer and redo.

[rhenderson]

Timeout on Read 16 Registers from Device 01

Good Read 16 Registers from Device 01

Timeout on Read 16 Registers from Device 05

Good Read 16 Registers from Device 05

Assuming the error behavior is standard LV, an error on a read would prevent the rest of the VI from executing. If that's correct, what's interesting is that my physical trace record using the logic analyzer never records a response to that read request. Either the end device misses it or the request is malformed?

[K C]

It kept me thinking and I worked further on it. Also because we use ModBus and multiple slaves already for a very long time.

I don't use the MB lib. We have dedicated MB commands and I started with MB and LV before the lib was available.

There are some MB timing rules that that are important. Most of them are from the time that low baudrate were used.

But with todays (fast) computers it could be too fast. 

Important is the time between two MB messages. It depends on the baudrate. At 9600 baud and above it is a few msec.

If I remove the delays in my VI's I also get a time-out error sometimes (after 10k-50k loops)

The delay must be at least 3.5 character time long.

If two MB messages are sent directly after each other a slave will see this as one command if there is not enough time between the two commands. This results in a wrong command with an incorrect CRC. The slave will ignore this message.

In my VI's this delay time is fixed to 5 msec. Low baud rates are not used anymore.

I added my VI's to your VI. Can you try this one?

Kees

[rhenderson]

Absolutely will do so. Apologies on missing this until today.

[rhenderson]

I'd say unequivocally that your library does better than LV's and also that I might have a device issue as well. I tested your library at a various amount of delays as well as the LV one reading the same registers, same wiring, same adapter, etc.

Next step would be to load into the cRio and use the hardware RS485 rather than the usb converter I have been testing on the desktop computer. Might get more deterministic behavior on the rio?

Library	KC	KC	KC	KC	KC	KC	LV	LV
ms Delay	0	1	2	3	5	10	0	2
1	0	58	637	246	719	31	210	33
2	65	496	719	1177	26	76	111	41
3	0	668	1124	1118	18	18	81	618
4	8	10	3135	1425	474	8	121	21
5	43	213	484	767	42	8	904	37
6	52	15	476	649	710	90	380	130
7	8	874	785	973	194	100	290	61
8	114	535	5648	169	734	0	71	0
9	5	220	1395	352	600	22	1204	396
10	0	640	770	159	7	13	24	326
Average	30	373	1517	704	352	37	340	166

[rhenderson]

Even better results on the rio.

Up to 11K using the 2ms delay. I assume it will fail overnight, but this indicates to me there is something way better about how KC's library does the timing vs how the LV library does them.

Of the 4 runs thus far on the rio, I have 4072, 5008, 16567 and over 4K now.

[rhenderson]

Still think the KC library is better than the LV included. 38400 also better than 19200 at least with 2ms delays.

Library	KC	KC	KC	KC	KC	KC	LV	LV	KC - cRIO	LV - cRIO	KC - cRIO	LV - cRIO
Baud	38400	38400	38400	38400	38400	38400	38400	38400	38400	38400	19200	19200
ms Delay	0	1	2	3	5	10	0	2	2	2	2	2
1	0	58	637	246	719	31	210	33	4072	109	1996	36
2	65	496	719	1177	26	76	111	41	5008	121	466	124
3	0	668	1124	1118	18	18	81	618	16567	188	319	299
4	8	10	3135	1425	474	8	121	21	8044	41	142	102
5	43	213	484	767	42	8	904	37	6319	201	617	45
6	52	15	476	649	710	90	380	130	15396	75	261	186
7	8	874	785	973	194	100	290	61	4067	37	144	35
8	114	535	5648	169	734	0	71	0	8921	44	526	92
9	5	220	1395	352	600	22	1204	396	666	162	826	143
10	0	640	770	159	7	13	24	326	13543	185	237	244
Average	30	373	1517	704	352	37	340	166	8260	116	553	131

[K C]

Still doesn't look good. The delay of 2 msec. or more should be enough. It is clear that there is something wrong. It should work without any errors.

Did you try a long delay, let say 10 msec. ? This because the result gets better with a higher baud rate.

I will think about it further, but for now I am out of options......😕

Kees