Copy Setpoint to different tag

I feel like bowing out of this thread.

There has been an almost total lack of response by the OP to any of the suggestions made, or answer to any questions asked of him.

It seems to me that they are trying to use a human to do the job of a PID controller, and humans definitely are not good at that !!

Good job they've got a HiHi probe, just gotta hope it is wired fail-safe ......

Well I just can't resist offering another solution : disable the analog output channel if HiHi ....

But you will have to write a "Module Reconfiguration" CIP MSG instruction, fired each time the EN bit changes state, easy enough to do ...

OkiePC said:

Why not leave the setpoint alone, and just use the high level condition in the part of the logic that writes the command to the output point?

If not high, then write the setpoint, else write 0 to the valve command.

Click to expand...

+1. You don't change the SP, you change the output. This is considered shedding.

Phrog30 said:

+1. You don't change the SP, you change the output. This is considered shedding.

Click to expand...

Neither of you has grasped that the HMI is writing the setpoint TO THE PHYSICAL OUTPUT on the module.

That means that when HiHi is reached, and the OP wants to write 0 to THAT SAME PHYSICAL output, then both the HMI and his MOV will be writing to the same address.

There will be odd times when the HMI value will win, briefly ....

daba said:

Neither of you has grasped that the HMI is writing the setpoint TO THE PHYSICAL OUTPUT on the module.

That means that when HiHi is reached, and the OP wants to write 0 to THAT SAME PHYSICAL output, then both the HMI and his MOV will be writing to the same address.

There will be odd times when the HMI value will win, briefly ....

Click to expand...

Oh I grasped it!! Don't understand how you can't grasp this simple concept! This is very simple programming. I expected more from you Daba.

Oh OK, so you were agreeing with everyone else, that the way they have it configured writing the HMI value to the physical output is wrong in all counts. I got wrong end of the stick and thought you were suggesting a solution.

Although the OP hasn't said so ( ), we are assuming that he can't change the HMI to write to a different tag, then it would be an easy fix ....

EDIT : I've suggested an alternative cure, needs no external hardware, & no wiring changes, in post #32. It might get overlooked ...

For grins and giggles, this is what OP originally asked for.

The only difference with what OP came up with is that it will save a 0 valve position across an alarm if a 0 was sent from the HMI during a non-alarm time. It may also save a changed non-zero value sent from the HMI during an alarm state.


It is written for MicroLogix and uses O:0.3 as an analog output, when O:0.3 is actually 16 discrete outputs.

drbitboy said:

It is written for MicroLogix

Click to expand...

As you know MicroLogix "behaves" in terms of outputs being written AFTER the program scan. It's easy to "assert", although it makes code position-dependant.

Your post may just add fuel to a fire that shouldn't have started in the first place ...

PS did you see my post #32 : doesn't need an alternative output channel or any external relays, or whatever, just a bit of code to disable the channel ....

We still don't know whether said tank (we know it's a water tank) feeds water to his processes (which he said are shut down on HiHi), or the "processes" effluent water to the said tank.

Shutting down his "processes" because an effluent water tank has gone HiHi seems a bit strange, just divert it to the drains.

Shutting down his "processes" because a source (buffer) tank has gone HiHi just makes the situation worse - plenty of water to deliver to processes he shuts down.... doesn't make much sense ...

Poor-man's control strategy, IMHO

Here's my case, can I rest it here ....

But his last post #26 infers he's not coming back ....

There's no emoji for :sigh:

daba said:

As you know MicroLogix "behaves" in terms of outputs being written AFTER the program scan. It's easy to "assert", although it makes code position-dependant.

Your post may just add fuel to a fire that shouldn't have started in the first place ...

PS did you see my post #32 : doesn't need an alternative output channel or any external relays, or whatever, just a bit of code to disable the channel ....

Click to expand...

agreed, those are all better solutions. And I like our re-wired hardware approaches even better.


This one answers the original query though, how to not lose the cached value during the alarm.


Although I dunno, this does not seem that difficult to me, so sometimes I worry that by providing answers we are only encouraging folks to go deeper into the weeds on their own when they don't even understand proportionality and scaling, and should probably be contracting professionals, which would actually be more economical. Btw, I am referring to the programming queries here. The other stuff, like "export to .l5x, edit line XYZ, stand on your head until all the change falls out of your pockets, then re-import," I mean, that is just outrageous that the OEMs allow such brokenness in the industry. But in the end it's like the dog on the bicycle at the circus: it's not that it rides so well, it's that it rides at all.

daba said:

But his last post #26 infers he's not coming back ....

There's no emoji for :sigh:

Click to expand...

This forum is not about the OPs.

drbitboy said:

This forum is not about the OPs.

Click to expand...

OP obviously thinks he has solved his problem, not the problem.

He has a tank going HiHi, shutting down processes because of an operator entered set-point ????

How does that equate ?

And leave it up to the operator to release the HiHi lockout whenever he feels like it ???

How does that equate ?

Makes you wonder why they put a PLC in there in the first place ....

daba said:

Makes you wonder why they put a PLC in there in the first place ....

Click to expand...

LOL, that's what I mean. Any idiot can learn to program (heck, look at me); understanding the process is where the added value is.

I appreciate the structured criticism and feedback

I do understand the process & thanks again for helping