Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Hi Holger,

 

Thanks for the additional information.

To summarize:

The triggered acquisition works in one direction but if you move the encoder backwards you don't see an image.

We implemented the A & B inputs to read out the encoder counts to figure out the position of the object.

The pulse generation doesn't take care of the signal B. This is the reason why you don't get an image if you turn the encoder backwards.

 

Regards,

 

Elmar

 

PS: Yes I can remember that we worked together in 2007.

On the first day I collected all the data to get the big picture.

On the second day I provided a direct contact to our R&D team.

Finally we released a new library to control VBAI (old communication was based on Active X)

 

 

 

 

0 Kudos
Message 21 of 34
(1,321 Views)

Hi Elmar,

 

first of all thanks that we finally touch the main problem. Anyway, I do not understand your explanation since the encoder always toggles line A and B regardless of the direction - only the phase between A and B descides about the direction so if you only look on line A you will see the same behavior forward and backward. Furthermode I see an X4 decoding for the SCALED_ENCODER which is only bossible if you consider A and B together. But anyway, if the NI CL cards can only trigger in forward counting mode, then please inform us about it. If I buy a car with stearing weel offered I assume to be able to go left AND right and not to make a 270 deg. turn left in order to go right! In the end of this project I need to explain guys from a big car company in Stuttgart why we need to toggle the lines A & B by mechanical means in order to grap images in backward move if we do not find a way to resolve this. Since we are going to build this system many times I need to also descide if we need to change hardware again - so please check with the NI developers if this is somehow hard coded or can be solved by means of software configuration. 

 

Then there is the other point about the position reset. How does this fit into this picture? Did I miss this out anywhere or is this yet another puzzle?

And finally, how on earth did anybody get the above mentioned CVI example running? Or was the testing done theoretically?

 

If you start reading this posting from top you will see that this is what I tried to explain form the far beginning but because I do not get a deep enough view inside the hardware to explain you what really causes the problem please do not blame me for not pointing out things in more detail. I just start to learn what actually happens.

 

And by the way I was thinking about the following 3 month of nighly conferences with Nic and Brad and a loss of about 30 kEuro of extra salary and many sleepless nights after you could confirm the problems we reported... and I do not want to step into such a thing again. But this is not the right place - I would appreciate if we could get in touch by email or phone to finally solve the problem about the forward / backward mystery, the problem of the needed position reset and about any solutions to circumvent this and about how to handle reported problems in a proper way.

 

Kind regards, Holger

 

0 Kudos
Message 22 of 34
(1,317 Views)

Hi Holger,

 

Yes the phase between the A & B signal is responsible to increment or decrement the counter. But the phase signal is not routed to the pulse generation only the A signal. I added an image which explains the triggering and the encoder count. If you move forward (line 3 in the image) you send some lines to the camera as soon as you hit the last encoder count. If you want it earlier you have to reset the counter.

 

Please forward me the following information:

  • Encoder (single ended on A- and B- or differential A-,A+ and B-,B+)
  • Encoder frequency
  • Encoder Voltage level
  • If you take a look at the attached image how should the triggering work in your application?

With this information we can figure out which option we have and talk about a possible solution.

We can also set up a conference call after you provided me the answers to my questions.

 

Regards,

 

Elmar

 

0 Kudos
Message 23 of 34
(1,296 Views)

Hi Elmar,

 

the encoder signal is RS422, i.e. Line A+, A- and B+, B- as differential signal. The encoder reading is perfect, i.e if I run the linear motor in a loop forward and backward for an hour I end up with the same reading at µm-resolution compared to the internal position readout of the controller. Termination is also fine. The encoder signal is "generated" by the linear motor controller and drives a GenICam camera as well with no problems. The readout of all 3 devices correspond. The freqency depends of course on the driving speed of the linear axis but on my tests I had 4-80 kHz on the encoder together with a ENCODER SCALING FACTOR of 4 with gave about 1-20 kHz ExSYNC frequency for the line trigger CC1. I also confirmed this by routing the ExSYNC trigger to an external line. The jitter is below 5% if I do not run the axis too slow.

Anyway, as said before, the triggering works in principle besides the problem that I cannot grab an image on the way back and the puzzling position reset that I have not seen anywhere in the documentation or somewhere else so far (till you explained that).

 

