Studio 5000: 3 Push buttons copies 3 different values to VFD...

[AutomationTechBrian]

This is what I was hoping for.... I'll explore this some more when I get home tonight. Chelton... I don't see how you're associating "3" with the value. Can you, or anyone explain that?

 

[I_Automation]

1- Check PB
2 - Set line as False
3 - Down to next branch

 

[drbitboy]

I don't see how you're associating "3" with the value. Can you, or anyone explain that?

The MOV in the fourth (last) rung uses the 3 as an indirect* address into the array Width_Actual[], where

• Width_Actual[1] = Actual_Normal_Width
• Width_Actual[2] = Actual_Wide_Width
• Width_Actual[3] = Actual_Custom_Width

This is what I was suggesting in an earlier post; it's extensible, and there could easily be several customs, with only one rung required for each.


I think this is what you have been asking for from the OP: the one rung, with the MOV at the end, is all that is required to actually load the value, instead of one rung per Actual_*_Width; there will always be one rung per PB to detect the press of course**

* or maybe it's "indexed?" I am not fluent with the jargon


** unless there is some fancy bit twiddling: The PBs could flip bits in a DINT (you suggested that option in post #4) that is used as the indirect address, and the indirect addresses with valid values*** could be 1, 2, 4, 8, ..., with all other address set to -1, and the last move is only performed if the value at the indirect address is not -1. So if someone pressed PB Normal and Custom at the same time, the DINT would be 1+4=5, and Width_Actual[5] would have been loaded with the value -1, and the final COP or MOV into VFD_Values[0] would not be done on that scan. Another way would be to only do the COP/MOV if there was only one bit set in the DINT; that way you would not have to set all the unused positions in the Width_Actual[] array to a known invalid value. Yes this wastes a lot of space in Width_Actual[], but memory is usually cheap.


*** Width_Actual[1] would be .005; Width_Actual[2] would be 0.011; Width_Actual[4] would be the current Custom value

 

[AutomationTechBrian]

Your code will rely on the HMI sending a 1 to set the bit then a 0 to reset on pressing/releasing of the button. I have always found it more reliable to use the HMI/scada to just send a value, then the PLC will reset the command.

This is another solution.

View attachment 55348

Your move at the end... I get it now. This is EXACTLY what I was looking for, but didn't know how to accomplish it.

I'm going to play with it a little, but I could see that coming in handy in several instances. It's so obvious, I can't believe I didn't see it this morning. Thanks!

I haven't finished looking at the other posts yet.

 

[chelton]

Good to here you have picked it up. @drbitboy did a good job explaining the concept.

 

[daba]

This is how I would do the job. The HMI buttons would be animated by the PLC tags, not the "button press".

On PanelViews, for example, a button has a "Value" connection, and an "Indicator" connection.

EDIT : Of course you could always use "Interlocked" buttons, but they have no "Indicator" connection, and you have no idea what is true in the PLC. Connecting the "Indicator" connection to PLC tags would give positive feedback of the current selection.

If you don't connect the "Indicator" tag to anything, the button animates from its own "Value" connection, which for a momentary button will only be true while the button is being pressed.

You can see from the PLC code that as soon as I see a "button-down" I immediately turn it off, creating a "one-shot" effect. This prevents the COP instructions from being executed thousands of times until the button is released (You only need to COP once !).