Has anyone tried VB6 SearchEx WriteAsynch as an Interupt Work-Around?

[SpiritualMadMan]

Joel,             I am a fledgling VB6 Programmer who has been writing VISA code in VB6 for a few years. Nothing fancy. Just trying run a few things to make my life as a Cal Tech easier. 

            Anyway, a guy at work, who gets paid to program, or rather debug someone else’s code, had an interesting circumstance that ran the Processor Load up to around 30% (He had reduced it from over 50% by excising excessive Do Events...)

             Same code that was running at 3% on another system with slightly less answer back delays on the Physical GPIB Bus.             He learned it was only happening when asking for a read back of the Status Byte, when additional Power Supplies were added to the local VXI (I think) Bus.             And, apparently caused by the additional delays required for the VXI to gather the Status.                          I found your article about Synch and Asynch in Labview and thought you might have an answer for my question.              While VB6 doesn’t have an actual (inside VB6) way of handling Software or Hardware Interrupts…             I was wondering if NI-VISA would allow a programmer to use Asynch reads and writes then follow with a Win32 API Call to SleepEx? Allowing the host Processor to go off and do other things until NI-VISA got back whatever it was waiting on?              Just curious… If anyone had tried it or if it so obvious to a casual observer that no one's even tried it?  I am thinking that the Thread ID for the SleepEx wouldn’t match the NI-VISA Read/write Call? And, therefore an infinite delay (in SleepEx) would never return. The only way it could work is if everything within VB6 had the same Thread ID?             All my VISA programming, so far, is *very* serial in structure… I also do DAO and ADO programming. Until now I’ve left the API calls alone. So, you can understand the gaps in my understanding?             Thanks!             Mike Sr. 

[Justin_E]

Hey Mike,

There is a token in the C:\ProgramData\National Instruments\NIvisa\visaconf.ini file (or C:\Documents and Settings\All Users\Application Data\National Instruments\NIvisa\visaconf.ini on WinXP) that tells the system when to do asynchronous transfers and when to do synchronous transfers. The token is 'MinAsyncCount' under [VISA-CONFIG], and should = 512 by default. If the requested count is less than MinAsyncCount, then the transfer is completed synchronously. If it's greater than or equal, then it's completed asynchronously, which is what it sounds like you want to happen.

So if you want to enable poll mode, you can either do transfers of size 512 bytes or greater or you can change the token's value. Then, you can call viWaitOnEvent w/ timeout > 0, and VISA should do the appropriate polling (rechecking every 1ms, which translates to ~9ms Windows time) . This type of polling should ensure very little CPU usage as a percent of total system CPU usage.

Also, note that by default viReadAsync/viWriteAsync will create a new thread, so you can't use the SleepEx function. Hope this helps!

[SpiritualMadMan]

Thanks Justin...

That was what I was "afraid" of. (New Thread being created.

Mike Sr.