I am using Ignition version 8.1.1 and I am using Vision.
I have a ‘Start A Run’ button that takes the operator to a screen for inputting information for a run on a machine. Once the operator pushes the ‘Start Run’ button, the button ‘Start A Run’ on the main side menu needs to be disabled. That I can do in a few ways. The problem I have is that once the run is finished, the ‘Start A Run’ button needs to be enabled again. This is where things have gotten tricky.
I had it working based off input into the fields the operator input on the Start A Run screen. However, that does not work as the operator may need to leave the screen to change a setting on another screen and then come back to the Start A Run screen. How I had it based off the input fields meant that once they input into a certain field, the ‘Start A Run’ button disabled and they couldn’t get back to that screen if they needed to.
I have tried creating an internal (to Ignition) tag that I wrote a 1 to when the ‘Start Run’ button was pushed but I can not figure out how to get that to change to a 0 when the run is finished.
I need a way to make this work the way the customer wants it to. Does anyone have any relatively simple ideas?
What decides when the cycle ends? There could be a few ways to approach it. Either could use a timer or gateway script to lower it on an interval, or if you move the tag to the device the PLC could potentially reset after a cycle.
Or if there is some sort of in cycle tag for the device, you could reset it on a value change of that.
I have a tag that changes from 0 to 1 when a run is finished. Is it possible to get get the one tag to change the other tag’s value?
Yup, if you open tag properties you should be able to setup an event script that will run on Value change. You can put in validation to make sure the value is changing to the appropriate value and then have the script lower the tag to enable/disable the button.
Do I set the Tag Change Event Script on the tag that will change the other tag or the tag I want to be changed? Also, how would that look? I’m assuming it would not be an If(…) statement.
If i understand correctly, you can do this with two tags, one to indicate the cycle is complete, and one to bind to your button’s enabled property.
On your button choose an event to bind to disable your button:
Then create a tag change event on your cycle tag to re-enable:
You will want it on the tag that changes when the cycle ends.
as for a rough example, you can find some decent ones in the manual to get you started. But yeah it would be an if statement to check the value is what you expect, and then just a system.tag.writeBlocking() call to write to the other tag.
On my ‘Start Run’ button I have 2 tag changes for the PLC (it resets the values), the tag value change for my input lock, and my screen swapTo. My input lock is set here as
value = 1
system.tag.writeBlocking('[default]Start/Input_Lock_A'], [value])
Then on my tag for the run being over I have
On Tag Event Script, on Value Changed
If currentValue.value = 0:
system.tag.writeBlocking("[.]Input_Lock_A", 0)
Ignition says there is something wrong with the line “If currentValue.value = 0:”
Any ideas?
I think you need == instead of =.
That seems to have been part of the problem. I changed it to
If (currentValue.value == 0
system.tag.writeBlocking("[.]Input_Lock_A", 0)
and now Ignition is unhappy with the second line. Any ideas on this?
You need to be using the right syntax. Python Syntax
If currentValue.value == 0:
system.tag.writeBlocking("[.]Input_Lock_A", 0)
All this talk of scripts, why can’t you just bind the end of cycle and/or run tag(s) to the enabled property of the start a run button? If the operator navigates away, a script will not fire. Properties that should be based on the states of tags should be done using bindings, not scripts.
For example, Button enabled expression binding:
!{running} &&
{cycleFinished}
I actually like your solution better, but can you elaborate on this?
I would have done this In the PLC, but the OP requested it via Ignition.
Ok, I’ve had a better read now and I was a little premature with my comment (although it still stands).
So in essence, you have:
- a button to get the ball rolling on starting the process, ‘Start A Run’. Once clicked, a run configuration panel is shown and this button is disabled until either the configuration of a run is cancelled or the run has started and then stopped/completed (assuming you have a PLC tag for machine running status)
- some configuration fields with run parameters/setpoints/etc. and then a ‘Start Run’ button to actually start the machine.
For something like this, I would:
- create a custom property on your Window root container,
configuringRun, to store the “configuring a run” flag. - on the Window startup event handler script, set this flag to
Falseso that it’s force-reset each time the window is navigated to. You might also want to reset the run parameter values as well, in which case it might be good to create a function to do this so you can call it whenever you need to reset the values and cancel the configuration. I would create this on the Window root container. - set the
configuringRunflag toTruewhen you click the ‘Start A Run’ button. This is the only action for this button. - set the enabled condition of the ‘Start A Run’ button to:
!{Root Container.configuringRun} &&
!{Root Container.machineRunning} //<-- see below
- show the configuration panel when the
configuringRunflag is true. - create another custom property on your Window root container,
machineRunning, and bind it to the machine running tag. On the Window’s onPropertyChange event handler, use this script to monitor this tag and reset the flag/run parameters when it goes off:
if event.propertyName == 'machineRunning' and event.newValue == 0:
event.source.configuringRun = 0
This is basically how I had it originally that the engineer on the PLC didn’t like. However, after talking with him some more, he now wants it this way again.
I say “basically” because we have an input for number of items to process. My original lock for the ‘Start A Run’ button was that if the tag for how many items to process was greater than 0 then the ‘Start A Run’ button was locked out. The PLC engineer didn’t like that originally because he didn’t want the button locked out (disabled) until the ‘Start Run’ button was pushed. We don’t actually have a tag for {running} or {cycleFinished}, just weather or not there is a number of items to process.