Sending and displaying real-time data between Actors

[Mike_Le]

I've created a set of Actors that pick up data from a hardware source and display that data live in a Chart indicator.

The organization is pretty simple:

1) Controller Actor: Launches the Hardware, Plotter, and Analysis actors. Mediates messages between them.

2) Hardware Actor: responsible for setup and shutdown of communication with the DUT. As it picks up data, passes them up to the Controller.

3) Plotter Actor: picks up hardware data from the Controller and plots the data to the Chart. Also provides controls that let the user change what signals are plotting and what they look like.

4) Analysis Actor: picks up hardware data from the Controller for analysis; results and/or raw data can be saved to file.

The DUT produces data at a rate of 1kHz. It's theoretically possible to stream about 200 signals at this rate, though in practice it would be exceptional if someone were to gather more than 50 at once.

At first, I had the Hardware Actor pick up each data-point individually and immediately forward each point to the Controller. But the Plotter Actor down-stream had trouble keeping up with the 1kHz rate.

My fix was to have the Controller "batch" the messages. The Hardware Actor is still producing at 1kHz, but the Controller builds an array until 30 data-points have been received and then forwards the 2D array to the Plotter.

Now the system was fast enough for a few signals, maybe 5-10.

But as I add more signals, I find that my software starts to fall behind the hardware data.

A colleague suggested using a DVR to store the picked up data and passing the reference around instead of the data array. My concern is that this breaks the "contract" of Actors communicating only through Actor Messages. This thread was helpful, but I thought I'd start a new thread for this particular use-case. I imagine others have used Actors for streaming hardware data and have come up with better, more elegant solutions than I could!

[This is cross-posted from LAVA.]

[komorbela]

According to my tests on AF this behavior is normal. AF is just not the fastest messaging framework that can be implemented in LabVIEW. It has two components that make is relatively slow:

1. Uses priority queues. It makes sending atomic messages(messages with little or no data content) about 2 times slower. More on this: https://decibel.ni.com/content/docs/DOC-24589
2. Uses dynamic dispatch. Once per message a dynamic dispatch VI is called. It has an overhead and it makes atomic messaging 3 - 8 times slower. Read more on this: https://decibel.ni.com/content/docs/DOC-13709#comment-31559

Please don't take my numbers seriously as accurate measurements, but approximately these are what I measured at least on my PC.

If you read all the links you will understand the reason for AF being slow. I think you can get some speed by leaving out priority queues and use normal queues, but I see no immediate solution for the dynamic dispatch problem.

I have a similar system in work, and what I do is to use as much data in a packet as my GUI's refresh rate requires (so for a 1kHz signal to achieve 25 fps you can send arrays of 40 data points). I see that you use this trick for the Controller, but use it for the Hardware actor also.This way the user still experiences "real-time" behavior, but you spared with messages.

Hope it helps a bit.

Just have copied my thoughts to the original LAVA post. Sorry for posting here, didn't see that the discussion already got started on LAVA.
Message was edited by: komorbela

[dostini]

In one of actor my projects I use the Actor messaging for control messages and a different medium (notifiers) to share data between the different actors. The data media get constructed and the refs get passed around as the various actors start up. Then the "Go" message gets sent around and the actors start generating and consuming data at whatever rate they need to. This way the control heirarchy remains inviolate, and data gets passed around much more quickly than sending it through the actors' message queues.