LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Finite Retriggerable Pulse train for Engine Control

Solved!
Go to solution

Hi

 

I developed an engine control VI almost similar to the one discussed in this thread. It gives the desired result but with slight delay.

Each cycle is marked by a TTL signal, lets call it Ex signal.

In my program, first a signal is generated which serves as starting point to generate TTL signals to direct the injection in subsequent cycles based on Ex signals. It stays low after pointing the start to ensure enough cycles are skipped. It is also re trigger-able by the Ex Signal.

Based on this signal another task generated a finite number of signals.

 

The first set of injection is right as per the tick count set by me. But the second sets are delayed by some ticks. I think the re triggering causes the delay. If so is there any way to stop this? Attached figure and VI for reference. If anyone can help me to fix this, it will help me to complete my project. 

 

Thanks

 

In the picture, the Black one is the signal that controls when to start firing, Red is the firing pulse, Green is the exhaust TDC based on which all the signals are defined.

Download All
0 Kudos
Message 11 of 18
(919 Views)

Some newer hardware supports a DAQmx property that can enforce the same "initial delay" for all triggers in a retriggerable counter pulse task.   Older hardware has its own particular defined behavior that isn't configurable this way.

 

Here's a link to show how to do it in LabVIEW for an X-series card (or probably also other data acq hardware based around the DAQ-STC3 timing chip).  For other hardware, you'll find a number of hits on the site by searching for "initial delay retriggerable".

 

FYI, 0 is not a legal value for the initial delay inputs of your pulse tasks.  Internally, the tasks must be coercing that to be the minimum allowed # Ticks which is 2.   Also, your stop button is outside your main polling loops.  It will be read 1 time while the tasks are being configured and when you press the button after that, the loops never see the change. 

 

 

-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 12 of 18
(912 Views)

Hi Kevin,

 

Thanks for replying. I used a delay of 1440 ticks which correspond to 1 cycle. I thank you for your suggestion as this really doesn't affect my experiments as I just run 1 extra cycle.  I am able to generate signal 1 accurately now, by correct usage of ticks . But my injection signal is still offset. If I use combinations of high tick + low tick = 1440, only the first set of signals is correct but latter set of signals (generated by re triggering) are offset. 

 

I am not sure what is causing this issue. Please let me know if you find any other drawbacks. 

 

Thanks for your help.

0 Kudos
Message 13 of 18
(899 Views)

I really can't comment in any useful detail without a much more complete & clear description.  A timing diagram would be excellent and should identify & distinguish:

  • external signals you don't control.  Do they repeat?  Is the timing irregular?  How much?
  • signals you plan to generate
  • edges which must line up in time
  • edges that must show a fixed timing relation to other edges

Also, a little more big picture explanation: what are you trying to do, what do you hope to accomplish by doing 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).
0 Kudos
Message 14 of 18
(889 Views)

Hi Kevin, 

 

Sorry for being unclear in the problem description. I am currently working on a diesel engine setup where I need to develop the injection control system. The injection control system should perform the following functions

1. Give a TTL signal to the injection circuit at accurate time (based on Crank Angle Degree of crank shaft)

2. The TTL signal should control the duration of injection by controlling the TTl pulse 's high duration

3. It should be fast enough so as to control the engine at 600 RPM

The injection control has access to two signals, 

1. Crank Angle Degree based on crank shaft rotation (The shaft encoder has 720 pulses per each crank shaft rotation)

2. An Exhaust Top Dead Center signal to serve as reference for injection and other purposes.

I also have to ensure that there is a certain number of skipped or non injection cycles after each group of injection cycles i.e 'm' injection cycles followed by 'n' non injection cycles and so on. I have PCI 6602 card which has 8 counters to do this job. I have used CO Pulse Ticks Sub VI to approach this problem. The current program is designed such that one task generates a reference signal is generated whose rising edge determines the start of group of injection cycles. A second task uses this reference signal to make only certain number of injection cycles and then stay low until it is again re triggered by the reference signal.

 

This VI gives me required controlling but only the timing of first group of firing signal is correct after which it shifts. In the experiments I am expecting the CAD pulses to be not regular, there will be variation in their frequency and I wish to capture it too. 

 

-There are two external Signal which I donot control. 1. CAD pulses coming from Crank Shaft encoder ~ 720 pulses per rotation 2. Ex TDC which is once per rotation of Crank shaft encoder based on which the injection pulse is referenced. 

