LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RPM as a Function of Crank Angle (optical encoder - counters)

Counter tasks do not seem to like start triggers, is there an easy way for me to circumvent that dislike?

Thanks!

~milq
0 Kudos
Message 11 of 28
(3,248 Views)
Milqman,

Thanks for contacting National Instruments.  I would consider routing your errors a bit differently since any error that could occur on your second task's start will not be seen.  If you are measuring frequency and you increase your period it will continue to count, but most of our counters can count very high being 32-bit, which is the case for you, so you should be good in that regard. 

Regards,
Kenn North
Principal Product Manager - Search, Digital Analytics
http://ni.com/search
0 Kudos
Message 12 of 28
(3,246 Views)
Yes, I noted that as a P.S. in my last picture.  I didn't realize that I hadn't finished it in my picture.

What I want is synch'd individual revolutions of data to be passed to the host computer.  How frequently I get them is somewhat unimportant.  I would like it if I could produce repeatable data (by triggering at the same spot on the encoder each time).


0 Kudos
Message 13 of 28
(3,243 Views)

A few comments Re: most recent screenshot:

1.  Re: Start Triggers for counter tasks.

The regular Start Trigger can only be used for counter output (pulse generation) tasks.  For input (measurement) tasks, you would need to use an "Arm Start" trigger.  Trouble is, you can only configure it using the DAQmx Trigger property node, like the ones where you set retriggerable = True.   However, as far as I know, the "Arm Start" trigger (used for counter input tasks) can't be set as retriggerable.  I don't think retriggering a finite acq could easily get you what you want anyway though.  It doesn't leave you enough read time between finishing one acq and getting the next trigger.   In sum, use the DAQmx Trigger property node to configure an "Arm Start" trigger with the appropriate inputs (signal source, active edge, etc.)

2. Since you have a unidirectional motion and you're only performing X1 quadrature decode anyway, I REALLY think you should get rid of the position measurement task entirely.  Use your Freq task alone.  The cumulative index of your freq samples IS the position.  See earlier postings for more details...

3. I always do Period measurement rather than Freq.  They seem conceptually equivalent, but I'm not certain that all the config calls are truly similar.  In any event, you may need to change your DAQmx Timing call to use the "Implicit (Counter)" version rather than the "Sample Clock" version.  I know that's what I'd need to do for a period measurement.

4. Not sure why you'd prefer a finite acq to a continuous acq.  Early in the thread you talked about a graph looking "dumpy."  Was that the main reason?  If so, there are probably other ways to improve it.

-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 14 of 28
(3,235 Views)
So, what I want to end up with is a graph whose X-axis is angle (not actually true, but it will be a known function of angle that is not relevant to this conversation) and the Y-axis is speed (represented in RPM).  I want the left side of the graph to always be 0 degrees, and the right side of the graph to always be 360 degrees.  I want to update this graph with new information on a fairly slow but arbitrarily determined interval.  I want to be able to stop this application, and restart it with the same settings and be able to compare graphs (repeatability).

I will get started on the array mashing, that you so much for your help, and I apologize for being a little stubborn, I have this portion basically defined so it feels wrong to abandon it for a drastically different approach that deals with array mashing (which compared to matlab, labview is not very good at doing).

Back to the salt mine,
~milq
0 Kudos
Message 15 of 28
(3,230 Views)
Hey guys, I got distracted, but when I came back to this, I finished it up:


It works pretty much as desired.  I still have some buffer issues (but I think a lot of that is related to the fact that I am using an RT system and there is latency going back and forth when it is starting up).  I just wanted to say thank you.

~milq

The final problem that I encountered was the fact that I still had the encoder wired to the block for position.  That of course was not going to give me frequency of the A signal.  Once I got that cleared up, and ironed out the other kinks (in the subVIs you see there) everything is working like a charm.  Thanks again you guys, for your help.
0 Kudos
Message 16 of 28
(3,193 Views)

Hi Milqman

 

I read some of your post regarding your project. I know it has been a while since 2006. However, I would like to get some ideas from it.

 

I would like to acquire a data of pressure and also angle from engine. Pressure sensor and angle encoder are used.

 

However, how to decide or how to design the VI so that the DAQmx will only require the data of pressure during the first trigger of angle encoder. Instead of that, how to know that the the angle encoder already 720 degree so that I would say it is already one cycle of pressure that I would like to acquire.

 

I would be appreciated if you or others could assist me.  

 

Thanks.

 

-Fird- 

0 Kudos
Message 17 of 28
(2,526 Views)

Hi Fird,

        I'm not sure that I completely understand your application- but from what it sounds like, I think you may be able to create separate DAQmx tasks for your angle and pressure and configure your triggers separately.   It sounds like you just need a start trigger for your pressure measurement.  Could you please explain in more detail what you mean when you say, "

Instead of that, how to know that the the angle encoder already 720 degree so that I would say it is already one cycle of pressure that I would like to acquire." ?  Are you just wanting to trigger your acquisition when your encoder reaches 720? 

 

Thanks in advance for the additional info!

 

 

0 Kudos
Message 18 of 28
(2,496 Views)

Hi Anita.

 

Thanks for your response. Basically, I would like to acquire data of pressure using pressure sensor. At first, I would like to use angle encoder to determine the angle of the crank. However, as I'm using USB 6009, I wont be able to do Angular Encoder.

 (Just to let you know, I'm having two USB 6009).

 

By taking some ideas from the attachment VI, I then design a similar VI to acquire the pressure signal while the angle encoder use as External Clock also as Trigger. Please refer to the picture below. 

 

1.jpg 

From an encoder, we will be having 3 main signal from A,B, and Z. For this VI, I'm using A as source of clock while Z as source of a trigger.  

 

I'm not sure whether this way is correct or not.

 

I will test it tomorrow (as now at France is late night - 3am).

 

If you have any enquiries that could help me to try out this VI, please let me know.

 

Thanks.

 

-Fird- 

0 Kudos
Message 19 of 28
(2,491 Views)
Hello Fird. I won't help you much with your issue but I will give you little warning. USB 6009 is more a children toy than a serious measurement device for measurements on engines. The card is multiplexed (it has only one A/D). If you are trying to do some fast meausurement and comparison of the pressures you will run into problems since the time when the card is switching to a new channel will play a role. If you have low RPM or lazy pressure changes you should be fine.
Message Edited by ceties on 06-26-2009 03:59 AM
LV 2011, Win7
0 Kudos
Message 20 of 28
(2,480 Views)