A custom HAT was built for a RPI 2B. This board has a PIC micro-controller that communicates with Proview via serial ModBus RTU.





For ease of software and firmware development, the HAT can be removed from the RPI and connected directly to an Intel-based Proview Workstation via a standard FTDI USB cable.




Initially, the PIC uP was programmed as a ModBus RTU Slave, where Proview initiated questions and the PIC returned answers received from field devices. Field devices communicate to the PIC board via a 433 MHz receiver (not shown). That approach worked fine.

However, due to extremely limited RAM, the PIC was reprogrammed as a ModBus RTU Master and Proview as a Modbus RTU slave. As field information is received by the PIC, the information is passed to Proview as Single or Multiple Register writes. Also, once per second, the PIC sends clock seconds to Proview as a WDT. So far, so good. The PIC board also has an IR detector that receives commands from a TV remote. TV remote commands are also pushed to Proview as ModBus RTU Single Write Register commands. For comfortable use, TV commands must be received by Proview within a 1/4 second or faster.


My question is focused on maximizing Proview ModBus RTU Slave performance. A one-second WDT single register write is received without errors for days on end. However, when a burst of information is received, Proview ModBUS RTU slave cannot keep up. Even if scanned at 50 times per second. Multitudes of communication errors are reported in Proview. My understanding is serial inputs are buffered by Linux, 4096 characters by default. PUTTY can keep up without errors at 9600 baud with or without 3.5 character spacing between messages. So, I'm fairly certain the ModBus communications are being received OK.

Empirically, my conclusion is Proview ModBus RTU slave can handle only one ModBus transaction per thread scan. Proview can receive Multiple Register writes in a single transaction, OK. But, if two or more messages are received between thread scans, communication errors occur.

So what to do? The issue seems to be a lack of hand-shaking between the PIC and Proview. It seems there may a few possible paths to pursue:

1) The PIC uP sends one write command, then must wait for a Proview ACK, before sending the next write command.

2) Reconfigure Proview as ModBus RTU Master and PIC as ModBus RTU Slave. But, there is the limited RAM issue.

3) Choose a protocol other than ModBus?


Your suggestions and comments are solicited.

/Ron

Update: Option 1) has been implemented and tested:

The PIC uP sends one write command, then must wait for a ModBus Response before sending another write command.

In this case, the PIC is self-throttled to push messages no faster than Proview can handle. Results are very good. Proview responds, beautifully! The PIC is sending twelve ModBus RTU single register writes per second to Proview at 9600 BAUD, but waits for a ModBus response before sending the next command.

ModBus protocol specifies a minimum 3.5 character delay between successive messages. Obviously, BAUD rate limits maximum throughput, too. At 9600 BAUD, twelve message per second are sent and received, even with a Proview Modbus thread scan rate of 1.00 second. Twelve message transactions occur "under the surface" without errors. The Modbus_RTU_Server Module's RX_packets and TX_packets counters show multiple packets received and sent per thread scan. Of course, Proview's ModBus registers update only as fast as the thread scan time. But, that's fine. The goal of this exercise was to maximize ModBus RTU throughput without communication errors. That goal has been achieved! Proview performance is more than adequate for this particular application.

/Ron