Example Relationship DevelopmentA vertical Z axis following the height of a defined spherical surface as the X and Y axes are independently programmed to move over that surface is a simple example of a custom programmable relationship. This example comes from a real-world application and is a good introduction to the usefulness of customized programmable relationships within coordinated motion systems.
Figure 1 shows a 3D printed antenna array being deposited on a partial hemisphere. The ability to maintain the tool tip’s position relative to the surface in coordination with the X and Y motion is greatly simplified by programming the known spherical relationship of X, Y, and Z axis positions into the motion controller. The user can then simply program the desired projected 2D profile in X and Y coordinates with Aerotech’s CADFusion 2D graphical motion development tool, and the profile will be correctly re-projected onto the desired hemisphere because the Z axis will implicitly follow the programmed spherical relationship. This custom relationship is easily programmed using two A3200 programming features: the AXISSTATUSFAST command and the TrajectoryDelayFilter parameter. These two features provide a wide range of capability for users to program custom coordinated relationships between system variables and axis motions, and they are straightforward to use.
Figure 1. 3D printing of antenna array on partial hemispherical surface. Photo courtesy of Professor Jennifer A. Lewis, Harvard University.
For this simple hemisphere example, first let us define the relationship to be programmed into the Z axis trajectory generation. Figure 2 depicts a side projection of the hemisphere where a known zero location has been established at the apex. For any point in the X,Y plane a defined Z axis position can be established based on the nominal radius of the hemisphere. Knowing the radial distance from the hemisphere’s axis through X and Y position commands, a triangle can be drawn where the legs are R, K, and √(Xpos2+Ypos2). Through Pythagoras’ theorem we get Equation 1.
K=√(R2-(Xpos2+Ypos2)) (Eq. 1)
Figure 2. A side projection of the hemispherical artifact to be 3D printed on from Figure 1. A zero location has been established at the apex of the hemisphere, and its radius is nominally known. This allows for the position command of the Z-axis to be implicitly generated as a function of X-axis and Y-axis position command.
Additionally, it’s clear from Figure 2 that Equation 2 is also true.
Zpos=R-K (Eq. 2)
Combining the two we end up with the relationship to be programmed into the Z axis trajectory as a function of X and Y position commands (Equation 3).
Zpos=R-√(R2-(Xpos2+Ypos2)) (Eq. 3)
Now that the desired motion relationship between the Z axis and the X and Y axes has been established, we can learn to program this relationship into the Z axis trajectory and then learn to synchronize it with that of the X and Y axes.
Programming with AXISSTATUSFASTA sample AeroBasic code usable in the A3200 software suite has been provided in Appendix A. It shows the steps required to execute a dependent Z axis trajectory generation per the relationship established in Equation 3 with the X and Y axes trajectories. Since the Z axis trajectory is dependent on the X and Y trajectories, the AXISSTATUSFAST command must be used to collect the X and Y position commands at the motion update rate. The “MotionUpdateRate” parameter in the system configuration file sets the trajectory generation frequency for each axis. Generally the maximum motion update rate is 8 kHz for servo stages. In the coding example an 8 kHz MotionUpdateRate setting is assumed for all axes.
The AXISSTATUSFAST command allows the user to collect different data items at the rate at which they are generated. In this instance, we collect the “PositionCommandRawUnfiltered” data stream from the X and Y axes. This raw, unfiltered signal must be used so that no irreconcilable filtering delay is built into the calculated Z axis trajectory. This allows the Z axis to be properly re-synchronized with the X and Y axes using a trajectory delay. You cannot achieve synchronization between all axes if you use the filtered command signal.
The AXISSTATUSFAST command can be seen in lines 25 and 26 of the sample code. AeroBasic “CRITICAL” code blocks are executed at a 1 kHz rate. In the sample code, everything is contained within a CRITICAL START and CRITICAL END command block. Therefore, to capture the full 8 kHz of X and Y trajectory signals in a 1 kHz task execution, 8 data points must be captured and populated into an array each time the CRITICAL code executes. The number of data points captured with each execution of the AXISSTATUSFAST command is defined by the last argument in the command line. Now that the X and Y trajectory points are in an array, they can be used to calculate the Z axis position for that cycle’s 8 trajectory points. To see a full list of what data items can be collected by the AXISSTATUSFAST command and for implementation directions, visit the “DATACOLLECT ITEM” command and “AXISSTATUSFAST” command A3200 help file topics, respectively.
To calculate the Z axis trajectory, a simple FOR loop structure is built to walk through each XY command location and calculate the corresponding Z axis command per the spherical relationship established with Equation 3. At the end of the FOR loop is a PT (Position and Time) command line, where the Z axis is commanded to the calculated position in the specified time interval of 1/8 of a millisecond, corresponding to the eight times the FOR loop will run in the 1 millisecond long CRITICAL code section. This matches the trajectory rate of the X and Y axes of 8 kHz. After all eight Z axis positions have been calculated and commanded, the next eight X and Y trajectory points are collected and the process is repeated as long as the relationship is enabled.
With the sample code running in a background Task, primary motion is commanded to the X and Y axes in another Task. The Z axis will always follow the spherical surface defined in Equation 3, regardless of where X and Y are commanded to go. The last problem to solve is synchronization.
Synchronizing TrajectoriesThe user must implement a trajectory delay on both the X and Y axes to synchronize the motion of all three axes. Because the Z axis is left to react to commands being sent to the X and Y axes, it is inherently lagging behind in its execution of its trajectory compared to the X and Y axes. The execution of the CRITICAL code section takes 1 millisecond, and there are additional delays from collecting the X and Y trajectories from the machine controller. To compensate for the delays seen in the Z axis, the user must go into the system configuration file and put in a TrajectoryDelayFilter to the X and Y axes, which can be found in the Axis>Motion>Filters folder section. This parameter adds an initiation delay in the X and Y trajectory execution of the same magnitude as that seen by the Z axis due to the relationship calculation. Thus the axes are perfectly re-synchronized.
The required value of the TrajectoryDelayFilter, set in milliseconds, depends on the system arrangement and the drives being used. In this instance, a delay of 3 milliseconds was needed to account for the code execution and the delays associated with the drive hardware used. The simplest way for a user to determine the correct delay is to measure the phase lag seen in the Z axis command stream relative to that of the X and Y axes in the Digital Scope utility before adding the TrajectoryDelayFilter. Figure 3 shows a captured Digital Scope plot showing the Z axis command stream lagging behind that of the X and Y axes prior to the addition of a trajectory delay.
Using the left and right cursor lines, the required 3 millisecond delay can be easily measured. Figure 4 then shows the same motion line after a 3 millisecond delay has been implemented in the X and Y command streams via the TrajectoryDelayFilter parameter. You can see that motion on all three axes is now synchronized to the exact same trajectory generation cycle.
Figure 3. Screen capture of A3200’s Digital Scope utility showing a phase lag on the Z axis command response due to the programmed spherical relationship reacting to the X and Y axes commands.
ConclusionWhile this example of a Z axis tracking a spherical surface is simplistic, the concepts used here provide a very powerful capability to the user when it comes to non-linear custom kinematics programming. Extremely complex functional relationships and kinematic transformations between the motions of large numbers of axes, both real and virtual, can be programmed directly in the AeroBasic language. Axes whose trajectories are dependent on the motion of other axes and non-linear custom kinematic transformations are a common problem in many complex automation applications. Additionally, you can form relationships that aren’t solely based on position. One could program the position of a subordinate axis based on a function of another axis’ velocity commands and/or acceleration commands, in addition to position. The AXISSTATUSFAST command gives users the versatility to prescribe any kinematic relationship they can think of between real and/or virtual axes alike, while the TrajectoryDelayFilter parameter allows the motion execution to remain synchronized.
Figure 4. Screen capture of A3200’s Digital Scope utility showing the X,Y, and Z axes’ commands synchronized after a TrajectoryDelayFilter parameter of 3 milliseconds was added to the X and Y trajectories.
Appendix A. Sample AeroBasic Code (Download Text File of Complete Program)