Where to put programmed stops

Good Morning All,

I am trying to figure out where I should place a series of triggered stops. I have a set of conditions that when met, will stop the machine from the gateway side. As of right now, our operators can ignore the ignition components and clear their counters on the machine side. For very obvious reasons, I want to make sure that they are unable to do this. I have a good idea on how to handle the PLC side, but I am leaning towards a gateway script for this?

Here are the very rough outlines of how I plan to create my conditional stops.

#Unique processes to stop gages
if WIP_ID_HEAT =/= LAST WIP_ID_HEAT    #HAPPENS ON WIP SCAN
	MES.HOLD = True    #TIED TO THE E-STOP FUNCTION TO HALT THE MACHINE
	AGR_FULL  = True 
	SKID_FULL = True
	OPEN 'Pop' SHORT_TOTE_PRINT
	OPEN 'Pop' SHORT_SKID_PRINT
if WIP_ID_PART_NUMBER =/= LAST WIP_ID_PART_NUMBER    #HAPPENS ON WIP SCAN
	MES.HOLD = True
	AGR_FULL  = True 
	SKID_FULL = True
where SHORT_TOTE_PRINTED = True    #HAPPENS ON SHORT TOTE PRINT
	SKID_FULL = True

#Common processes to stop gages ALL PREDICATED ON TAG VALUE SCHANGE
where BATCH_FULL = True						
	MES.HOLD = True
where SKID_FULL = True
	MES.HOLD = True
where AGR_FULL = True
	MES.HOLD = True

All tags except for the MES.HOLD tag are pointing to created ignition tags.

1 Like

I’m thinking the best way might be through a UDT tag pointed at a bit to toggle on the machine’s PLC. Use an expression to check the state of a few other tags to toggle the stop on or off. Anyone have any advice from some time they did something similar at their workplace?

1 Like

I might be confused, but are you using the SCADA/HMI to control machine operation?

Maybe a bit more detail would offer you more help.

2 Likes

I see “scripting” mentioned in the original post. It also questions “where” to put triggered stops. If you have existing views that are aware of the “machine counts”, perhaps you could put your (“program stop” logic) in a view’s script-event, like valueChanged, and check for conditions like . . .

if AGR_FULL == True:
	# code here to stop machine
if SKID_FULL == True:
	# code here to stop machine

Am I on the right track here?

1 Like

Machine control must not depend on a view or window being open in a client. Unless there’s a heartbeat to stop the machine if the client isn’t on that view/page or window. Any control-like operations should be in gateway scripts/SFCs, or better, in the PLC itself. User interfaces should only provide events to command the process (start/stop/setpoint/recipes) which can then carry on with just the gateway (or just the PLC).

5 Likes

The OP mentions that “operators can ignore the ignition components and clear their counters on the machine side”. That statement sort of implies that these “counts” already exist in a view’s UI. Being somewhat new to Ignition, I thought maybe it would be easiest to have script(s) (nestled in with and close the actual counting logic on the view) that send the “machine stops”. Anyway, you make a good point. I’m mainly trying to get a clearer definition or more direct question from the OP

1 Like

Machine control from HMI is most of the time a bad idea (at least in my experiences). Aside from the points @pturmel suggested, it’s also harder to troubleshoot. Let the PLC do what it does best. If the PLC needs input from the HMI, then use a state machine and handshakes.

1 Like

The plan was to have the machine be unable to resume running until they press a button on a display unique to each group of machines. The reason I was going that direction was to guarantee that as a batch is done, they press the button the collects the batch data and prints a tracking label.
I am starting to think that it would be easier to have the triggers I need them to press be sent from the machine, rather than require the operators to go through two separate processes. Functionally speaking, it should be easier for everyone involved. Is the way I would go about this would be to have a gateway script? I was thinking that an expression tied to the status of a tag (true/false, etc.) would be a pretty solid way to go about it.

Ok, so the process is “run until complete”, presumably where Ignition can see some status in the PLC that indicates “complete”. Use that to enable the batch data capture/print buttons. Include in the print button a write to the PLC that signals to reset the “complete” status to allow the next run. Don’t allow anything else to reset that status.

2 Likes

Exactly, but I have 27 identical machines that I would need to change the HMI program for to remove their complete button. Is there any reason I couldn’t tie my logic to the operation of the machine’s button?

1 Like

I don’t see how you can satisfy your desire that the machine not be able to cycle again without printing from Ignition if you don’t change the PLC and/or HMI code. Sorry.

2 Likes

I figured that would be the way it ended up, I needed more practice programming PLCs anyway! Thanks everyone!

1 Like