11-26-2024 02:12 PM - edited 11-26-2024 03:01 PM
I am new to NI and have tried to find this information but couldn't locate any relevant documentation.
We have a working solution with the USB-6501 and a C# app. The C# app starts a Task, a CountEdgesChannel and a CounterSingleChannelReader, which can read the incremental count. This works great.
My question is:
Is the count kept in the DAQ device or in the app memory? If it's in the app memory, this would make my next question irrelevant.
When the app closes, it loses the count. Is there a way to read the current count from the DAQ device without resetting it? The only way we can open a channel is by setting the initialCount, which overrides any existing value. Starting a channel without passing the initialCount would be perfect but that does not seem possible. We figured out that, since we could pass the initial count, if we could retrieve that info, then we would be able to achieve our goal.
Here's the code we use to create the channel and reader:
_task = new Task("PulseCounterTask");
_channel = _task.CIChannels.CreateCountEdgesChannel(_channelName, "PulseCounterChanel", CICountEdgesActiveEdge.Falling, 0, CICountEdgesCountDirection.Up);
_reader = new CounterSingleChannelReader(_task.Stream);
Thank you
Solved! Go to Solution.
11-26-2024 03:56 PM
NI DAQ devices are session based, which means, the DAQmx stores all necessary data related to configuration, measurements and more. The life of the DAQmx task applies to its data.
I would assume it is part of the DAQmx Task, when you clear the task, you lose all data associated with the task.
11-27-2024 06:59 AM
If you need to "start from where you left off" through an app shutdown and restart, it'll be up to you as a programmer to manage that in the app. A common thing to do is write out the count to a file before app shutdown, then read it back in during app initialization.
As a note: the raw counting happens in hardware on the DAQ device. In a simple non-buffered counting task, the DAQmx driver retrieves the instantaneous value for your app when you make a read() function call. If you were in a buffered counting mode, DAQmx would work in the background to transfer arrays of count values into DAQmx task memory space, then your read() call would bring it into your app memory where you the programmer can do things with it.
But as you've discovered, each time you start up the app and start up the counting task, some initial count value will be set before you have any opportunity to try to read whatever count value might have been sitting there in the register. In truth, I don't know whether there would be a relevant value there anyway. As far as I know, the count value *could* get reset to 0 as part of closing out the task. But I can't check that because there's no way to access the count once the task has been closed and before a new one sets a new initial value.
-Kevin P
11-27-2024 07:59 AM
Thank you for your clear answer guys.
Unfortunately, keeping the count externally when the programs close does not work in our situation. The real count continues to increase while the app is closed. Reading back our value from our external source would give us the wrong number.
I see two solutions :
1) Tracking the elapsed time between the falling edge events. In our situation, they would/should be constant. With this info, we should be able to calculate how many events we have missed. That being said, I have not read if it's even possible to have the elapsed time between events.
2) Create another app, which would live as a service, with shared memory between this service and our app. The main difference, and the gain here, is that services cannot be closed by user interaction. The app would read the count value from the service. This would keep track of the count 99% of the time. A reboot would create a flaw in the count. But by mixing solution 2) with solution 1) we could achieve a close to reality count.
Do you guys see another solution?
11-27-2024 08:33 AM
If all that you need is a reliable counter unaffected by computer software, you can get an industrial counter and read off it using some protocol it supports.