Advice Needed for Distributed Measurement and Control System

[Shehezaada]

Hey guys!

I wanted to get some expert advice on a distributed measurement and control system I've been tasked to create for a research project. Essentially, I have to gather measurements from a number of devices on a LAN, where the devices can vary in make/model and communication protocol (power meters using MODBUS, proprietary communication protocols, or BACnet)  These devices have varying/intermittent response rates on the LAN, mostly due to their distance from the router. I've followed two approaches in the past with mixed results:

1) Centralized DAQ Loop
I try to go with an OO approach where the parent class is Device, and it's "Get Measurement" VI is overridden with device specific commands. A configuration file indicates the devices that need to be queried and the DAQ loop just takes care of any new devices that are added. The issue is that some devices have slower response rates than others, which slows down the thread considerably. Some devices also need to have their connection refreshed - which again, doesn't help. This was abandoned pretty early on.

2) One loop per device
Hacky solution but it's worked so far - each loop takes care of it's own device, with the timing being controlled by a software defined clock. Definitely not scalable.

Has anyone faced this in the past? I get the feeling that the Actor Framework might address this ...but just wanted to check before getting too far in.

Shehezaada

[Mads]

I would create actors/clonable module(s) for the different devices yes. That way you can dynamically create and destroy as many "loops" as you want.We do this in all our distributed monitoring solutions.

Before all the frameworks we have available now, like DQMH, Actor Framework, the Message Library etc., existed we just cloned device templates VIs, where each such template takes care of pretty much all the tasks related to that device (with the help of some centralized services for logging etc).We do the same for communication interfaces. So, for each serial port e.g. we have a port handler that the devices use as a middle-man to share that port.

Nowadays we use frameworks like DQMH to do much the same. Devices are now clonable instrument DQMH-modules that get initialized with a device object - which in turn contains an interface object in its private data (composition) which it uses to talk to interface DQMH modules. The various modules are created/destroyed by separate DQMH modules - a "Device manager", an "Interface manager" etc. We use broadcast events in the interface modules for example to facilitate debugging. If we need to figure out what it going on on a given interface, we can activate an observer which will then stream that data as UDP traffic to a debug client on the network...(One advantage of routing all the communication through such interface handlers instead of using semaphores or other mechanisms to share access.)

Edited September 14, 2018 by Mads

[drjdpowell]

One loop per device is very scalable, when combined with asynchronous calls to allow an arbitrary number of such loops.  The details are a bit tricky, but its the most scalable way to do it, which is why multiple people have generated frameworks to do it more easily.  

[Shehezaada]

Awesome replies guys - I'm assuming DQMH is the Delacor Queued Message Handler?

 

I really like the idea of a device manager like you suggested Mads. I'll give it a whirl. Thanks everyone!

 

[drjdpowell]

Yes, DQMH is Delacor's framework, and is on the Tools Network, as is Messenger Library (which I wrote).

Edited September 14, 2018 by drjdpowell

[Shehezaada]

Great work drjdpowell! Thanks a lot