Showing results for 
Search instead for 
Did you mean: 

Load value from a file to the configuration of a DAQmx Virtual channel.

Dear Bob & Collin


Thank you for the info about the type def, I've tried to insert the bridge config into my program, Bob, and eureka, it works! 😉 Thanks a lot for that. But now I have the problem that the next steps in my program won't work and I got some coercion dots... When I press the "set channel" button, labview needs to attach the name of the sensor to the channel of the module that I select, and the next button needs to change from disabled to enabled. When I do this now, my program freezes and I can't continue. I also connected the errors, but labview doesn't pop-up any errors... 



With kind regards,



0 Kudos
Message 21 of 26

The only thing in the attachment was the Project (.lvproj) file, not the VI ( file.  Can you attach?



0 Kudos
Message 22 of 26



Oops, i'm sorry... Thought if i attached the projectfile, then everything would be in it. But ofcourse I will attacht the 😉


Thanks for the fast reply.



With kind regards,



0 Kudos
Message 23 of 26

There are very many serious design flaws here.  I'll point out a few, and some suggestions for how to fix it.  Be warned -- the best way is to (more-or-less) abandon what you've started and begin again.

  • The Event Structure is for handling Front Panel Events (though you can also handle User Events, but that's another topic).  Generally the code in the Event Structure does one or more very simple (and very quick) tasks -- nothing time-consuming (like data acquisition, data processing, or file I/O).
  • When the Event Structure is used in this way, it typically is in a parallel loop, a "Producer" in a Consumer/Producer relation with the main Processing loop.  For example, a Set Channels Value Change would trigger a Consumer action to save the new settings for the Channels, ready for the next step.
  • Usually there is a "Go" and a "Stop" button, with a corresponding response in the Consumer.  "Go" could mean "Start Data Acquisition, using all of the settings that I've already told you about", while "Stop" could mean "We are all done, so close the files and get ready to exit".
  • Communication between these two loops is often done via a Queue.  A particularly interesting form of Consumer/Producer is called the Queued Message Handler, because the Queue contains a Cluster consisting of a "Message" (telling the Consumer what to do) and some optional "Data" (telling the Consumer something relevant about the task).  In the case of Set Channels, the Message could be the string "Set Channels", and the Data could be the changed Channel Settings (available in the Event loop, and passed via the Queue to the Message Handler acting as the Main Program).  This particular model is very popular in LabVIEW -- there are numerous examples, including in the Sample Projects and in the File/New/From Template choices.
  • I notice that you have all of your DAQmx routines together, meaning you are trying to make the entire complicated program work all at once.  I recommend that you write a few very small and simple VIs that do nothing more than take data from a single Analog or Digital channel and display it in a Chart.  This will allow you to get the sampling rates and so forth worked out.  Start with a single channel, then add multiple channels.  Do the same (in another test VI) for the other DAQ tasks.
  • Generally (but not always!), DAQ tasks have an Initialization step (where the channels are defined and configured, and the DAQ started), an Acquisition step (where samples are taken or output is produced), and a finalization step (where things are shut down).  Initialization requires a Task or I/O Constant, but none is needed when the Task ends.  If you are using a Queued Message Handler as your main loop, you can have a Message "Initialize DAQ" that defines the channels and passes the DAQ Task Wire into a Shift Register, an "Do DAQ" Message that uses the wire to take samples, and a "Stop DAQ" Message that stops things.

It may sound like this is Much Too Complicated, but I think you'll find that breaking your problem up into multiple loops (Event and QMH, Producer/Consumer) and breaking your main processing into sub-Tasks within a loop structure (with data saved in Shift Registers) will result in code that is (a) more compact, making it easier to see all-at-once and grasp, (b) more self-documenting (particularly if you choose good names for the Messages), and (c) easier to both create and maintain.


Good luck.  If you choose to Be Brave and go this route, you'll be sure to find help when/if you "get stuck", and you'll learn a lot in the process.


Bob Schor

0 Kudos
Message 24 of 26

P.S. -- I may have forgotten to mention this, but your Data Acquisition stuff should absolutely not be inside a (Front-Panel) Event Structure!


0 Kudos
Message 25 of 26

Thanks for the well described information. But I've started from scratch now, it was getting to complicated for me. But I'm still stuck now, I will try to explain whatfor I want a program in another new topic.


But really thanks, Bob Schor, sorry I reply you so late, but I had exams, and the LabView program needed to wait a little bit...


With kind regards,



0 Kudos
Message 26 of 26