OSF output not being caught ...

I am using MicroLogix 1200 and PanelView C400.

I have a button, "Start" that should start and run a motor for 5 minutes on the PanelView. Presently, this button is a latched pushbutton.

I am trying to tie the handshake bit, which should unlatch it, to the output bit of an OSF instruction that has the /DN bit of my timer as an input.

In my mind, this should unlatch the button when the timer expires. For the life of me, I cannot figure out why this isn't working. If I'm understanding correctly, the OSF instruction should see the timer ACC reach PRE and, therefore, the /DN bit should transition from high to low. This should cause the OSF instruction to set a bit for a scan cycle. This bit, which is my handshake bit, in the HMI, should unlatch the button. It's not ... any guesses?

..the OSF instruction should see the timer ACC reach PRE and, therefore, the /DN bit should transition from high to low..

Click to expand...

This should cause the OSF instruction to set a bit for a scan cycle.

Click to expand...

based on that statement, you already know what the problem IS - but you just haven't recognized it ...

let's paraphrase your statement ...

This should cause the OSF instruction to set a bit for JUST ONE SINGLE scan cycle.

Click to expand...

here's what's probably causing your problem:

ONE single scan is not long enough for most HMI devices to "see" ...

remember that you're dealing with MESSAGES between the PLC and the HMI - and that these messages must take place over some type of communications link ... it would be VERY rare for an HMI to be able to "catch" a change in a bit's status which only lasts for one single scan ...

suggestion: temporarily take the OSF out of the equation for a test ... then toggle the handshake bit yourself ... does the system work that way? ... if it does then you'll need to come up with a way to use the handshake which doesn't involve a "one-scan window of opportunity" for the HMI to "see" the bit's status ...

if these ideas don't help with your problem, consider posting your program code and we'll try to help you out with it ...

now going further ...

many experienced HMI programmers won't use the Latched buttons – or even the Maintained contact buttons either ...

the reason is that sometimes there is a communications loss between the HMI and the PLC ... in some cases this can turn into some EXTREMELY serious (lawyer-level) problems ...

ask yourself:

suppose that my operator has used an HMI button to turn a pump/valve/motor/etc. ON ...

now suppose that the HMI dies – or loses power – or the cable gets broken – etc. ...

big question: how will the operator be able to turn the device OFF? ...

the way that most beginner programmers write their programs, there isn't going to be an easy answer to that question ...

what it all boils down to is that many experienced programmers will only use Momentary On buttons for their HMI devices – and then they program the PLC logic to make use of those "buttons" to handle situations where the HMI can no longer be counted on to properly control the PLC's internal bits ...

here's a story just to frame this part of the discussion:

I saw an application once where the HMI had about forty screens – and MANY of those screens had MANY buttons ... every time the power to the building would flicker, the operator's standard operating procedure was to go through the entire HMI application – screen by screen – and press and release EVERY button ... due to the way the program had been written, this "cycling of the buttons" was the only way to get the HMI and the PLC back "in synch" again ...

the truth is that all of those fancy types of "buttons" that are available with most HMIs work just fine under "shop" conditions when the programmer is setting them up ... but ... when you start considering how they'll work in actual "field" situations involving a power failure – or a cable disconnect – or a "stuck" button on the touchpanel – or a dead HMI - etc. - well then the programming needs to be a lot more "robust" than most beginners shoot for ...

going even further:

are you planning to use a "heartbeat" signal - or some other way for the PLC to tell whether the HMI is properly up and running? ...

many experienced programmers use something like this to have the PLC automatically turn certain outputs off in situations where the HMI is suddenly "out of touch" ...

in most applications there will be SOME of the field outputs which need to remain in their last states when the HMI drops out – but OTHER field outputs really should be automatically turned OFF until things get sorted out again ...

Has anyone told you guys, lately, how awesome you are?

That's exactly what I'd figured - that the single cycle wasn't sufficient for the HMI.

I'll switch, per your cautionary tale, to a momentary press and use the /DN bit as an indicator tag to have the button display as though it were pushed. Any challenge with having the HMI access T4:0/DN, directly, as a tag, or should I set up an intermediary?

as long as the HMI can address it, there shouldn't be anything "wrong" with using the Done bit directly ...

but ... even so ...

many experienced programmers will "pack" the data into one or more consecutive words (integers or binaries) so that the HMI can make just ONE (single) "read" or "write" operation – instead of having it "hunt and peck" for specific bits which would otherwise be scattered throughout the processor's data fields ...

the basic idea is to have the "messages" transfer the data more efficiently ... for bigger projects that might be a distinct advantage ... for smaller projects it might not be worth messing with - except as experience for future use ...

Should anyone else run across the same, apparently the HMI cannot directly access the timer /DN bit. I tried several attempts and all failed. But, simply tying the /DN bit to an OTE and using that as the indicator tag worked flawlessly.

gregmmurray said:

Should anyone else run across the same, apparently the HMI cannot directly access the timer /DN bit. I tried several attempts and all failed. But, simply tying the /DN bit to an OTE and using that as the indicator tag worked flawlessly.

Click to expand...

Yeah, those cheeasy off brand HMI drivers are pretty weak. I once used a numeric input device with up/dn arrows that could only write six 32 bit integers to N7:0 through N7:23.

In your case I would also investigate how the first word of the timer element is addressed. It may be a word/bit number you need in the C400.

I am one of those guys Ron mentioned who uses momentary buttons in the HMI and then only uses the rising edge or otherwise unlatches the action in the HMI.

If you choose to use the rising edge or one shot rising instruction with HMI buttons and then the HMI button does get "stuck on" due to lost communications, when comms come back, it may take an extra button press to get the HMI to trigger the next rising edge.

If you don't like oneshots and want the most user friendly answer, then use a timer to limit the duration of the button press event. Seal in a timer with its TT bit and use the TT bit where the button would be in the rest of the ladder. If you want the button press to last 1 second no matter how long it really lasted so you can see it when troubleshooting, then this is the best answer.

If the button gets tied down, the TT bit will go off, the DN will stay on...easy to see and work with, at the expense of a tidy little TON. This also keeps people from short cycling your button driven devices to death. I have one operator who can hit a hardwired robot reset button 13 times per second...yes I measured it...

Should anyone else run across the same, apparently the HMI cannot directly access the timer /DN bit. I tried several attempts and all failed.

Click to expand...

I'm not familiar with your model HMI, but just as an experiment, you could try using T4:0.0/13 for the Done bit ... I seem to remember one brand of HMI that would accept a syntax along those lines ...

to be honest though, I'd probably just use rungs in the PLC's ladder logic to "pack" the data as I mentioned in an earlier post ...

if you've already got something that works, I wouldn't waste any time on the "done bit" syntax - it's just an experiment to try for kicks ...