jlofft

Thanks for the input everyone. Flex727. The coil in question is the last coil in the second picture "N2 Purge Ready." Essentially, is it possible the Positive Transition Coil for the HMI input to get stuck in the off setting since the button becomes invisible and thus is never checked again for the return to off state (HMI button is always true since it never "resets") Would a Positive Transition Contact resolve the issue discussed here? Seems like it would if the question above is false. Ausman. Yes, this is something I definitely try to be aware of when writing these because it's happened in previous code (probably to everyone). I would love to be able to simulate and test-play, which is why it would be absolutely fantastic if Unitronics ever develops a simulation program because the amount of IO and wiring that needs to be installed/bypassed to test even these smaller aspects (invisibility and state transitions, as this programs required X,Y,Z to happen before states can move forward) can be significant time sinks. It's also a little disappointing that Unitronics doesn't have a "momentary push button" option which is what the set/reset logic is supposed to emulate, and is virtually standard throughout all programming libraries except Unitronics. But, it looks like they sort of get around this with the Positive Transition Contact, however, it's far less than ideal. I chose Unitronics on this project because of its smaller scope and features that come built-into the HMI, and would definitely use it again. But, ff I were doing something mission critical or needed to do significant prior testing I would probably use a software that had simulation tools so I can test out various aspects of the buttons, etc. Thanks for the input everyone.

Hello, Thanks for the response. With regards to this "It absolutely does (if you coded the button correctly), but with a direct contact instead of a positive transition contact, it can execute many times (maybe hundreds of times) before the reset occurs because of the time it takes to remove your finger from the button." The contact is staying "true" even after the press has been released, so when the process restarts, it zips right past this section. Now there may be one aspect that is causing this: the visibility of this button is linked to the "N2 purge ready" coil on the line above it. If this button is pressed it would move to the next state and thus the button on the HMI Button becomes invisible. Does this keep the PLC from evaluating the button state? "what keeps the PLC from doing what it's doing here and just just not to turn it off?" Sorry, this was worded poorly. Would a positive transition contact be subject to the same issue due to invisibility (if this is the cause?). When the program transitions to the next state and the button becomes invisible, If the PLC stops evaluating the button state (N2_HMI_READY) and thinks it's permanently set is it possible the positive transition contact gets stuck in the off state (since the HMI button doesn't et reset) and I have the opposite issue. Thanks for the responses, I do appreciate it.

Hi Flex727, The "positive transition contacts" suggestion in the OP actually came from a few of your older posts. First question: Why doesn't the current logic work? As in, why doesn't it reset? And with the positive transition contacts. I imagine the "Set" from the HMI is just like a latching input, so does the positive transition contact provide the "unlatch" portion as well. I see how it would work, but I like to try and understand why /how certain functions work. A better way of putting it, the positive transition stays on for one cycle when the input goes hi, what keeps the PLC from doing what it's doing here and just just not to turn it off? Lastly, with the "positive transition contacts" I assume I can remove the reset part of the button. Thanks for your help

Hi Isakovic, Thanks for the reply. I'm posted a few pictures of the actions in question. One of the buttons that does this is the "HMI_START_N2..." As you can see it's setup as a Set/Reset. The second picture shows where/how this logic executes. The issue is the reset never seems to occur. This subroutine "pre-oxidation start" is called continuously also. So it looks like unilogic just stops executing the second "reset" command. I've had other buttons do this as well with the set/reset setup and the way I've gotten around it, as stated in the original post, by using a not-output to clear them when the process completes So with this, I seem to be missing something on how unilogic executes the HMI commands vs. standard IO. Any other IO would have been false, but this stays true.

Hello, I'm having some issues with understanding how Unitronics integrates the HMI inputs to the PLC inputs. This is a vague start, but I have a state machine going (this project is essentially done and I've made it through it with some work-around), that requires user input to move from one state to the next. I am currently using the Set/Reset on the HMI buttons but many of the buttons seem to get stuck in the ON state (the program has moved to the next sub-state in the program), even though the logic is no longer true. Why does it do this? I see suggestions in the forums about using the positive transition input, but how does this interact with the "Set bit" function of the HMI button? Does the HMI button reset? Here's an example of the program: Subroutine 1 State 1 Stuff happens User pressed HMI button to move to state 2 (ON) subroutine state = 2 State 2 Stuff happens And this is where I get a little confused on how this works because the User input to move to state 2 from state 1 will stay ON instead of resetting. I've gotten around this my simply resetting everything (not-output to reset the HMI button) at the end of the process sequence , but this seems gimmicky Thanks for any input