ION Pulser Module Strange Behavior

[richard_schwass]

Hi there,

We recently discovered strange behavior of the Pulser Module in an ION 7650 seemingly by-design.

The PulseWidth register which you would expect is just used to define the width of the pulse also defines a delay prior to sending the pulse to the output channel.

We expected the module to send the pulse to the output as soon as its internal scanning detects an input pulse and then hold that pulse for the duration defined in PulseWidth.

We want an  immediate pulse with a duration of 2 sec. Set to this our testing confirms that we will get an "ON" approx 2 sec after input pulse and another "OFF" a further 2 sec after that.

The only way to make it more immediate is to set the register to minimum of 0.02 sec which will then provide only a brief pulse on the output and risk the downstream equipment to not see it.

Could we request that consideration be given to either removing the delay aspect keeping it just as "width" or if delay is to be retained then define it in another register please?

Of course this would be a huge exercise to roll-back into the products but perhaps could be incorporated in any future firmware releases. Certainly the upcoming PM9000 should address this.

Thanks for reading...

Regards Richard

[sesa56307_bridg]

Hi Richard,

Thanks for the feedback!  We'll certainly consider this as we continue to make improvements to the ION modules.

I'm not familiar with the detailed implementation of the Pulser Module myself.  The description in the ION Reference document says that the module operates once per second, and then determines the number of equally spaced pulses to generate over the next second.  It doesn't mention the duty cycle, or the use of the PulseWidth register to control a delay before the pulse.  This is a bit different from the behaviour you described.  But is it possible that when you saw the delay of "approx 2 sec", it was actually the delay to wait until the next one-second boundary, and then to generate a pulse during the next second as described?  The Pulser Module (by design) will not provide a high-speed response to a condition, it is geared more toward generating a stream of pulses.  So there will be some measurable delay between the input pulse and the transition of the output.

In any case, it doesn't sound like the Pulser Module is doing what you need today.  Have you tried using the Digital Output Module instead?  I think it should provide a much faster response and may be a better fit for your application.  If you are trying to drive an output pulse using an ION pulse register (like you would with a Pulser Module), then you could just link that pulse into the "Force ON" input of the Digital Output Module (without linking the "Source" input).  Or if you are trying to drive an output pulse using an ION boolean register, then you could use the "Source" input.  Either of these approaches, combined with using the "PulseWidth" setup register on the Digital Output Module, might fit your need.

Best regards,

David Tuckey, Firmware Architect

[richard_schwass]

Hi David,

Appreciate the reply... always great to chat with a firmware guy!

We believe the module is in fact operating at high-speed. It is linked to a high-speed register which is a set-point off of "HS Freq". Each module is listed as operating at one-cycle when we "View Diagram Text" as diagnostic from ION Designer. Also, the image below is grabbed from the ION Device Templates reference which shows the Pulser module able to operate at either one-cycle or one-second depending on what its linked to. Finally, if we test it at its minimum register setting of 0.02s then we get an overall repeatable response time of approx 500ms from setpoint operating and pulse being sent out a relay input.

We did want to use a Digital output module as this would work better for us but when linked to a high-speed framework, the processing power requirement exceeds what we have available in the customers meter template. It is a heavily loaded template!

We can live with it as is from now as the customer is satisfied with an overall response time of 2sec in this case. We just think that if our investigated results are correct then the behavior is unfortunate.

Cheers Richard