Errors when counters read zero

[GDthomas]

I have to read a signal from circuit to determine the RPM of three motors. At times these motors will be at zero RPM so there will be no pulses being output. I'm using three counters on the cDAQ chassis and a NI 9401 digital IO module. The problem I'm having is when the RPM is zero and there are no pulses coming into the 9401 the DAQmx read.vi times out and throws an error. (See the vi and error below) As long as there is a signal present all is good but I will need it to function when there is no signal input. How can I get around this?

Thanks

[CoastalMaineBird]

You are asking it to STOP the loop, in case of ANY error.

Consider extracting the error CODE and testing for error #-200284.

If that is the error, then do NOT stop the loop and simply try again.

If it's some other error, you probably DO want to stop.

If NO error, you do NOT want to stop.

[Kevin_Price · Accepted solution]

An *expected* error is not the end of the world.  Immediately after the DAQmx Read function, check for the specific timeout error code that you know you'll get sometimes under normal conditions.  Then handle it instead of just passing it along.  Here you might just assign a 0 value to RPM and then erase the error.

A second refinement is to give some more careful thought to the timeout value you feed to DAQmx Read.  It should be short enough to keep the loop responsive, but long enough to account for "Samples per Loop" at the lowest RPM worth measuring.

A third refinement could be that when you *do* timeout, you make extra effort to try to get *some* data out of the task.  After erasing the error, you could query for # available samples and then read *that* amount.   It's unclear whether this partial data is of any particular use in your specific app though.

-Kevin P

[GDthomas]

Steve & Kevin,

Thanks for the ideas. I think the idea of extracting the error code is the simplest way to go.  I like the idea of substituting in a 0 at that point also. It didn't make sense to me until I thought about it, the vi is waiting for data, no pulses no data and it times out.

[CoastalMaineBird]

It didn't make sense to me until I thought about it,

That's the way it goes sometimes...

[StrugglingwithLabView]

Hi, I have the same problem with the RPM sensor stopping to read when the RPMs are 0, but I am really new at Labview and Im not able to fully understand your solution and how to implement it, I am using a code that has been provided to me so I am not really familiar with it. Here I attach the screenshots I took about it, please if you could help me I would  really appreciate it.

Thanks for your time,

Marcos

[GerdW]

Hi Struggling,

---

@StrugglingwithLabView wrote:

I am really new at Labview and Im not able to fully understand your solution and how to implement it,

---

When you are that new to LabVIEW you REALLY should take those "Training resources" offered in the header of the LabVIEW board.

Once you learned the basics you should implement the suggested solution: check the error number and stop only when the error number is not 200284…

[Kevin_Price]

Sorry to say, but you're really gonna need some time digging in and learning some basics.  Counters are kinda unique in the DAQ realm in that they don't measure or deliver *signal levels* (like AI, AO, DI, and DO) but instead they deal in counts and time (though time is really just derived from counts and a known frequency).

The second image you attached tells me that the code you were given is no good.  It betrays a very fundamental misunderstanding of counter task data and/or signal processing functions.  The task data is a single count.  The processing function wants to act on a good-sized set of signal level data.  They are *fundamentally* not compatible, so you're going to need to start over on the counter stuff.

My recommendation: spend some time with the shipping examples for counter tasks.  Open an output and an input task so you can run both at once.  Their front panels will let you easily choose a PFI pin for your counter output example and then choose the same PFI pin for your counter input example.  Spend time observing and experimenting with different kinds of counter tasks, particularly edge counting and frequency measurement.  For now, stick with the 1-counter method for frequency measurement b/c it'll be easier to understand.

I don't think I can usefully help with details such as those discussed earlier in the thread until you've spent some time to get more famliiar with counters.  Then you'll be equipped to follow and understand better.

-Kevin P

[StrugglingwithLabView]

Hey, it's me once again. I have managed to disable the error, but now I want the program to read 0 RPM when it doesn't have any input signal on the sensor, can this be done with a case structure or something similar?

I am attaching the excel file where it can be seen that as soon as the motor stops it does not read any RPM at all and just leaves an empty space in the Excel column for RPM, and I want the program to write 0 RPM in those blank spaces

Thanks for your help and quick responses I really appreciate it

[Kevin_Price]

I can't really improve on what I already said back in msg #3.

Background: here's the problem with me.  I tend to be pretty choosy about which threads I spend significant thought and time on.  And it's pretty rarely the ones with "new user" questions.  I'm just a volunteer contributor here and put most of my efforts into things that help "keep me sharp".  Moderately complex stuff, interesting tidbits, or topics that happen to fall in a niche where I have fairly unique experience.

I saw the multiple DAQ Assistants, the (dreaded) dynamic data wires, and the Express VI all in a common loop, and I'm just probably not ready to get heavily involved yet.  Sorry, it's just kinda like this: I'm generally up for leading a hike up to a modest summit once you get to the trail head, but am probably not going to come pick you up and walk you half way across the country to bring you there.

Fortunately, others are more generous with their time and expertise, and I'm glad they are!

-Kevin P