DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

2 different main VIs in the same DQMH module

It may just be plain stupid but I'm considering duplicating the main.vi in on of my DQMH modules, let me explain :

My module is a data concentration module, it receives data over the network from multiple different sources, aggregates the data, passes the aggregated data to some "data processing" modules.

 

I have a Data Replayer app that acts like the data sources and streams data over the network in order to test my data concentration module but in order to facilitate the validation on the data processing module I'd like to simply load the data - already aggregated - from a file or database and pass it to the data processing module, thus removing impact of the network.

 

Normal operation :

TiTou_0-1641851727426.png

 

Simulated :

TiTou_1-1641851757851.png

 

To implement this I first thought of creating a different module to be launched instead of my data concentration module, but I just thought that *maybe*, do a "save additional copy" of my main.vi, called it main-simulation.vi and the edit the "Start Module.vi" by adding a boolean input "Simulated module?" and launch either main.vi or main-simulation.vi depending on this input.

 

I does sound a little lazy-ish but appart what rules would I be breaking and what issues would I expose myself to?


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 1 of 11
(1,674 Views)

I would suggest creating a class hierarchy for your data generator and creating  a simulated child class.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 2 of 11
(1,662 Views)

I would always recommend simulating the behavior of your code. I do this in any case to test the functionality of my VIs.


The best solution is, as Sam wrote, to do it via classes. But it also works via case structures, which simply call other sub-VIs if you are not familiar with classes.

Message 3 of 11
(1,634 Views)

@Taggart wrote:

I would suggest creating a class hierarchy for your data generator and creating  a simulated child class.


I've done that in a different scenario and it went well, in the current scenario I'm a bit reluctant to go this way in fear of over-head in execution time that dynamic dispatch would introduce.

This data concentration module is the bottleneck of my dataflow so I'm trying to keep it as efficient as possible.

Am I being overly paranoid about dynamic dispatch introducing over-head?

 

Edit :
At this point all options are on the table. I've never dug into the magnitude of the over-head that dynamic dispatch would introduce, anyone has any clue?

 

All I could find was this NI document "Decisions behind the design" (last updated in 2009 if I'm not mistaken)

And this discussion on LAVA, which is also a bit old.


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 4 of 11
(1,624 Views)

Based on what I heard in the past and my own experience, I feel that before removing a possible over-head due to dynamic dispatch, it's better to look into the code to find optimization.

 

Saying it differently, I don't think dynamic dispatch can be an issue here, but I didn't see your code. I may be wrong…


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 5 of 11
(1,608 Views)

There is most definitely a performance hit for using dynamic dispatch (mostly, it seems, because inline is not an option for DD). Depending on your timing constraints, that might or might not pose a problem. We had to move away from DD in one of our projects where we had to execute a timed loop on a real-time target with a loop iteration time of 50 micro seconds.

 

A little bit more information can be found here: https://dokuwiki.hampel-soft.com/kb/ni-rt/performance#empiric_proof 

 

For those with access to the Champions forum, there are some interesting discussions there: 

Determinism, jitter and timed structures on RT 

Execution time of Dynamic Dispatch LVOOP vs. Cluster and SubVIs on Real-Time




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 6 of 11
(1,603 Views)

Thanks all for your insight.

 

I'll let this topic mature a bit in my head and have a design review with my team.

 

 


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 7 of 11
(1,599 Views)

Do we speak about a Real-Time-System here? Is this a highly optimized system where this really counts? 

I made the same experience like Olivier said. In most cases there are other optimizations which weight much more.

0 Kudos
Message 8 of 11
(1,595 Views)

Nope, it's not an RT app, most the time it runs on Linux (Ubuntu), sometimes it runs on windows and it also can de deployed on Linux RT but this is being slowly phased out.

 

I fully understand and appreciate Olivier's comment on focusing on making sure the code is well optimized before worrying about potential micro-seconds overhead of DD.

 

As I said, this module is our dataflow bottleneck, we do spend a lot of effort to benchmark it and improve it when possible.


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 9 of 11
(1,566 Views)

@TiTou  a écrit :

I fully understand and appreciate Olivier's comment on focusing on making sure the code is well optimized before worrying about potential micro-seconds overhead of DD.

…and I fully appreciate Joerg's comment and its experience on RT I don't have 😅 (I think I love learning things 🤗)


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 10 of 11
(1,550 Views)