Prioritisation and lock blocks

If there are several commanding channels that command one or more jointly used commanded channels, their jobs - or more precisely their programs - compete to send jobs to the jointly used agent. The Job Manager determines the order of commands.

The job that has waited the longest for assignment is prioritised. An internal timestamp is used for this and is reassigned each time a new command is delivered for the first time. If they occur simultaneously, preference is given to the channel with the lowest configuration number ‘j’ in the parameter master[j].log_id of P-STUP-00206.
If the selected client cannot execute its command despite it being assigned (e.g. a job is placed in the agent queue - because the queue is full, for example), the client must wait. All other clients also wait. No reprioritisation takes place.
The wait can only be interrupted by an abort (MCV_GrpResetForced, MC_GrpStop), which is executed by preference.

In extreme cases without additional intervention, several active clients - i.e. several simultaneously running CNC programs - can result in the chaotic processing of competing jobs.

If this is not permitted and a commanding job requires exclusive access to the commanding sequence in "its batch", it can create a "lock block". The NC commands for this are:

#LOCK and
#UNLOCK

When the #LOCK command is executed, a client permanently blocks all other clients from sending their commands until #UNLOCK - or until the end of the client’s program with M30. The prioritisation described above is disabled for this time. This allows predefined job sequences in the queues of commanded channels and jobs in cooperating channels where their jobs/programs can be stored virtually "simultaneously" and deadlock-free in the agents.

Notice

The lock block only affects specific Job Manager commands. All other CNC commands continue to be executed regardless of this.

Notice

If no lock block is active, a newly commanded #LOCK command competes with all simultaneous commands in other commanding channels. The prioritisation rule described above applies.

Notice

A reset/stop command from any client is always enforced regardless of an active lock block. An active lock block is then deactivated.