retriggerable finite pulse train

[bcummings]

I have a problem using a retriggerable finite pulse train as in the NI example Retriggerable_Finite_Pulse_Train. I use ACTOUT to gate the first re-triggerable pulse control and the second pulse control generates the continueous pulse train which is gated by the first retriggerable pulse control. The ACTOUT signal is generated by an AI control which senses a crank trigger (Hall Sensor). The re-triggerable pulse train is used to modulate a fuel injector in sync with ignition timing and RPM.  If the period of the ACTOUT signal changes due to a change in RPM, the pulse train is recalculated. It works OK with one hitch. Even at constant RPM, after about 15 re-triggerer pulse trains the final pulse of the train does not complete. This leaves the signal high in-between successive re-triggerer pulse trains. This incorrect high signal between re-triggerer pulse trains means that the fuel injector is incorrectly left on between pulse trains, when it should be turned off. This incorrect high signal goes on for about 10 pulse train events and then returns to normal. I use the ActualPeriod of the first re-triggerable pulse to ensure the pulse train ends correctly within window of the first re-triggerable pulse, but it seem to wander. Is there another way to create a different type of re-triggerable pulse train that overcomes this problem. I may have to use a single re-triggerable pulse instead of a re-triggerable pulse train as this work correctly every time. However, multiple pulses creates a finer mist from a fuel injector and is the correct why to modulate a fuel injector. The

[bcummings]

CORRECTION TO PREVIOUS POSTING THERE WAS AN ERROR IN HOW I DESCRIBED THE PROBLEM:

I have a problem using a retriggerable finite pulse train as in the NI example Retriggerable_Finite_Pulse_Train. I use ACTOUT to gate the first re-triggerable pulse control and the second pulse control generates the continuous pulse train which is gated by the first retriggerable pulse control. The ACTOUT signal is generated by an AI control which senses a crank trigger (Hall Sensor). The re-triggerable pulse train is used to modulate a fuel injector in sync with ignition timing and RPM.  If the period of the ACTOUT signal changes due to a change in RPM, the pulse train is recalculated. It works OK with one hitch. Even at constant RPM, after about 15 re-triggerer pulse trains the final pulse of the train does not complete. This leaves the signal high in-between successive re-triggerer pulse trains. This incorrect high signal between re-triggerer pulse trains means that the fuel injector is incorrectly left on in-between pulse trains. This incorrect high signal goes on for about 10 pulse train events and then returns to normal. This pattern repeats. I use the ActualPeriod of the second control's continuous pulse train to ensure the pulse train ends correctly within window of the first re-triggerable pulse. This work but with time this pulse train seem to shift slightly. Is there another way to create a different type of re-triggerable pulse train that overcomes this problem?

[George M.]

Hi,

This is indeed strange behavior, and I am going to need to some other information to help narrow down the issue:

1)  What hardware are using?

2)  What programming language are you using (LabVIEW, CVI, etc.)?

3)  Can you simplify your code to show just this behavior?  That is, remove all of the external code that is not relevant to this problem, and then copy it to this thread for us to look at.

Thanks, and have a Great Day!

George M.

[bcummings]

Thanks for the reply.

I have attached a document that answers your questions.

Take Care

Bruce

[bcummings]

George,

After further testing I have decided to simply use a retriggerable pulse train that gives a single pulse. It works OK and I'll be using it instead of the more complicated multiple pulses. I believe part of my problem is that I should be using real time hardware instead of the 6040 and 6013. (i.e. compact RIO or PXI-7833R )

Thanks so much for consideration of my problem.

Bruce