The PTC block solution for Dirk's application had me thinking about an
application I am working on right now. There are 1st Out lights on a field
panel here and they want all of the lights to stay on and when a 1st Out occurs
they want only that light to flash on/off. This way they can tell if any of
the lights are burnt out and can also quickly locate the one that shut them
down because it will be the one flashing.
I played with the PTC block and liked what I saw until I tried to change
the frequency of the .OUTINC parameter cycle time. There is a parameter named
.REPTIM that allows you to change how often the block evaluates the error and
apply the Gain based on the PBAND setting. .REPTIM is supposedly connectable
and settable, but there is something the EDOC doesn't tell you. Changing
.REPTIM from the block detail display does not cause the PTC block to
initialize and the PTC block will store the new setting but will not apply it
until the block is initialized. Cycling the block from Auto to Manual, or
downloading a change in ICC/IACC will make it work. The PTC block WILL accept
and apply changes to all of it's other tuneable parameters such as PBAND, MEAS,
and SPT without the need to initialize the block. WTF, another feature
discovered the hard way.
If anyone is interested, here are the parameter settings you use to cause
the .OUTINC parameter of a PTC block to cycle on and off once per second when
the block is in Auto. Use all of the block default settings and just change the
following parameters as shown below:
.MEAS = 50.0
.SPT = 100.0
.PBAND = 100.0
.REPTIM = 0.0330. (Defaults to 1 minute. 0.033 minutes is 2 seconds and
.OUTINC will cycle on for 1 sec and off for 1 sec with these settings.)
If you reverse the error by flopping
.MEAS = 100.0
And
.SPT = 50.0
The PTC block will cycle .OUTDEC at the same frequency as it previously cycled
.OUTINC. With a GAIN of one, (PBAND = 100) and a 50% error between .MEAS and
.SPT the .OUTINC parameter will cycle 50% on and 50% off.
Pretty simple once you understand how it really works. Use default .5 sec
Period and don't try to set .REPTIM less than twice that time.
Cheers,
Tom VandeWater
Control Conversions, Inc.
On Jan 31, 2016, at 5:19 PM, Tom Vandewater <tjvandew@xxxxxxxxx> wrote:
I like your idea a lot Alex and it would work very elegantly too. In
Dirk's case it would require one PTC block per instance and I think he was
trying to just use one block to do all 10 but in reality 10 PTC blocks
wouldn't be much of a load on a CP270 and it would allow individual
triggering, isolation, and time tweaking of each of the 10 if needed. Tying
his continuous discrete input to the .MA of the PTC block would put the block
in AUTO when the pulse output was needed and back to Manual when not needed.
Very clever idea Alex. Maybe it just whooshed right over everyone's head;<)
BTW, I once used a PTC block as a temperature controller for an unusual
application. As temperature increased in a still-pot it indicated the
concentration of high boilers was accumulating in the bottom. If we pumped
out the sludge/high boiling material from the pot the temperature would
quickly drop to the boiling point of the remaining material. We could've used
a continuous control valve and a PID controller except the amount of material
that needed to be removed was so small and the stream so sludgy it constantly
plugged the valve or eroded the valve seat. The eventual solution was to
open a larger ported discrete ball valve for a very short time to drop the
temperature. The PTC block was perfect for this. It opened/closed the valve
very quickly when the temperature was just a little above setpoint and if the
temperature continued to rise, would open it proportionally longer to
maintain control.
Cheers,
Tom VandeWater
Control Conversions, Inc.
On Jan 29, 2016, at 8:50 AM, "Johnson, Alex"
<alexander.johnson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
No one likes the PTC block idea?
AJ
