>>While I'm certainly not an NI-488.2 expert, I believe there are both >>synchronous and asynchronous functions in NI-488.2.
>Not in the 488.2 spec but in the C library and/or the driver and at the >VISA call level. The problem is that there is NO NI-488.2 for OS X >(at the moment). So I am developing sth-488.2 based on the incomplete >488.2 DDK toolkit that NI provides. The trick is how to move that >asynchronous call in the library (when I get it implemented) into the >synchronous nature of a LabVIEW call into a library. There are two options for this. One is using occurrences. You basically call into the external code passing it the occurrence refnum and invoke the asynchronous C API function in there and return back to LabVIEW. This C API signals back at completion either through an OS event or callback and at that time you trigger the occurrence in your C code. To do this triggering you simply call the Occur(LVRefNum occurrence) function. This function is not prototyped in extcode.h but is exported by the labview.lib link library in all versions of LabVIEW. The LabVIEW diagram waits on the occurrence with a timeout and on return of the Wait on Occurrence you call either the external code to retrieve the data (no timeout) or cancel the operation (timeout occurred). This is basically the same the VISA Read node for instance does internally although it does this in the LabVIEW code and not on a diagram. I have not been able to find the necessary LabVIEW API calls to actually place all this into the external code. The big problem is the implementation of the Wait on Occurrence in a way that LabVIEW knows that it should do other things until the occurrence is triggered. It may also be so that this is theoretically doable in CINs only as CLNs do not have the necessary additional calls such as CINAbort etc to allow such an external code to be interrupted from waiting when the user wants to shutdown the application. The other solution is to actually stay in the C code and pass control back to the OS through OS API functions while you wait on the event to occur. I do believe this is what DAQmx does. This blocks the LabVIEW thread invoking the CLN but allows LabVIEW and other applications to continue to make use of the CPU. A cosmetic issue with this is at least under Windows, that in the task scheduler LabVIEW seems to use up 100% CPU power while waiting in this way but everything on the system is as responsive as otherwise. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
