Read Pulse Width Based on a shaft's position

[Matt_AM]

Hello Fancy Folk,

I am trying to read a PWM signal (Pulse Width measurement) based on a shaft's position.  I have a 4096 count/rev encoder on the shaft and am sampling my analog signals based on said encoder's A signal going high.  I would also like to sample my PW on the rising edge of A.  The analog signal goes to a PCI 6229 analog in channel while the encoder and PW signal go to a PCI 6602.  My issue is, I can't seem to get the PW to have a sample clock with the Encoder's A line as my trigger.  I was reading around and it looks like the PW is hardware timed.

So my work around is that I am planning on using the error handling from my analog signal to determine when I should read my PW and having my analog signal read based on the encoder's A signal.  In the image below, I have the basic layout for what I want. 

On the left side, I am creating my tasks and setting the timing source to read based on 6602/PFI0 (this may not actually be the A line, but this image serves as a basic overview of my solution) as well as the PW in.  in the while loop, I have set a timeout of .25s and if there is no timeout (no error) I am reading my PW measurement.  If there is a timeout (error), I am clearing the error.

From my understanding, Implicit timing for HW timed signals means read the current value on the DAQ device, so since the analog signal is gated by my encoder, my PW signal should also be gated by my encoder since it's only read if my encoder tells my analog signal to read.

This solution passes my "straight face test" and I wanted to see if anyone had a better solution or could see any issues with my solution.

Thanks,

Matt

[Kevin_Price]

Executive summary: in my opinion, that approach is doomed. 

Hardware-timed single point is very very rarely something to use outside of a Real-Time app.   The software timing and decision making to jump from an AI read to the *initiation* of a counter pulse width read  is probably not gonna give you good enough time / crank angle correlation between your measurements.

You've gotta do it with hardware somehow, and it's gonna get a little involved. 

Right now I can only outline some things rather than lay out all the details.

You're going to need to sync with a hardware trigger while tracking cumulative time of both (actually all, more on this later) tasks.  They will be sampling at a variable rate so the individual sample values will NOT line up in time.  But you can certainly resample or interpolate to get VERY MUCH better correlation than the software-timing you were intending.

Counter input are unique in not supporting a standard Start Trigger.  You need to configure an "Arm Start Trigger" for a continuous sampling semiperiod task.  This same trigger needs to start your AI task so you can correlate t=0.  You will also need to add a counter period measurement task to capture the encoder intervals that determine your AI sample timing.  It too needs to be Arm Start Triggered.

So starting from the triggering signal, you'll collect 4096 AI samples and 4096 period samples per rev.  The semiperiod measurement will be off on its own, sampling at a rate determined by the PWM signal itself.

So as you collect samples, your software needs to track the cumulative time associated with each AI sample (using the data from the counter period task) as well as the cumulative time associated with the PWM measurements (using the data from the counter semiperiod task).

-Kevin P

[Matt_AM]

Kevin,

Is a semi period measurement gatable?  I'm not sure if thats the right term, but I mean this in the sense of, can I have it acquire the signal based on the encoder's A signal like I can for the AI signal?  I assumed if I couldnt gate the PW measurement, I wouldnt be able to gate a semi period one either. 

Assuming I can gate a semi period, how do I go about determining if my measurement is reading the high time when the task starts?  I've done semi period measurements in the LV 7.1 and had issues making sure that I was looking at the high time.

I am assuming that I can use the encoder's A line to arm the counter and AI tasks, so that shouldnt be an issue.

I understand what you mean with SW delay between the AI and counter reads and the comment stating RT would allow my logic to work.  For slower speeds (1 RPM for now....) I figured I could get by with the current method.  But if I really wanted to use my solution, I would have to go to an RT device (which I do have a cRIO, I just dont want to make new cabling, rewire, and recode what I got).

Thanks for your input,

Matt

[Kevin_Price]

Several "quick hits."  Each section addresses a separate issue.

No, semiperiod is not "gateable" in the sense that I think you mean.  The PWM signal itself causes the semiperiod samples to happen -- this is what is meant by "Implicit Timing" when you call DAQmx Timing.  Every PWM cycle yields 2 semiperiod samples.  The time associated with those samples is entirely independent of the time associated with samples driven by the encoder.  And you can't change that.

There's a DAQmx Channel property you can set that defines the "Starting Edge" for semiperiod measurement.  So if you set that as a rising edge, the first sample will be a high time.  Thereafter, the samples will alternate low time, high time, low time, etc.

   LV 7.1 was a long time ago, so I wonder if you may have been trying semiperiod measurement with an E-series device?  I know that back when I was using E-series under traditional NI-DAQ, you couldn't choose the starting polarity.  But that got fixed with later generations of hardware (along with DAQmx driver support).

You could use the encoder's A channel as a trigger, but I make a practice not to use the same edge of the same signal for both triggering and counting or sampling.  It seems like asking for ambiguity from a signal-level race condition.   You've got plenty of counters available on your 6602, I'd recommend using one of them to generate your own trigger signal after you know all the tasks are armed and ready to react to it.

RT clarification:  I wasn't so much recommending FOR the use of RT, more recommending AGAINST the use of hw-timed single point sampling outside of RT.  It's rarely called for and successful.

-Kevin P

[Matt_AM]

Kevin,

Thanks again for the response.

1) If the semi period isn't "gateable" I'm having a hard time understanding how I link the semi period read to the encoder position. I guess are you saying that I should sample my semi period, encoder position, and AI measurements continously and use the change in encoder to denote when "A goes high" or something like that?  I guess if I set AI to be gated by encoder A and I started all 3 tasks at the same time, then I could read AI and get the timestamp to know when "A went high", figure out how many samples of "continuous semi period and encoder" occurred and grab that data point. 

IIRC, the semi period measurement works by having the signal run into the counter's gate while a known clock runs into the source, then when the PWM signal is high, the counter reads the number of pulses from the clock and gives me the corresponding time measurement.  I bring this up to say that I understand why I can't "gate" the measurement type. 

2) cool cool, Ill look into that property node.  Ya, LV 7.1 is rough to code in (there weren't LV projects yet), but you know, if it aint broke, why fix?  And then we wonder why we're drowning in technical debt... 

3) makes sense with race condition.  I can use a random PFI line for my start trigger.

4) I was just spit balling ideas regarding my current method of using HW timed.  My logic being that the only way to get my method to work is using an RT device with a stupid fast timed loop so there would be as little delay between the reads as possible.  

Thanks,

Matt 

[Kevin_Price]

1.  Reread my msg #2.  Period measurement of the encoder and semiperiod measurement of the PWM signal can be used to determine a cumulative time at each sample of those two respective tasks.  Having both tasks start from the same "Arm Start" trigger makes sure you also have the same t0.

-Kevin P