Data Acquisition Idea Exchange

[#1]

Based on this question, I would like to add a new category of events to LabVIEW: Max-events.

This category could contain the following events:

-Hardware Added

-Hardware removed

-Configuration changed

    -Scales

    -Channels

    -Tasks

If you know other events, please post them.

[#2]

MAX 4.7 supports a new LabVIEW programmatic API called NI System Configuration that provides the ability to Find Hardware and get properties like the devices status to tell whether or not it is currently connected to the system.  Look in the LV Example Finder under Hardware Input and Output/System Configuration. 

However, it doesn't currently provide support for events.  If we were to support events how would you anticipate it being exposed?  What would you want it to look like?

[#3]

It does seem like this feature would best fit in as part of the System Configuration API.  I can't speak for the Original Poster, but to me the following would make the most sense:

[#4]

Yes that is good enough for me! I really like dynamic events.

[#5]

TCPlomp, this is a very interesting idea. Thanks for posting it.

There is already a Windows-specific way to get notifications about hardware added/removed (WM_DEVICECHANGE) but accessing it from LabVIEW pretty much requires writing a DLL in another programming language, it's not supported on LabVIEW RT, and it doesn't report devices that Windows doesn't know about (such as SCXI and SCCs). This idea would be easier to use and more portable (in some ways) than WM_DEVICECHANGE.

How would you use these events? Would a program using these events be concerned only about the current state of the system, or would it be important to identify what has changed?

If these were DAQmx events, passing the event structure a "DAQmx Device", "DAQmx Global Channel", "DAQmx Scale Name", or "DAQmx Task Name" type seems like an obvious way to identify the newly added/removed object. Since these types are convertible to strings, they should still be useful for identification purposes after the object has been removed. I'm sure there are other approaches I haven't thought of.

If these were NI System Configuration events, there are many ways the newly added/removed object could be identified, and here are just a few that come to mind. Passing a resource refnum to the event structure would probably be pretty convenient to use, assuming that you could still query properties from a resource that has been removed. I would expect the G code in the event structure to be responsible for closing the refnum. Passing the Expert/Resource/Alias properties to the event structure could work too. Or maybe a list of properties to pass to the event structure could be specified at event registration time?

Reporting a newly added device to the event structure as a DAQmx Device or a nisyscfg "User Alias" introduces the possibility for a race condition: what if someone else (especially another "Hardware Added" observer) renames the device as soon as it is added? Besides that, it might also be useful to have a "Hardware Renamed" event.

Brad

[#6]

Another downside to WM_DEVICECHANGE which has come up recently is that the event fires before the hardware is necessarily available in DAQmx (see here).