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

[A_Person]

Hi Rammer and Holger:

I apologize for the delay in my response.  I've been pretty with some other tasks.  Some of this conversation is starting to go beyond what I remember of camera files and triggering on the camera link boards.  I am working to get someone from the support group to take a look and address your questions.  Thank you for your patience.

[h.baur]

Hi Rammer,

regarding CC and Line 4: In the "NI Camera File Generator Help" you will find some information about the "internal" line 4-7.

Line 4 defines internally the frequency for CC1, while line 0 gives the pulse duration for each peak on line 4. See chapter "Adding Pulse Generation Actions"

[Eric-M]

Hi Holger,

I'm working on catching myself up on what has happened so far in this discussion forum, to see how I can be of assistance.  In the meantime, there is an article that briefly discusses Camera Control Routing that may be of some help.  I apologize if that is redundant in any way, but it may help.

[h.baur]

Hi Eric,

I appreciate that you are going to touch this topic. But this is also a severe thing! I assume that most CL line-scan cameras use encoders as sync source.

Therefore I did not even think about this when ordering the PCIe1430s from NI since RS-422 is explicitly mentioned as a possible source.

Unfortunately the CVI examples do not work and the documents do not help either so RS422 is not working the way written down in the spec!

At the moment I found a way to circumvent the lack of documentation at least in one moving direction (i.e. using the IMAQ function described before).

But I do have a really bad felling because I do not see how it works nor does the behavior make sence after I read trough all available documents

touching CameraLink cards, the camera File (generator) and the IMAQ lib.

I would really appreciate the possibility to have the freedom to route the signals from RS422 (i.e scaled encoder signal) to CCn programmatically. Using a specific camera file

setting would also be ok if there would be a description how to do so.

Could you maybe check how NI did an internal test regarding the RS-422 and the PCIe-1430? For this any brand of camera on the CL Line should

have received the ExSync signal somehow on CC1 to CC4. This is basically all I need to understand.

The position readback of the RS-422 line works fine all the time so the main problem seems to be the routing to the CCn line on the FPGA.

Since using encoders on CL cards is a really basic setup there should definitely  be a document describing its proper setup and use.

Kind regards, Holger

[DarkLordOfG]

Holger,

It could be that I am missing something but could you use IMAQ Configure Trigger 3?  Here you would select "scaled encoder signal" as your source and "trigger each line (line scan)" as your action.  This should route the scaled encoder to the CC1 line if I understand this function correctly.

John

[h.baur]

Hi John,

what I really need for a line scan camera is the line trigger. imgSessionTriggerConfigure2() (I guess this is what you mentioned above) does the frame start triggering (i.e. a Z-Pulse on the encoder).

I use imgSessionStartAcquisition() to start the acq. The scaled encoder shall trigger each line.

So here is my setup again:

A) setup line trigger. The external line no (1) and skip count (0) seem to be irrelevant for Scaled encoder.

imgSessionLineTrigSource2(iLS_ZK1_SessionID, IMG_SIGNAL_SCALED_ENCODER, 1, IMG_TRIG_POLAR_ACTIVEH, 0); 

B) Setup the sequence

imgSequenceSetup(iLS_ZK1_SessionID, 1, vBufferlist, ui32SkipCount, 1, 1);

imgSessionStartAcquisition(iLS_ZK1_SessionID);

imgEncoderResetPosition(iLS_ZK1_SessionID);   // without the encoder counter reset it does not work!

C) loop till image is complete.

imgSessionStatus(iLS_ZK1_SessionID, &ui32Temp1, &ui32Temp2);     

D) stop acq.

imgSessionStopAcquisition(iLS_ZK1_SessionID);

This setup works BUT only if I reset the encoder and only in positive direction. If I run trough the zero position without an encoder counter reset the acq. does not work.

Also I do not have the possibility to grap an image on the way back so at the moment I have to use a relais to

swap line A and B on the RS 422 line manually!

there are the following commands available. Are there any more relevant?

imgSessionTriggerConfigure2   - Configures an acquisition to start.

imgSessionLineTrigSource2     - Configures the line trigger (works in principle but see comments above)

imgSessionTriggerClear           - clears a trigger

imgSessionTriggerDrive2          - used to drive external lines on internal events like acq. done

imgSessionTriggerRoute2         - used to route external lines i.e. RTSI to external. Unfortunately CC lines are not available

imgSessionTriggerRead2          - reads the status of a certain line

Holger

[Elmar_NI]

Hi Holger,

