Showing results for 
Search instead for 
Did you mean: 

Time Elapsed between encoder pulses

Go to solution

Hi Everyone,


I basically need to measure the time between the rising edges of the encoder B pulse. I am running an engine at 600rpm and acquire pressure data from it for each CAD(crank angle degree). My encoder gives me a pulse at every 0.5 CAD so I have 720 pulses each revolution. I use the Z pulse which is the exhaust top dead center pulse as the trigger to start data acquisition. I need to measure the time between each CAD pulse and write that time into a separate column of a spread sheet.


The reason I need to do this is because I record high speed videos of the combustion and the camera generates a precise time stamp for every image after it receives the trigger to start recording. I need to be able to find the the corresponding CAD and pressure value to each image and the only way to accurately do it is to compare the time.


I really hope someone can advise me on this as this mod is very important for me right now and I can't complete my thesis experiment till I do this and I'm facing a time crunch. Would be very grateful for any help and guidance.


I've also attached my pressure program VI. It does not have a while loop and needs to be run continuously and I know that's really bad but I've just been using what the guy before me did and haven't had time to modify it.




0 Kudos
Message 1 of 31

Hi reuven,


You will need a hardware counter to accurately measure the elapsed time between encoder pulses. Especially if your encoder is firing at 400kHz, you will not be able to measure those times in software. 


If you do not have access to a counter, you could potentially use the image capture trigger on your camera to trigger encoder acquisition, although I'm not sure the system you have described will work in this configuration. You would have to be able to measure the absolute encoder position at any point in time.




Duncan W.

0 Kudos
Message 2 of 31

Hi Duncan,


Yes you're right about the counter part. I have a 6040E DAQ card with 2 counters and also a 6601 timing card with 4 counters. I need to know how to be able to code it in labview. Also, if I'm not mistaken, I get 7200 pulses from the encoder per second. 


Would you happen to know what I could do to record the time between each pulse? 





0 Kudos
Message 3 of 31

Sweet! You should be able to measure the period of your encoder pulses using the counters you have available. I would recommend taking a look at the NI Example Finder for a basic template for measuring pulse period using a counter. Specifically, look for the example titled "Counter - Read Pulse Width and Frequency (Continuous)", then select the period configuration from the first case structure to see how a task would be configured for this purpose.


As an aside, it can be somewhat difficult to line up measurements using the timestamps provided by LabVIEW, so I would recommend making sure you trigger both the camera and encoder acquisition with the same trigger signal and then use offsets to line up samples, if you are not already planning to. I've seen people try to match samples by comparing absolute timestamps and it can be nearly impossible to get the software timing to match DAQ acquisition with external hardware, like your camera.


Also, you are correct about the pulses per second. I forgot to convert from minutes to seconds.


Duncan W.

Message 4 of 31

Thanks so much Duncan! I will definitely take a look at the VI you told me about and try to incorporate it into my program. Just a couple of queries:


1. Do you think I will be able to measure the time elapsed between each CAD pulse and write it in a fourth column in my spreadsheet basically 7200 times a second the way that I write the pressure value?


2. I'm not quite sure I followed your doubt about the time stamp. What I plan on doing is something like this. I generate the time elapsed for every CAD from the start. Now I use my injection signal to also trigger the camera and I know at what CAD I inject, for example 350deg. Then I can start counting the time from that point on wards and match it to the time of the image in the video. Am I making a mistake here?



3. Since you brought up the word timestamp, I was initially inclined the use the timestamp task in labview as that seemed very simple, but then I realized that the limiting factor as far as I know is the resolution which is in milliseconds whereas I need something in the range of a 100us. Do you think it's possible to obtain a higher resolution from the timestamp task?


4. This is rather important: I used one counter on my 6040E as the clock in my pressure acquisition VI that I attached in this thread. I used one counter from the 6601 card in a separate VI to control injection. If in the pressure VI I wanted to add this time stamp mod and use a counter from the 6601 card instead of the 6040E, would that work? So basically I'm asking can one VI in labview using counters form two different devices?


Thanks and sorry for asking so many questions but sometimes it's hard to find a straightforward answer online.


Appreciate the help.



0 Kudos
Message 5 of 31

1. Yes. See Producer/Consumer.


