real-time rotary decoder and "pulse shifter"

[John.McLane]

Hi everybody,

I'm trying to set up a real-time rotary decoder for use as a pulse shifter via labview.

Basically that means I have two input channels (ttl-pulses, ~20us high) from a rotary engine. One channel contains a pulse at every °CA (cranc angle) up to 12kHz (increment). The other channel contains a pulse every 720 °CA (the bottom dead centre of the charge cycle, BDC_cc). With that information a pulse is to be generated on one output channel (also ttl high) , that triggers my measurement setup. This pulse is to be shifted in a programmable relation towards the BDC_cc input, aiming for a sceduled measurement table.

I got it running by continuously reading the BDC_cc channel until a rising edge is detected, then counting the increment edges up to the designated trigger point and then generating a pulse on the output channel. The problem is that the output trigger is about 70-120us late. In short that is too much; a maximum error of ~20us is acceptable. Digital channels seem to work fastest, so I scrapped counter-based acquisition.

I'm quite new to LabView, so I'm sorry if the answer is obvious...

My acquisition setup consists of:

PCI-MIO-16E-1

BNC-2120

LabView 12.0
Max 5.3.1f0

Widows XP

This setup seems to exclude some of the options Labview offers, such as externally sampled digital acquisition or externally triggered counter-based acquisition. Manual interpretation of analog input channels is way to slow.

I've attached my currently working version.

Any input woud be appreciated...

[Topper_Harley]

Hi John,

what you did in your VI is working with all software-timed tasks. That is, your VI reads/writes one value after another by accessing the NI-DAQmx driver. The logic combining the states of your input lines is run on the CPU. Good job for a LabVIEW beginner!

The time boundary you are experiencing is due to the software-timing: It takes your computer a certain amount of time to process each driver call. This is expected.

The next step for better performance is to work with buffered tasks and digital triggers. This is starting a task by the state of a digital line. In your case, you could start a counter task to count edges. Do retriggering as necessary.

Form that point on, it is software timing again: Read  the counter register (with a rate defined by a hardware clock). Compare the number of edges to the user provided number and set the output accordingly.

DAQmx does not allow to define logic conditions in hardware (besides triggers).

Still, this approach is likely to speed up things.

Tips and Techniques in Data Acquisition Triggering - NI-DAQmx

https://www.ni.com/en/support/documentation/supplemental/21/ni-daqmx-data-acquisition-triggering-tec...

Using a compactRIO real-time system is the next leap in performance. I/O is still software-timed but response times are faster than with a PC.

This requires compactRIO hardware and LabVIEW Real-Time module.

The best option is to use FPGA technology. With an FPGA it is possible to define logic that is executed in hardware. This requires National Instruments FPGA hardware and LabVIEW FPGA.

I hope this gives you some ideas what your options are.

Regards, Topper

PS: When working with DAQmx, placing all DAQmx-VIs that belong to one task in a straight line improves readability of your VI.

[John.McLane]

Hi Topper,

thanks for your detailed response!

The critical part seems to be the driver access, resulting in a (too) low software-sided scanning rate. If I understand the concept of buffered acquisition correctly it won't help in this context since the delay between hardware-based detection and software-based interpretation would not be affected but only the hardware-sided frame-rate.

Counter register access seems to take considerably longer than a digital channel access (about 20% longer; this seems to be true for any counter-based acquisition).

Making use of the trigger funtion though seems to be promising, it provides quite elegant solutions. Unfortunately my approach results in an error 200452 ('Specific property is not supported by the device or is not applicable to the task.') . I'm quite sure this is not a hardware capability problem (hardware filter in the 'DAQmx-Trigger' allows my settings). Did I make a critical error in my approach there?

The use of a micro controller or a hardware-based logic looks very interesting, though the use of existing hardware running on the same system as the measurement software would be preferred.

Regards, John

[Topper_Harley]

Hi John,

a trigger does not make sense with software-timing. Create a buffered task (use the DAQmx Timing VI) and define a trigger with DAQmx Start Trigger VI. Before you do, have a look at the example "Digital - Finite Output.vi". It ships with DAQmx.

Topper

[Kevin_Price · Accepted solution]

John,

I have only a minute right now but think I can fiddle about with a simulated device tonight or tomorrow.

I'm quite sure there'd be a clean hardware-timed solution if you were using an M-series or X-series

MIO board, but the older generation counter timers on the E-series board may not quite support what

you need.  It's been a while since I had to rely on that generation of hardware.

The basic approach I'm thinking of is to use the crank angle pulse train as the clock that sets the

delay timing of the pulse you want to generate.   You'd be "timing" the pulse based on the actual 

angular position, helping you sync to a specific crank angle.  The issue is how and whether E-series

counters support triggered (or retriggerable) pulse generation.  If they don't, I'd suggest you consider

getting newer DAQ hardware that will support this kind of triggering and give you very precise pulse

placement.

-Kevin P

[John.McLane]

Hi Kevin,

thanks, that actually explains a lot. It seems the hardware capability option-filter on the property nodes has been playing some joke on me... I've been producing nothing but error messages with every approach on external clock timing and triggering (e.g. sth. like timing the digital output task on the crank angle pulse train and creating an output like (0, 0, ..., 0, 1) triggered by the bdc pulse; or counting up to the ca pulse before the sought one and then creating a buffered single 'true' output triggered by the next following ca pulse, similar to the approach suggested by topper). I'm don't have access on my labview stuff right no, so I can't post any examples, but even some of the DAQmx examples didn't work properly - so limitations of the E-series sound very reasonable. Guess there won't be any way around upgrading our hardware...

regards, John