Can I generate pulse trains on the PCIe-1427 without waiting for frames to be acquired?

[ysirotin]

Yes Exactly,

I aim to acquire continuously after the trigger and my camera does not have a start on trigger mode.  I would like to have the board generate a pulse train.  Can I do that via the camera file generator?  If not, please point me to the documentation I requested in my previous post.

Thanks,

  --Yevgeniy

[kellam]

You cannot do this via the camera file generator.  To generate pulses with the IMAQ driver, you need to use the imgPulseCreate2() function.  It is described in the NI-IMAQ function reference help file, which can be found at http://digital.ni.com/manuals.nsf/websearch/061425BC4011F7DB8625761C0066601B

Note that you will not be able to drive the line to the camera directly with the pulse created by this function.  The easiest workaround is to drive the pulse out an unused RTSI line and configure the acquisition to trigger on that line.

[ysirotin]

As you may know (and as I found out recently from NI), my imaging board (PCIe-1427) does not support continuous frame triggering from an RTSI line.  I can start acquisition, but cannot have an RTSI line supply a trigger for each frame.  Is this indeed so?  How do I work around this?

All that my camera needs to be happy is a TTL pulse that starts when acquisition is triggered by the DAQ and repeats at the frame rate (e.g. 30 Hz).  One simple solution we have already tried is to clock the camera from the DAQ using a digital output configured to send out a timer pulse.  However, this is an ugly solution as it seems obvious to me that we should be able to do it using the IMAQ board and save ourselves an extra cable.  

I will note here that I have a CamLink break-out box so that I have direct access to the camera control lines.

I am also having trouble viewing the documentation files that you pointed me to.  When I open these on my computer I can see the headings on the left but not the content on the right which just says "Navigation to the webpage was canceled".  

Thanks for your help,

  --Yevgeniy

[kellam]

I've attached a pdf of the document instead of the .chm.  If you don't mind telling me, which OS are you using?  Our documentation team had never gotten a report of this issue before, and they'd like to investigate.

You should not have an issue doing continuous triggering from the RTSI line - just use the IMG_TRIG_ACTION_BUFFER option for the "action" input on imgSessionTriggerConfigure2

[ysirotin]

Thank you for the pdf.  This is basically the same documentation available online?

I am running Windows Server 2008 R2 x64.  

Here is a link to a previous thread I started that ended in the unsatisfying conclusion that I could not pulse trigger from an RTSI line onto a CC line using my board:

http://forums.ni.com/t5/High-Speed-Digitizers/Unable-to-add-IMAQ-devices-to-RTSI-in-MAX-Only-DAQmx-c...

In terms of imgSessionTriggerConfigure2, will I be able to trigger this way at 30Hz with guaranteed temporal fidelity?  For example. what is the delay between the trigger on an RTSI line and the start of frame acquisition?  Is this a fixed delay?  How do I actually route this RTSI trigger to the CC line?  I am sorry if these are simple questions, but I did not see this described in the documentation.

  --Yevgeniy

[kellam]

The pdf should match the online documentation - I had a doc developer run a utility that converts chm to pdf on it.  

When you use imgSessionTriggerConfigure2 to set up the triggering, that creates a route completely in hardware from the RTSI line to the trigger signal in the board.  When using the CC line to the camera, the board's trigger signal is routed internally to the internal pulse generator for the CC line (the one configured by the camera file).  Likewise, when you use NI-IMAQ to create a pulsetrain, the call just configures a hardware pulse generator that is driven from the selected source signal.  The effect of this is that you have a deterministic system with low jitter.

When you configure the buffer trigger with imgSessionTriggerConfigure2() and have the camera file set appropriately, the driver automatically routes the RTSI line to the trigger of the CC pulse generator, so you don't need to do anything additional.

One gotcha to be aware of - the clock of the board is different than the clock of the camera.  Therefore, if the camera can't receive a second trigger until the first image has been transferred (the camera docs should point this out if it is true), realize that the 1/30th of a second for the camera might be a little longer than the 1/30th of a second of the pulse train generator, and you could miss a frame.  The timing will be very close, since both the camera and the board probably use 20 or 30 ppm crystals, but you might need to 30Hz pulse to be 30.00001Hz or so.  If the camera's crystal is faster than the board's crystal, or if the camera can be retriggered immediately after exposure, this won't be an issue.

[ysirotin]

Great, so for my board I cannot route an RTSI signal to the CC line.  How do I proceed?  

Next question is when can I see the pulse (with an oscilloscope)?  Is it after I call imgPulseStart or does it only really start after acquisition starts?  

Finally, is there a way for me to open a session using imgSessionOpen, configure the pulse, close the session using imgClose and then open another session to actually start acquisition with the pre-configured pulse running?

  --Yevgeniy

[kellam]

I'm confused by your statement "Great, so for my board I cannot route an RTSI signal to the CC line".  Calling imgSessionConfigureTrigger2() does this - by setting the buffer trigger to be the RTSI line, when the board sees the trigger on the RTSI line, it generates the appropriate pulse on the CC line.  The attributes of the CC pulse are set in the camera file.

Since you should configure the generated pulse to be triggered by the RTSI line that the DAQ board is driving, you won't see the generated pulse until both you've called imgPulseStart() and the DAQ board generates its trigger.

IMAQ is completely session based, so you will not be able to have a board generate a pulse while the session is closed.

[ysirotin]

In the camera file, I have no option to route an RTSI line to a CC line.  I posted a link earlier to a thread where another engineer explained this to me (please feel free to correct me if I understood it wrong).  Please advise.

  --Yevgeniy

[kellam]

You don't need to route the RTSI line to the CC line.  The CC line is driven by a pulse generator, and configuring the buffer trigger sets up the RTSI line to be the trigger of the pulse generator.