The problem with that is NR will always be running late and the resulting processing delay will increase more and more. You must have a processing that is able to crunch incoming data at a comparable speed. I have seen this myself with a similar scenario where I am doing AI video analytics on incoming video streams. The little RPi is struggling long time after events have ended in comparison with faster machines that can cope with the load. If you continuously keep pushing readings 24/7 at higher speed than the machine is able to process it will get flooded. If this is used in a factory supply or production line application everything after will be delayed. In a warehouse application this would delay deliveries to customers 
1 Like
NR will always run late assuming reading rate is always equal to or higher than processing rate of NR. If that is the case, then just have more instances of node-red which pickup from the queue to match that rate (e.g if scanning rate is 1200/sec then have about 7 instances of NR processing at 200/sec with extra buffer added) . However, My assumption is scanner will scanning only in bursts with gap in between. In that is the case then as long as gap is 6-7 times the scan burst then single (or with a backup NR) can easily catchup during that duration.
If the readings can be queued somewhere before delivery to a Node-Red instance, that queueing mechanism can help you with many things such as:
- savely store items in queue in case there is no node-red instance running or unavailable for processing (overload resulting in backlog)
- deliver items in queue to multiple node-red instances to increase throughput and possibly your availability - in case one node-red instance has an outage
Plenty of opensource message / queueing systems are available that can be integrated in Node-red.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
