Finite Retriggerable Pulse train for Engine Control

[nithyan2]

We are using Labview to control injection and spark timing on an engine.  We use the Z-signal from a shaft encoder to create a reference signal that is used as a trigger for two counters, one for fuel injection and one for spark.

Currently, we are able to inject/spark once every N cycles.  What we would like is to be able to inject/spark X times in a row every N cycles, as shown in the figure.  For example, create a reference pulse every N cycles that triggers a retriggerable, finite pulse train of X pulses.  In the example shown, N = 8, X = 3.

Please see attached “Engine Control VI”, which is a working VI with which we can fire the engine once every N cycles. Also attached is our counter pulse generation VI “6602 Pulse (SubVI)”. In order to obtain the desired finite, retriggerable pulse train, we have tried to add a new counter triggered by the reference signal  (“Engine_multi-fire_trial VI”) – but when we use the ‘Finite pulse’ mode, we always get ERR -50103 on the spark counter.

Any help would be greatly appreciated. Thanks!

[cdaug]

What hardware are you using to run this task? Error -50103 can happen for many reasons, the two most common being 1) all of the timing engines on your hardware are already being used or 2) you are trying to start a task with a channel that has been included in a task that is already running. Below are two articles I think would help solve your issue. One is common causes of the error you're seeing and the second is a retriggerablef inite pulse train example.

Causes of NI-DAQmx Error -50103: "The Specified Resource is Reserved" Link: http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89

Using One Counter to Generate a Retriggerable Finite Digital Pulse Train with an NI 66xx and NI-DAQmx, Link: http://digital.ni.com/public.nsf/allkb/4A9AF19480E50C6D862571B70058142A

Take a look at these articles and get back if you have any questions!

Best,

Chris D. | Applications Engineer | National Instruments

[nithyan2]

Hi Chris,

Thank you for your response. We are using a PCI-6602 card. I looked at the two articles you recommended. 

I am not sure if you had a chance to look at my attached code, but here is how the counters are basically configured:

Working code (Firing once every N cycles)

PFI38 - Gets Z signal, triggers CTR 0 

CTR 0 output - Reference signal (pulse)

CTR 1 output - Injector pulse, triggered by CTR 0

CTR 2 output - Spark pulse, triggered by CTR 0

Trial code (To fire X times every N cycles)

PFI38 - Gets Z signal, triggers CTR 0 

CTR 0 output - Reference signal (pulse)

CTR 3 output - Finite pulse train, triggered by CTR 0

CTR 1 output - Injector pulse, triggered by CTR 3

CTR 2 output - Spark pulse, triggered by CTR 3

1. Based on the first article regarding ERR -50103, it seems that the most likely cause in my case would be "Case 3: Using multiple counter tasks on the same device." In the working code, outputs of CTR1 and CTR2 are both triggered by CTR0, but there is no error.

But in our new trial code, outputs of CTR1 and CTR2 are both triggered by CTR3, and this causes ERR -50103 in CTR2. I am not sure why.

2. For the Finite retriggerable pulse, I want to use something similar to the example code in the article you shared:

But I am not sure I fully understand how this works (see circled in red), especailly the pause trigger. Based on my configuration of counters described above, I am not sure which counter I must connect to the CO Pulse Ticks VI in my case - I am guessing CTR 3 as thats what I want to have a finite pulse train to use as a trigger for CTR1, CTR2.

And as for the pause trigger, I really don't know what I should connect here in my case. Based on my configuration, could you please recommend how I set this up?

Kindly refer to the codes I attached earlier. Please let me know if you have questions. Thank you so much for your time.

Thanks,

Karthik

[Kevin_Price · Accepted solution]

Short answer: in your second scenario, use counter 4,5,6, or 7 instead of counter 3.  The problem is that a finite pulsetrain on a 6602 requires the implicit use of a "paired counter".  The pairs are: (0,1), (2,3), (4,5), (6,7).  The error arises because you have two tasks that both need to reserve use of Ctr2.  Once you use one of the higher-numbered counters, its pair will be available and you won't get that error.  This situation was described in Case 3 from cdaug's first link.