Yes they repeat but the irregularity in timing is of the order of 0.1 ms and I want to control accounting for the irregularity. 

-I plan to generate one signal, the injection signal. But that signal must be present in few cycles and absent in subsequent controlled number of cycles, 'm' injection and 'n' non injection cycles. 

-I wish to control this injection cycle with respect to certain CAD pulses from the Ex TDC signal.

 

I hope this explains the problem. Please let me know if I can be more clearer in explaining some portions. Considering that I have just started with LabVIEW a few weeks back, I appreciate your suggestions.

 

Attached VI

 

 

 

 

0 Kudos
Message 15 of 18
(884 Views)

Thanks, that was a really great write up!

 

You've got a tricky DAQmx problem here.  I'd *like* to come up with a solution using only your 6602, but I'm not sure I can piece that together.  A simple external logic circuit might be needed.  Let's work our way along step by step.

 

First, let's look at how you'd fire an injection pulse on *every* cycle at a specific angle relative to TDC, and with a fixed pulse width.  This probably requires 2 counters.

 

The 1st counter is used to generate 1 pulse per rev with the active (let's say rising) edge occuring at the desired position.  It would be configured for continuous samples.  Use the external TDC pulse as a start trigger, define the pulse specs in Ticks, use the CAD signal as the Tick source.  Configure the pulse specs so that high ticks plus low ticks equals 1 rev (720 Ticks).  Set initial delay to define where the injection pulse should occur relative to TDC.   So now this counter output will pulse once per rev but at the correct offset from TDC to trigger injection.

 

The 2nd counter will be a retriggerable single pulse.  Units can probably be seconds.  Use the rising edge of the 1st counter as the trigger signal, set minimal values for both initial delay and low time, and set your high time to be your injection pulse duration.

 

A 3rd counter can be used to measure frequency of the CAD pulses.  It should be a continuous sampling task configured to use an "Arm Start" trigger, probably using the external TDC signal.  Be aware that with the 6602, the very first measured frequency may be based on a partial CAD interval.  I know that's what would happen in period measurement mode and suspect that the same may be true for frequency measurement.  If so, it would represent the interval from the Arm Start trigger edge to the 1st following CAD edge. 

 

So we're almost there, but this doesn't address the desire for "M revs on, N revs off".  This is where things get (more) tricky.  It'd be nice to set up a 4th counter that could be used as a "pause trigger" by either your 1st or 2nd pulse generators, BUT I don't believe you can use both a pause trigger and a start trigger on the same counter task.

 

The way to do it indirectly would be for a 4th counter to generate a pulse train that would go M revs high, N revs low.  This one could trigger off TDC, just set initial delay to choose the offset from TDC.  The pulse specs should be based on Ticks from the CAD signal. 

 

Then you configure a 5th counter for continuous pulses at a high rate like 10 MHz, and tell it to use the 4th counter as a pause trigger.  Then you further go back and reconfigure your 2nd counter (the real injection pulses) to use the 5th counter as its timebase, adjusting pulse specs as appropriate.

 

Even after all this, there will likely be a few more details to be worked out.  For example, the M high cycles probably need to be offset to start at the same position as the injection pulse.  You need to be careful about how you sequencing the startup of these tasks.  There may a rev of two of startup behavior before you can get to your desired repeating behavior.

 

I'd advise you to try these ideas a little at a time.  Make separate vi's for each of the 5 counters to help you test things out in modular pieces before trying to integrate them all into 1 vi.

 

 

-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 16 of 18
(874 Views)

Hi Kevin,

 

Thanks for the ideas to solve this problem. Now I am able to capture the CAD pulses with respect to time in a different VI, so I am able to capture high frequency of variation.

 

One more solution is if I can use the signal generated from the first task in the attached VI as gate of the counter for second task I may be able to solve this problem. I am not able to do by connecting the out of task 1 to the gate port of counter used in task 2. Is there something else I am missing.

 

Thanks Kevin

0 Kudos
Message 17 of 18
(855 Views)

Hi Kevin, 

 

I am now able to implement the m skip and n injection cycles. Your suggestions helped me a lot. I think it should run fine with my experimental setup. I have attached the VI for any further reference.

0 Kudos
Message 18 of 18
(845 Views)