hal/python control scheme help

I'm working on a project using a machine vision camera taking pictures of a fast moving object. Constantly updated still images allows view of the object as if it were standing still, like a strobe. I'm working on a custom GUI since everything LinuxCNC is pretty much tailored to machine tools and isn't really suitable. I'm using a Mesa 7I76e. A stepper drives this camera side to side along an axis (X) and that was working in the stock LinuxCNC so that's all fine. but that's the only typical axis.

I have a ways to go on the UI and figuring out all the Hal/Python stuff but most of that's been done before so eventually I'll figure all that out. The one thing that's a concern is figuring out the trigger control for the camera. The trigger is just an output pulse from the Mesa card I/O but I have to figure out the timing. Theres a 600ppr encoder that will meter the line speed, this is using the provision for the spindle encoder, tho there's no "spindle" motor the encoder just monitors the speed of the line the rig is hooked up to. Theres also a PNP sensor that detects the object, I'll call this the "index". So idea is:

The index sensor detects it's trigger and goes high. Then the camera output is triggered and takes a picture and is displayed onscreen. Now the camera trigger output can't be time based because the line speed will change. I also need to advance and retard the cameras trigger through the GUI, this acts as a "Y axis", this gives the effect of moving forward or backward along the object. I'm assuming the scheme is to receive the index pulse and trigger the camera on a number of counts from the encoder. I can advance and retard the camera trigger (Y axis) by reducing or increasing the number of encoder counts until the camera trigger is output. What I don't know is how to implement this in linuxCNC. I was looking to pass this off in the user exchange but I had no hits so I'm on my own and any help is appreciated.

Yes, I think you could use the encoder index so the first step is setting encoder index_enable true when searching for an object
Then when index_enable is cleared (because an index was detected) the encoder position will be zeroed so the encoder position is now relative to the object. This can in turn arm your position comparator

At the minimum I suspect you will need several hal components including
"comp" (the comparator for comparing the encoder position to the offset)
"onsehot" (for generating a fixed length pulse from the comparator output)
"and" (for arming the one shot only when waiting for the offset count)

Is encoder (IDX+) Field voltage tolerant? The PNP sensor is 12-30v and will ideally run off the 24v power supply everything else is.

No, encoder index is a 5V signal so an opto-coupler, a transistor with a base resistor suited to 24V
or voltage divider would be needed with a 12/24V PNP sensor

I have it installed with the Voltage divider. It's at about 4.2v when the sensor goes high but only sinks to about 1.2v. Halshow sees it changing state, but I'm wondering what the threshold is and if that will be reliable. Didn't get around to the HAL stuff yet, I'm sure that will be fun.

The encoder inputs have 2K pullups to 5V so if you use a voltage divider, it should be low impedance
say 800/200 ohm

Are we able to ignore/count index signals? I'm winding up the control scenario in my head and it looks like using every index to count pulses will be an issue. So lets say their would be 600 counts between indexes, and this would change from day to day so I need a margin. So would I be able to use say every 3rd index, then start counting pulses that may extend beyond the length of 1 index? So 600 counts per index, but every third index and count 800 pulses after the accepted index?

You can count index signals in hal if they are wide enough (and they wont reset the position unless index enable is true)
If the index pulses are too short to count at the servo thread sample rate (shorter than 1 ms) you either have to live with the position being reset every index or count the index pulses some other way (for example, if you are not using quadrature, the B input of the 7I76Es encoder input could be configured at a additional counter with custom firmware)

Hmm, I assume you mean that the 3 indexes would have to happen within 1 m/sec to count them?

Right now I'm using one of the shorter expected distances as an example which is 11" at a speed of 500fpm, if my math is right I have 9.09 indexes/sec so it looks like I'm well above that, or am I misunderstanding?

OK so the index signals are very slow so can easily be counted in software say with the "updown" counter component