LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

daqmx continously output

Hello,

I have some question. I have changed the NI example that i can simulate to phase shifted signals. Is it possible that the signal will continously output without this loop in the vi.


I want to run the vi only one time to send the data to the daq card and then should the card send the sine continuously.

But if i delete the for loop i only get one sine on my osci.

Do somebody know what i mean?
0 Kudos
Message 1 of 17
(3,463 Views)
You have a DAQmx Clear Task function at the end of your code.  This will stop the task and reclaim its resources.  You can remove it from this location but it is good practice to clear tasks when you're finished to avoid wasted resources.
 
K
LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019
0 Kudos
Message 2 of 17
(3,451 Views)
Hi! I use the DAQPAD-6016 with labview 7.0 and i have to create to pulsetrains with 90 kHz shifted 90° to each other. i was able to do one train on ctr0 and ctr1 output but i did not find a way to realize the phase shift. Thanks in advance, Peter
0 Kudos
Message 3 of 17
(3,434 Views)

I'm not very familiar with the specific capabilities / limitations of the DAQPad boards so here are 2 possibilities you can try:

1. Under DAQmx, I think you should be able to give them both the same freq & duty cycle, but set their initial delays to represent a 90 deg phase shift.  The initial delay is the delay value used before the very first pulse -- thereafter the low and high times are used repeatedly.

2. You could set up the lagging pulsetrain as a retriggerable single pulse where the leading pulse acts as the trigger.  This approach is probably a bit more complicated, so post back if the 1st method doesn't work out and you need more details on this method.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 17
(3,422 Views)
Hi! Thanks a lot for the fast answer. ad 1. i tried that already and it works principally but my problem is: inial delay is to be set in seconds with only two numbers behind the comma, so the smallest delay i can set is 10 milliseconds. but as my signal is around 100 kHz (period = 10 us) i would need a delay of 2.5 us to achieve a 90 degree phase shift. Or is there an other alternative to realize delays than using the inital delay-input of the "create channel"-vi (with selcetor on CO-pulsfrequ) ? ad 2. i also tried that one, to let the ctr1 be triggered by PFI0, which is externally connected to ctr0 which runs with 100 kHz. but i had 2 problems: first, i could not create more pulses, there is always only one time a pulse for each start of the program. and the 2nd problem was the same as above, i could not create a phase shift of 2.5 us. best regards, Peter
0 Kudos
Message 5 of 17
(3,409 Views)
...i attatched you my vi, maybe you can give me another hint... 
that vi works well but only up to 50 Hz due to the restriction that at initial delay i can only write 0,01 as minimum which is 90° for a 50 Hz signal.

thanks again,
Peter

ps. my labview version is 7.0
0 Kudos
Message 6 of 17
(3,404 Views)
I'm not near my LV PC to look at the code now.  But I suspect I've got a solution for you.
 
The actual values you give to the freq / duty cycle inputs are NOT limited to 0.01 sec precision.  However, the actual front panel control or block diagram constant may have its display properties set to limit the precision of what is displayed. 
 
You could type in a value like 1.0e-5 and the numeric will contain the value 1.0e-5, though it may only display 0.00.  Try it and see.
 
Now to fix the display, right click the numeric and select "Format and Precision..."  There are many options there to play with.  Pick lots of digits (either signif digits or digits of precision) and unselect the "hide trailing zeros" option.  Voila!
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 7 of 17
(3,395 Views)
Hi! Thanks for the help, the problem with the precision seems to be solved. But my two ctrs (0, 1) seem to have random phase at the beginning, even they are in one task which is started once. Or do i have to use other timing conditions?
I have 2 vis for each ctr before the "start"-vi:
1. daqmx - create channel (CO - pulsfreq)
2. daqmx - timing ("continous sampling, implicit)
Thanks meanwhile, Peter Brugger
0 Kudos
Message 8 of 17
(3,393 Views)

Sorry, my bad.  In the back of my mind I was assuming they would both start off a digital start trigger since that's what I would do with my DAQ board.  However, I don't think the DAQpad counters support digital start triggers.  So option 1 really isn't an option for you after all.

Option 2 may still be a possibility but I'm still not 100% sure about your hardware.  Your 1st (master) counter should be a continuous pulse train while your 2nd (slave) should do retriggerable single pulses, using the master counter's rising edge as a trigger.  To set this up, you'll need to use a DAQmx Trigger property node with the "retriggerable" setting wired as True.

I'll assume that you'll have a low idle state with high pulses.  Setup the right pulse specs on your master counter.  For your slave, the "low time" and "initial delay" setting should be identical and equal to 1/2 the master counter's high time.  The high time should be 1/2 the sum of the masters' high and low times, i.e., 1/2 the total period.

I *think* that should be the right settings if your hw supports retriggerable single pulses.  There've been some recent discussions though which ultimately pointed to the following knowledge base article.  The article, frankly, doesn't seem 100% crystal clear and consistent to me, but the conclusion seems to imply that you'll get consistent delay timing from trigger to rising edge if you set your initial delay and low time to be equal.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 9 of 17
(3,387 Views)
...Thanks a lot for your help, at least the ext triggering works now ("finite pulse train" & number of samples: 1 & retriggerable) .
I just have to check out how that delay thing works... is it possible that if i choose the initial delay at the create-task-vi, that only the task starts to work delayed but not every triggered pulse?
best regards,
Peter Brugger
0 Kudos
Message 10 of 17
(3,378 Views)