05-23-2014 10:22 AM
I am working with a NI USB 6218 to create a continuous read and write application. The goal is to have 16 Analog In channels reading voltage, 2 Analog Out channels configurable across their range, 4 Digital Out channels configurable to high or low and 4 Digital Out channels with triggered single pulses that have adjustable width.
The last part is the one giving me trouble. I've seen several examples of pulse train configuration for DAQmx but I have not been able to find anything on single triggered pulses. Also, in terms of the VI's architecture, I am wondering if this type of design requires a Queued Message Handler, given the different types of channels I need to control, or whether an Event Structure in a While Loop would be sufficient.
Would appreciate any advice you can offer,
Solved! Go to Solution.
05-27-2014 01:11 PM
To clarify, you want to be able to send 1 digital pulse triggered by a user click? You could setup the DO channels to output a finite amount of samples and put the Start Task, Wait Until Done, and Stop Task within a case structure that is connected to a boolean on the front panel. When the user clicks the boolean, it will enter the case that allows the task to execute.
You could also continuously write the value of a boolean control to the output of a digital task similar to the built in Digital - SW - Timed Output.vi found in the example finder (Help >> Find Examples) under Hardware Input and Output >> DAQmx >> Digital Output. This would simplify your architecture a little so you don't need a QMH and are just directly reading the digital value that is clicked. Then, set the trigger to read rising edge and the event will only be triggered whenever the user changes the boolean changed from low to high.
Do these ideas seem useful to you?
05-28-2014 02:54 PM
Thank you for your response. I've used DAQmx before but only for single function applications (read analog, write digital) so I'm still getting used to parrallel operation. Today I read up on DAQmx but I'm left wondering if the best (standard?) approach is to do a QMH or an Event Case in a While Loop since there is only one device being controlled? I ask because I've previously used a QMH, more specifically a Producer-Consumer, because I was controlling several instruments with different timing considerations. In the white paper on Measurement Multithreading in NI-DAQ 7, I get the impression that I can run the Analog In in parrallel with the ouput but that leaves me wondering whether the Digital Out and Analog Out should be together or can they be parrallel as well?
Thank you for your suggestions regarding the Triggered Pulse. The idea is to trigger a single pulse when the user clocks on the appropriate control in the front panel with four independant chanels. Going back to my questions regarding the architecture of a continuous DAQmx input and output, I'm curious if the second suggestion is better since it doesn't require a QMH? Alternatively, if the entire architecture will require a QMH, the benefit no longer applies.
Hope to hear from you,
05-29-2014 05:22 PM
Based on what you have described, a QMH seems to be more complicated than what you would need for your application. I am not sure we are refering to the same QMH though because you mentioned Producer-Consumer which is a much simpler architecture. The QHM architecture (there is a project template for this) is complicated and is most useful when you have a large amount of VIs and systems that are communicating back in forth. You can easily communicate between various DAQmx tasks and loops that are running in parallel within one VI using more simple techniques (queues, notifiers, local variables, FGV, etc.).
Depending on performance requirements, you could use an event cse in a while loop or simply poll (read the values of) the user inputs on each iteration. The polling method is much simpler to setup but can be more computationally expensive since the loop is iterating more often.
You should create different DAQmx Virtual Channels for different IO types: AI, AO, DI, and DO. Therefore, you would have different tasks for each of these all running in parallel. However, you can put multiple channels on the same virtual channel.
Does this answer your questions?
05-30-2014 01:08 PM
Thank you for the clarifications. I also thought that the QMH, even the Producer-Consumer, were too complex for this task. I will try implementing this with a seperate loop for the Analog In, since it runs continuously independent of what's going on with the other channels, and a While Loop/Event Case combo for the dynamically updated channels. I was toying with the idea of seperating the Digital and Analog into seperate loops but will hold off until I have something fucntional.
Thanks again for the advice,
06-02-2014 09:46 AM
Glad to be of help. Best of luck to you!
06-04-2014 03:01 PM
I considered your suggestions and played around with possible configurations until I got Analog Out, Analog In and Digital Out (partially) working with an Event Case inside of a While Loop. The Analog Out runs in a While Loop parallel to this structure since it just needs to continuously log. The Digital Out portion that handles the Triggered Pulse, however, is still giving me some trouble.
Your two suggestions for the Triggered Pulse were outputting a finite amount of samples with a Wait Until Done or continuously writing the value of a Boolean control like in the Digital - SW Timed Output example. I read the Retriggerable Tasks in NI-DAQmx white paper but I don't see how either solution will give me control over the pulse's width. With regard to outputting a finite amount of samples - does the sample amount correspond to time? If so, why would a Wait Until Done be needed? Also, the white paper gives me the impression that this would produce a time limited pulse train instead of a single pulse of a predetermined width. Finally, with regard to continuously writing the value of a Boolean, what would control the length of the pulse? Would it be how long the button is pressed?
I'm attempting to implement your suggestions but the whole endeavor could really benefit from some clarification. Would really appreciate any advice you can offer.
Hope to hear from you,
06-05-2014 03:51 PM
I tried my best with your suggestions regarding the Pulse implementation. I should have mentioned this earlier but I am using an NI-USB-6218 which, I believe, is an M series device. It does not allow me to select a clock or use the Trigger subVI. My solution was to put in a simple Wait inside a While Loop. This allows me to create a pulse, however, it is not near as precise as I would like. 1 millisecond comes out closer to 1.2 and the different varies while 0.1ms looks like .8. I realize that this is probably not the correct way to implement this functionality and am hoping for some direction. The goal is micro-second control of the pulse.
Hope to hear from you,
06-05-2014 06:43 PM
For an output pulse, you can use a Counter to output a single pulse as shown in this example. The example also has triggering available if you want to add that functionality to your code. You can use the ctr0 or 1 for the Counter (onboard your USB-6218) and several of the PFI lines would work for the Output Terminal (these can be found in the Device Routes table in NI-MAX - I used PFI14). This moves your output pulse to hardware timing so you have less latency. The built in triggering is hardware level but if you wanted to change it to software, you could add that logic into your code before starting the task. Does this example seem helpful to you?
06-08-2014 05:02 PM
Thank you for the suggestion; it feels like we are getting closer!
Using that example I have been able to get reliable pulse width control to the microsecond. The problem I am having is that I cannot control individual channels if more than one has been accessed:
I set up a Case Structure with a Boolean Control to select either PFI4 or PFI5 as the ouput channel. I ran the updated VI and found that both channels were outputting the pulse intended for a single channel that was to be selected. In debugging, I discovered that if I unplug and plug in the device, or if I am starting the VI for the first time, the initial Boolean selection works and only the channel selected outputs the pulse. When I switch the control and select the other channel, however, both channels begin output the same value no matter which of them is selected. I've spent the day trying to fix this but can only get truely individual performance from the channels if I run them in parrallel using seperate counters. This will not work for my application since I am trying to generate pulses on four PFI channels.
Do you have any thoughts as to what is linking these channels together?
Hope to hear from you,