Counter Problem at low sampling rate

[sha33]

What I am trying to do is to count the input from the camera and generate the number of pulses depending on the delay and interval. At the rate of 33ms the program works perfectly but if the sampling rate is 150ms it generates 2 pulses at a time. Is there a better solution to my problem ? Am I doing anything wrong ? Is it a problem with the loop timing or acquisition timing? I have attached the program. What puzzles me is that it doesnt work if the rate is lower! Please HELP.

Thanks 

p.s. I am very new to LabView so please excuse my ignorance.

[Speedy_Badger]

Hello sha33,

I have looked over your code and your previous post and I have a few additional questions that will hopefully get us closer to a solution.

What device are you using for this application?
When you refer to 33ms and 150ms rates, are you talking about the signal from the camera or the signal from the pulse generation?
Is the signal coming from the camera TTL?
Have you tried your device with a simple example (Help » Find Examples) to see what the lowest frequency you can accurately measure is?

Let me know more about your application and the above questions and we'll try to get you back on track!

Regards,

Message Edited by Speedy Badger on 02-08-2008 09:17 AM

[falkpl]

It was hard to follow your code but one issue I have found in the past that could be your problem is that with low frequency (Relative to the sampling frequency) NI daq has a property called duplicate count prevention.  When this is on it can make samples where no counts come in to be removed from the count buffer.  You can turn this off with a property node (you will have to convert from ExpressDaq though).  Some more detail on what your terminology means will help diagnos the problem.

Paul

[sha33]

Hey guys,

Sorry it took me while. It was a carzy Friday. To answer your question.

What device are you using for this application?

- The Counter board is a NI 6601. And the camera is CoolSnap. The camera sends pulses to the counter board and the counter board counts and  generates the pulses.

 
When you refer to 33ms and 150ms rates, are you talking about the signal from the camera or the signal from the pulse generation?

- I have 2 cameras. The first one that sends pulses (TTL) at the rate of 33ms (33ms is the length of one cycle). Although my program looks complicated, all it does is that it reads the count and according to the delay and interval it generates the pulse. For example we want to generate the pulse after the 150th count  and then after every 300 count.  I am not saying what I did is the right one maybe there is a better solution but the bottom line is that all I want to do is to generate pulse after certain number of pulses and then after every interval.


Is the signal coming from the camera TTL?

- It is TTL.

Have you tried your device with a simple example (Help » Find Examples) to see what the lowest frequency you can accurately measure is?

- No I have not. Which example I should use?

I am very new to LabView and I am not sure why it would generate the 2nd pulse. It works fine at 33ms (the first camera) but the other camera sends out at 150ms. I see the 2nd pulse being generated right after the first one.  Please help!

Thank you all!

[Speedy_Badger]

Hello sha33,

Thank you for getting back to me with more information. After looking through your code once more, I believe I have found the issue. Since this application is timed entirely in software, it is based on how quickly your operating system can run the program, and thus cycle through loop iterations. Since you have no Timing VIs in the program, this loop is running as fast as possible. Now, in the 33 ms case, you are getting a TTL edge a lot faster, so the DAQ assistant is updating its count faster as well. Lets say hypothetically that your loop is iterating at 60 ms. This means that every time you run through the loop your DAQ assistant will read the updated count value, and since you are counting every 33 ms, your count value will have updated.

Now let's look at your 150 ms TTL signal. This is significantly longer than the 33 ms signal in the previous case. Lets say hypothetically your loop is running on average at 60 ms again. This time, your edge will come in and the counter will increment, generating a pulse with the second DAQ assistant accordingly. Now your loop will run through again 60 ms later but your next edge on the 150 ms signal is still around 80-90 ms away. This means that your DAQ assistant will return the same count value as the last iteration, and once again a pulse will be generated.

Obviously the numbers I used for the loop iteration timing are hypothetical and entirely dependent on the operating system and its resources (i.e. it will run slower with an MP3 or Movie playing in the background). My suggestion would be to use a timing VI such as Wait Until Next ms Multiple to clock your loops more consistently. The goal would be to make sure that your loop is repeating faster than your counter is updating. Alternatively, you could account for the possibility of no counter input in your overall application to prevent a false positive.

Let me know if I can clarify any of the above information, or if you have any additional questions related to this issue.

Regards,

[sha33]

OK. Thank you very much! I tried with a times loop. It works if the pulse is exactly 150 ms but the pulse coming in and going out are not synchronized. You mentioned something about. So I assume the timing has to depend on the pulse coming in .

"Alternatively, you could account for the possibility of no counter input in your overall application to prevent a false positive."

How do I achieve that?

Thanks again.

[sha33]

Sorry about the scattered thoughts. Here is what I did. I put in a timed loop as you suggested but the problem is that the pulse generated and edge count are not synchronous. I put in the delay of 150 ms so whats happening is that at the time the loop checks for the edge count, the pulse has already been generated.  What I really need is  - count dependent executon of the loop. I dont know how to do it. I tried making the edgecount boolean but  really couldnt get anywhere. If you have any suggestion, I would really appreciate.

Thanks

[Speedy_Badger]

Hello sha33,

I am not sure I understand exactly what you are describing. The 150 ms delay controls the overall iteration of the loop. That being said, the code that is executed within the loop is happening according to the flow you created. For instance, the pulse will be generated as soon as the count requirement is met, which could occur earlier than 150 ms. Thus, you will have a "dead time" before the next iteration. My initial suggestion of the timing VI was to account for the fact that you could be reading your count register before a change occurred, as was the case for the slower signal. Since you are using software timing, there will always be a delay that is not deterministic.

"I put in the delay of 150 ms so what’s happening is that at the time the loop checks for the edge count, the pulse has already been generated."

Can you elaborate more about this statement?

Was there a synchronized behavior in your original application?

Also, could you include a screenshot of the changes you made to your application?

I have included two very useful links below that might be useful now and with your future applications. I would recommend either the 3 or 6 hour LabVIEW Introduction Course listed on the page from the second link.

Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications
How Can I Learn LabVIEW?

Regards,

Message Edited by Speedy Badger on 02-14-2008 07:39 AM

[sha33]

Hey Chris:

I think you answered your question. I know there will be a delay to execute thru the loop and then generate the signals but I can tolerate that. But the problem seem to have solved by doing this.

See Attachment.

I am trying to trigger the loop when there is a pulse. So, for an example - the counter register has dynamic value 1,2,3 ,4.... . My approach was to execute the loop whenever there is a change of state on the counter. Previously the problem was that the loopwasnt executing according to the counter but the delay timer for the loop.

_|``````|__|``````|__|``````|__|``````|__|``````|__|``````|__|``````|__|``````|__|``````|__|``````|_ - 150 ms cycly - i cant control the flow of the input signal.

    |``````|_________|``````|_________|``````|_________|``````|_________- 150 ms delay loop execution and pulse generation
start          

OR

 |``````|_________|``````|_________|``````|_________|``````|_________- 150 ms delay loop execution and pulse generation
start  

So you see when ever I execute the program, I may start at the any of the above.  It comes down to when i hit the button .

I want ...

_|``````|__|``````|__|``````|__|` `````|__|``````|__| - Input
  |``````|______|``````|_________|``````|_________|``````|_ - Output (assume all the signal are of same length - this is just to show the synchronousness)

So i want output  to be generated at the time the signal is high on the input.

I am sorry but I cannot make it any clearer than this. But if you take a look at what I have done and give me feedback, I would really appreciate it.