Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Externally triggered repetitive pattern generation with a DAQCard 6533

Hello all.....

I am still having problems with externally triggering pattern generation using the DAQCard 6533. The problem I am faced with is as follows. I have externally generated triggers of 100uS duration, repeating every 30mS. I want to trigger a pattern generation output from each one of these triggers. I pass these external triggers into the ACK (StartTrig) pin on my DAQCard 6533. I hope to then trigger my pattern output after each external trigger and wait for the next one to repeat the pattern again. I repeat this for some 4000 external triggers. The pattern output consists of 200 10uS pulses, with a period of 100uS. I achieve this by setting the group up with a timebase of 1uS and a request interval of 10. I then fill a 16 bit array of 1000 elements with the desired output (1,0,0,0,0....repeating) to generate my 10uS pulse at the desired rate on line 0 of the configured port. I set the count number in my output using DIG_Block_Out to 2000 so as to output all the array data. Consequently the pattern output should take 20mS. I then loop this for the desired number of external triggers. This works fine. The problem occurs at the end of the pattern output before the next external trigger. Some 1 to 2mS after completion of the pattern output the output from the pattern generation group goes high and remains high until the next trigger. Ideally I want this to remain low!! I have tried increasing the elements in my output array, filling them with zeros and increasing the count accordingly. This has the affect of reducing the time the output is high before the next external trigger but does not remove it all together. Am I doing something fundamentally wrong? Is there a way to ensure that the lines that show the pattern output default to zero? It is necessary for me to do some processing in the 10mS or so following the pattern output, before the next trigger pulse.


I am not faced with the same problem if I fill the first five elements of my output array with zero's, but this has the affect of shifting my first pulse in the pattern output to some 100uS after the falling edge of the external trigger. I ideally want to trigger from the falling edge of the external signal and have my first 10uS pulse immediately. HELP.....


I have attached a timing diagram that may help to explain my problem.


Kind regards


Tired and Alone
0 Kudos
Message 1 of 7
(4,287 Views)
What functions are you calling between triggers? I'm guessing you are probably calling DIG_Block_Clear, though that should not set the line to high unless you have teh DPULL line connected to the +5V connector. Other than that, the line should stay in the same state that pattern ended in.

If you are calling DIG_Block_Clear between patterns, add a delay in your code before calling it. This way, you will be able to tell if it is the Block_Clear function that is setting the line high.

Brian
0 Kudos
Message 2 of 7
(4,287 Views)
Hi Brian

Thanks for the comments. I actually call DIG_Block_Check, which if I am correct calls DIG_Block_Clear when all the data has been transferred. I am also using an in-house connector assembly that gives me access to the 68pins of the PCMCIA card. Is it possible interference could be causing my problems? The position at which the problematic line on my pattern generation port goes high is a little too consistent I think for this though.

A snippet of the code is as follows (there are other functions concerning other ports in change detection mode and general output but I have removed them and I am still faced with the same problem....)

// pattern buffer is a 1000 element 16 bit array, filled with
// 1,0,0,0,0.... repeating
// pat
terncount is 2000 (assuming 8bit tranfers)

for(int loop=0; loop<1000; loop++)
{

//******************************************
//Code to generate the output pattern
//from the selected group and buffer
//******************************************

iStatus = DIG_Block_Out(deviceNumber,patterngroup,
Pattern_Buffer,patterncount);

iRetVal = NIDAQErrorHandler(iStatus,"DIG_Block_Out",iIgnoreWarning);


while ((ulRemaining != 0) && (iStatus == 0)) {
iStatus = DIG_Block_Check(deviceNumber,patterngroup,&ulRemaining);
iRetVal = NIDAQYield(iYieldON);
}

if(PeekMessage(&message1,NULL,0,0,PM_REMOVE))
{
if(message1.message==WM_QUIT)
{
PostQuitMessage(0);
return(0);
}
TranslateMessage(&message1);
DispatchMessage(&message1);
}


iRetVal = NIDAQErrorHandler(iStatus,"DIG_Block_Check",iIgnoreWarning);

//need to reset ulRemaining
ulRemaining = 1;

}

Any ideas?

Jamie
0 Kudos
Message 3 of 7
(4,287 Views)
Jamie

I am a little confused on how you are setting up the output operation. From your description above, it seems like you are doing retriggerable pattern generation, though that is not supported by the 6533. Can you explain to me how you are setting it up so that it outputs the pattern for every trigger?

Thanks, Brian
0 Kudos
Message 4 of 7
(4,287 Views)
Brian

Once again, thanks for the reply.

The words 'Not Supported' sound ominous!

Basically I set the DAQCard 6533 prior to entering the pattern generation loop. I configure group1, port 0 for 8 bit output using :

DIG_GRP_CONFIG(deviceNumber,1,1,0,1);

I then configure this group for pattern generation using:

DIG_BLOCK_PG_CONFIG(devicenumber,1,1,0,1,10,0);

I then configure the triggering for this group using:

DIG_TRIGGER_CONFIG(deviceNumber,1,1,1,0,0,0,0,0);

I perform error checking along the way.

I then go into the loop I showed in an earlier correspondance, where I output the pattern some 4000 times, each pattern output triggered from an externally generated pulse passed into StartTrig (ACK) pin on t
he card.

I am trying to do something here that can't be done? (please tell me it is possible to do it !!) Will I need to re-configure the group for each trigger, for instance putting the above initialisation code into the loop? Or is there another way of doing it? Or do I need a different card. I have had success doing it this way when I start my pattern with a zero. I get the same pattern generated from multiple triggers. My intial problem occurs when I start my pattern with a 1.

I hope the card is suitable as it was originally purchased after conferring with a local sales representative and some time has been spent developing the project since then. I would hate to have wasted all that time.

Thanks for your help.

Kind Regards

Jamie
0 Kudos
Message 5 of 7
(4,287 Views)
Jamie

I see what you are doing now. Retriggerable pattern generation is not supported as a hardware feature, though the way you are implementing it, it works, though you must time your triggers correctly so that DIG_Block_Out has already been called before the next trigger. (It seems that you have already figured this out.)

As to the problem you are seeing, when DIG_Block_Out is called, it latches the first pattern on the DIO lines before the trigger arrives. This is expected behavior. Therefore, if the first pattern is a one, it will set DIOA0 high as soon as DIG_Block_Out is called.

The only workaround for this that I can think of is to add a zero to the beginning of the pattern so you have, 0,1,0,0,0,0,1,0,0,0,0....


Brian

I'm trying to see if I can figure out a workaround to this problem.
0 Kudos
Message 6 of 7
(4,287 Views)
Brian

Thanks for your help again. I was getting a little concerned yesterday that all the progress I have made in developing this project was going to be irrelevant, as the hardware wasn't appropriate. But your comments have illuminated the darkness. Thanks.

I have found a way around the problem where I trigger from the rising edge of the external trigger and fill the first 5 elements of my output pattern with 0's. The external trigger is 100uS long. This seems to work fine as long as the guy providing me with the trigger ensures his signal is the specified 100uS duration. It is essential that the pattern I generate starts with a 1 exactly 100uS after the initiation of the external trigger. Of course
this approach is not ideal if the external trigger is not accurate. But for now it seems to do the job.

Please let me know if you figure out a workaround for the problem I face triggering from the falling edge.

Kind Regards

Jamie
0 Kudos
Message 7 of 7
(4,287 Views)