Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

usb-6501 read counter value without resetting it

Solved!
Go to solution

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:

  1. 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.

  2. 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

0 Kudos
Message 1 of 5
(384 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 2 of 5
(351 Views)

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

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 3 of 5
(328 Views)

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?

0 Kudos
Message 4 of 5
(320 Views)
Solution
Accepted by topic author 1zero1

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.

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 5 of 5
(313 Views)