LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Time Elapsed between encoder pulses

Solved!
Go to solution

What you said makes sense but one thing is getting new hardware is out of the question right now with my adviser.

 

The second method you described would make sense for a process where the time between pulses is constant. However, since this encoder is connected to an engine crankshaft, it revolves faster for certain parts of the revolution than others. If that is the reason you said approximate timing then you're right. Also, the other part you mentioned is also not true in my case. As in the rotational speed is not near constant. I fluctuates with +/- 3 rpm.

 

That's the reason I wanted to do it for every pulse of the encoder and check the time either with respect to the trigger signal(Z) or relative to the previous pulse. Do you think it's not possible?

0 Kudos
Message 11 of 31
(1,700 Views)

Minions,

 

I wouldn't necessarily recommend either of these solutions for this application. Here's why:

 

1. FPGA - You don't need an FPGA in order to time these signals. You are correct that FPGA's allow you to measure, process, and log faster, but it would almost certainly be overkill in this instance. Not to mention LabVIEW Real-Time and LabVIEW FPGA have a substantial learning curve. You can time pulse period quite easily using the counters found on many cDAQ devices. These counters have a resolution equivalent to the period of their referenced timebase and many of NI's devices include timebases with frequencies in the MHz range (the 6601 has a 20 MHz source clock onboard). FPGA's are typically recommended for applications that need deterministic behavior (really really fast time-critical acquisition, tight control, etc.).

 

2. This is actually bad practice because of the inaccuracy of software timing that I discussed earlier in this thread. If you have some other timing resource in mind that can supply absolute timestamps when measurements are acquired, I would love to hear about it! However, it is typically not recommended to use software timing in any application that requires accuracy. This is because the data is actually buffered twice before reaching software: once on the DAQ device, and once in the PC buffer in the device driver. As you might imagine, these transitions are not instantaneous. For example, when your acquisition reaches the PC buffer, LabVIEW may not be allowed by the OS to use the processor for half a millisecond because it is running other programs. In this time, let's say 10 new samples arrive in the buffer. Now, when LabVIEW reads these samples, it timestamps all of them with the current timestamp. Not only are these timestamps now all the same for different samples, but they may not even be correct for any of the samples! Clearly, there was at least a half-millisecond delay caused by the OS (which we can't control). In conclusion, you are correct that this method for timing will provide a result, but it will be heavily quantized by the limitations of software. For fast timing applications, we want to get as close to hardware as possible.

 

To speak to your last point, actually, the clock on the 6601 should be able to keep up with the speeds in this thread. I'm not sure what you mean by "additional timing overhead", but overhead is typically first resolved by using a producer/consumer architecture and jettisoning the functions that do not have a deadline (usually logging) to the consumer loop. If, at that point, your application still cannot keep up with your acquisition, it may be time to consider an FPGA or Real-Time OS.

 

Anyway, I don't mean to shoot you down and I apologize if this comes off as such, but I also want to make sure that the information available on the forums is as accurate and helpful as possible.

 

Duncan W.

0 Kudos
Message 12 of 31
(1,697 Views)

1.  The code I posted comes from a few quick mods I did to a shipping example.  Most of the hardware config stuff (before the reading loop) should transfer pretty directly into your app.

   Period measurements *do* in fact measure time intervals so you are getting delta times between encoder edges.  (Thus, a cumulative sum of all periods can give you hardware-precise timestamps for every encoder edge.)

   You'll need to change the part inside the reading loop.  Right now it just reads chunks of data and the new stuff overwrites the old stuff.  You'll still need to log it, graph it, accumulate it, run some math, whatever.

 

2.  Yes you can combine them but it'll take a little more than just copy/paste.  Yes, you can specify an input terminal (such as the TDC trigger or the encoder pulses) to be used by multiple tasks at the same time.   That's the basis for getting hw-sync between tasks.

 

3. The "picture" is a special kind known as a LabVIEW "snippet".  Save the png file and drag it into an empty block diagram and it'll turn back into real, runnable, editable LabVIEW code!

 

 

-Kevin P

 

 

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).
0 Kudos
Message 13 of 31
(1,683 Views)

1. Great. So basically I do get values between edges. I need to log the data I get so what would you recommend to write the file? Can I just go ahead and use the write express VI the way I am right now? I write it to .lvm files.

 

2. Ok. Will work on that.

 

3. Awesome! Had no idea.

 

4. I was going through a really old thread of yours advising someone else on engine data acquisition. In that you modified one VI. Should I use that VI as a template? Any chance you happen to know a simple pressure acquisition VI that I can use for my task? 

 

All I need to do is acquire the voltages of pressure readings the way I do right now using the Z signal as the trigger and write that to a file and add this time stamp modification and use the encoder signals as the clock against which I write my pressure values. Some of the other stuff in my program are not needed.

 

Also, I need to acquire a set data like 20 revolutions for example. How should I do that? Should I use finite acquisition or continuous? And should the timing VI be sample clock or implicit? I'm not very sure about these concepts so I thought it's best to ask an expert on this as reading about it hasn't cleared my doubts. I've attached the VI and here is the link to the page I was talking about. 

http://forums.ni.com/t5/LabVIEW/quot-Start-Trigger-quot-for-encoder-measurement-AND-AI/td-p/484073/p...

 

Again, I really really appreciate your help and guidance. I just need somehow to create this program as soon as possible and begin experimentation.

0 Kudos
Message 14 of 31
(1,672 Views)

1. Can't really advise on any of the Express vi's, there are very few I've ever used.  I wouldn't generally put the file writing in the same loop as my data acq, but that kind of parallelism might be a bigger step than you're ready to tackle now so keep reading...

 

4. That old thread you mentioned and code you posted would probably *not* be the cleanest starting point for you.  It may help a little as a point of reference, but it appears to be aimed at solving a problem that's a little too distinct from yours.  

 