The second link won't be needed.  The essence of the idea is to use an external signal to serve the same purpose that the paired counter otherwise would have.  But you'd also need that external signal to have very precise timing properties for the frequency & # of pulses you want to generate.  It'll be simpler for you to just use Ctr 4 (and its pair, Ctr5) for your finite pulse train.

-Kevin P

[nithyan2]

Hi Kevin,

That did the trick! I changed CTR 3 to CTR 4 and it ran smoothly!

Thank you so much!

Best,

Karthik

[reuvengomes]

Hi Kevin,

I am also trying to use this VI for a similar application to control fuel injection to a diesel optical engine. I have a PCI 6601 card however which has just 4 counters. Since the finite pulse generation requires a pair, I was wondering if I could use 1 counter from my pci 6040E daq card and the rest from 6601. Do you think that would work, using counters from 2 different devices?

Thank you and would really appreciate your advice.

Reuven.

[a.cisneros]

Good morning Reuven,

If the frequencies are not contradicting between the 6601 and the 6040E DAQ card it should work. However, to avoid complicating matters, I would advise you to try to get both parts of the pair from the 6601 if at all possible and to use the 6040E DAQ card to replace the counter you move to become part of the pair for the finite pulse generation.

Here is the manual for the 6601 and 6602 if you would like to look through it: https://neurophysics.ucsd.edu/Manuals/National%20Instruments/6601_6602%20User%20Manual.pdf

I hope this helps you.

Angie Cisneros 

[reuvengomes]

Hi Angie, 

Thanks a lot for your advice. I've actually decided to go with a simpler approach to control the fuel injection instead of the above VI which is a bit too sophisticated for me to modify for my needs. I have decided to use the Generate Digital Re-trigger-able  Pulse VI to control the injection which is perfect for my needs. Basically I need to receive a trigger signal which is the exhaust top dead center pulse from my engine and start counting from there. For an ignition advance of say 10deg(so basically 350deg after the trigger signal) I would need to count 700 pulses since my shaft encoder sends a pulse for every half degree. I have a few quick questions which I would really appreciate being answered:

1. I want to keep the pulse low for the first 350deg and then emit a pulse after that. I want to know in what order does the counter output pulse VI execute the ticks. Does it execute the low ticks first and then high ticks if the idle state is set to low? I read somewhere that for  a retriggerable pulse, for what I need, I need to set the low ticks=initial delay. I would still like to know however just for my knowledge sake, if the initial delay is set to low, what executes first, low or high?

2. What should I do regarding my loop timing? The engine will be running at 600rpm and the source is the shaft encoder pulses for every 0.5 CAD(crank angle degree). Should I just delete the wait timing function inside the while loop? Is there a way to synchronize the while loop with the CAD?

3. This last one is not very important but would be convenient. I want to be able to control the number of injections so I want to use another counter to read the number of injection pulses it receives and then stop the program according to the number of injections I set. Can this be done within this same while loop or will it lead to complications?

Thanks and again, I would really appreciate any help and guidance.

Reuven. 

P.S. I've attached the file below just to make sure you know which VI I'm talking about.

[a.cisneros]

Hi Reuven,

Thank you for attaching your code and giving me such good thorough questions!

1) If you set low ticks for the initial delay then the first tick at 350deg will be high. That means the high is executing first and the signal is low during the entirety of the delay.

2) I would recommend deleting your wait. The vi you attached is writing the digital signal to your "Counter" input. The "Source of Ticks" input specifies what frequency the counter is being generated at. Using this frequency you can decipher the needed timing for synchronization with the counter being generated. In a new vi using the DAQmx read you can read the signal in at a pace synchronized by using the same pace as your writing function in the channel.

3) I would do this in a separate read vi with a similar architecture as the generating/write vi you attached. 

Angie Cisneros

[reuvengomes]

Thanks so much Angie! I have a better idea now of what to do. I appreciate it!