LabVIEW
Linear Encoder Faster Logging, Recording Time Stamps, Understanding Counters
Hi all,
I have done a few updates to my code and now I'm getting even stranger results. I have no clue why the encoder data is being inverted as seen in the image below, in addition to the 0 value readings.
I was i the same situation when I realized that a 3$ IC can count the pulses easily. My advice is to make/buy discrete hardware for that job.
Your issue is that you're misunderstanding what the sample clock does for an encoder device. The encoder counter's sample clock does NOT control when it counts pulses, it counts when you read the VALUE of the pulse counter.
The encoder counter will count pulses as fast as it will count pulses. There are some limits related to the internal base clocks, but generally speaking you don't need to worry about those, and that's NOT the sample clock.
The counter will count as fast as it needs to to keep up with your pulses. The *sample clock* will then read the value of that counter to an external buffer which is read by DAQmx Read.
For example: Let's say your encoder is increasing at a rate of 1000 counts per second. If you sample the system using a 10 Hz sample clock, you'll get readings of 0, 100, 200, etc. If you sample at 100 Hz, you'll get readings of 0, 10, 20, 30, etc. The internal counter is read into the buffer at each sample clock pulse.
Unfortunately, you're using an M series device, which doesn't have dedicated sample clock sources, but fortunately, you're synchronizing it with other analog devices. This means you can route the analog sample clock to the counter input, and read the analog inputs simultaneously* with your sample clock inputs.
See this example:
(That's a digital input, but you can switch it to counter input instead).
*Your device doesn't do simultaneous sampling of all of the analog input channels, so there will be a TINY delay between channels, but it's generally something you can ignore.
@Sayre wrote:
Hi all,
I have done a few updates to my code and now I'm getting even stranger results. I have no clue why the encoder data is being inverted as seen in the image below, in addition to the 0 value readings.
That's because your Build Array terminals are wired backwards- flip those around. You're prepending new data so it's before the old data. You almost certainly want to stick it on the end, not the beginning.
Also, delete the input to the "Source" input on the AI Voltage's Sample Clock function, DAQmx figures that out on its own. You're basically rerouting the AI sample clock correctly here.
Also, I'd clean up your code, don't maximize the front panel and block diagram, and don't use the flat sequence structure. That'll help others follow your code better.
If you can get it done in pure software or this is just an assignment, fine - don't read further.
Assuming you have to trigger the camera in fixed intervals. A decoding chip connected to one or more timer IC can give you the camera triggers for free. You can even adjust the intervals using jumpers. Those timers could then trigger your DAQ for pressure transfucer reading. Your servo has probably it's own encoders and a motorcontroller and is most likely not driven by your DAQ, unless it is a toy thingy.
