event handling with 6533

[Steely]

Hi, 
I am using a PCI-6533 with VB6 to capture a fixed amount of data asynchronously using DI channel "0" and Ack/Trigger (DIG_Block_PG_config).  The data rate is <9600 baud.
To eliminate polling, I tried invoking the General Event handling.  I've had teasing success in this mode, but sometimes crash my PC.
I have tried learning from the VB examples, and have scoured the "Traditional" manual.  I do not think I am interpreting/using the event example correctly, since I want/expect the event to fire every fixed amount of time, yet I've gotten this far success-wise.  I am not sure how much resetting I need to do in order to simply wait for the next event to fire.

I initially config DIG_Grp, Block_PG, and _Trigger, align the buffer, setup the General DAQ Event Control, start DIG_Block_In within a Sub I call once to kick the process off, then wait for the Event to fire.  My intention is to restart the process in the event handler. (OK? or loop in the calling sub instead?)

When the event fires, I capture my data, but sometime the app hangs. If I kill the process, it takes windows with it, but leaves a blue screen with an NI error msg (at work) pointing to clues to some addresses, a reference to some obscure IRQ error, and the nidaq32.dll

I originally was resetting/setting all of the _Config statements and event properties in the event handler, but later thought this unnecessary.  I do a Block_Clear, Set Event enabled to False, process my data, then re-enable the event and follow with DIG_Block_In.  Or can I simply re-do the DIG_Block_In statement after data handling in the code for handling the event?  I need this to run continuously.  Can I restart DIG_Block_In in the event handling code, or is this "circular"?   I am using error handling, but receive no errors before the app hangs.
In the meantime, I will revert to polling.  This seems ironic, as I am causing issues that I was trying to prevent.

Apologies from a noob.  Am writing after work, so I may not respond for 24 hrs.
Thanks.
steely

[Ryan_V[DE]]

Steely,

In order to clear things up, could you post your configuration and event handling code? Thanks!

Regards,

[Steely]

Hey Ryan,

Will send in 2 parts - don't know the trick to meeting the 5K character limit for this forum

Thanks,
Dan

code below:


Private Sub Form_Load()

    'Initiate Controller Telemetry reads from DIO card
    Call Get_DIO_buffer

End Sub



Public Sub Get_DIO_buffer()

    '  Variables are Declared at the procedure level and are Public
   

    iDevice% = 1
    iGroup% = 1
    iPort% = 0
    iGroupSize% = 2
    iPgConfig% = 1      '1 for pattern generation and input/request edge
    iPgTB% = 1          'time base used with pattern generation, 1=1us, 2 =10us, 3 =100us
    iReqInt% = 833      'time base interval used w pttrn generation, multiplier for the time base
    iStartTrigON% = 1   '1 = start trigger on hardware
    iStartPol% = 1      '1 = active Low (Tlm start bit leading edge)
    iStopTrig% = 0      '0 = None
    iStopPol% = 0       '0 = not used if StopTrig is 0
    ulCount& = 256
    ulBufferSize& = 200
    iResource% = 11
    ulRemaining& = 1

' init piBuffer
For X = 1 To 260            'debug
    piBuffer(X) = 0         'debug
Next                        'debug


    iStatus% = DIG_Grp_Config(iDevice%, iGroup%, iGroupSize%, iPort%, iDir%)
    iRetVal% = NIDAQErrorHandler(iStatus%, "DIG_Grp_Config", iIgnoreWarning%)

    iStatus% = DIG_Block_PG_Config(iDevice%, iGroup%, iPgConfig%, iReqSource%, iPgTB%, iReqInt%, iExtGate%)
    iRetVal% = NIDAQErrorHandler(iStatus%, "DIG_Block_PG_Config", iIgnoreWarning%)

    iStatus% = DIG_Trigger_Config(iDevice%, iGroup%, iStartTrigON%, iStartPol%, iStopTrig%, iStopPol%, ulPtsAfterStopTrig&, ulPattern&, ulPatternMask&)
    iRetVal% = NIDAQErrorHandler(iStatus%, "DIG_Trigger_Config", iIgnoreWarning%)

    iStatus% = Align_DMA_Buffer(iDevice%, iResource%, piBuffer%(1), ulCount&, ulBufferSize&, ulAlignIndex&)
    iRetVal% = NIDAQErrorHandler(iStatus%, "Align_DMA_Buffer", iIgnoreWarning%)


    ' setup the GeneralDAQEvent control
    GeneralDAQEvent1.Board = iDevice%
    GeneralDAQEvent1.DAQEvent = 1
    GeneralDAQEvent1.ChanStr = "DI0"
    GeneralDAQEvent1.DAQTrigVal0 = ulCount& / 10
    GeneralDAQEvent1.Enabled = True
    GeneralDAQEvent1.Refresh


    iStatus% = DIG_Block_In(iDevice%, iGroup%, piBuffer%(1), ulCount&)
    iRetVal% = NIDAQErrorHandler(iStatus%, "DIG_Block_In", iIgnoreWarning%)