Eric mentioned already in his post that you can use TTL,RTSI and ISO In signals and root them directly to the CCL. You can use the encoder input to trigger the camera but it's not possible to select an encoder input directly for the CCL. You can open MAX to see the possible options.Whats the reason why would you like to do that? Please feel free to create a product suggestion if this feature is very important for you.

Thanks Elmar

[h.baur]

Hi Elmar, Eric, John, Alex,

let me ask a couple of explicitly formulated questions since it seems I am the only one not able to use RS 422 with the PCIe-1430.

A) what does the command

 imgSessionLineTrigSource2(iLS_ZK1_SessionID, IMG_SIGNAL_SCALED_ENCODER, 1, IMG_TRIG_POLAR_ACTIVEH, 0);

exactly do?

A1) Does it internally route the scaled encoder signal to an internal trigger?

A2) If so, which one? Does it matter?

A3) Does it route the encoder to CCn defined in the camera file? If not, how does command know about how to route this signal?

A4) If so, how do I setup the camera with MAX in a proper way? Or do I have to edit the camera file manually?

A5) If so, whilch CC line is chosen by the command above?

A6) Why do I have to reset the encoder counter with imaqEncoderResetPosition() to get ExSYNC working?

A7) Why does the scaled encoder signal only work in forward direction? Can I toggle this behavior? Where is this information written down?

B) Regarding the camera file settings, mentioned by Alex.

In the PG settings I have

Pattern { Action (PG) { Line (0) {

Start (Low) } Line (1) { Start (Low) } Line (2) { Start (Low) } Line (3) { Start (Low) } Clock (0x78) RepeatSource (Fixed, 10) }

Due to the explanation above I shoud not get ExSYNC at all, right?

B1) So why does it work in my case with the above blue command?

B2) I also see an entry SignalLevels { PGOutput(RS422)} in my camera file. Seems relevant, but no information available. So on the one side NI asks me to modify the camera file manually to use an encoder but how shall I do this without any information about the contents?

C) There is a CVI example, called "HL Trigger By Encoder". Assuming that someone did run a test with that code, could you give us some information about the camera and the camera file (modifications) that were used to get it running? Also, please read the commends at the beginning of the c File.! Do you think this is of any help btw? It tells me that my CL camera needs an external wiring but I have not seen any line scan CL cam that can be ExSYNC on a separate connector. This sounds more or less as a Firewire or GiGE example .

D) So, if there are clear answers, great! If not, could somebody please take a PCIe1430 and a line scan camera and run a test with an encoder? Also please, feel free to send me a working setup. I could use a Basler sprint or Dalsa PC-30 CL cam to run such a test on a PCIe-1430 + ext. board.

Kind regards, Holger

[Elmar_NI]

Hi Holger,

Maybe it make sense to step back and talk about the application. What are you trying to do? What is the goal of this application and please post how the setup looks like? (Encoder speed,current icd file, camera setup, wiring)
This would allow me to point you in the right direction.

To your question:

A) what does the command exactly do?

The function defines the trigger source.

• iLS_ZK1_SessionID reference to the open imaq session
• IMG_SIGNAL_SCALED_ENCODER use the scaled encoder signal as a trigger source
• IMG_TRIG_POLAR_ACTIVEH fires a trigger if the signal is active high

A1) Does it internally route the scaled encoder signal to an internal trigger?    
If you use the function the framegrabber knows that you want a triggered acquisition and the board is waiting for a trigger signal on the Encoder input.

The incoming trigger signal drives the Pulse Generation (PG block) and this pulse train will be routed to the camera control line.

A2) If so, which one? Does it matter? No it's up to you
IMG_SIGNAL_SCALED_ENCODER, 1 points to the encoder signal.

It's up to you if you need the direction or not (A and B signal -> negative counter possible)

If only A signal is connected you are not able to read out a negative counter signal.

A3) Does it route the encoder to CCn defined in the camera file? If not, how does command know about how to route this signal?

Yes define the pulse train in the PG section of the camera file. Please use the camera file generator to add the signal to the PG section and select the camera control line. Normally it's the CCL 1 but it's really camera related.Some cameras allow to choose the CCL (check the camera manual).

You have to set the camera in external triggered mode. In this case the framegrabber board will receive the trigger from the encoder input and send it to the PG block. The PG block will generate a pulse train to the CCL which is defined in the icd file. After the camera receives the pulse it will send back the image data to the board.

A4) If so, how do I setup the camera with MAX in a proper way? Or do I have to edit the camera file manually?
Please use the camera configuration software of the camera to set the camera in the correct mode. For example Basler cameras use the CCT+ or the Pylon software to change the attributes.