If I understand your drawing, line A is used as trigger source combined with an internal logic signal from the FPGA that makes sure only a forward move is being recorded and if a short backward move happens to appear in between on the grabbing, there is a stop of the recording till the old position is reached again. 

 

So, finally we have the following conclusions (please correct wrong assumptions):

 

A) The correct setup for a line trigger from an encoder is

 

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

 

This tells the FPGA on the CL Card to route signal A together with the logic you explained, to a line that is defined in the PG section of the camera file.

The trigger number (1) and skipcount (0) is not relevant to scaled encoder setting.

 

B) the Position Reset is definitely needed, i.e.

 

imgEncoderResetPosition(SessionID)

 

must be used to define a starting position for the internal logic.Together with the camera file settings this is the reason why the CVI sample mentioned before does not word.

 

C) a grabing in negative direction is not supported by the NI CL cards so far - it has to be arranged by an interchange of line A and B from outside the card.

 

D) For the camera file there is no internal description available even tough I need to adjust the PG section.

 

The use of the position reset command is no problem but it would be great to be able to control the direction how to grab! Does NI has to generate a new bitstream for that or is is possible to do this by a software commend in the actual version?

 

Kind regards, Holger

 

  

0 Kudos
Message 24 of 34
(1,284 Views)

Hi Holger,

 

Yes thats the right interpretation.

 

If I understand your drawing, line A is used as trigger source combined with an internal logic signal from the FPGA that makes sure only a forward move is being recorded and if a short backward move happens to appear in between on the grabbing, there is a stop of the recording till the old position is reached again.

 

Here are my comments:

 

A: Correct.

The trigger number (1) and skipcount (0) is not relevant to scaled encoder setting.

The skipcount didn't effect the encoder count but it effects the pulse generation.

If you use skipcount 0 you rout every pulse to the PG.

If you use skipcount 1 you skip every second pulse. 0,2,4,6......

The trigger number make sense for the TTL and RTSI lines because there are multiple options.

 

B: Correct

It really depends on the application.

If you move backwards followed by a forward move you have to reset the encoder.

In this case you can start the acquisition directly in the forward move without waiting for the previous encoder count.

 

C: Correct

You have to reset the encoder and route the B signal to the A input.

 

😧 Correct

It seems we should improve the documentation.

There is no workaround in the icd file or a simple vi change. To implement a triggering backwards we have to change the bitstream and add a new functionality.

In this case this is a feature request.

 

But please feel free to post a diagram which explains how the triggering should work in your application.

 

Regards,

 

Elmar


Message 25 of 34
(1,277 Views)

Hi Elmar,

 

thanks for clarifying these issues missing in the doc.

 

There are a few other things you should really update in the documentation.

 

The camera link reference states that the 2 ports on the PCIe 1430 are independent channels - this is only partly true.

 

A) One cannot open a session on port 0 and port 1 (img::0 / img::1) in different threads.

 

B) There is only one single encoder counter on the card, i.e. if one resets counter on session (img::0) this also resets counter on session (img::1). I also assume that encoder scaling cannot be chosen distinct. Since the hardware IO ports as well as the encoder lines do not correspont to a single session it should be clarified what happens for example in a hardware conflict, i.e. one could drive the same HW line from session img::0 and session img::1.

 

Regards, Holger

0 Kudos
Message 26 of 34
(1,253 Views)

Hi Holger,

 

We are working on a getting started for the camera file generator. This will give us definitely the opportunity to improve the documentation.

To your questions:

A.) Yes that's true you must use both cameras in the same thread. You can use the cameras in two different vis but not in two different threads (like MAX and LabVIEW).

B.) There is only one encoder input on the extension board. Two encoder inputs requires a hardware redesign. I forwarded the hardware request to the R&D team. We will definitely keep it in mind for the next I/O board. Its possible to use one encoder and a different scaled encoder factor for each acquisiton. Maybe one workaround is to use the TTL inputs instead.

 

