studio5000 can osr and osf of the same bit share a storage bit?

[Bobobodopalus]

Just wondering if i can make my code look a little nicer and sharing storage bits like below
https://imgur.com/a/SMNxOPu

does this work or does it need separate storage?

 

[plvlce]

That would cause multiple issues, and I believe the second instruction would be essentially nonfunctional.

Let's consider how your posted example operates:

Prescan -- The OSR clears its output bit, then sets the storage bit 'true' to prevent trigger during first program scan. The OSF then clears its output, but sets the storage bit 'false' to prevent a trigger during first program scan. This invalidates the OSR's invalid-trigger prevention.

Transition from rung-in-false to rung-in-true: The OSR is evaluated and both output and storage bits are set 'true'. The OSF is then evaluated and sets the storage bit to 'true' and its output bit to 'false'. On the following scan the OSR's output bit is set false since the storage bit is already true.

Transition back to rung-in-false: The OSR is evaluated and sets both output and storage bits to 'false'. The OSF is then evaluated and because the storage bit is already 'false' (just set by OSR) it does not see this as a transition and sets its output to 'false'.

Looking at the conditions above, we can see that the OSF will never have a 'true' output.

tl;dr oneshots rely on their storage bit being in the state they last left them to detect transitions, if you re-use them in any instruction that can alter their state then they may no longer function properly.

 

[Bobobodopalus]

Ok thats fair, i suppose i thought the storage bit was reliant on the input rather than the output

 

[plvlce]

Ok thats fair, i suppose i thought the storage bit was reliant on the input rather than the output

The storage bit is set based on the input. But the output is set when it transitions from false to true (OSR) or true to false (OSF). Since it will transition when the first instruction runs, the second will always see it as having already transitioned, just as normally happens in subsequent scan cycles with a single instruction.

 

[I_Automation]

What I have seen done with storage bits, that initially was confusing until I found out the reason behind it, was every HMI PB check in the program used the same storage bit. But these were all OSR's.


This would set the storage bit when ANY PB on the HMI was pressed and not release the storage bit until ALL PB's on the HMI were cleared, so no pushing 2 buttons at once or a second button before taking a finger off the first button.



Not a fan of that method, as sometimes checking the storage bit that is only used once helps in trouble shooting.

 

[plvlce]

What I have seen done with storage bits, that initially was confusing until I found out the reason behind it, was every HMI PB check in the program used the same storage bit. But these were all OSR's.


This would set the storage bit when ANY PB on the HMI was pressed and not release the storage bit until ALL PB's on the HMI were cleared, so no pushing 2 buttons at once or a second button before taking a finger off the first button.



Not a fan of that method, as sometimes checking the storage bit that is only used once helps in trouble shooting.

Don't think I'm a fan of that but I can see it working, most HMIs I've seen (and touchscreens in general) don't seem to support multiple locations being pressed at once in the first place.

In that case it seems like the extra oneshots failing to work after one is made is a feature of the program as designed.

N.B. that would be having different input conditions for each oneshot, unlike the example OP provided which used the same input conditions for multiple instructions resulting in all but the first one being always nonfunctional.

 

[drbitboy]

But the output is set when it transitions from false to true (OSR) or true to false (OSF).

To elaborate:


PLC programs execute instructions sequentially in time, left-to-right and top-to-bottom in time, scan after scan in time.

The OSR and OSF instuctions cannot happen at the same time, so, when the input bit has an edge, only the first of those instruction will use the memory bit in it's correct state.

It could be done in a single AOI instruction, of course:

​

or even

​

which is nearly equivalent to the other approach.

However, both approaches would still have the first-pass initialization problem that @plvce elaborates; whether that is a problem depends on the application.

-

 

[I_Automation]

most HMIs I've seen (and touchscreens in general) don't seem to support multiple locations being pressed at once in the first place.

Actually a lot of newer HMI's support multiple button use. And most touchscreen monitors running iFix, AHMI, PanelmatePC, etc generally support multiple presses.



One on a machine I had to help with installation, that came from Taiwan during the lockdown and their installer could not come here, had some of the HMI buttons requiring a separate ENABLE HMI button to be pressed first then being held while the Jog, Raise or Lower buttons were pressed, not like robot teach pendants or older control panels with a physical ENABLE button nearby.


A lot of HMI's use 2 corners to get into service or comm's mode, so 2 buttons would be usable.

 

[plvlce]

Actually a lot of newer HMI's support multiple button use.

Well that would explain why I haven't seen much of it...

 

[I_Automation]

Well that would explain why I haven't seen much of it...

Been there.


Lovely to work in a shop where the newest machine (or component) was from 1985.