A5) If so, which CC line is chosen by the command above?
Need more information about the application itself to give a recommendation (Please check the camera modul which CCL is responsible for what. The default on most cameras is CCL1)

A6) Why do I have to reset the encoder counter with imaqEncoderResetPosition() to get ExSYNC working?
Need more information about the application itself to give a recommendation.

A7) Why does the scaled encoder signal only work in forward direction? Can I toggle this behavior? Where is this information written down?

Did you wire the A & B signal on the encoder input? You should definitely see a change in pluse or minus if you turn the encoder in different directions.

B) Regarding the camera file settings, mentioned by Alex.
In the PG settings I have
 
Pattern { Action (PG) { Line (0) {
Start (Low) } Line (1) { Start (Low) } Line (2) { Start (Low) } Line (3) { Start (Low) } Clock (0x78) RepeatSource (Fixed, 10) }
 
Due to the explanation above I shoud not get ExSYNC at all, right?
Right.

B1) So why does it work in my case with the above blue command?

It's good to hear that the application works.

Please check if there are any other pulse generation entries in the camera file. Delete all the pulse entries and you will see that the encoder line trigger will not work.

B2) I also see an entry SignalLevels { PGOutput(RS422)} in my camera file. Seems relevant, but no information available. So on the one side NI asks me to modify the camera file manually to use an encoder but how shall I do this without any information about the contents?

You don't need the entry it's there for the second generation boards and defines that the CCL is a RS422 signal that's it.

C) There is a CVI example, called "HL Trigger By Encoder". Assuming that someone did run a test with that code, could you give us some information about the camera and the camera file (modifications) that were used to get it running? Also, please read the commends at the beginning of the c File.! Do you think this is of any help btw? It tells me that my CL camera needs an external wiring but I have not seen any line scan CL cam that can be ExSYNC on a separate connector. This sounds more or less as a Firewire or GiGE example .
 Recording to A7 it seems to work. Maybe we must add some changes in the camera file or change the settings of the camera.But first it make sense to figure out what you are trying to do and what's the status at the moment. If the example is listed under NI IMAQ its definitely the right example for camera link triggered acquisition.

Regards,

Elmar

[h.baur]

Hi Elmar,

Maybe it make sense to step back and talk about the application. What are you trying to do? What is the goal of this application and please post how the setup looks like? (Encoder speed,current icd file, camera setup, wiring)
This would allow me to point you in the right direction.

once again: I use an encoder, line A plus B, RS 422, trig. speed max 16 kHz. The encoder counter on the PCIe 1430 runs up and down and is in accordance with the linear axis and another GeniCam camera that is also driven by the RS422 signal. So there is no doubt about the extension board and the wiring since the encoder counter value works great with no problem at all.

To your question:

A) what does the command exactly do?

The function defines the trigger source.

• iLS_ZK1_SessionID reference to the open imaq session
• IMG_SIGNAL_SCALED_ENCODER use the scaled encoder signal as a trigger source
• IMG_TRIG_POLAR_ACTIVEH fires a trigger if the signal is active high

A1) Does it internally route the scaled encoder signal to an internal trigger?    
If you use the function the framegrabber knows that you want a triggered acquisition and the board is waiting for a trigger signal on the Encoder input.

The incoming trigger signal drives the Pulse Generation (PG block) and this pulse train will be routed to the camera control line.

OK, so that's great to know now that this command drives the PG block, defined in the camera file and not any internal or external line as written in the manual.

A2) If so, which one? Does it matter? No it's up to you
IMG_SIGNAL_SCALED_ENCODER, 1 points to the encoder signal.

It's up to you if you need the direction or not (A and B signal -> negative counter possible)

If only A signal is connected you are not able to read out a negative counter signal.

Hmmm?? both lines A and B are wired, but the ExSYNC is only active in positive direction and only after an encoder reset as explained many times now! And I still do not see any reason for this behavior.There is no problem with the readout! Again, the problem is the triggering!

A3) Does it route the encoder to CCn defined in the camera file? If not, how does command know about how to route this signal?

Yes define the pulse train in the PG section of the camera file. Please use the camera file generator to add the signal to the PG section and select the camera control line. Normally it's the CCL 1 but it's really camera related.Some cameras allow to choose the CCL (check the camera manual).

You have to set the camera in external triggered mode. In this case the framegrabber board will receive the trigger from the encoder input and send it to the PG block. The PG block will generate a pulse train to the CCL which is defined in the icd file. After the camera receives the pulse it will send back the image data to the board.