2. This is a good idea, in principle, but how are you planning on injecting at a specific CAD? If you send the camera trigger when your software recognizes a certain CAD, then your camera will be out of sync. Software registers events (ex. CAD at 350 deg) at an arbitrary point in time after they occur. This time difference isn't very large (probably milliseconds or less), but it is virtually random and makes it nearly impossible to have fine-tuned synchronization driven by software. If you are okay with this error, you can ignore it and use the method you have proposed. Otherwise, you will need to use a single trigger signal that activates all of your sensors (best method).


3. I don't know what you mean by a "timestamp task". You shouldn't need to perform the timing yourself though. This is why you have the counter. It will count the number of clock cycles between rising edges of your encoder and then return that value as a sample. You can then multiply this by the clock period and it will give you time in seconds. The counter's resolution is only limited by the clock period, which should be much smaller than 100us in most NI products with counters.


4. Absolutely. You can route channels from any device in your system into a single VI. Just specify references to both channels and you can use them however you like.


Duncan W.

Message 6 of 31
Accepted by topic author reuvengomes


Here's a slightly modified example that adds in the use of an "Arm Start" trigger.  Counter input tasks need to be triggered this way as the standard start trigger isn't supported.


Note that the very first value buffered by this task will measure the time from the trigger edge to the 1st encoder edge.  It is *NOT* a full period.  It can still be useful though if you plan to calculate timestamps for each encoder edge relative to the initial trigger signal.  (Note: newer X-series NI boards made an ill-considered decision where they don't give you this option.  The first buffered value comes at the 2nd encoder edge after the trigger.  It really messes up trying to sync with an AI task that samples on *every* encoder edge.)



-Kevin P


arm start period measurement.png

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).

Message 7 of 31

Hi Duncan,


Thanks so much for clarifying these things for me.


1. I'm not familiar with this but I will read it. Hopefully I should be able to understand.


2. I now understand what you mean and you're absolutely right. At this speed, milliseconds can make a big difference. Hopefully my method of injection should avoid this problem. Remember the injection VI I mentioned for which I'm using one counter off the 6601. Well, I'm using a retriggerable pulse generation VI wherein the counter outputs a low value and a high value exactly when I want it to. I use my encoder as the clock source and the output is based on ticks. So if I specify 700 ticks low(basically 350deg) and then N ticks high, the high triggers my injection and the camera. So technically, I'm not using software to compare the values. However another thing in my case is that I control the duration of the injection using a pulse generator based on time rather than the CAD. So basically, labview sends a signal to the pulse generator which sends the signal to the injector for the specified time. This same signal is also sent to the camera so not sure if some inaccuracies are introduced again. I will try to modify the program to the way you mentioned though just in case.


3. Sorry about the confusion. What I actually meant was the get date/time VI which gives you the time in milliseconds. As you said though, using the counter would be far more accurate and precise. 


4. Good to know! I've been wondering about this one for a while.


Hopefully I should be able to figure out how to incorporate this into my VI.


Thanks again.



0 Kudos
Message 8 of 31

Thanks a lot Kevin. Few questions though:


1. Do you think I could use this particular VI almost the way it is to generate my time readings for every encoder edge? And will it give me the time relative to the previous encoder edge?


2. Do you think I can combine this with the main pressure acquisition VI I attached earlier in this forum? As in, can I specify the same input terminal like the terminal where I receive my encoder pulses or the exhaust top dead center trigger signal in two different VIs within the same main VI?


3. Would you happen to have the VI of the picture you attached?


Again, thanks so much for advice and I apologize if some of my questions are very basic as I'm not that experienced with labview and am not very strong with certain concepts in data acquisition, especially in things related to channels and tasks. I've tried reading but for some reason I'm still not very familiar with it.


Anyway, please let me know if I can combine the 2 VIs together.



0 Kudos
Message 9 of 31

If you want to get an idea about time, you have two basic options.

  1. Get an FPGA card or some other instrument capable of measuring time in increments smaller than 1ms.
  2. At every Z-pulse from your encoder, take a timed measurement.  Subtract the previous reading to get the delta then divide by your 720 pulses per revolution to get an approximate timing difference between each pulse (Provided that the rotational speed is near constant).


You do not want to try doing this every pulse as the clock does not have the resolution you would desire.  Plus, it would add additional timing overhead that isn't necessary when writing the data.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 10 of 31