Siblings

Very often several scripted devices can be written to describe different relationships between the same real motors. If the user expects to be able to move each scripted device without affecting the position of the other scripted device, then the set_siblings command can be used to declare this desired relationship between two parent devices.

For example, the average position of table_vert_1 and table_vert_2 can be written into a scripted device called table_vert. Moving this table_vert ``motor'' would move table_vert_1 and table_vert_2 by an equal amount. However, table_vert_1 and table_vert_2 can also be described in terms of an angle, table_pitch. With the table_vert and table_pitch motors now defined, a user may expect to be able to move table_vert without changing table_pitch. On the other hand, a user may also expect to be able to move table_pitch without changing table_vert.

A problem arises with this scenario when one considers that the table_vert motor issues two independent move commands to two real motors. These two motors may travel at slightly different speeds, thus altering the table_pitch motor during the move. At the end of the move, the table_pitch should once again be back to its original position before the move was started. This by itself is probably acceptable, as the limits of table_pitch are continuously checked and the move would be aborted if the limits were exceeded.

However, if a move of table_vert is aborted, either by a user or by a scripted device that has had its limits violated, the position of table_pitch will have been altered at the end of the move. Further moves of table_vert would maintain the new altered position of table_pitch. This is unacceptable because the table_pitch motor was altered simply because of an interrupted move of table_vert.

The set_siblings command can help the scripting engine overcome this problem by doing the following:

• With each move a motor that completes normally, the current position of all of the motor's siblings are stored as the last good position.
• With each move a motor that completes with an error (aborted or limit violation), no value will be stored.
• Every time a motor move is started, the status of all of the sibling motors are checked, and any of these motors that are not at the last good position will be told to move to their last good position before the initial request move is performed.

With table_pitch defined as a sibling of table_vert, aborting table_vert during a move will not update table_pitch's last good position. When table_vert is moved again, the table_pitch motor will first be moved to its last good position before table_vert is allowed to move.