Well, regarding to the camera everything is clear. Basler uses CC1 and we can use the serial comm. or the basler CC+ tool to switch to ExSYNC mode - as said before, it works IFF the NI Card does trigger the CC1 line. BUT it is still a mystery why this happens only in positive direction and only after position reset command.

A4) If so, how do I setup the camera with MAX in a proper way? Or do I have to edit the camera file manually?
Please use the camera configuration software of the camera to set the camera in the correct mode. For example Basler cameras use the CCT+ or the Pylon software to change the attributes.

Don't worry about the config. on the camera. It works! The problem is that ExSYNC is being routed in forward direction but not backwards and only after encoder position reset as said before!

A5) If so, which CC line is chosen by the command above?
Need more information about the application itself to give a recommendation (Please check the camera modul which CCL is responsible for what. The default on most cameras is CCL1)

A6) Why do I have to reset the encoder counter with imaqEncoderResetPosition() to get ExSYNC working?
Need more information about the application itself to give a recommendation.

What kind of information do you need?

A7) Why does the scaled encoder signal only work in forward direction? Can I toggle this behavior? Where is this information written down?

Did you wire the A & B signal on the encoder input? You should definitely see a change in pluse or minus if you turn the encoder in different directions.

YES I DO SEE THE COUNTER GOING UP AND DOWN DEPENDING ON THE DIRECTION I DRIVE. BUT THE EXSYNC DOES ONLY WORK IN ONE DIRECTION! 

B) Regarding the camera file settings, mentioned by Alex.
In the PG settings I have
 
Pattern { Action (PG) { Line (0) {
Start (Low) } Line (1) { Start (Low) } Line (2) { Start (Low) } Line (3) { Start (Low) } Clock (0x78) RepeatSource (Fixed, 10) }
 
Due to the explanation above I shoud not get ExSYNC at all, right?
Right.

B1) So why does it work in my case with the above blue command?

It's good to hear that the application works.

Please check if there are any other pulse generation entries in the camera file. Delete all the pulse entries and you will see that the encoder line trigger will not work.

B2) I also see an entry SignalLevels { PGOutput(RS422)} in my camera file. Seems relevant, but no information available. So on the one side NI asks me to modify the camera file manually to use an encoder but how shall I do this without any information about the contents?

You don't need the entry it's there for the second generation boards and defines that the CCL is a RS422 signal that's it.

C) There is a CVI example, called "HL Trigger By Encoder". Assuming that someone did run a test with that code, could you give us some information about the camera and the camera file (modifications) that were used to get it running? Also, please read the commends at the beginning of the c File.! Do you think this is of any help btw? It tells me that my CL camera needs an external wiring but I have not seen any line scan CL cam that can be ExSYNC on a separate connector. This sounds more or less as a Firewire or GiGE example .
 Recording to A7 it seems to work.

NO!

without imgEncoderResetPosition(SessionID) the triggering does not start at all nor does it work in negative direction!

Since I cannot see any direction definition in the camera file it has to be the same odd behavior on all kind of cameras.

But since there is no document about the internals of the NI camera file it's really hard to be sure.

Maybe we must add some changes in the camera file or change the settings of the camera.But first it make sense to figure out what you are trying to do and what's the status at the moment. If the example is listed under NI IMAQ its definitely the right example for camera link triggered acquisition.

I deeply agree! But if I were at NI I would rather run a test. Remember 2007 and the 6 month odyssee we had together....

Regards, Holger

Regards,

Elmar

[h.baur]

Hi Elmar,

Maybe it make sense to step back and talk about the application. What are you trying to do? What is the goal of this application and please post how the setup looks like? (Encoder speed,current icd file, camera setup, wiring)
This would allow me to point you in the right direction.

once again: I use an encoder, line A plus B, RS 422, trig. speed max 16 kHz. The encoder counter on the PCIe 1430 runs up and down and is in accordance with the linear axis and another GeniCam camera that is also driven by the RS422 signal. So there is no doubt about the extension board and the wiring since the encoder counter value works great with no problem at all.

To your question:

A) what does the command exactly do?

The function defines the trigger source.

• iLS_ZK1_SessionID reference to the open imaq session
• IMG_SIGNAL_SCALED_ENCODER use the scaled encoder signal as a trigger source
• IMG_TRIG_POLAR_ACTIVEH fires a trigger if the signal is active high

A1) Does it internally route the scaled encoder signal to an internal trigger?    
If you use the function the framegrabber knows that you want a triggered acquisition and the board is waiting for a trigger signal on the Encoder input.

The incoming trigger signal drives the Pulse Generation (PG block) and this pulse train will be routed to the camera control line.

