DAQmxReadAnalogF64 possible to be non-blocking?

[tbihn]

The device we are using is the NI USB-9162. We are using a non-standard PC, so are trying to avoid anything that will require a card, since the expansion possibilities are limited to a couple low profile PCI slots. (Traditional PCI cards will not work).

The idea of using an active x control is interesting, but we have had a lot of issues re-registering dlls when people have tried to build them in the past.  Are you referring to building a DLL or something else? I'm using class modules and creating objects off of them, but have not had the chance to experiment with building active x objects in VB6. Could someone upload a small sample of a control using a timeout event to set a flag?

Is it possible to have an active X contol run its timer independently of the main program execution (asynchronously) in VB6?

Thanks for the advice. I'm going to run out and redefine my class module to setup the task when initialized and see how it affects the performance.

Tom

[cborn]

Tom,

My demo program (some 5 messages back in this thread) demonstrates an ActiveX control that fires off an event to its application, and that happens on a timer when it detects that it is running on simulated NI hardware. I've added digital IO and moved from using the typelib to Declare statements since then, for reasons I gave in another thread in this forum, but the idea should be clear enough from that code. It is an ActiveX OCX, not a DLL.

Timers in ActiveX controls run asynchonously in VB6, in just the same way as timers in the parent application do.

If you have distribution issues with OCX modules then you may be better off just keeping everything in your main .EXE
My controls get used by others in the organization, at other sites and in applications I have no control over, so having my specifics encapsulated in the ActiveX controls is particularly useful here.

David

[Tom_W_[DE]]

Hi tbhin-

The USB-9162 is just a carrier for the actual DAQ device you are using.  Can you please let me know which module (i.e. cRIO-92xx) is being used in conjunction with the carrier?  BTW, David- thanks for your excellent input and insight.

[tbihn]

The actual models are: 9421 and 9472, sorry about that. Thanks for the great inputs. I modified the routine to keep the tasks open instead of closing them and reseting the device each time and the read times are down well under a millisecond.

I'll have to take a look at the OCXs, I developed an application using one timer for each sensor, each sensor of course is one digital input. I have the timer interval set to 1 and the response time is acceptable for my application. (By the way, I found that I needed to put a "Do Events" in each timer. The result without was that the first two or three timers loaded got all the CPU attention and the others were pretty much ignored. By using Do Events, they all shared pretty much equally.

The class modules all work well together, but the thing runs into trouble when I try to incorporate it with other mainline code. I noticed that the timer events are sometimes getting hit, other times ignored when the main application is doing nothing. Maybe the OCX approach will help here. I'll start a new thread with that one.

[cborn]

Tom,

Using an OCX won't help with your timing issues, its benefits lie elsewhere.

For timing, you should treat your timer event code much like you would an interrupt, and try to avoid doing too much in the handler code, but rather pass as much as possible back to the mainline to process.

I would suggest that rather than use a separate 1mS timer for each input, with the overheads attached to that, you could use a single timer, read in the entire port, and check for changes there, passing the result back to the mainline to handle.

David

[Merlin-3]

I had the same problem using Delphi, because the value 1 for "DAQmx_Val_SynchronousEventCallbacks" I got from the .h header is not accepted by the callback registering function and using 0, the default option, the callback function does not return the stack pointer correctly (crashing the application) if I declare the callback function as "cdecl".

What is the numeric value of the DAQmx_Val_SynchronousEventCallbacks option?

The manuals and the .h file set the callback function as "cdecl". But using Delphi this does not work anymore as worked in the reliable and good Legacy NiDaq dlls I have used for more than 6 years ! Sigh... I am getting really upset with this new mx drivers ...

If I cannot change the thread calling the callback event function and the "cdecl" does not work as well... what to do? To forget 6 years of software development using NI cards?

Well, I used "stdcall" for the callback function and it worked. But I do not know why...

Lavio

[Erik_J]

Hi Merlin-3,

If you are experiencing error -50251, please consult the following KnowledgeBase, it has great information on using DAQmx with Delphi.

KnowledgeBase: Can I Make NI-DAQmx Calls From Borland Delphi?

I hope this helps!

Regards,
Erik