question

There may be a better answer than this, but if the transporter is in the middle of moving a pallet from one point to another and their shifts end, I would think the operator would finish the task and then leave. If that is the case, you could give the transporter a task sequence that incorporates a stop task. When sent to the transporter, they will finish up their current tasks before starting your tasks that tells them to stop.

If you look at the Time Table's Down Function pick options, there is an option for Travel to Location/Object, Delay Until Down Time Complete. This shows how that would be accomplished. In those options the transporter isn't stopped, rather it's delayed, but the code cold be easily modified to change the task type.

Alternatively, if you're using process flow to handle all of the transporter logic, you could have the Down Function do nothing and then have a Event-Triggered Source listen to the Time Table's Down Function and do a similar thing within process flow. Or perhaps just notify another token that the stop has been initiated.

If my first assumption is incorrect and they would instead not start a new task right before the shift is over, that's a bit more difficult. You would have to determine what the criteria is for not starting a task close to the end of the shift. Whether this be time or based upon how far the pallet has to move etc. In this case you would need to add a check to where ever you give the transporter transport tasks and see if there is enough time to perform the task before dispatching the tasksequence.

Hopefully this helps!