Real time data from GX5292

Tom P.
Fort Wayne, IN

Apr 23, 2010
1 Post

0 ✔  |  ✗ 0  

Re: Real time data from GX5292

I know the GX5292 really isn't capable of real time data streaming, but I'm in a situation where I need to find a way to make it stream data in real time as best as I can. I've come up with a method of commanding the GX5292 to do short bursts of data gathering, pause the card and read the data from the card. The trouble now, is how do I read the data file and convert it to a hex value that I can display? The DI output file appears to be in some compressed form that at first glance is not easy to reverse engineer. Is there a library that exists that would allow me to directly read from a GX5292 output file? Has no one else had the need for this?

Solution Available
Dale J.
La Verne, CA

Apr 27, 2010
21 Posts

1 ✔  |  ✗ 0  

Re: Real time data from GX5292

Hi Tom,
This is just a repeat of the information I posted to your Magic incident, but it will close the loop on this forum.  There are several functions in the DIO driver that facilitate reading and writing patterns to a file and to the hardware.  The functions are the same, the only difference is whether you pass in a file handle or an instrument handle.  Here is a simple example of how to read vectors from a DIO file, write the vectors to hardware, run the hardware, then read captured data from hardware:

Sample():
{
Short    nBanks, nBoardHandle, nDensity, nStatus, hFileHandle, nBoardType;
Long    alTriState[1], alResp[1], alStim[1], lSize;
String    sFileName;

    \\  First read from DIO file
    Strcpy(sFileName,".\\DioSample.di");
    
    DioFileOpen(sFileName,1,nBoardType,hFileHandle,nStatus);
    DioFileGetNumberOfSteps(hFileHandle,lSize,nStatus);

    \\  Use Malloc to dimension arrays - couldn't remember syntax
    Redim alStim[lSize];
    Redim alResp[lSize];
    Redim alTriState[lSize];
    
    DioReadDirectionMemory(hFileHandle,alTriState,0,lSize,nStatus);
    DioReadOutMemory(hFileHandle,alStim,0,lSize,nStatus);
    
    DioFileClose(hFileHandle,nStatus);
    
    \\ Initialize hardware
    DioSetupInitialization(0,1,7,nDensity,nBanks,nBoardHandle,nStatus);
    
    \\ Write vectors read from DIO file to hardware
    DioWriteDirectionMemory(hFileHandle,alTriState,0,lSize,nStatus);
    DioWriteOutMemory(hFileHandle,alStim,0,lSize,nStatus);
    
    \\ Write Halt command at last vector
    DioWriteCtrlCommand(nBoardHandle,lSize-1,8,0,0,0,0,nStatus);
    
    \\ Arm instrument and Trigger
    DioArm(nBoardHandle,nStatus);
    DioTrig(nBoardHandle,nStatus);
    
    \\ Wait for DIO to finish - could also poll status register
    Delay(200);
    
    \\ Make sure hardware is halted
    DioHalt(nBoardHandle,nStatus);
    
    \\ Read captured data from hardware
    DioReadInMemory(hFileHandle,alResp,0,lSize,nStatus);
}

Regards,
Dale

Eduardo O.
San Nicolas de los Garza, Nuevo Leon

Dec 14, 2021
1 Post

0 ✔  |  ✗ 0  

Re: Real time data from GX5292

Regarding a possible continuous capture of data.

Is it possible that by commanding a couple of GX5292 a capture can be continuous?

Say we have a pair of DAQ boards GX5292 and try something like:

1. InitializeBothDAQBoards();
2. While acquisition be required do:
    {
        StartAcqDAQBoard(1);
        TransferDataFromDAQBoard(1);
        StartAcqDAQBoard(2);
        TransferDataFromDAQBoard(2);
    }
3. Capture session concluded

Dale J.
La Verne, CA

Dec 14, 2021
21 Posts

0 ✔  |  ✗ 0  

Re: Real time data from GX5292

Hi Eduardo,
So, what you are trying to do is emulate real-time capture - correct?

As the post mentions, the instrument does not support this capability.  It is certainly possible to "ping-pong" back and forth between two instruments to try and emulate real-time capture, but the potential for missing data (non-contiguous recording) is pretty high.  It would be difficult to start the "pong" instrument immediately on the next cycle after the last record cycle of the "ping" instrument.  There are tricks you can employ to minimize this.  For example, if you are not recording on all 32 channels, you can use one dedicated channel from each instrument to trigger the alternate instrument.

You also have to be aware of the time it takes to off-load the captured data before needing to re-arm the instrument.  If the time to capture data takes less time than to read the captured patterns to your host PC, you will lose data.  For example, for the approach mentioned above, you must have sufficient time while capturing data on instrument #2, for instrument #1 to upload it's captured pattern to your PC, then have your software ARM instrument #1 so it is waiting for a trigger generated by instrument #2 at the conclusion of it's capture cycle.  And vice versa if you wat to continue this process over time.

If you are only interested in one "ping-pong" cycle, then much of the problem goes away.  You only need to worry about triggering instrument #2 at the conclusion of the capture on instrument #1.  The buffer fill and upload times becomes non-critical.

I also would suggest a slightly different structure than what you posted:
{
   StartAcqDAQBoard(1) (ARM and TRIGGER);
   ArmAcqDAQBoard(2)
   TriggerAcqDAQBoard(2) near the end of AcqDAQBoard(1) capture
   Wait for AcqDAQBoard(1) to complete it's capture
   TransferDataFromDAQBoard(1);
   Wait for AcqDAQBoard(2) to complete it's capture
   TransferDataFromDAQBoard(2);
}

I hope this explanation was helpful.

Regards,
Dale



Please Note
You need to have a M@GIC account to participate in the Forums.
Not yet registered on our website? Click here to register today!

All content, information and opinions presented on the Marvin Test Solutions User Forums are those of the authors of the posts and messages and not Marvin Test Solutions'. All attachments and files are downloaded at your own risk. [Read More]