Best Practices for Acquiring, Processing, Sending Out, Logging, and Displaying Data in One VI

[tsr26]

Hi all,

Attached is a project [in LV 2015] that I am starting from scratch for a rehab device in my lab. I am a PhD student and have been using a different (old) LV program to control the device for years and finally am taking to time to redesign it properly. I am looking to use all best practices possible so that this code can be maintainable, expandable, and robust. 

     In the project folder there is a 'resources' folder that has a Word Doc explaining my headspace and ongoing design considerations I have.

     Essentially I am looking for people with more LabVIEW savvy than me to look at my code skeleton and tell me what I could be doing better before I get too deep into this. I am a one-man team and am amenable to just about anything. But being a one-man team also means not a lot of engineering collaboration...That being said I greatly, greatly appreciate anyone's insights. 

     I tried to clearly outline what the program needs to do and why I designed it this way, I am happy to clarify anything.

     I am using DAQmx to collect and send out analog data to servo drives. I am also communicating with my motor servo drives via MODBUS TCP to change values of certain registers if that makes a difference in terms of how I structure anything. 

[bheemann]

Hi,

I had a quick look:

- use version control instead of "...v1.vi"
- in most cases do not use "wait"-VIs instead use blocking-mechanism of event-structures, queues, user events or notifiers
- Have a look at QMH (queued message handler ) template to learn from
- in most cases you should use queues or user-events instead of notifiers for communicating between loops.
- queues for many-to-one communication
- user-events for many-to-one (or many-to-many if registered multiple times)

Both types work according to the fifo principle and and are based on loss-less communication.

Notifiers can be "overwritten" and can be better used for updating e.g. gui values where its only important to see the newest value.

Go with a producer-consumer-scheme as you have already started. But use queues and enqueue inside producer and dequeue with switch-case-structures for different cmds inside consumer. For every consumer loop use an own queue. ( for a very deep dive you can have a look into the actor framework for queue-based communication mechanisms )

If you would like to go with user-events than you should have a look at the DQMH-Framework. It uses user-events as the communication mechanism.

To answer some of your questions from the comments of your main.vi:
- You need "named"-queues/notifiers/ if you would like to obtain a reference by name in an other VI.
- register all your user-buttons in the producer event structure
- wire your shutdown sequence to the error wire of the release notifier to be sure that its called at the end

As a tip at the end:
go for the labview training videos core 1 to 3 to learn basics and next time use the forum to ask more explicit questions because its difficult to answer on such a post because it depends on your skill level where to start. Reading other threads and looking yourself at projects or tutorials is more accurate to your needs than the time it costs to write such a post which may raises more questions than it answers.

But maybe there will still be someone who is more self-less than me and who will discuss the project with you in detail. 😉

[tsr26]

@bheemann

You rock for looking this over and giving me feedback. I do realize it was very general and I wasn't happy about posting it that way necessarily. To be honest, I have been working with LabVIEW for several years done a lot of research including all the Core exercises you mentioned, leafed through 'LabVIEW Graphical Programming' by Jennings and de la Cueva, went to a talk by altenbach, etc. However, I got to the point where it seemed like the design choices lined up with my research, but I needed another programmer's input (that magnanimous person you referred to ;)). I will do my best to break things down though moving forward...

As for the feedback, I'm looking into version control now again - I stopped considering it for some reason

Last clarification here: I used a notifier for sending the acquired data to the 'display loop' because I am fine with some of those data points going 'missing'. Are you recommending still using a queue here? I imagine acquired data wouldn't work being relayed as a user event.