Measurement Studio for VC++

cancel
Showing results for 
Search instead for 
Did you mean: 

<Repost> [Failed] Integration of externally triggering a camera with generating a pulse train using DAQmx C API

I post my inquiry at this section again. It was originally posted at [Machine Vision] Section as linked below.

 

https://forums.ni.com/t5/Machine-Vision/Failed-Integration-of-externally-triggering-a-camera-with/td...

 

I would like to make an integrated programming code of hardware-triggering a camera with generating a pulse train.

 

If anyone could address this issue or make a comment on this then, I would appreciate a lot.

 

Attached below is the snippet for this work.

 

Below are the hardware and software specifications that I am using now for this work.
---------------------------------------------------------------------------------------------------------------------------
DAQ board: NI USB-6363 (BNC)

Camera: IDS camera (Model: U3-38J1XLE-M-GL_Rev_1_1)

Camera feature: 'ReadOutStart' only surpported as a 'TriggerSelector' parameter

Camera pin: An external trigger input is supported only. There is no any flash light output.

Pin connection: The camera external trigger 'input' port was directly connected with the PFI12 (i.e., Counter Output 0's terminal) on the DAQ board via BNC to Alligator clip cable.

Programming language: Visual Studio 2017, MFC (Microsoft Foundation Class)
---------------------------------------------------------------------------------------------------------------------------

 

In detail, I have already checked that an externally-triggered camera MFC code alone could capture image quite well by using a sample code of 'VC_DigPulseTrain_Cont' at DAQmx C API. According to the pulse frequency that I adjusted in the 'VC_DigPulseTrain_Cont', the frame rate of a real time image was reflected well. However, Those codes are not yet integrated but separated at present.

In the snippet that I attached, I had tried to integrate the two codes together for making one MFC code. Therefore, I tried to use a synchronization object of 'CEvent' in order not to monopolize a CPU from a worker thread of 'AcquisitionWorker()' so that I expected to do a pulse generation seamlessly. However, the integrated code is not working. That is, any pulse train does not be shown on an oscilloscope and thus the camera can not capture an image any more.

 

In Labview, in my memory, the synchronization between a camera capture and a DAQmx trigger signal is carried out by correctly deploying all the configurations via a 'Merge Errors.vi' right before a 'while' loop. So, I tried to imitate the advanced synchronization Labview examples between devices.

 

Below is a representative snippet inserted in the attached.

// Start capture worker thread
m_threadAcquisition = AfxBeginThread(AcquisitionWorker, this);
g_EvCam_capture_ready.PulseEvent();
DAQmxStartTask(FTTaskHandle);

Kindest regards and many thanks in advance,

Headalma

0 Kudos
Message 1 of 3
(587 Views)
Regarding the above, I would like to revise one point. I mentioned that when the 'TTL pulse generation code' and the 'externally-triggered camera code' are operating individually (named 'separate codes' situation), then the camera can capture an image. 
 
At that situation, frankly, I did not use 'Lock()' which belongs to 'CEvent' Synchronization Object.
 
In summary, even though the 'separate codes' are operating independently, when I insert the 'Lock()', then the TTL pulse signal was not generated any more and thus the camera did not capture any image.
 
Therefore, I conclude that the key to the solution might be depending on whether or not such a 'Lock()', which is one of synchronization object classes, would be utilized correctly.
 
Any comments on this would be much appreciated.
 
Below is a snippet in case the 'separate codes' are working well.
 
while (parent->m_threadAcquisitionRunning)
{
     // g_EvCam_capture_ready.Lock();
 
     bool acquired = false;
 
     try
     {
          // Get buffer from device's datastream. The buffer is automatically locked until it is queued again.
          const auto buffer = parent->m_dataStream->WaitForFinishedBuffer(5000);
 
          auto image = parent->m_imageConverter->Convert(peak::BufferTo<peak::ipl::Image>(buffer), 
                                   peak::ipl::PixelFormatName::Mono8);
 
          // Queue buffer so that it can be used again
          parent->m_dataStream->QueueBuffer(buffer);
 
          // Rotate by 90 degrees
          parent->m_imageTransformerIPL.RotateInPlace(image, peak::ipl::ImageTransformer::RotationAngle::Degree90Clockwise);
 
          // Display buffer in window
          parent->RenderBitmap(static_cast<unsigned char*>(image.Data()));
 
          acquired = true;
     }
 
...Continued...
0 Kudos
Message 2 of 3
(577 Views)

Regarding 'Lock()' and 'UnLock()' that I mentioned before, I have experienced to successfully synchronize a camera capture and a DAQmx Counter Output TTL signal.

 

Attached below is a snippet for that work.

 

At that time, I used a line scan CCD camera (Goodrich) with a frame grabber (NI PCIe-1433) and DAQ board (NI USB-6363).

 

Please compare two cases, that is, 'A snippet for synchronizing a camera via a NI frame grabber' and 'A snippet for synchronizing a IDS camera' as shown below.

 

In case of IDS camera code, except for a 'Lock()' function from 'CEvent', another Lock() of 'QueueBuffer()' is explicitly used.
Therefore, two kinds of Lock() functiontilities might cause bumping with each other, I think.

 

On the other hand, in case of a NI frame grabber code, it might be implicitly used, I think.

 

In addition, I found that a frame grabber is used for a very high speed image capture as well as a more precise triggering.

 

Therefore, the reason why the integrated code for IDS camera is not working might be two things - One is 'with or without a frame grabber', the other is 'Explicitly or implicitly using a Lock() related functionality'.

 

If anyone has a comment on it, I would really appreciate a lot.

--------------------------------------------------------------------------------------------------------------
A snippet for synchronizing a camera via a NI frame grabber:

while (DAQThreadFlag == true)

{

Event_DAQ.Lock();

 

QueryPerformanceFrequency(&DAQFrequency);

QueryPerformanceCounter(&DAQBeginTime);

 

// Wait at least for the first valid frame

errChk(imgGetAttribute(Sid, IMG_ATTR_LAST_VALID_FRAME, &currBufNum));

currBufNum++;

 

// Copy the last vaid buffer

errChk(imgSessionCopyBufferByNumber(Sid, currBufNum, CopyBuffer, IMG_OVERWRITE_GET_NEWEST, (uInt32*)&actualCopiedBuffer, NULL));

 

user_buff = (uInt16 *)CopyBuffer;


--------------------------------------------------------------------------------------------------------------
A snippet for synchronizing a IDS camera:

 

while (parent->m_threadAcquisitionRunning)

{

g_EvCam_capture_ready.Lock();

 

bool acquired = false;

 

try

{

// Get buffer from device's datastream. The buffer is automatically locked until it is queued again.

const auto buffer = parent->m_dataStream->WaitForFinishedBuffer(5000);

 

auto image = parent->m_imageConverter->Convert(peak::BufferTo<peak::ipl::Image>(buffer),

peak::ipl::PixelFormatName::Mono8);

 

// Queue buffer so that it can be used again

parent->m_dataStream->QueueBuffer(buffer);

 

Best regards,

Headalma

0 Kudos
Message 3 of 3
(529 Views)