Time Elapsed between encoder pulses

[reuvengomes]

Hi Kevin,

I just tried out the VI but got an error relating to the start task. Would you have any idea why this is so? Could it be something to do with finite acquisition? I read that at least for finite counter output, it usually requires a pair of counters. I'm not sure about this case though.

Would appreciate your suggestions.

Reuven.

[Kevin_Price]

To try to figure it out, I went into MAX, created a *simulated* PXI-6040E (the PCI version wasn't available as an option to simulate), selected it, and examined the "Device Routes" tab at the bottom of the window.

I had forgotten that the E-series boards had more routing limitations than the M-series and X-series boards I've gotten used to for the past 10+ years. 

According to the routing map, an AI Start Trigger can be sourced directly by Ctr0InternalOutput but *not* by Ctr1InternalOutput.  The first thing to try is to use Ctr0 as the intermediate triggering counter and use Ctr1 as the period measurement counter, including the needed screwdriver wiring changes.  If there's still an error, we may need to be more explicit about sourcing the triggers from the "Ctr0InternalOutput" signal.

An alternative would involve the use of Export Signal to send the triggering pulse directly to a specific RTSI line and then configure the AI Start Trigger to come from that same RTSI line.   I used to do that kind of manual routing config a lot many many years ago before DAQmx.  Looks like you'd still need to use Ctr0 as the intermediate triggering counter to have decent routing options.

[time passes...]

Dang!  Just checked another thing.  Looks like "Arm Start" triggers aren't supported on the 6040E.  So now it looks like you're gonna have to spread your tasks across the 2 boards and do more explicit screwdriver wiring to share timing signals.

The period measurement *must* be on the 6601 in order to support Arm Start triggering.  I'd put the intermediate counter on the 6601 as well b/c the routing is more flexible and the code I posted ought to work on the 6601 for the two counter tasks.

Then you'll need to screwdriver wire from the 6601 output pulse to the 6040 AI Start Trigger (default pin PFI0 according to MAX ) and probably designate PFI0 as the AI Start Trigger.

-Kevin P

[reuvengomes]

Thanks for that Kevin. I really hope that works. I will probably try the second option that you explained. I just need to confirm what to do first. But before that, I just need to take a slight diversion and ask you for your opinion on my injection VI just to make sure that I'm doing it right. 

To control my injection timing, I basically just using a stock retriggerable pulse generation VI that I found online. Basically, it uses my encoder pulses as source ticks and outputs a pulse. I trigger it using the Z signal and count for example 700 pulses(350deg) during which it keeps the pulse low and then increases it for the number of ticks I want. Very simple and straightforward but just wanted to verify that this is as accurate and precise as I can get. In a previous injection control VI that I attempted, I would compare the edges counted and match it to the value I wanted but that was too software based and introduced delays(probably in the millisecond range but enough to affect combustion). Just want to make sure that's not happening here. I need it to be as accurate as possible. Also, a doubt I had was that this VI didn't have any timing VI like an implicit one or anything and I see that almost all counter task related VIs have some sort of timing VI. I've attached it below. Please let me know if it's OK. Also, I use ctr0 of the 6601 for this operation.

And coming back to the pressure timestamp program, so my understanding is that I should specify say ctr1 on the 6601 as the intermediate trigger and say ctr2 for the period measurement.  And instead of wiring the Z signal to PFI0 of the 6040E, I send it to ctr1 of the 6601 and wire the output of ctr1 to PFI0 of the 6040E. So basically just some simple swapping of the BNC cables hopefully. 

Thanks again. I'll try it out and let you know how it goes. 

[Kevin_Price]

The stock retriggerable pulse generator vi you posted will work fine once all the input parameters are set correctly.   I'd just add a Wait delay in the loop (prob 100-200 msec) so as not to burn CPU unnecessarily.

The lack of DAQmx Timing.vi is fine.  The timing config is needed for tasks with multiple i/o samples such as buffered AI or a continuous pulse train.  Technically, you're setting up a single pulse and it's the retriggering that makes the single pulse repeat.

Caution:  I don't remember all the specifics but know that different counters can have slightly different retriggering behavior regarding the use of "initial delay" and "low ticks".  My takeaway has been to use a low idle state, and wire the same value to both initial delay and low ticks so that the 1st rev behaves the same as subsequent revs.

   I would also tend to use the minimal value of 2 high ticks b/c it gives you the most flexibility while keeping the sum <720 (1 rev).

Your description of adapting code & wiring to use only 6601 counters sounds right.   I think you're almost there!

-Kevin P

[reuvengomes]

Hey, thanks for replying Kevin. I thought you got bored of my never ending queries.

I still haven't had the chance to try and run the combined program as I went ahead and got started with the experiments. I'm just using the VIs separately right now. Not very accurate but it'll do in these circumstances.

I do the exact same thing you mentioned about using the same value for the low ticks and delay and set the idle state to low. 

Just one conceptual question though about the wait time in a loop. My understanding was always that the wait time is the time between consecutive loops and that say in this case, each loop would correspond to one pulse of the encoder.  But apparently it isn't. How does it work then?

[Kevin_Price]

If there's a Wait in a loop, the wait time must elapse during each iteration of the loop before the next iteration will begin.  I don't understand what you're referring to about expecting each iteration to correspond to one encoder pulse -- can you elaborate?   Which sample program are you talking about?

-Kevin P

[reuvengomes]

So what I meant was that each iteration of the loop would correspond to one counter pulse output or one read input etc. For instance, in the injection VI I posted, if I need the pulse after 700 ticks of the encoder, then I thought the loop would need to iterate at least 700 times to correspond to those ticks and perform the specified action. Or say in the pressure acquisition, I thought we would need more loop iterations than the number of readings to be read in a set amount of time and that if the loop didn't iterate fast enough, it would miss/skip reading our outputting values. Do you understand what I'm trying to ask now? I hope that makes sense.

If it doesn't, don't bother about it. I have a very important question to ask you and would appreciate your answer for this more than the above question. You may just ignore the above query. The thing is that the B pulse of my encoder is acting weird. Instead of having a low idle state and outputting a 5V signal for each CAD(0.5 Deg in my case) always, sometimes when I rotate it, the idle state switches to 5V and for every CAD it goes down to 0. Then if I stop rotating and start again, the idle goes back down to low and goes high for each CAD. So basically, it always pulses while being rotated, but the idle state fluctuates every now and then. I'd like to know in my pressure and injection programs, will it matter to the program if I've not specified on which edge to count? The pressure program takes pressures corresponding to each CAD pulse and the injection program needs to count the number of B pulses to vary the injection advance. So if the idle state fluctuates mid rotation or whatever but continues to pulse, will my program work fine? I tried a simple edge counting in NI MAX for one rotation of the crankshaft and it counter 720 pulses correctly. I ran the engine once and the pressure program worked as well. But the other day, while running an experiment, everything was working fine until all of a sudden, my pressure program stopped gathering data and gave me an error saying some signal it expects hasn't been received and the injection program just wouldn't fire and so I had no combustion. Today I tried the injection program also again but rotated the engine very slowly by hand and it triggered the injection. Does this erratic behaviour have something to do with the B pulse? Sometimes it's recognized, sometimes it's not? Please let me know your thoughts on this.

[Kevin_Price]

1. No, the DAQmx task configs are set up so that the hardware & driver handles that stuff for you.  With the injection pulse, there is nothing whatsoever to relate the hardware to the loop iteration #.  With the AI, the driver is accumulating samples into a buffer in the background.  Because it's a Finite Sampling task, it knows it's done when the buffer has been filled.  The loop simply queries to see if the task knows it's done, then you can read the entire array of data all at once from the buffer.  It really doesn't matter very much how many times you iterate or how fast.  

2. Honestly, it sounds to me like the encoder signal is normal and that you have a wrong expectation about it.  Channel B doesn't have an "idle state" (nor does Channel A).  It's just a square wave that cycles 720 times per rev.  The low and high state transitions correspond to specific physical rotation angles.

  I suspect that wherever the encoder happens to be right before starting the motion is what you're labelling as "idle state."  To me, it's entirely reasonable that this starting state would be unpredictable, sometimes starting low sometimes starting high.  It's pretty much just a 50/50 chance.

3. The fact that rotating the engine slowly by hand fires off injection at the right position is a good confirmation of the basic task config.  It's driven by the hardware encoder signals and is not dependent on engine timing or speed.

   I don't know what happened the other day when things weren't getting triggered, but I wouldn't suspect any issue with the encoder B channel, which as far as I can tell is just fine.

-Kevin P

[reuvengomes]

Thanks so much Kevin for the clarification!

It makes sense to me now. All three points. I probably had the wrong expectation of the B pulse. The times I thought the idle state had moved must have been the times when the encoder was on a specific angle position. The only thing that might have been causing me issues might have been the Z signal or the exhaust top dead center signal which is an AND operation between the Z signal and a signal from a sensor that detects the motion of  a toothed disk with a 2:1 timing belt so that we receive one signal every two rotations. That is the signal that triggers both my programs so I guess that might have been the issue.

[reuvengomes]

Hi Kevin,

I tried making the changes to the time stamp program and the wiring connections but still got a start task related error. I've included pics of the front panel with the error and what I set things too. And also the block diagram. I specified ctr 1 of the 6601 as the intermediate trigger. I wired the Z signal to the gate terminal of the counter which is PFI34 in my case. I wired the output of ctr1(PFI32) to PFI0 of the 6040E(where I usually wire the Z signal). I specified ctr2 for the period measurement. I specified a separate terminal for the pressure readings PFI7 like before for the 6040E. Is there something I'm doing wrong?

Reuven.