OK, so that's great to know now that this command drives the PG block, defined in the camera file and not any internal or external line as written in the manual.

A2) If so, which one? Does it matter? No it's up to you
IMG_SIGNAL_SCALED_ENCODER, 1 points to the encoder signal.

It's up to you if you need the direction or not (A and B signal -> negative counter possible)

If only A signal is connected you are not able to read out a negative counter signal.

Hmmm?? both lines A and B are wired, but the ExSYNC is only active in positive direction and only after an encoder reset as explained many times now! And I still do not see any reason for this behavior.There is no problem with the readout! Again, the problem is the triggering!

A3) Does it route the encoder to CCn defined in the camera file? If not, how does command know about how to route this signal?

Yes define the pulse train in the PG section of the camera file. Please use the camera file generator to add the signal to the PG section and select the camera control line. Normally it's the CCL 1 but it's really camera related.Some cameras allow to choose the CCL (check the camera manual).

You have to set the camera in external triggered mode. In this case the framegrabber board will receive the trigger from the encoder input and send it to the PG block. The PG block will generate a pulse train to the CCL which is defined in the icd file. After the camera receives the pulse it will send back the image data to the board.

Well, regarding to the camera everything is clear. Basler uses CC1 and we can use the serial comm. or the basler CC+ tool to switch to ExSYNC mode - as said before, it works IFF the NI Card does trigger the CC1 line. BUT it is still a mystery why this happens only in positive direction and only after position reset command.

A4) If so, how do I setup the camera with MAX in a proper way? Or do I have to edit the camera file manually?
Please use the camera configuration software of the camera to set the camera in the correct mode. For example Basler cameras use the CCT+ or the Pylon software to change the attributes.

Don't worry about the config. on the camera. It works! The problem is that ExSYNC is being routed in forward direction but not backwards and only after encoder position reset as said before!

A5) If so, which CC line is chosen by the command above?
Need more information about the application itself to give a recommendation (Please check the camera modul which CCL is responsible for what. The default on most cameras is CCL1)

A6) Why do I have to reset the encoder counter with imaqEncoderResetPosition() to get ExSYNC working?
Need more information about the application itself to give a recommendation.

What kind of information do you need?

A7) Why does the scaled encoder signal only work in forward direction? Can I toggle this behavior? Where is this information written down?

Did you wire the A & B signal on the encoder input? You should definitely see a change in pluse or minus if you turn the encoder in different directions.

YES I DO SEE THE COUNTER GOING UP AND DOWN DEPENDING ON THE DIRECTION I DRIVE. BUT THE EXSYNC DOES ONLY WORK IN ONE DIRECTION! 

B) Regarding the camera file settings, mentioned by Alex.
In the PG settings I have
 
Pattern { Action (PG) { Line (0) {
Start (Low) } Line (1) { Start (Low) } Line (2) { Start (Low) } Line (3) { Start (Low) } Clock (0x78) RepeatSource (Fixed, 10) }
 
Due to the explanation above I shoud not get ExSYNC at all, right?
Right.

B1) So why does it work in my case with the above blue command?

It's good to hear that the application works.

Please check if there are any other pulse generation entries in the camera file. Delete all the pulse entries and you will see that the encoder line trigger will not work.

B2) I also see an entry SignalLevels { PGOutput(RS422)} in my camera file. Seems relevant, but no information available. So on the one side NI asks me to modify the camera file manually to use an encoder but how shall I do this without any information about the contents?

You don't need the entry it's there for the second generation boards and defines that the CCL is a RS422 signal that's it.

C) There is a CVI example, called "HL Trigger By Encoder". Assuming that someone did run a test with that code, could you give us some information about the camera and the camera file (modifications) that were used to get it running? Also, please read the commends at the beginning of the c File.! Do you think this is of any help btw? It tells me that my CL camera needs an external wiring but I have not seen any line scan CL cam that can be ExSYNC on a separate connector. This sounds more or less as a Firewire or GiGE example .
 Recording to A7 it seems to work.

NO!

without imgEncoderResetPosition(SessionID) the triggering does not start at all nor does it work in negative direction!

Since I cannot see any direction definition in the camera file it has to be the same odd behavior on all kind of cameras.

But since there is no document about the internals of the NI camera file it's really hard to be sure.

Maybe we must add some changes in the camera file or change the settings of the camera.But first it make sense to figure out what you are trying to do and what's the status at the moment. If the example is listed under NI IMAQ its definitely the right example for camera link triggered acquisition.

I deeply agree! But if I were at NI I would rather run a test. Remember 2007 and the 6 month odyssee we had together....

Regards, Holger

Regards,

Elmar