LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how do I sequentially output 3 different voltage forms of finite duration and synchronize the second one with an input channel?

Solved!
Go to solution

Hi John,

 

I've made my code much like yours shown and I'm now able to get a continuous periodic output voltage.  I'm now trying to sync an input channel with the output.

I was a bit reluctant to take my start task and end task vi's out of the loop as that does not physically represent the act of reading the input of each scan, one at a time - which is the goal of the application.  But I see now there is no other way to keep consecutive waveforms tight together; which is also necessary.  I should be able to work with this code, the next thing to properly include is my input channel reading.  I'll let you know how it goes and send a copy of the code when it's done.

 

cheers,

Kyle S 

0 Kudos
Message 11 of 15
(393 Views)

Hi Kyle,

 

That's good to hear.  You could implement the synchronization like this:

 

Output_Input_Ramp.png

 

 

Each loop iteration would still return one cycle of data without the need to restart the tasks themselves.

 

 

Best Regards,

John Passiak
0 Kudos
Message 12 of 15
(387 Views)

Hi John!

 

Here it is.  I've finally got a code that does exactly what I need it to.  Thank you for all your help!  I can't wait to use it in my research.

 

Best regards,

Kyle Shiells

0 Kudos
Message 13 of 15
(367 Views)

Good to hear--in your code though there is no guarantee of start order between the analog input and analog output task:

 

RbScan.vi Block Diagram on Build.png

 

 

Since you are triggering the analog output task from the analog input task, you want to make sure to start the analog output task first so that it is armed and ready for the trigger when the analog input task issues it.  You could enforce the execution order by wiring the "error out" from the AO start to the "error in" on the AI start.

 

 

Also, a minor detail--you are wiring a user-defined sample rate (derived from "scan time") into both the AO and AI task and depending on them running at the same rate for synchronization.  This should be fine as long as the scan time is a multiple of 50 ns (your card uses a 20 MHz timebase), but if you try to input a time that the card can't precisely generate the rounding is different for AI and AO tasks (AO round to nearest available rate, AI tasks always round up).  It wouldn't be an issue unless the user wants to enter very precise time intervals, but to make the program a bit more robust you could read back the coerced sample rate from one of the tasks and pass it to the other (or you could share a sample clock instead of start trigger like I showed in my previous post).

 

 

Best Regards,

John Passiak
0 Kudos
Message 14 of 15
(361 Views)

Hi John,

 

Thanks, I'll keep all of that into account.

 

Cheers,

Kyle S

0 Kudos
Message 15 of 15
(342 Views)