Gantry Issues

In several MANZ's applications, gantry systems (pair of parallel axes) are implemented as master slave pairs. Where master is a part of a bigger (XYZ) group and each of the group's axis can be a master to a different slave axis. The whole issue can be exteneded to any group of geared axes that are moving together one physical object.

Problems:

Problems occur when due to asymmetrical engagement of the system either by different stopping starting or mechanical non-symmetries.

1.) Motors are directly working against mechanic and possible mechanical breakage/damage can occur.

2.) The systems forms a mechanical feedback loop and instability in form of axis runway can occur.

3.) Load is distributed not equally, therefore dynamic behavior of one axis differs from the other.

Prevention features:

1. Slave deviation: difference in position between master's and slave's feedback is monitored if it exceeds certain threshold an error is generated and the system stopped. MC-BASIC: <slave>.SlaveDeviation .
2. Slave disconnect: when slave is disabled either due to explicit user command or as a result of an error it's master is automatically disabled. MC-BASIC: <slave>.SlaveDisconnect .
3. The master is "aware" of its slaves. Keeping slave in enabled state when master is disabled can introduce a feedback loop (mechanical linkage between slave and master) resulting is a system that is not always stable i.e. we have a runaway. This can be prevented using SlaveDisable flag, each time a master is disabled due to whatever reason all its slaves will be disabled too. MC-BASIC: <master>.SlaveDisable .
4. In order to keep the delay between master and slave minimal it is imporrtant to take care about the order of calling of axis RTK. Connecting slave to a master automaticaly re-orders their RTK by changing their priorities.

Table of Actions

We define General Axis Deviation (GAD) is as one of the following events:

• position follwing error (Pe > PeMax)
• velocity overspeed (Vfb > Vospd)
• excessive acceleration (over Sys.MotionMargin*Amax)
• excessive torque (over Tmax)
• slave deviation (SlaveDeviation > SlaveMaxDeviation)
  

Action:	<slave>.SlaveDisconnect 1 (default) (or master is PEXT)	<slave>.SlaveDisconnect 0	<master>.SlaveDisable 0 (default)	<master>.SlaveDisable 1
Slave GAD	Disconnecting: sax.slave=0 Stopping master axis Stopping slave axis	Stopping the first master if it is moving, else disabling the master	Nothing affected
Slave GAD (when slave is stopped)	can not occur as slaved axis is considered always in a moving state (ismoving ≠ 0)
Slave GAD (when master is stopped)	Disabling master. Disabling slave
Master GAD	Stopping master axis
Master GAD (wnen master is stopped)	Disabling master axis			Disabling slave axis
Error on slave axis	Disconnecting: sax.slave=0 Stopping slave axis	Stopping slave axis	Nothing affected
Error on master axis	Stopping master axis
Disabling master: (max.en: 1→0)	Nothing affected			Disabling all slave axes that are directly or indirectly connected.
Disabling slave: (sax.en: 1→0)	Msyn is reset No disconnection.	Msyn is reset Disable all master axes connected directly or indirectly.	Nothing affected

Re-ordering the master-slave sequence.

In softMC the sequence of calling different RTKs is assured by giving them different priorities (starting from 20). By default the first axis (the one with lowest ID) has the starting priority (20), the next has 21, and so on. IF the group's RTK is activated, it gets the priority number of it's first axis. In this way we assure that no RTK interrupts execution of the other one.

Once the new master slave pair is given, the system should check the priorities of their RTK tasks, if prio(RTK_Slave) > prio(RTK_Master) then everything is OK, if not they should be exchanged but before that we must check if the specified master is a slave to another axis, if yes then this pair should be checked also.

Slave-Disable

• Name: <axis>.SlaveDisable
• Type: long
• Values: 0 or 1
• Default: 0
• Limitations: Modal-Only, Read/Write
• Context: Task or Terminal

See Also: SlaveDisable

Once the <master>.SlaveDisable is on, each time the axis is disabled (due to an error, or by direct assignment i.e., ”en=0”) all of it's slave axes will be disabled:

If the user directly enters:

master_axis.en = 0

• If the default error handler disables the axis
• If the axis is disabled by an automatic disable due to a position error on a stopped axis
• If the torque threshold is exceeded on a stopped axis.
• If the VOSPD is exceeded on a stopped axis
• If the master is disabled because it is a part of the group that is being disabled (or some axes of it are).
• If the master is disabled because being master of another axis having <axis>.SlaveDisconnect flag set to 0(This is when this feature is on).

Slave - disconnect

• Name: <axis>.SlaveDisconnect
• Type: long
• Values: 0 or 1
• Default: 1
• Limitations: Modal-Only, Read/Write
• Context: Task or Terminal

Flag for protection against unwonted disconnection between master and slave pairs during camming/gearing. If this flag is off, the master/slave pair will be disconnected from each other only by explicit issuing: “<slaveaxis>.slave= 0” or “STOP <slaveaxis>”.

See Also: SlaveDisconnect

	NOTE
	Special care must be taken to avoid loops i.e. if the master disables the slave and the slave disables the master there must be a way that explicit enabling of master-slave pair succeeds.

Manz's Bugs related to this issue:

Issue 0997 B/F: Runaway with ActiveDisable switched off in gantry / missing synchronization

Issue 1681 F:Runaway with axis enable of gantry slave axis

Issue 0917 B: Slave jumps with following mode transitions on master

Issue 1003 B/F: Master-Slave order affects PCMD synchronization