Measuring rpm - counter freezes

[ceties]

Hello,

I ammeasuring rpm of the camshaft using the IRC sensor and NI PCI 6120, NIDAQ 8.7.1.I use the one counter method (Method 1) and all seems fine as long as I use 720 pulses perrevolution (ppr). When I switch to 3600ppr the counter sort of freezes when thecamshaft is at around 2500rpm. The AvailableSamples start to show 0 and thus Idon’t read anything. The weirdest thing is that no error appears. It doesn’tseem to be possible to have the buffer full since I set it to generous size (1000xppr=3.6M) andI read it quite fast. Not mentioning that with that size atthat rpm it would take 24sec to overflow the buffer if I didn’t read it at all.

Has anybodyencountered such a problem? I also attach screenshots from my app.

Thanks alot for any ideas

[Mark_SAI]

Hello,

Does it still do it if you change the 'Low Frequency with 1 counter' to 'High Frequency with 2 counters'?:

[ceties]

Hi and thanks macaba. I need as many rpm readings per revolution as I have pulses. For that reason I use the one counter method. The reason why I chose the method is also described here

[Stefo]

Hi ceties,

can you maybe post more complete code here ? We can do some brainstorming on it.

regards,

Stefo

[ceties]

Well, it won't be that easy since it is actually four queued state machines but I will try to dig out the important part.

[Stefo]

Hi ceties,

Were you able to take out more complete code which shows how you configure the counter ? 

Or, in case you already solved the problem, you can maybe share knowledge what you found out 

I'm ready to help 

Martin

[ceties]

Sorry I worked on another project and then it was time for vacation.

The problem persists. I realized that I don't check the status of the DAQmx task so I eventually recived the error: -200141 Data was overwritten before it could be read by the system.

I did some testing with attached VI:

The speed of reading of the data from the buffer doesn’t seem to influence it

The CPU load doesn’t seem to play role. It is neglectable.

With attached VI it takes 30s at 2000rpm (pulse train = 120kHz) before the error appears.

It is influenced by the size of the buffer I set. But in the same time the buffer is still nearly empty = I read it fast enough. If I set the buffer size 10x3600 the error appears very soon(2sec at 120kHz). If I set it to 1000x3600 it appears later (above mentioned 30sec).

What is going on here? I am becoming a bit desperate.

Thanks for any advice

Message Edited by ceties on 09-10-2009 09:22 AM

[Stefo]

Hi Ceties,

Hope the vacation was nice 

I checked your code, and it seems to be fine. I have some posibilities to brainstorm:

1. If the error is not seen all the time after the same period of time, it could be possible that you have some glitches in your encoder signal, which could cause very fast overflow. It is difficult to filter glitches with your device, as it doesn't support digital input filtering. You still can filter them with external filter.
2. Secod think which came trough my mind is some problem with driver. I haven't found anything similar, but inspite of it you could try different DAQmx versions.
3. Double check you have DMA configured as data transfer mechanism (Counter Input -> General Properties -> More -> Advanced -> Data Transfer and Memory -> Data transfer mechanism of DAQmx Channel property node)

From own experience, I would suspect first 2 the most.

Martin

[Stefo]

Hey Ceties,

One more suggestion. You can try to "filter" the glitches with 2nd counter. Configure the 2nd counter to retriggerable pulse generation (I haven't verified your board supports it) with specified times, and use output of this counter as input for the 1st counter which will measure frequency. Thus you should be able to say for sure, whether you have glitches or not. If not, try different versions of DAQmx.

Hhope it helps.

Martin

[ceties]

Thank you for your help Stefo. I really appreciate it.  

1.The error is always seen after the same period of time. If I use smaller buffer it appears sooner, with bigger buffer later. If I use 720ppr it doesn't appear (although I think to remember that it appeared with really high frequencies which I cannot test now). If I use 3600ppr it comes sooner or later. Altogether the frequency seems to be an issue.

If there were glitches I would also see senseless reading of the frequency/rpm(by other words there would be fake impulses that would cause false reading) but that works perfect.

2. I might test that

3. I checked it-DMA

I am becoming desperate 🙂 I might need vacation again 🙂

Message Edited by ceties on 09-10-2009 11:20 AM