Multifunction DAQ
Acquire AI signals and Ctr signals from PCI 6221 M Series,
Hi,
you want to synchronise up the acquisition of the analog and the counter readings.
I'm making the assumption here that you're using a pulse train from a shaft encoder and you need to tie in the voltage at every pulse generated, whilst using the counter to measure the pulse period.
You can use the incoming pulse train as the gate input for a buffered period measurement setup on the counter, and the ai sample clock for exactly when the ai aquires.
The problem with this is when each gets initialised. If the shaft is already in motion at high speed, then you'll be receiving one pulse on a setup stage (say the ai) just before the ctr stage gets setup and runs. This means your synchronisation could be out by a pulse, and you won't necessarily know, since the acquisition has to be stopped and so does the buffered period measurement, so there's going to be a lag there again, so you can't just look at the length of the data acquired, and think the longest one started first, and they finished at the same time and adjust the data.
What rate are you running at? If it's relatively slow between successive rising edges of the pulse train, then you might be lucky most of the time, since you could start both (after having initialised both tasks) within the period of the pulse, however, you could be unlucky and start say the ai first, a pulse comes in, triggering an acquire, and then start the ctr.
One option is to use the same medium for both parts, and use the ai for the speed measurement too, that way you can recreate the data.
Run at an appropriate free-running speed, and acquire the pulse train, the voltages and anything else you need.
You can then look at all the traces, and discover exactly when things changed.
The disadvantage of this is that you're time resolution is only as good as the ai acquisition rate, and you'll generate lots of data.
Since this is very hardware dependant, you could always use a counter and a digital line.
Here's my thinking :
Shaft is already running, but tied to a counter which is set for a retriggerable pulse generation on a really short pulse. This counter is gated by a digital line.
The output of that counter goes to the gate of the period / frequency measuring counters and also to the ai sample clock. You setup the "measureing" counters and the ai, and start them off. Nothing will be happening at this point, since the digital line would still be low.
Now in software, you activate the digital line to high. Since this then allows the pulses to come through, you get the ai and the counters started at the same time and synchronised.
If you're using two "measuring" counters then this isn't going to work, since you'd need a third one. Also if you're measuring the pulse period and pulse semi-period, then the third counter generating the pulses would destroy this.
If this is the case, then use an external AND gate tied to the incoming pulse train and the digital line to synchronise the start.
Hope that helps.
Sacha Emery
National Instruments (UK)
1. What does "gate input" mean? Does "being gated" mean "to set the clock"?
GATE means to allow through in a particular condition. So your pulses are only allowed through when the gate is high etc.
2. To use pulse train from the shaft encoder as the gate input, as I will be running the shaft at different rates, the pulse train signal will then be varying. Do you think it is still OK?
That's what I think you need. Every rising edge gives you the buffered period measurement (have a look in the manual for a description of the timing of this) so you get your speed, and you get an analog input measurement at the same time if you've set it up to use an external clock (example finder in LabVIEW and go to the examples in Hardware input and output->Daqmx->Analog Measurements->voltage->Cont Acq&Graph Voltage-Ext Clk.vi) and you'll need to wire onto the clock source you specify on the front panel.
3. Can you please provide me the VI example of how to set up the pulse train as the gate input? I am quite new to Labview.
Do you mean the pulse train from the shaft encoder as a gate to a counter doing the pulse generation again? (example link I posted last time does this) Or do you mean the pulse train from the shaft encoder as the gate to the buffered period measurement? ( Hardware Input and Output->DAQmx->Counter Measurements->Period or Pulse Width->Meas Pulse Width-Buffered-Cont.vi and read the documentation in the vi properties)
4. You assumed that motor shaft is already in motion when we start the acquisition. What if we start acquisition before running the motor? Can we do that and is it going to help to ease the situation?
Starting the acquisition first makes life so much easier, since both the AI and the counterside of things would be waiting on the pulses then.
5. The rate I am running my motor is about 250 rev/s or about 12,000 pulses/s produced by the shaft encoder. Is it OK to avoid the synchronisation problem you suggested?
Not necessarily. It's more likely at higher speeds, but even at a very low speed, you could still do config AI, config ctr, start ai, pulse comes in, start ctr, and you're out of snych.
6. Could I also have VI example showing how to measure the "period" using AI pin? (Can we do this in DI part too?)
You need to do a straight forward acquisition (say a finite one for easiness - Hardware Input and Output->daqmx->analog measurements->voltage->Acq&Graph VOltage-Int Clk.vi), and then use something like the pulse parameters.vi from the analyze->signal processing->time domain palette (do a search on the functions palette if you can't find it easily). You'll need to unpack the array of data from the waveform that the daqmx read returned, and that's on the waveform palette under get waveform components. Set it to extract the y array.
If you're very new to LabVIEW I'd recommend coming on one of the training courses.
If you decide to do this, then please contact your local office (the UK is 01635 572400) and ask for the course co-ordinator. We do courses right from beginners all the way up to advanced application design techniques.
Failing that, a good set of books are available for self learning - try http://www.Waterstones.co.uk and search for LabVIEW. Something like LabVIEW for everyone is a good introduction :
Hope that helps
Thanks
Sacha Emery
National Instruments (UK)
Sorry missed a little off the last question
Can we do this in DI?
Technically yes, however, you have to know the timing on the digital input. Since there isn't a clock specifically for digital input, you would need to do correlated digital input, either to the analog input task you'd need to setup, or by providing an external clock (example in Hardware Input and Output->DAQmx->Digital Measurements->Cont Read Dig Chan-Ext Clk.vi).
You'd then need to search the array of values back for when it changes from false to true, and then from that point for true to false. Knowing the acquisition rate and the number of elements in the array inbetween, you can then multiple up, and get the total time the pulse was high. If you want the complete period, then look for the first low to high, then the second low to high, and apply the multiply of the time per sample x number of samples to get the total period.
Thanks
Sacha Emery
National Instruments (UK)
Hi,
at this point, you'd need a rtsi cable to link the pci cards together. Then you need to export the appropriate signals from one card to another, but since you've a physical link in the system, you will have a phase lag down the cable.
Testing is best done with a known signal, such as a sinewave and a digital signal, such as a square wave 0-5V which you can synchronise the generation of to the sinewave going on the AI. That way, you can look at the real world signals going in on an oscilloscope, and then see how that looks in your code.
THe following links should help.
http://zone.ni.com/devzone/conceptd.nsf/webmain/BF5474CCECE506EC86256FA300686599
http://zone.ni.com/devzone/conceptd.nsf/webmain/6DC991028566309886256F990080A720
I would recommend you talk to one of the alliance members to do a proof of concept on this system. I can give pointers, and example code, but not develop the system as a whole.
Also, I think there's a misunderstanding in exactly how the cards work. You said :
The thing that confuses me most is the synchronisation and sampling rate. From my understanding, the different channels (AI/AO, CTR) take in signals in at the rate set by their internal clock (hardware clock). We as a user can decide how often we want to pick those signals to be read or used by settting the sampling rate (by Labview software). This means that all the signals input via DAQ card via hardware clock for each different channels are already there but we only choose some signals to be used.
The hardware takes a configuration from the software, and is not "free running at macimum rate". i.e. if you ask for 100 Samples per second, the onboard clock is divided down to match as close to this rate as possible. Once you start the configured setup, then the card starts to acquire (unless you're setup for triggered with no pre-trigger in which case no data is acquired onto the card. The cards have a small onboard FIFO. Once configured and acquiring the cards acquisition section puts the data to the FIFO, and the MITE chips are responsible for transfering that information over to system memory in as efficient a means as possible. The software reads then pull the information from the system memory buffer (which is used in a circular fashion if continuously acquireing) into the application memory, where it can be analysed by your process (application).
So in short, no the data is not already synchronised.
You can find information on the alliance program members here.
Hope that helps
Sacha Emery
National Instruments (UK)