ControlLinesSource {

UseDefaultSource (No)
CCSourceLine0 (External, 0)

 

Will allow to root the signal directl from the TTL input to the CCL.

You can also use the PG section

 

ControlLinesSource {

UseDefaultSource (Yes)
CCSourceLine0 (External, 0)

 

This entry in the icd file will allow you to use the PG section for the TTL input. You can also specify the skip trigger which is similar to skip encoder.

 

Regards,

 

Elmar

0 Kudos
Message 27 of 34
(1,247 Views)

Hi Elmar,

 

thanks again for the quick answer. The problem with B is that I still need to reset the encoder counter before I can grab an image as described in length above. But by sending a reset to port 0 I also see a reset on the counter regarding to port 1. There is in principle no need for me to have 2 separate A and B lines. Two distinct counters would be sufficient.

 

Holger

0 Kudos
Message 28 of 34
(1,244 Views)

Hello Holger,

 

I agree with Elmar... there's only a hardware port for a single quadrature encoder on the 1430.

 

However, have you tried taking your RS-422 encoder and converting it to TTL pulses?  You could use the TTL version of A+/A- as a framegrabber input (like TTL 1), and then copy that output to CC1?  I'd expect a Camera File section like the following:

 

ControlLinesSource {

   UseDefaultSource (No)

   CCSourceLine0 (External, 1)

   CCSourceLine1 (None, 1)

   CCSourceLine2 (None, 2)

   CCSourceLine3 (None, 3)

}

 

In this manner, the A+/A- part of the quadrature encoder would be copied to the first Camera Control Line.  It would work backwards as well as forwards.  If the camera can be set to be sensitive to both edges of CC1, then the camera would expose for every other (instead of every fourth) tick of the X4 quadrature encoder.  You wouldn't have to call imgSessionLineTrigSource2, since the actual TTL 1 signal would be copied to CC1.

 

Since I'm a hardware engineer, I also thought of this:  

Put a discrete XOR gate chip in front of the framegrabber, so that the TTL 1 input isn't just a TTL version of A+/A-, but is the XOR of A and B.  This signal will invert itself on every quadrature encoder tick (forwards or backwards).  If the camera is sensitive to both rising and falling edges of CC1, then you've got exactly the same thing as a second quadrature encoder that works backwards (except that you can't read the count of your hand-made quadrature encoder).  Like I said, I'm a hardware engineer, so of course I think about adding more hardware to the system.  🙂  But, if you have access to a discrete TTL XOR chip or can buy one on digikey/mouser/jameco, this could be an option.

 

Either way, this setup doesn't require resetting the quadrature encoder because the quadrature encoder tick is directly sent to the camera, and works equally well forwards and backwards.

 

For the other camera, you could do something similar, or use the regular quadrature encoder for triggering.

 

Thanks,

Daniel

 

Staff Digital Hardware Engineer

Vision Hardware

National Instruments

0 Kudos
Message 29 of 34
(1,228 Views)

Holger,

 

I had one more thought...

 

You mentioned "no need for me to have 2 separate A and B lines."  I may have misunderstood your use case -- you're not looking to have the cameras running on two separate conveyor belts... you just want them to be reset independently.

 

When you read the quadrature encoder count, then yes... resetting the quadrature encoder from img::0 will also reset the quadrature encoder count reported on img::1.  However, the part of the FPGA that prevents backwards ticks from firing PG (the quadrature scaler) resets on a per-acquisition-unit basis.  This is intentional so that if you're depending on duty cycles of scaled-quadrature-encoder-timed-pulses (see imgPulseCreate2), you have control of when they get reset.

 

So, although the count has reset on both boards after only one call to imgEncoderResetPosition, you'll still need to call that function from both.

 

 

 

By the way, it appears that the original decision to keep the quadrature encoder working in a forwards direction only was intentional (the hardware now calibrates out any jitter or manual adjustments on the production line, especially for scaled-encoder-timebase-pulses).  

 

However, this seems like a valid use case, and I (like you) am surprised that this hasn't come up before.  To get the quadrature scaler to work backwards would require a separate mode so that other customers' current behavior isn't broken.  I'll see what I can do to get this feature request considered in the next round of firmware updates.

 

Regards,

Daniel W.

Staff Digital Hardware Engineer

Vision Hardware

National Instruments

Message 30 of 34
(1,223 Views)