Absolute angular encoder to trigger high speed camera

[_discoVolante]

Hi!

I am new to LabView and I have a task I am struggling with.

My goal is to use an absolute angular encoder to trigger a camera at a desired angle (0-2pi). This angle may vary, but is for starters set to the default value 2 in "Global values".

The shaft that is connected to the encoder will rotate at 700 rpm, but with a slight variation, so time based triggering would not work.
The absolute encoder outputs an analog signal from 0 to 10, but is scaled in the program to vary from 0 to 2pi.
I am using a Basler ace 1440 and LabVIEW Version 19.0.1 (32-bit).

I want the system to be quite accurate, so that the angular position of the image captured vary by a maximum of +-0.05 radians from the desired angle.

My current program works as follows:
I have split this task up in two separate programs, and some global values.

1. An encoder program "EncoderTrigger.vi". When the angular position value of the encoder is slightly less(1.9) than the desired value(2.0), it uses the current velocity to calculate the a wait-time until the position is at the desired value, and it sets the global Boolean value  “Trigger camera” to true. 

2. An image grab program "GrabImage.vi". When “Trigger camera”  is true, it waits the calculated wait-time and it starts a producer loop which grabs an image and saves it in a consumer loop. I do not know the delay between the programs, but I thought of subtracting the delay from the wait-time.

For now I have to manually set the global value "StartEncoderProgram" to true each time I want to grab new images. This is done to make sure it doesn’t trigger multiple times between 1.9 and 2, which happened in a previous program I had. In the future I want to automatically capture an image each time the desired angle is passed by the encoder i.e. capture one image at each revolution.

So, I have a feeling this is all a bit messy and I am looking for some help to improve. The way I calculate the wait-time seems logical in theory, but I have a feeling it is not the best way to do it.
I have red on different forms about extracting a specific buffer number, but I cannot get my head around how exactly this can be done in my case. Which VIs I could use for this and how to know which buffer number to take? And also, how to know the delay between loops or programs?

I have also red about using a Trigger VI instead of true/false values, but I find this a bit tricky as well. Can a trigger VI be used in my case? 

I also want to say thanks from the help I have gotten from the following threads:
https://forums.ni.com/t5/LabVIEW/How-to-Optimize-Camera-Speed-fps/td-p/3958048/page/2?profile.langua...
https://forums.ni.com/t5/LabVIEW/Need-a-trigger-based-on-particular-angular-position-of-encoder/td-p...

Any help on how to improve my program would be greatly appreciated! 🙂

Thank you

[wiebe@CARYA]

---

@_discoVolante wrote:

Which VIs I could use for this and how to know which buffer number to take? And also, how to know the delay between loops or programs?

I have also red about using a Trigger VI instead of true/false values, but I find this a bit tricky as well. Can a trigger VI be used in my case? 

---

Synchronizing processes is best not done with VIs. Use Queues, Notifiers, User Events or Channel Wires instead.

Not sure what a Trigger VI is.

You get to "know" the delay between loops by measuring. You can make VIs (FGV) for a permanent measurement, or timer probes for a development time solution (debugging).

Here's a thought: when passing the trigger from one loop to the other, pass the timestamp as well. When you receive and handle the trigger get the time and you'll know the delay.

When everything is working correctly, I expect the delay to be neglectable. If the loop is busy, there might be a delay. This delay won't be static (it's more a jitter than a lag).

An approach can be to continuously acquire images (unless there's flash lightning). Keep the images and their timestamps in a circular buffer. When you get a trigger, get the image closes to the trigger timestamp from the buffer. This buffer will be a memory hog, but as it's circular, it will be efficient.

[Kevin_Price]

I agree and would summarize this way.

1. The best option is to *control* the angle/image correspondence using hardware signals.  I do not know if this is feasible with your absolute encoder and your camera.

2. The alternative is to capture both angles and images with a means to carefully *correlate* them.

-Kevin P