How to route Quadrature Encoder signal to CC1 using PCIe 1429 + IO extension card

[Eric-M]

Hi all,

In a step towards creating better documentation on this subject, we have created a tutorial that shows a step by step process of routing a TTL on the IO Extension Board to the CC1 line.  Below is a link to the tutorial.

How to trigger each line on a line scan camera

Hope this helps solves some of the issues.

[h.baur]

Hi Daniel,

thanks for also clearing another important point - and yes, we only have one conveyor belt but maybe different starting positions. At the moment I need to grab 2 really big images to make sure that I see the features on both sides that do have different positions.

I do not really understand the part about the imgPulseCreate() function. I understand the functionality (i.e. like the signal routing function but to produce a single pulse or a pulse train). But we do not use this function at all! So how does it fit in? I thought that the pulse creation has to be done in the camera file under the PG section. I would love to create those pulses triggering the camera via the CC lines manually in the C code i.e. by routing the scaled encoder signal directly to the CCn line but as far as I understood the answers in this forum this is not possible.This would really give us the freedom we need and would get rid of all those questions that rise up with the camera file (i.e. forget about the camera file at all). We already control the camera via serial line so the CCn creation is the only part we cannot really control.

I think the only way to clear all those topics is to understand what the FPGA actually does and which part of the software has control of those parts.

The PCIe-1430 with 2 (independent) ports has to share the same IO module so to me it is absolutely unclear what happens if I route a signal out. Can each SID use some lines independently and the user has to make sure there is no signal mixing?

Will the camera on port img::0 and img::1 run synchronised if they both depend on the scaled encoder signal? We use the same strobe signal and route the scaled encoder signal out to trigger a flash controller and sometimes only one camera does see light.

Do I have to route out the scaled encoder signal twice for SID 0 and SID 1 onto 2 independent IO lines?

Regarding the next FPGA bitstream.. A flag to toggle Lines A and B on the encoder imput would be sufficient, right?

Thats the way most camera vendors handle the problem on GenICam linescan cams.

Kind regards, Holger

[h.baur]

Hi Daniel,

today I routed the SCALED_ENCODER signal from port 0 and port 1 of the PCIe-1430 to IO 3 and 5 respectively and I recognised that both signals do run with a certain delay (probably one X4 encoding step)  as well as exactly in parallel from time to time so even tough there is only one hardware line for A and B and and a reset does clearr both ports there seem to be to different counting registers that produce the internal scaled encoder signal....

It would be great if we could clear this topic.If you want me to run any further tests please let me know...

Kind regards, Holger.

[Daniel_W]

Hello Holger,

The imgPulseCreate() function can use an absolute timebase derived from an on-board oscillator, or it can use the quadrature encoder as its timebase.  in other words, you can set up a pulse lasting exactly one quadrature encoder tick.  Unfortunately, you can't use imgPulseCreate() to drive the CC lines, so it's not particularly relevant in your case.  I just brought it up as another example of how existing functionality relies on the behavior of the quadrature tick timebase (used in imgPulseCreate and for triggering per-line), and couldn't be changed without adding a new mode, thus preserving backwards compatibility.

For the 1430, shared resources (like the IO lines) are managed by the NI-IMAQ driver.  If a second imgSession tries to drive shared resources, it will return an error.

Also, you bring up an interesting point that jogged my memory.  There is an attribute that changes the PhaseA polarity.  Reversing Phase A's polarity would essentially cause forward ticks to be counted backwards.  Hitting this attribute, combined with resetting the quadrature encoder should cause the quadrature encoder to "run backwards" (e.g. count forwards and trigger as you expect, even though the line is moving backwards).