End Sub

[Steely]

Ryan,

part 2 of 2 with error handler

tnx,
Dan

Private Sub GeneralDAQEvent1_Fire(DoneFlag As Integer, Scans As Long)
   
    Call CleanUp                     'reset event
    Call Process_Telemetry    'parse and test
    Call Write_Data_log        'record
   
    'Get ready to GO again
    GeneralDAQEvent1.Board = iDevice%
    GeneralDAQEvent1.DAQEvent = 1
    GeneralDAQEvent1.ChanStr = "DI0"
    GeneralDAQEvent1.DAQTrigVal0 = ulCount& / 10
    GeneralDAQEvent1.Enabled = True
    GeneralDAQEvent1.Refresh

'     Start the pattern generation input of 256 "items" upon the digital start trigger.
    iStatus% = DIG_Block_In(iDevice%, iGroup%, piBuffer%(1), ulCount&)
    iRetVal% = NIDAQErrorHandler(iStatus%, "DIG_Block_In", iIgnoreWarning%)


End Sub



Sub CleanUp()

'   Turn off DAQ Events
    GeneralDAQEvent1.Enabled = False        'clear the Event
    GeneralDAQEvent1.Refresh

'   Don't check errors on purpose.
    iStatus% = DIG_Block_Clear(iDevice%, iGroup%)   'replaces DAQ_Clear

End Sub

[Ryan_V[DE]]

Steely,

Your configuration code looks fine, but I'm a little confused as to what you are doing in the event handler code. I would check the DoneFlag and based on its status, either continue the acquisition, or start a new one. Only in the latter case do you need to refresh the event and call DIG_Block_In(). Have you tried this? Is this when the computer locks up? How exactly does it crash? Do you get a blue screen? What happens if you run in the VB6 development mode. Does it still crash?

Thanks!

[Steely]

Ryan,

Thanks for looking at this - I do apreciate it.

As for the event handler, no, I am not checking the Doneflag and I should - perhaps the process is ongoing when the Event fires.
I will test it in the handler.
Once the acquisition starts, I only have to capture 255 bits that are sent at 1200 baud as a blob/burp, and then nothing for a fixed amount of seconds - this duty cycle is at a fixed rate so I expected that when I got to the handler, I had the whole blob.  In the handler, and working under this assumption that the acquisition was complete - I Refresh by calling Cleanup, I process and the data I need, and relaunch DIG_block_in.

SOunds like based on what you think is going on  that I am jumping the gun and that could be it.

I have been running everything in the IDE (development environment) and that is when I saw occasional lockups.  It is when I call Windows Task Manager (a manula Ctl-Alt_Del) and kill t he process (VB) that I bring the system down. I do get a blue screen at that point.  Since it was not stable in the IDE, I dd not try to run a compiled executable.

I now think (but not straightly - yawn) that I may have also had some contention between timers and other bus (GPIB) calls that I am/was making asynchronously whihc contributed to this condition, but the blue screen mentions the nidaq32.dll.  Unfortunately, schedules what they are, I am forced right now to use what I (my polling version) have as an application to do some product testing.  My code looks great to everyone else.  I say not straightly because we are in crunch mode (some long hours)- but I hope to come up for air one of these days and debug/fix (a luxury).  Believe me t hat out of professional curiosity and pride, I want to make this as cool as poss and learn something more about it's event.

I will ping you and let you know if I get  to check this out - I am not done with it yet.  This is a cool card.

Thanks Ryan,
Dan

[Steely]

Ryan,
sorry about the smilies in the code - some artifact of html or something - comes up only when I posted it above.

Please let me know if I didn't answer your questions.

Regards,
Dan

[Ryan_V[DE]]

Dan,

You don't always add smiley comments in your code? I know I do... Anyway, just post to this forum again if you are ever able to resume debugging the code.

Thanks,  

[Steely]

Ryan

FYI - It looks like tomorrow is the day I get to debug my error handling.
I did have one short chance a few days ago to implement it, and I found I was looking at the Done Flag.
I may be firing the event too soon, so I will investigate checking to see if the acquisition is complete, or maybe change in the event property to fire when acq is complete.

I also read that the low level DAQ Clear may already have been sent by the Block_Check, in addition to the one I call in Sub Cleanup.  I think too that I may have nested things too much - the event handler spawning another acq only to fire the acq event from within the handler.

I will let you know how I make out - I will be using a flow chart provided in Fig 3-24 of the Traditional DAQ manual as a guide. 

Also, I found the error I received earlier and provide it below - I earlier incorrectly referred to file type mentioned as a .dll.

Stop: 0x000000D1 (oxBACDADA0, 0x00000002, 0x00000000, 0xBBCEBA28)
Driver_irql_not_less_or_equal
Address BBCEBA28 Base @ BBCE1000, DATESTAMP
40f71b9d - NIDAQ32K.SYS
Beginning dump of physical memory

Regards,
Dan