My advice: careful choice of hardware config and data reading method will help make sync relatively straightforward.  

A. So, the PFI terminal for the encoder pulses should be wired (LabVIEW block diagram "wired", not screwdriver on terminal block "wired") to both the AI task as the sample clock source *AND* to the counter period task as the period input terminal.  

B. The PFI terminal for the Z-index should be LV-wired to the both the AI task as a Start Trigger *AND* to the counter period task as the "Arm Start" trigger source.

C. DAQmx Timing should be "Implicit" for the counter task.  This basically means that the timing depends on the signal being measured.  DAQmx Timing should remain the standard "Sample Clock" type for the AI task.   I'm not sure how to explain this difference simply, it has just always kind of clicked for me.

D. If you'll always collect a reasonable size finite amount of data, it'll be simpler to use Finite Acquisition.  LV-wire both tasks to collect the same # samples.  I would easily include as many as 1000 revs at 720 samples/rev "reasonable."

E. When calling DAQmx Read, be sure to read the same # samples from both tasks so that the data you display and write shows the correlation correctly.

F. Watch out for timeout errors on DAQmx Read for longer runs.  The default timeout is 10 sec, but you can choose whatever you want.  Note that long timeouts will lock up execution on the DAQmx Read call while waiting.   It isn't normally a good practice, but it might be your simplest first step to just use a long timeout.

 

 

-Kevin P

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).
0 Kudos
Message 15 of 31
(1,657 Views)

Wow! Thanks for that. I think I have a much better idea now of what to do. I still have a few doubts though. I created a separate thread to clarify on my doubts on combining the 2 VI's. Here's the link: https://forums.ni.com/t5/LabVIEW/Help-Needed-with-Engine-Pressure-Data-Acquisition/td-p/3652118

 

Could you please give me your inputs on questions 1, 2 and 3?

 

On your advice:

 

A and B: Perfect! I've always wanted to know if this was possible and had tried in another VI once but had some errors relating to certain resources already being used and were probably unrelated but since I don't know this stuff too well, assumed it was because I was try use the same terminal for two tasks.

 

C: This makes things clearer.

 

😧 I think this is kinda related to my questions 1 & 3 and something that I need most help with. How do I sync up the 2 operations? The current pressure VI is a finite acquisition type and as such does not use a while loop. Can I keep that the same and use this counter period VI below that? Will it match? Or do they both need to use while loops and be synced somehow? I apologize if these questions seem stupid.

 

E: Will do.

 

F: I read that a timeout of -1 could be entered so that it waits endlessly. Is this alright?

 

Also you already sorta gave me your opinion on question 2. In my current finite acquisition pressure VI, the measurement VI seems to work fine and I get all my values. There is no loop in this VI however so I'm not sure how the write process is taking place i.e. whether it keeps writing every values received each time and holds up the process or whether it just reads the data after it has been acquired from the buffer and thus does not affect acquisition rates.

 

Again, thanks for all the time you've spent clarifying my doubts. I'd really appreciate more of your inputs. You could also reply within the new thread itself.

 

Best,

 

Reuven. 

0 Kudos
Message 16 of 31
(1,651 Views)

Attached is code I couldn't test but should be at least very close to correct for the hardware config.

 

Because both acq tasks are set for finite sampling and both read all samples at once after task completion, there is no loop and thus no particular worries about when and how to write to file.

 

All the data handling (scaling, calculations, graphing, writing to file, etc.) is left for you to finish up, but the DAQmx code should be pretty sound.  The most important subtlety was making sure the two tasks synced to the same instance of TDC pulse if the program starts while the engine is already running at 600 RPM.  An intermediate triggering counter was used for this purpose.

 

Consequently, I chose to specify all tasks to run from the same MIO board.  Otherwise, we'd need to get into either the topic of the RTSI timing cable which you probably don't have, or a bunch of careful screwdriver wiring to route signals in parallel to the 2 boards.

 

See attached.

 

 

-Kevin P

 

 

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 17 of 31
(1,643 Views)

Note: In the posted code, all the channels and terminals reference Dev3. I thought I based this on one of your prior postings, but in another thread there are indications that it should be either Dev1 or Dev2.   Your choice whether to modify all the channel and terminal names in the code I posted or whether to go into MAX and rename the 6040E to be Dev3.

 

 

-Kevin P

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).
0 Kudos
Message 18 of 31
(1,634 Views)

Goodness! I can't believe all the trouble you took! Thank you so very much! I really hope this works for me now and I don't have to bother you with these questions again.

 

Thanks goodness you saw my other thread and my attempt to combine the VIs. I thought that since they were both receiving the same signals, they wouldn't be any issues with respect to triggering and stuff.

 

What you assumed was perfect. I do run the engine first and then start the acquisition.

 

Regarding the devices, my 6040E is Dev1 but used to be Dev3. And the 6601 is Dev2. I'm sorry for the confusion. Even after saving the VI however, the configuration on the front panel seems to stay the same. 

 

So just to verify, do I just use both counters from the 6040E? Since you said you configured all the task to run off the MIO board. And for the loop in the period measurement part, is it OK for the wait time to be 100ms? 

 

Again, thanks so much. You have no idea how much I appreciate this.

 

Reuven.

 

 

0 Kudos
Message 19 of 31
(1,629 Views)

Yes, use both counters from the 6040E.  

 

The loop delay is pretty arbitrary.  Short enough to seem responsive to a user clicking stop, long enough to not waste cpu with polling.  It's a way to wait for the finite tasks to finish while still allowing a user to stop early.  Super long timeouts on Daqmx calls aren't interruptible

 

 

-Kevin P

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).
0 Kudos
Message 20 of 31
(1,611 Views)