Trouble Exporting Basler sprint pixel clock to PCI 1428

[adamjblack]

I'm trying to synchronize timing between an image grabber (1428) and camera (Basler sprint linescan) and would like to use the camera's pixel clock signal. I can output every signal with the trigger drive2 vi except the pixel clock, I get the error "Resource Unavailable."

I've tried changing the Advanced Acquisition settings (e.g. Synchronize Timing, Noncontinous Line Enable, Fast Rearm) and checked the clock of the camera (40MHz) and the max speeds available by the 1428 (50MHz) and still cannot get access to the pixel clock signal (the 'Resource Unavailable' error from trigger drive 2). Is this option just not possible with the 1428  or is there something else I'm missing.

I'm using LabVIEW 2011 on Windows 7 64-bit and IMAQ 4.6.1

--Thanks--

[Jeff-P]

Hi adamjblack,

A couple of questions for you to get a better idea of what is going on!

Which specific camera are you using? I was looking up the specs for Basler sprint cameras and there are a number of them, so it would be helpful to know which one you are using.

Also can you give me some more information about your application? Just to confirm that I understand what you are trying to do, you are trying to import the camera clock to the image grabber to synchronize the two devices?

Also you are using the trigger drive2 vi, how do you have it configured? Would it be possible for you to post a picture of that part of your code?

Regards,

[adamjblack]

Jeff-P,

I'm using a Basler SpL4096-140km. I have it set for

Video Output:2 Tap 12-Bit
Clock:40MHz
Line Acquisition Mode:Vertical Binning
Horizontal Binning: Enabled
Free-run, Programmable with a Line Period of 50us

To ammend my previous post, I'm running IMAQ 4.6.4

I've attached a JPEG of my VI that produces the error.

I want to use the pixel clock because I need to synchronize control signals (analog channels from a DAQ) to the frame acquisition of the camera. I am using 'Trigger Every Buffer' (IMAQ Configure Trigger3), I notice my frames could be off by one line here and there due to the 'Frame Start' signal operating off of the 'Horizontal Synchronization Signal' when the control signal is operating off of a different clock (default DAQ timebase). I could export the 'Horizontal Synchronization Signal' which works fine, but for operations inbetween frames the control signals need a higher rate, which is why i want it derived from the pixel clock.

[adamjblack]

I think I should clarify that the 'Trigger Each Buffer' signal is coming from a counter that is using the 'Horizontal Synchronization Signal' for the source of ticks. This counter trigger also triggers the control signals whose sample clock needs to be faster than the 'Horizontal Synchronization Signal', which is why I want to use the pixel clock.

[Jeff-P]

Thanks for the additional information, I think I understand what you are trying to do. I have been looking into this and I am not sure why you are not able to export the pixel clock. As you originally said, this might be a limitation of the 1428 hardware, but I am going to look into this further and try to confirm that one way or the other.

Regards,

[adamjblack]

I've done some additional testing with a PCIe 1429 with the Basler spL4096-km and a Basler Ace series acA2000-340km and I get the same error whether I use the sprint camera on the 1428 or 1429 (in base or full configuration, which I don't think matters but I tried it anyway). I also get the same error exporting the Basler Ace pixel clock on the 1429.

I've tried Labview 2011 32 and 64 bit.

If it matters, both frame grabbers are connected to the PCIe 6361 via a RTSI cable. I've tried only connecting it to the 1429 (I don't think it even needs to be connected but I tried anyway) but that didn't help.

Do I need to try reinstalling IMAQ? I just don't know why the resource is unavailable. Both the 1428 and 1429 can detect the pixel clock and display images and export any other signal from the 'Trigger Drive2' vi except the pixel clock.

[Jeff-P]

I spoke to one of our developers for these boards and he indicated that it is not possible to route the pixel clock on third generation boards (1429/1430/1427/1433/1435 and later). He mentioned that an alternative you could consider is that the framegrabber can create a pulse up to 2MHz and export that on both RTSI and CC0. Hopefully that gives you a workaround.

Regards,

[adamjblack]

Thanks Jeff-P

That would be a more than sufficient work around. Just to clarify, are you referring to the 'Generate Pulse" VI? So I should set the 'Pulse Parameters' in the units 'seconds'? If so, I was unaware that it had microsecond resolution since its base units (seconds) is so large.

[Jeff-P · Accepted solution]

Yes using the Generate Pulse VI, specify the units as seconds and the pulse width as a small fraction to achieve the higher resolution.

Regards,

[adamjblack]

Fantastic! works great--Thanks again