Deterministic updating of retriggerable pulses

[Vern]

I have 3 retriggerable pulses occuring after the trigger of a z-index on an optical encoder. 6602 counter card and the pulses are controlling fuel injection and ignition of an engine. The pulse specs need to be updated when they change. (acceleration, fuel pulse adjustment, timing, etc) Presently, I am using a state machine to update only if one of the pulse specs has changed from the previous loop iteration. This minimizes the updating, but, my problem is...

If the updating (Group Config of the counter through Program of counter) is happening while the next Z-pulse occurs, a "miss" occurs and I don't get my pulses for that rotation of my encoder.

I am running Labview RT 5.12 (s/b upgraded to RT
6.1 by next week). I need to find a programming method that lets me time or insert my new pulse specs at a specific time. ie. after the pulses have occured on one revolution and before the next z-pulse occurs. I have approx. 50 ms of "spare time" in which I could update these pulses prior to the next revolution.

The "Pulse Width Modulator" is a good example, of changing on the fly, and uses the "Switch Cycle" function in the Counter Control vi, but I believe that only works with pulse trains, not with retriggerable pulses. I would still want to find a way to "time" that updating process so it doesn't cause me to miss a z-index pulse.

Any ideas would be greatly appreciated!
Thanks
Vern

[Geneva L.]

Vern,

I think we discussed the same application in a different posting. The idea I had was to use retriggerable pulse generation in parallel with the pulse width modulator. Thus, the retriggerable pulse generation would occur whenever the Z index occurred, and use the current source signal for the specs of that retriggered pulse.

One thing I don't understand is what controls those pulse specs. It seems that you actually want to have a sequence of changing the pulse specs, waiting for the Z pulse, then having the pulse sent out, and repeat. So if you are implementing this in a state machine, then it sounds like you are running into software dependencies as far as the timing. However, instead of using a state machine, you could probably run the pulse width mod
ulator in parallel and use some other means of having it change the specs at the appropriate time. That's just an idea which really depends on how and what changes those pulse specs.

Also, you are correct that there's no point in calling the functions to change the pulse specs unless they have changed. You can use a case structure in the loop, so that the loop does nothing in one case for when you don't want to change the pulse specs, and in the other case, calls all those functions.

Regards,

Geneva L.
Applications Engineer
National Instruments
http://www.ni.com/support

[Vern]

...."use some other means of having it change the specs at the appropriate time. That's just an idea which really depends on how and what changes those pulse specs."

The pulse specs are being changed manually (with a front panel control) for now, but will eventually be the results of a calculation based on other sensor data and possibly PID control loops. They won't change every revolution of the encoder, but could change often, especially in response to a large change as the control loop settles on a new target value. The "pulse width modulator" uses a pulse-train only function (switch cycle) that doesn't apply to retriggerable pulses...Oh, how I wish it did. Early on, I had the Set Attibute (for the pulse specs) and the Program vi's only being updat
ed in a while loop to minimize the time required to change the specs, but it didn't work well. Now I have all 3 counters Group Config'd, spec'd, and Programmed each time it updates. I believe the programatic updating takes a short enough time that it could happen in my "extra time" that occurs each cycle. I just need a triggering method to time it correctly. I'm imagining using some sort of trigger, like my 3rd pulse, to tell my pulse updating vi when it should execute. Not sure what structure, if any it should be in to minimize the time required to operate. I'm reading about Occurences, and Notifications. If it all operates quickly enough, these might be an approach for me to use. I don't have alot of detailed programming experience, so I don't know all of the nifty programming logic and tools available. I've attached my existing program, if your willing to take a look, you can see what I'm doing (don't laugh too hard). I really appreciate your answers and help! Thanks alot
.

Vern Smith
vsmith@crcwnet.com

[Geneva L.]

Vern,

Actually, you can use the pulse width modulator idea with retriggerable pulse generation. I should have picked up on this earlier instead of suggesting the hard way to do it with 3 extra counters. I apologize for leading you astray earlier.

You can choose the operation to be retriggerable pulse generation, and the switch cycle works the same way. The thing you might need to work out is the wait time in the loop before it iterates again to check the pulse spec parameters, if you want it to check more frequently. Still, as the counter is waiting for that gate signal for the Z index, there should be time in the loop to change those pulse specs.

Occurrences and notifications also could work for when you want the pulse specs to be che
cked instead of polling with that time delay in the loop. They are based on something else occurring in software, unless you have a board that supports DAQ Occurrences. For DAQ Occurrences, an event can be generated based on something the board detects or acquires. There is currently not support for DAQ Occurrences with the 6602, but I see you mentioned sensor data. I imagine that you might be using a board with analog inputs to gather that sensor data, so that is a possibility. You can find out more about DAQ Occurrences through the LabVIEW examples or on the http://www.ni.com/support pages when you type in "daq occurrence" and go on to choose Learning to use product features and functions.

Regards,
Geneva L.
Applications Engineer
National Instruments
http://www.ni.com/ask