Modbus blocks other threads

If I don’t have another Mobus device connected to my SITcore based board so Modbus master blocks when listening for a reply. This messes up the GUI touch so trying to do any configuration changes means that the user can’t use the interface.

Anyone else has seen this issue?

I have a fix for this. Add this as line 192 in ModbusRtuInterface.cs

Thread.Sleep(0);

Modbus appears to still work as normal but any timeout doesn’t block your other threads. :slight_smile:

My guess, UI uses dispatcher for events and not having a sleep would prevent the dispatcher for working properly.

1 Like

Modbus blocks other threads · Issue #1099 · ghi-electronics/TinyCLR-Libraries (github.com)

Thankls

1 Like

Do you have any simple project to reproduce. We are going to add sleep(0), but we are wondering that, would it be sleep(1) is better?

I just read through that code. It looks like it spins in a tight loop consuming all the processor time waiting for the next read interval. While a sleep(0) gives other threads a chance to run, a correct fix is to sleep until the next read instead of spinning until the next read. That’s much kinder to other threads that want a shot at running.

There also may be pathways through the code where the next read time is never set though I don’t think that contributes to the problem - it just makes for a tighter loop and more serial reads.

1 Like

Is this what you are playing with this holiday? Hint hint

This would be important when you are working as a slave device, although I have not yet fully tested this but I am working on code this week with 1 device as master and a second TinyCLR board as a slave along with another non TinyCLR Modbus slave.

Dave: What I am saying by “tighter loops” is “tighter than necessary for RTU”. There’s a lot of time you can spend doing other things between passes to dequeue the serial fifo without risking overflow. By hogging the cpu, it’s not making the reads faster or more reliable - just starving out other threads.

The algorithm already calculates a ‘next read time’ - but instead of yielding that time to other threads, it burns it up in loop cycles.

Gus: Oh how I wish. We are still in Europe and I am hardware-deprived. We head back to the US in around two weeks.

2 Likes