?

Log in

No account? Create an account

Previous Web | Next Web

More boring FPS programming stuff...



So, I think I've finally worked out what's wrong with the recover-operation-from-power-failure side of my new software version... in theory, nothing...

If I'm right (not guaranteed, but it all sorta fits a bit too neatly...) then its tied up with the electrical and electronic side of things, not the programming.

So, at the heart of the control system is a funky gizmo called the Master Control Relay (or MCR). Essentially, what this does is disconnect all the loads. But the "essentially" hides a fair bit of complexity...

So, in more detail...

The MCR individually controls two safety contactors. These are wired so that both of them have to be energised for the various load circuits to be energised. The combination of two of these relays is to reduce the potential problem of the load not getting dropped if a contactor were to weld its self in the 'load active' state (sometimes contactors arc when they switch and a welding can occur).

The MCR is energised by having a pulse of electricity on its "activate" circuit. In the FPS, this is controlled by a relay, which is under PLC control. If the pulse is, instead, a continuous "on", the MCR will still try to activate, but only once, after that it will ignore the signal (in other words, the MCR is activated on the "rising edge" of a signal, not by the presence of a signal).

Now, the most important part of the MCR is the "MCR hold active" circuit. This must be energised for the MCR to be in the active state... The MCR is very sensitive to loosing energisation on this circuit and will break the load circuits at the hint of a broken 'hold'... This 'hold' circuit has the Emergency Stop 'mushroom' buttons along it... these are normally closed switches, so that when you hit the button, they open and break the hold circuit, which causes the MCR to drop to its de-energised, "load inactive" state.

Obviously a power failure also causes the MCR hold circuit to de-energise, and the MCR drop.

And this is where I suspect part of the problem lies...

You see, currently there is only one sense line running from the whole EStop/MCR/Safety Relay setup to the PLC... and it monitors the state of the MCR. Within the PLC, it gives a logical 1 when the MCR is active and a logical zero when the load is dropped.

So, in the earlier software, where there wasn't any attempt to resume on power recovery, this wasn't an issue; if the MCR was dropped, it meant either that the power had failed or that the EStop had been pressed. In the event that the power has failed, there are two System Registers in the logic controller that can be monitored (one indicates a "cold start", the other a "warm start," where a warm start means that the pre-powerout state is properly preserved in battery-backed up RAM and a cold start means the state was lost). These registers are only set for one cycle after power is restored, but they provide enough information to let me program an "initialise MCR" capability in the control software and to have this be triggered either by a power-up event having occurred OR a Reset event having occurred after an EStop button has been pressed and subsequently released (the EStop mushrooms latch when they get hit, you generally have to do something, like turn them anti-clockwise a quarter turn to get them to un-latch).

So yeah, that's the old software... it works and there's no problems with the design of the electrical system if that is all the capability expected from the plant.

Unfortunately, we want to have a high availability plant... and that means it needs to be able to sit in a site that gets visited, say, once a week and run itself, dealing with minor hiccups (like power failures or transient faults) in a sensible way that will return the plant to operation.

Now we're closer to the problem... but its necessary to understand a little about the PLC too...

The PLC doesn't switch off immediately when the power supply is isolated.

There, that's all we need to know about the PLC, atleast its the pertinent information for now.

So, the crux of the problem....

When the power goes down, the MCR immediately drops the loads.

Unfortunately, because the PLC doesn't immediately stop processing, (and there are no documented ways to programmatically monitor the state of the power feed and therefore implement a "power lost" event handler), the PLC detects the dropping of the MCR state to logical 0 and decides that an EStop has been pressed. This, in turn, sets the "running" state to false. The plant then sits in the "EStop Activated" state, waiting for a Reset event until the transformer de-energises too far for the PLC to stay up (or whatever the reason for the non-immediate stoppage of processing is...). The 'resume on power return' code is triggered by ('warm start'=TRUE) AND (running=TRUE)...

Not quite sure how to deal with this situation... there are two possibilities:

  • add another sense line to the EStop/MCR/Safety Relay circuitry. This would be reasonably simple to add to the circuit; its just a case of adding a modular N/C switch to the back of the E-Stop switch assembly and having a line from the PLC input common to the switch then back to one of the PLC inputs (we have atleast two spares now that we don't have two flow sensors!)

  • or, work it out programmatically... I THINK its possible to change things enough for the power resume code to not rely on the 'running' variable, by introducing an 'active' variable... the 'running' variable is too intrinsically threaded through all the control software for it to be removed, but the 'active' variable should be reasonably simple to implement... it could be set to logical 1 when a Start event occurs and set to logical 0 when the plant completes its shutdown process. This would mean that ('running'=FALSE) AND ('active'=TRUE) => EStop... which should be enough to work the rest from....


-laughs- so, before I started writing this entry, I was pretty much convinced I was gonna have to revise the wiring... its amazing what trying to explain stuff can do!!! Now I have a way to not revise it! !!!YAY!!!

Edit: *smeg*, I still would need the sense line... i won't work programmatically afterall... it will still go into the EStop state, and things will still be ambiguous without the sense.... *SMEG*!!