Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Retrigger Start Over

So I have a cDAQ 9188, with a 9205 AI module, and 9264 AO module.  I want to create a sine wave that my AO is in phase with an AI.  For this example lets say I know the frequency and amplitude of the AI, so all I really need to do is create a similar sine wave as an analog output, then setup a trigger to start it when my AI crosses zero rising up, signaling the start of the next cycle.

 

I figured I would do this output one cycle at a time, in case my frequency don't quite line up.  So I see the start of a cycle on AI, perform a trigger to start a single cycle on AO, then look for the next trigger.  This all works just fine with some work arounds using counters to retrigger.

 

My issue is this.  If I create a single cycle as an AO and my frequency is slightly too slow, meaning the time to output is a little longer than the analog input, then I may miss my next trigger.  According to the help on the Retriggerable property node for DAQmx timing the output (or input) of a retriggerable task, will only trigger again once the finite operation is complete.  So if I generate a wave, and a trigger happens while still outputting, then I will miss that trigger and hold my last value (which would be 0) until the next cycle trigger.

 

After all of that here is finally my question.  Is it possible to have a trigger, cause a finite output to start back over, instead of finishing the output until a new trigger will be seen?

0 Kudos
Message 1 of 4
(4,555 Views)

Hooovah,

 

I dont know of a clean way of acheiving your end goal but I think a work around is possible.  

 

Before I get to that let me ask for a few pieces of information.

1) What frequency range do you expect?  Will the frequency be changing significantly?

2) In what way does your output waveform differ from your input waveform?  Would it be possible to write an algorithm to mathmaticaly convert wave1 into wave2?

3) How much discontinuity is acceptable?  

 

Potential workaround: Can you tie two AO lines together and output every other period on a different line?  Signal integrity would deteriorate and reflections would increase but it might be good enough for your application (whatever it may be). This would require two different retrigerable tasks since each line would require one task.  You have an AI and a counter already (maybe others as well) so you might run into the total task limitation of the cDAQ chassis.  

 

Let me know what you think.  Tell me why it will or wont work for you.  

0 Kudos
Message 2 of 4
(4,525 Views)

I should have given more information on what I'm trying to do but I was hoping for a simple answer.

 

I'm actually investigating what it would take to make a resolver simulator.  I have developed one for an R series FPGA card and it works great.  The problem is our platform for tester development is moving tword cDAQ.  So if I can't accomplish this with cDAQ then it isn't the end of the world, but it would be nice if can be done.

 

For a resolver simulator to work, two waves must be generated, and they must be in phase with an input sine wave.  The amplitude of the two waves, and the phase deinfes where the position of the motor is in 360 degrees.

 

So my input wave frequency depends on the input from my DUT which at the moment is undefined.  In testing with my cDAQ hardware any faster than 500hz maybe an issue, since I want to output a clean wave meaning probably 100 points per wave so an output rate of 50K.  So for now lets say the excitation frequency is 500hz.  This means I need to generate two waves both at 500hz, and all three of these signals need to cross 0 at the same time.  The tolerance of this "same time" is also unknown but in the past I've seen it be off by a bit and still be alright.

 

So the TLDR version.

 

1) Input excitation at 500hz, the frequency shouldn't change at all but I expect that it may by a very small amount, and our ability to detect the 500hz may also be off by as much as +/- 0.1hz.

 

2) The output waves differ by a phase shift of 0 or 90, 180, or 270 degrees, and amplitude.  This is to simulate a resolver position and not motion.  

 

3) Shifting the phase of the outputs from the input by maybe 1/8th the wave maybe acceptable.  At 500hz this is 250us.

 

The more I think about it the more I realize using this hardware will limit myself a great deal.  I'm guessing this just means that I need to stick with the FPGA for this.

0 Kudos
Message 3 of 4
(4,511 Views)

"2) The output waves differ by a phase shift of 0 or 90, 180, or 270 degrees, and amplitude.  This is to simulate a resolver position and not motion."

 

For me this indicates you came to the right conclusion with FPGA.  you might branch from R series to sbRIO or cRIO if you like the IO modules of C series.  

 

 

0 Kudos
Message 4 of 4
(4,507 Views)