Very precise pulse generation and simultaneous counter problem

[RnDMonkey]

Hi everybody, hopefully somebody can help me with this.

The much-talked-about NI-DAQmx Error -50103 "The Specified Resource is Reserved" 

I have the M-series 6221 DAQ, and I need to generate a very specific pulse train, then record that pulse train after it has been driven by a FET, transmitted through an inductive charger coil pair, and amplified back up to 5 volts where it goes into a microprocessesor.

The pulse train I generate is an asynchronous communication packet consisting of 3 bytes of data and 2 bytes of checksum transmitted as pulses at a 2 kHz rate.

I send an initial 5 pulses to wake up the microprocessor, then wait 235 ms. At that time, I send each of the communication bytes at 200 ms intervals. An example would be a pulse train of 5, 28, 1, 174, 9, 37.

I have been able to generate a very stable and accurate pulse train using a timed loop with a pulse generating SubVI in a case structure within the loop by creating a pulse width task and using implicit timing to generate N Samples corresponding to the number of pulses in each byte. However, I want to verify the integrity of the data packets right at the microprocessor input, but am unable to run my edge counter due to the -50103 error.

From my research on these forums, I've deduced that since I am using Finite Samples generation, I am actually tying up both counters on my DAQ for that one pulse generation routine. This also dashes my hopes of running 2 pulse generation circuits at once. I tried to use Continuous Samples to generate the pulse train, using a Wait For (N Samples * 500 µs) Milliseconds in a timed sequence between the Start Task and Stop Task VIs, but the timing is not stable enough to accurately generate the correct number of pulses every time. The frequency of the pulses is not a very stable 2 kHz either. I was only able to use implicit timing for the sample mode, because when I try to use Sample Clock DAQmx timing with the Continous Samples sample mode selected, an error says I must use Hardware Timed Single Point sample mode with the Sample Clock selected. But when I try to select Hardware Timed Single Point, as error says that that property is not allowed for Sample Clock timing. That second error is not the same as I get with a simulated DAQ of the same model.

What can I do???

[Kevin_Price]

Here are my thoughts:

1. I don't know the overall timing needs for your communication protocol, but your reliance on software timing (the Timed Loop) gives me pause.  It appears that the Timed Loop only controls the interval between finite pulsetrains (bytes) though, so you may be ok.

2. The 6221 supports hardware-timed DIO on its 8-bit port0.  I believe this is the route to a satisfactory solution with reliable hardware-based timing.

3. An outline of how I've approached a very vaguely similar app:

   A. Plan to generate your own sample clock with one of your counters, say Ctr0.   As I understand your app, this will need to run at 2 kHz.  Configure it but don't start it immediately.  Also, I would recommend a 95% or greater duty cycle -- more on this later.

   B. Configure a DO task to generate your output pulses.  Configure it to use Ctr0's *leading* edge output as the sample clock.  You'll need to define your DO buffer to represent the pulse train state at every 0.5 msec sample clock tick.  During your 200 msec pauses, you'll have 400 consecutive "off" states.  Define and write the buffer representing the entire message before starting the task.   Then, start the task.

  C. Configure a DI task to measure the pulsetrain that comes back out of your conditioning circuit.  Configure it to use Ctr0's *trailing* edge output as the sample clock.  This is why I suggested the 95% duty cycle.  You'll generate a (potentially) new pulse state every 0.5 msec.  But you won't measure your circuit's output until 0.475 msec later, just 25 microsec before the next pulse state is generated.  This gives maximum time for stabilization. 

       Depending on your needs, you may then want to start dropping your duty cycle down lower and lower until you find a disagreement between the digital pattern you generate and the one you measure coming back.  That'll give you an idea about the system's response time.

  D.  After both your DO and DI tasks are started, *then* you can can start your counter task.

  E.  Depending on how and when you configure, start, stop, and clear your tasks, you may have options about which ones are continuous and which are finite.  One way is to make the DO and DI finite while making the pulse train continuous.  If you do this, you'll want/need to stop and restart the DO task (and probably the DI too) after each message.  You could also make the DO and DI continuous while making the pulse train finite.  This would probably be a little trickier as you'd need to put more effort into managing the data acq buffers.

-Kevin P.

[RnDMonkey]

Thank you for the response, Kevin. A few questions:

I need a 50% duty cycle at 2 kHz, so should I actually set my CO to 4 kHz and send each pulse as a 1,0 or 0,0 for high and low? How do I pass the values to the DO line? Do I just build a 1D array of boolean or digital data and pass it into a DAQmx write VI that has a DAQmx timing VI on it?

I only want to send the command packet once, for a total duration of 1235 ms. How do I implement your methods in E.? On one hand, if I can buffer the pulse train and then generate a single clock burst of 1235 pulses (or 2470, as the case may be if I have to generate a high and low transition for each pulse in order to get a 50% duty cycle), then I could be assured that the timing would be exact and I would only get a single packet. On the other hand, I don't know if that would allow me to operate 2 separate pulse generators at the same or different times. How would I set up finite sampling of the DO and DI with continuous clock pulse generation, and would I be able to run 2 separate DO and DI with a single CO?

Also, if I use finite generation on ctr0, I would be tying up ctr1 as well, right? If I used continuous generation on ctr0, would that leave ctr1 available to be used for another DO/DI pair?

I've attached my current pulse generation code section. The first byte (byte 0)of 5 pulses is constant, with a 235 ms delay between the start of byte 0 and byte 1. Between the start of byte 1 and the start of byte 2 there is a 200 ms delay, same with the remaining bytes. Bytes 1-5 are variable, but it seems easy enough to use math to calculate the remaining off time and insert enough 0,0 to give the proper delay between bytes.

In the future we plan on moving to syncronous communication, but that's a ways off.

[Steve_B]

Hi morgol,

You could create a task where the counters are continuous and you can use that clock for a finite generation/acquisition on your DIO lines or where your counters are finite and the DIO tasks are continuous. The finite counter task will require 2 counters while a continuous counter task only requires 1 counter. The DI and DO tasks can be configured to have the same clock if you set it up that way. You would be able to load the data into an array pass it to the DAQmx Write VI in the DO task.

You seem to be well on your way for your application.

[RnDMonkey]

Well, this turned out very well, thanks for the help! Here is a snippet of what I ended up with, if anybody else wants to check it out. 🙂

By the way, ignore the /Winry/PFI12 reference in the second DAQmx timing VI. I use custom DAQ names, and missed that one when I changed it for posting here. Just change it to Dev1 or whatever your DAQ is.

Message Edited by morgol on 09-15-2008 09:56 AM