Where to put programmed stops

General Discussion
1

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
2

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
3

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
4

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
5

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
6

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
7

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
8

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.

9

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
10

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
11

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
13

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

1 Like
15

Our end solution was to utilize gateway scripting and an external data source (we used a server side database to keep hands away from our counts), it receives the input from the OPC tags, conducts a machine ā€˜stateā€™ evaluation. Using this method allows for unique instancing, weā€™ve also started to tie these into other functionality. Thanks to @pturmel, you had me pointed the right direction from the start.

2 Likes