08-31-2017 04:44 AM
Hello community,
I'm a bit confused, that I'm apparently not be able to get informations (properties) of local virtual channels of a DAQmx task.
My use-case is, that I would like to set my DAQmx device into save state on application shutdown, which means to set analog out tasks to 0V and digital out tasks to FALSE.
What I tried do to was, to iterate through a list of my tasks and get the channel types of the associated channels to determine if I have to do a analog or digital write operation.
Does anybody have a idea, or do I have to memory manua, which task does which operation?
Thanks in advance
Holger
08-31-2017 06:13 AM
08-31-2017 07:08 AM
Hi GerdW,
of course I know the properties of my tasks. But why do I have to remember them in my application, when the driver also have them and I can ask them?
The question can be more general, why channel properties do not work on local virtual channels?
In the meantime I talked to NI support and they told me, my solution for which I needed my shown vi, is not a good one. So I have to change my architecture and would not need it anymore.
Thank you GerdW for your answer. But some behavior of DAQmx is very strange.
Regards
Holger
08-31-2017 07:15 AM
One of my earlier LabVIEW/DAQ challenges was dealing with a PXI box that had Digital Outputs connected to various pieces of Lab equipment -- when the PXI was turned on, its DO lines were (as I recall) allowed to drift to +5v, which made the Lab equipment, particularly audio, start to hum loudly. [I fixed it by creating a PXI Start-up routine that set all of the DO lines to 0v].
So I looked at my own code, and tried to see if, knowing nothing about the rest of the program and what was connected to what, I could "deduce" (from DAQmx Property Nodes) which DAQ devices I was using. I think that, if this is possible at all (and I don't think it is), it will be very difficult, and thus prone to error. For example, one of my routines uses "internally-created Tasks" (i.e. I don't pre-define the Task in MAX or in the Project) for a USB-6009, a multi-function AI/AO/DI/DO unit. Looking at my own code, it became clear that unless I programmed it into the code, there was no "query" to tell what Channels I was using, whether they were Input or Output, Analog or Digital.
Thus I agree with GerdW -- at the time you start designing the code, you know what the devices and channels are, and can easily write both the initialization code and the (sorry for this made-up word) finalization code at the same time (so you won't forget to do it later).
Bob Schor