Triggering a While loop with the initial movement of a rotary encoder

[MikeStebbins]

Hello,

I am currently using LabVIEW 9.0 and a USB-6212 board to measure the counts from a rotary encoder and then convert it into the distance traveled by a linear actuator.  The VI and a picture are included.  The pertinent parts are labeled 1-6, on the left-hand side.

I need to find a way to "kick-off" a separate While loop (not shown in the VI) as soon as either the A or B input from the encoder changes state, i.e., as soon as the actuator starts moving.  The While loop will generate a serial command every XX msecs.  The start of sending those commands needs to be synchronized with the start of movement of the actuator.

Right now I take continuous samples using the index signal from the encoder as a sample clock and then read them from the buffer every 10 ms and enqueue the data, to be processed by the While loop on the right-hand side of the VI every 100 msecs.  It doesn't work to just check the data in the 10 msec While loop to see if the encoder has started moving in the last 10 msecs and then kick-off the serial command While loop if it has, as the serial command and encoder position might be too far out of sync.  I'm hoping that I can use something like a DAQmx Trigger on the A and B input signal to trigger the serial command While loop and synchronize these two events closely.  But, in searching the boards I haven't found anything to help me do this.

Thoughts, examples, or different approaches would all be very welcome.  Thanks for your help,

Mike

[Kevin_Price]

Well, I dunno.  I've got a few thoughts for you that may help with part of the problem, but I'm afraid that keeping sync to less than 10 msec may be a tall order.  (I'm assuming Windows or other non-real-time OS here.)

To try to "trigger" off a change in the A or B channel of the encoder, I would suggest using the M-series board's digital change detection feature.  You'll very likely need to physically wire your A & B signals in parallel over to DIO pins that are part of port 0.  Only port 0 supports change detection.

Next, I'd try using a Timed Loop that is controlled by "DAQmx Create Timing Source" where you specify the change detection event as the timing source.   Set the period to 1 so the loop will iterate on the first change detection event.  Hardwire the loop to stop on its first iteration.  Then you just need to fire off your serial messaging loop, either inside the only iteration of the Timed Loop or immediately after it ends.

However, it may be tough to maintain sync over a period of time.  It'd probably be better to use another Timed Loop for the serial messaging rather than a While Loop with a simple msec wait, but there's still no guarantee.  So I would also suggest that you capture a timestamp at each serial message you send.  So if you can't maintain the 10 msec intervals perfectly, you can at least have a decent measure of the actual interval times.

-Kevin P

[MikeStebbins]

Kevin,

Thanks for your quick response. 

This thread (http://forums.ni.com/t5/Multifunction-DAQ/pause-trigger-strange-behaviour/m-p/732523#M41132) links to a NI Develop Zone article that states "USB Bus-Powered M Series devices like the USB-6210 and USB-6211...do NOT support change detection."  Does the USB-6212 Bus-Powered DAQ fit into this category?

You are correct that I am using Windows.  I've been tasked with trying to make it work and have read a lot about machine changes and code optimization in an effort to give Windows the best chance it can have.  I had planned on using a Timed Loop (which I didn't state in the original post, my bad) and writing out a timestamp, just as you suggested. If it doesn't work sync tight enough, I'll need to look into a RT system.

Mike

[John_P1]

Hi Mike,

The 6212 does fall into the Bus-Powered M Series category.  Unfortunately, these boards (621x) do not support clocked DIO, and also do not support change detection.  Change detection would have allowed you to generate an event in software (or hardware) when either the A or B line changed state.

The 621x boards do support other events (e.g. Sample Clock Event).  If you could implement the change detection with external hardware (i.e. send a TTL pulse whenever one of the lines changes), you could use this signal as a sample clock event to kick off your parallel while loop.

I really am not too happy with this idea however.  Even if you find a good way to implement the change detection externally, you will still have bus latency and non-determinism from the OS to trigger the second loop.   If you want the serial data clocked out deterministically and synchronized with your first encoder pulse, I would strongly recommend upgrading to a USB X Series which should (depending on your requirements) be able to implement the clocked serial output itself based on a Change Detection Event trigger.  This would remove the non-determinism of Windows and USB from the equation altogether.  Keep in mind that these boards are not powered off of USB like the 621x (they use an external power supply).

Best Regards,

[MikeStebbins]

John, thank you for the reply.

Unfortunately for me, this is a graduate research project, which translates into tight budgets and "making-do" whenever possible.  With that in mind, I want to try to make the existing board work if at all possible.  Or, maybe I should say my advisor is interested in that approach 🙂

I wrote the small example program included this afternoon.  The 3 parts of the picture show the different stages:

1: The bottom loop reads the digital state of signal A from the encoder in iteration 0 and enters that into the shift register.

2 (top loop cut out as it remains unchanged): After iteration 0, the bottom loop moves into the False case structure, in which it compares the latest signal A value with the previous iteration's.  If they are the same (no movement), the bottom internal case structure is false, and the notifier isn't activated. 

3: When the current iteration's signal A value is different than the previous value, the bottom loop's internal case structure equals true, the notifier is activated, and the bottom loop is stopped.  That notifier "triggers" the upper case structure, which contains a simple testing While loop that runs indefinitely from that point on.  This would actually contain my Timed signal-generating loop.

In running a few tests with this, it seems to work.  Does anyone see any show-stoppers with this idea?

Thank you for the help; it's appreciated.

Mike

[MikeStebbins]

I forgot to mention in the previous post that ran a wire out from PFI 8 (the A signal counter) to P0.0, as Kevin mentioned.  That is the digital input in the code I included.

Sorry for the additional post, but I can't figure out how to edit my previous.

Mike

[John_P1]

Hey Mike,

Polling the digital line could work too.  The caveat with that is if the encoder pulses are shorter than the period of your loop you might miss them.

Best Regards,