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

[AutomationTechBrian]

In many ways, I'm still stuck in Logix 500 mindset. I'm just trying to think out of my box, and you guys are the best source for different ideas.

So here's the thing I'm thinking about tonight...

Instead of one size programmed into the machine, I'm adding 3 sizes, with 3 push buttons on the HMI: Normal, Thick, and Custom. The custom has a value entry box. Right now, my thought is 3 ladder rungs, with a combination of 3 XIO and XIC bits to make the lines mutually exclusive, and a copy function after that on each rung that copies the Real number into the 2 Integers designated for that value in the communication going to the VFD. It's very basic thinking, and it makes me feel there should be a different way to look at this. ...maybe using just one rung?

Anyone have time to share their thoughts? I'll start working with the above plan, but I might change it if we come up with something better. (I'm installing the upgrades on Tuesday)

 

[cardosocea]

Different IDE doesn't mean that problems are solved differently in the same language. The simplest way I can think of a solution to this is to group all three rungs into a single rung with 3 parallel branches so that the entire logic for the speed is enclosed in a single rung.

Additionally, I'd make sure that the buttons get disabled until the machine is stopped, but I suppose you looked into that and it's not related to this problem.

 

[drbitboy]

I recently saw a post about recipes, that might be worth researching.


Also, since this is only one number, the values could be placed in three positions in an array, and the HMI button for each mode of operation (Normal, Thick, Custom) sets the index used to select which value from the array is copied to the integer, which is done with one rung. So there is only one integer to control instead of three discrete bits.



Bells and whistles:


In this approach it is painless have several custom spots in the array, so the operators have the flexibility to build a library of custom values, instead of having to check logs for what is used for a custom product, and a custom value that comes up more frequently could be left in its spot until is is made permanent with changes to the program.


Also, adding new default values (e.g. "Thin") to the array is a little simpler: increase array size (maybe); add the new value to array; update HMI. No rung changes are necessary. For that matter, if there are several custom slots, perhaps a frequently used custom value is moved to the first custom slot and only the HMI is changed to make (declare) that slot a non-custom value, with no changes to the PLC program (other than updating the array in the backup copy). In the one bit per value case, a new default value requires adding an XIO to existing rungs plus adding another rung.

 

[AutomationTechBrian]

I recently saw a post about recipes, that might be worth researching.


Also, since this is only one number, the values could be placed in three positions in an array, and the HMI button for each mode of operation (Normal, Thick, Custom) sets the index used to select which value from the array is copied to the integer, which is done with one rung. So there is only one integer to control instead of three discrete bits.



Bells and whistles:


In this approach it is painless have several custom spots in the array, so the operators have the flexibility to build a library of custom values, instead of having to check logs for what is used for a custom product, and a custom value that comes up more frequently could be left in its spot until is is made permanent with changes to the program.


Also, adding new default values (e.g. "Thin") to the array is a little simpler: increase array size (maybe); add the new value to array; update HMI. No rung changes are necessary. For that matter, if there are several custom slots, perhaps a frequently used custom value is moved to the first custom slot and only the HMI is changed to make (declare) that slot a non-custom value, with no changes to the PLC program (other than updating the array in the backup copy). In the one bit per value case, a new default value requires adding an XIO to existing rungs plus adding another rung.

I was thinking about this as I was driving today. I think what I'm searching for is a function that ties one array value with another...

DINT 001 (1) - Real .005
DINT 010 (2) - Real .011
DINT 100 (4) - Real (Value entered on HMI)

When A= 1, Move .005 into B... etc.

I can tie this into button colors, as well.

So... I'm just trying to understand how to do this in a "Studio 5000" way.

 

[drbitboy]

Are the PBs momentaries?

 

[daba]

Are the PBs momentaries?

A simple question, but one which opens up a whole bunch of others.


The HMI makes the selection, and that is simple enough to program in the PLC, but what happens if the power fails, how does the PLC recover ?


I can't see anything wrong with a simple XIC HMI_button MOV value to destination scenario, the destination will be retentive, so should recover from a PLC restart without change.

And that is how it should be in 100% of cases IMHO, the HMI simply commands the PLC to adopt a stance, and that stance should be retained whatever happens.

I have never advocated the use of latching or toggle buttons on an HMI, they impose a level of "control" that should be in the PLC

 

[AutomationTechBrian]

Are the PBs momentaries?

Yeah, that's the only way I could see having three buttons that can be independently selected... with the active button changing from gray to green.

 

[AutomationTechBrian]

A simple question, but one which opens up a whole bunch of others.


The HMI makes the selection, and that is simple enough to program in the PLC, but what happens if the power fails, how does the PLC recover ?


I can't see anything wrong with a simple XIC HMI_button MOV value to destination scenario, the destination will be retentive, so should recover from a PLC restart without change.

And that is how it should be in 100% of cases IMHO, the HMI simply commands the PLC to adopt a stance, and that stance should be retained whatever happens.

I have never advocated the use of latching or toggle buttons on an HMI, they impose a level of "control" that should be in the PLC

I understand what you're saying. After all, I wear two hats: programmer and technician, and there is a difference. But this is the place to experiment. I created this program... it's my baby.

Default value will be 001, Normal width. (It's a un-winder, winder application)

 

[AutomationTechBrian]

I just finished dinner. I'm going for a little walk and then starting in. I'll install it tomorrow morning.

 

[daba]

Yeah, that's the only way I could see having three buttons that can be independently selected... with the active button changing from gray to green.

The "active button" ???

Momentary buttons on an HMI are only "active" when someone presses them.

All the HMI interfaces I have ever done will OTU the HMI button inputs when seen in the PLC. No timing interferences, no overlaps, simply rising edge of a pushbutton makes the change ....

Indication of the current selection or mode should not be indicated by the button states.

 

[AutomationTechBrian]

The "active button" ???

Momentary buttons on an HMI are only "active" when someone presses them.

All the HMI interfaces I have ever done will OTU the HMI button inputs when seen in the PLC. No timing interferences, no overlaps, simply rising edge of a pushbutton makes the change ....

Indication of the current selection or mode should not be indicated by the button states.

Yes, "active" button. This is what I've settled for. I get an active button by means of a seal-in. This style is the same ole controls I would have programmed into a SLC 500... I wish I could come up with something better for the last three rungs.

 

[AutomationTechBrian]

Here are the 3 Test Buttons:

 

[janner_10]

You can tidy it up by putting the COPs on the end of the first 3 rungs and you dont need the last 3 rungs.

 

[chelton]

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.

 

[I_Automation]

Yes, "active" button. This is what I've settled for. I get an active button by means of a seal-in. This style is the same ole controls I would have programmed into a SLC 500... I wish I could come up with something better for the last three rungs.

One thing I got in the practice of doing (with SLC's & PLC 5's) is putting the Most Common On item on the first line, then the less common on items on branches below.

In your lines 1-3 the HMI PB is only on maybe 6 times a day, while the Normal_Width is on for millions of scans.

On CLX the entire rung is processed, but on SLC's, PLC-5's, Omron, Mitsubishi, Panasonic and other PLC's if the first line of the rung is TRUE then the branch is not processed at all.

XIC PB NXB XIC Tag BND vs XIC Tag BND is 3 less steps per scan, multiplied by how many hundred rungs can be programmed that way does make a difference in scan time - and it can be significant for a SLC.