User Tools

Site Tools


ms2000_optimal_alignment_procedures

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ms2000_optimal_alignment_procedures [2016/09/07 22:26]
asiadmin ↷ Page moved from documentation:ms2000_optimal_alignment_procedures to ms2000_optimal_alignment_procedures
ms2000_optimal_alignment_procedures [2019/04/18 23:34] (current)
Line 1: Line 1:
 +====== MS-2000 Controller Optimal Alignment Procedures ======
  
 +<WRAP center round info 60%>
 +This Tech Note was written for MS2000, MFC2000 and RM2000 controller. However the same procedure can also be used on Tiger/​TG-1000 controller.
 +</​WRAP>​
 +
 +
 +MS-2000 controllers with firmware Version 8.0 and later may use the procedures outlined below to obtain optimal performance of the MS-2000 stage and/or Z-drive. ​ Users with earlier firmware versions, or older hardware, should contact ASI for further information regarding upgrade options, or other service issues.
 +
 +===== Alignment Overview =====
 +
 +The MS-2000 controllers with Version 8.0+ firmware are highly configurable. ​ Settings for the stage running speed, ramp up/down time, error thresholds, servo parameters, driver alignment settings, etc., may all be changed and saved in non-volatile memory. ​ At ASI, we choose an optimal set of parameters suitable for most users before the stage leaves the factory, but our configuration may not necessarily the best for your application,​ or it is possible that conditions have changed and realignment is in order. ​ Complete optimization consists of four parts. ​ 1) Aligning the drive card to the stage and/or Z-drive motors, 2) Selecting speed and configuration parameters that you wish to use for the controller, ​ 3) Saving the new settings to non-volatile memory so they are available upon power-up, and  4) Testing the new settings for suitability.
 +
 +Proper calibration of the analog driver is required to get smooth, very slow speed operation of the stage with the digital closed-loop control. ​ Proper drive card alignment also makes the joystick operation as smooth as possible under high magnification.
 +
 +===== Drive Card Alignment =====
 +
 +The purpose of aligning the analog feed back for the drivers is to reduce the dead zone near zero speed when low voltage is applied to the motor. ​ The chart below shows typical a typical transfer function for various feed back adjustment values.
 +
 +[{{ ms2k_optimal_alignment_1.jpg?​direct&​300 |Click to Enlarge}}]
 + 
 +As you can see, without any feedback, (blue diamonds, ''​AA=1''​ case) there is a substantial region where supplying a commanded speed to the motor results in no motion whatsoever. ​ The digital loop can somewhat overcome this nonlinearity,​ and still provide accurate positioning,​ but the dead zone will give rise to “wind-up” and overshoot in a digital loop that is well-tuned for the constant slope section of the transfer curve. ​ Increasing the feedback (larger AA number) reduces the size of the dead region and significantly “linearizes” the transfer function near zero.  Not surprisingly,​ problems associated with poor drive card alignment show up when the motors need to move slowly, i.e. when completing a move.
 +
 +===== Adjusting the Feedback Alignment (AA) =====
 +
 +All of the steps below require a connection to a computer terminal program. Refer to  [[tech_note_rs232_comm|RS-232 Communication]]
 +
 +
 +<WRAP center round important 60%>
 +WARNING: When doing the alignment of the motors, be sure there is room for the stage to travel a few centimeters and that there is no objective lens in place.
 +</​WRAP>​
 +
 +
 +The following example will show alignment of the X axis.  Alignment of the Y axis and Z drive channels is analogous.
 +
 +Before we change anything we need to know the current feedback parameter setting. ​ To find out, issue the command:
 +
 +<asi> $ User’s typing shown in this typeface
 +MS-2000 responses are shown in red</​asi>​
 +
 +<asi> $ AA X?     
 +X= 82    ​
 +:​A</​asi>​
 +
 +If you think the feedback is a little low (stage sluggish on landing) you can just increase the present value by a few counts using:
 +
 +<asi> $ AA X=85
 +:​A</​asi>​
 +
 +Always issue the auto-zero command after changing the AA value to re-balance the output amplifiers.
 +
 +<asi> $ AZ X
 +Zero C:0                  ​
 +C C:0 H:0 L:101
 +D C:1 H:0 L:109
 +Bracket H:125 L:109
 +E C:1 H:125 L:109         
 +E C:1 H:117 L:109         
 +Zerod at: 110</​asi>​
 +
 +The procedure re-balances the amplifier now with the new Feedback value.
 +
 +If you don’t get good results the first time, you can try higher or lower feedback values and re-test the motion.  ​
 +
 +Too much feedback can result in unstable jerky motion, the motor may tend to buzz, and the [[commands:​azero|AZ command]] will often produce inconsistent results when repeated several times. ​  ​Reduce the AA value is you see these symptoms.
 +Too little feedback can result in no motion. ​ With too little feedback, the motors will be trying to get to target but will be unable to do so, resulting in the status letter **M** (//Motor//) or **B** (//Busy//) on the LCD screen staying on for longer periods of time after a move. 
 +
 +===== Checking the Feedback Alignment (AA) =====
 +
 +The alignment routine contains a built-in self-test that generates the data used in the chart above. ​ To start the test use the command:
 +
 +<asi> $ AA X=500    ​
 +:​A</​asi>​
 +The number 500 triggers this test.
 +
 +The data from this test are saved in the controller and must be dumped to the screen for you to evaluate. ​ To do this, type the dump command:
 +
 +<asi> $ DU 
 +idmp = 52
 +pos  err   spd
 +   ​-25 ​       0        0
 +   ​-31 ​       0        0
 +   ​-38 ​       0        0
 +   ​-47 ​       0        0
 +   ​-58 ​       0        0
 +   ​-72 ​       0        0
 +   ​-90 ​       0        0
 +  -112        0        0
 +  -140        0        0
 +  -175        0        0
 +  -218       ​-3 ​       0
 +  -272      -11        0
 +  -340      -32        0
 +  -425      -46        0
 +  -531     ​-290 ​       0
 +  -663     ​-488 ​       0
 +  -828     ​-686 ​       0
 + ​-1035 ​    ​-990 ​       0
 + ​-1293 ​   -1326        0
 + ​-1616 ​   -1689        0
 + ​-2020 ​   -2172        0
 + ​-2525 ​   -2792        0
 + ​-3156 ​   -3520        0
 + ​-3945 ​   -4430        0
 + ​-4931 ​   -5673        0
 + ​-6163 ​   -7114        0
 +    25        0        0
 +    31        0        0
 +    38        0        0
 +    47        0        0
 +    58        0        0
 +    72        0        0
 +    90        0        0
 +   ​112 ​       0        0
 +   ​140 ​      ​11 ​       0
 +   ​175 ​       1        0
 +   ​218 ​      ​21 ​       0
 +   ​272 ​      ​46 ​       0
 +   ​340 ​      ​77 ​       0
 +   ​425 ​     156        0
 +   ​531 ​     284        0
 +   ​663 ​     431        0
 +   ​828 ​     578        0
 +  1035      932        0
 +  1293     ​1254 ​       0
 +  1616     ​1636 ​       0
 +  2020     ​2063 ​       0
 +  2525     ​2723 ​       0
 +  3156     ​3438 ​       0
 +  3945     ​4353 ​       0
 +  4931     ​5560 ​       0
 +  6163     ​6983 ​       0
 +</​asi>​
 + 
 +The numbers show the results for moves in both directions. ​ The first number in each triplet it the speed ‘drive’ value, the independent variable. ​ The second number, the relative speed the stage is moving. ​ You want to be sure that there is motion at the low drive levels (below +/-500), and that the speed is at least quasi-monotonic. ​ The example shows a typical, well-adjusted stage axis.
 +
 +If you see very slow, usually zero, movement for drive values < 500, you could increase the AA value.  ​
 +
 +===== Setting Speed and Configuration Parameters =====
 +
 +The discrete nature of encoders and timing cycles place a few limits on acceptable speed and up/down ramp settings. ​ We do not try to go slower than one encoder count per servo-cycle,​ so this imposes certain discrete values for minimum slow speeds. ​ It also makes no sense for a ramp to have a change in speed of less than one encoder count per servo-cycle. ​ These constraints are built into the range-checking that is performed whenever either the speed (S) or the ramp time (AC) setting is changed. ​ For instance, if we want to move at about 100 microns/​second,​ we issue the command:
 +
 +''​S X=.1 Y=.1''​
 +
 +Then, ask for those values to be read back:
 +
 +<asi> $ S X? Y?
 +: X=0.088110 Y=0.088110 A</​asi>​
 +
 +We see that the controller has adjusted our choices somewhat.  ​
 +You can quickly see many of the controller parameter settings by issuing the info command:
 +
 +<asi> $ I X
 +Axis Name      : X                  Error Status ​  :
 +Input Device ​  : JS_X     ​[J] ​      Motor Signal ​  : ​     128
 +Max Lim        :  110.947 [SU]      Min Lim        : -109.053 [SL]
 +Ramp Time      :       36 (ms)[AC] ​ Ramp Steps     : ​       6
 +Run Speed      :  0.08811 (mm/s)[S] vmax_enc ​      : ​       6
 +dv_enc ​        : ​       1           ​enc_bl_crossovr: ​      55
 +Drift Error    : 0.000500 (mm)[E] ​  ​enc_drift_err ​ :        5
 +Finish Error   : 0.000097 (mm)[PC] ​ enc_finish_err :        1
 +Backlash ​      : 0.040000 (mm)[B] ​  ​enc_backlash ​  : ​     453
 +Kp             : ​      20 [KP]      Ki             : ​       1 [KI]
 +Kv             : ​      25 [KV]
 +Axis Enable ​   :        1 [MC]      Motor Enable ​  : ​       0
 +CMD_stat ​      : ​ NO_MOVE ​          ​Move_stat ​     :   ​FINISH
 +Current pos    :  0.00000 ​          enc position ​  : ​ 8388608
 +Target pos     : ​ 0.00000 ​          enc target ​    : ​ 8388608
 +enc pos error  :       ​-1 ​          ​EEsum ​         :       -5
 +Lst Settle Time:       54 (ms)      Ave Settle Time:       84 (ms)</​asi>​
 +
 +The parameters that are user-changeable are indicated by the presence of their command shortcut in the listing above. ​ For instance, if you wished to reduce the Drift Error parameter you could issue the command:
 +
 +''​E X=.0002 Y=.0002''​
 +
 +Subsequent info requests would show the change to the **Drift Error** as well as to its corresponding parameter **enc_drift_err**,​ which is the Drift Error expressed in units of encoder counts.
 +
 +Setting the appropriate error tolerances can have a dramatic effect on stage performance. ​ Landing “on the count” is often possible, but will occasionally cause the controller to hang because mechanical “stiction” just doesn’t allow the motor to move such small amounts. ​ Hence, we usually ship controllers with the **Finish Error** set to a distance equal to one encoder count. ​ Once the stage moves to within the **Finish Error** distance of the target, it declares the move finished, clears the busy flag (the **B** on the LCD display), and enters the **NO_MOVE** state. ​ Should the stage subsequently drift away from the target more than an amount specified by the **Drift Error**, the controller will re-energize the motors and bring the stage back to within the Finish Error distance once again.
 +
 +In some instances, final positioning is very important so you may wish to reduce the **Drift Error** to one or two encoder counts. ​ Doing so will cause the controller to attempt to reposition the stage more frequently. ​ If you don’t care so much about accuracy, but are very concerned about the time it takes for the stage to settle to the target, you could increase the **Finish Error** parameter. ​ You should notice a substantial decrease in the settling time.
 +
 +On stages without linear encoders, we recommend using the built-in anti-backlash routine to improve the repeatability of the stage movement. ​ The Backlash parameter specifies an offset distance from the final target position. ​ A commanded move first moves to a target position offset by the Backlash parameter, and then subsequently moves on to the target. ​ Although this helps to improve the repeatability of commanded moves, for some applications,​ it will cause more problems than it cures. ​ To turn the Backlash off, just set its value to zero.  **(B X=0)**
 +
 +===== Setting Servo Parameters =====
 +
 +Changing the servo parameters should be done only if drive card alignment still doesn'​t get the performance that is required from the system. ​ The servo parameters that you may want to adjust are the KP and KI settings that determine the response of the servo loop to trajectory errors during a move.  The KP term sets the motor drive proportional to the error, and the KI term sets the motor drive proportional to the time integral of the error. ​ Before changing anything always query the controller to find out the present values of the parameters.
 +
 +<asi> $ KP X?
 +A: X=50
 +$ KI X?
 +A: X=5</​asi>​
 +
 +In general, increasing the KP parameter increases the stiffness of the motion; the stage more closely follows the desired command trajectory. ​ Increasing the KI parameter fixes persistent errors more quickly, especially finding target at the end of travel. ​ Too much of either parameter can cause instability and overshoots. ​ Here are a few rules of thumb for setting these parameters.
 +
 +  * Start with KI X=0.  Increase KP value until unstable motion is detected on long moves. Back off KP value until motion is smooth.
 +  * Start with KI approximately 10% of the KP value obtained above. ​ Make several short commanded moves and be sure the Busy clears quickly. ​ If not, increase KI.
 +
 +Once you have made changes, be sure to save the settings as discussed below.
 +
 +===== Saving Settings to Non-Volatile Memory =====
 +
 +Once you are happy with your settings, you can save them to flash EPROM so they will be used on subsequent start-ups. ​ To save all of the current settings to Flash memory, use the [[commands:​saveset|SAVESET command]]
 +
 +===== Testing and Error Checking Servo Motion =====
 +
 +==== Testing the Motion ====
 +
 +The MS-2000 controller has several built-in diagnostic capabilities that are useful for troubleshooting difficulties and for tuning the servo motion parameters. ​ It is often useful to see how well the servo motion tracks the theoretical trajectory programmed by the controller for the move.  The controller has a built-in buffer that can hold 200 move steps. ​ For best results, restrict testing to a single axis at a time; otherwise, information from multiple axes will be interleaved in the dump buffer. ​ Any motion from any axis will write information into the dump buffer until it is full.  To begin a test, first reset the buffer with the command:
 +
 +**DU X **       ​[reset the dump buffer]
 +
 +Then make a short move, e.g.:
 +
 +**M X=12345** ​  ​[Moves about 1.2 mm]
 +After the move is complete, you can dump the buffer to the screen:
 +
 +<asi> $ DU
 +idmp = 121
 +pos  err   spd
 + 0 , 45 , 2250
 + 45 , 135 , 6310
 + 114 , 270 , 11348
 + 169 , 450 , 15840
 + 196 , 675 , 19218
 + 184 , 945 , 21034
 + 169 , 1215 , 20476
 + 118 , 1485 , 18464
 + 59 , 1755 , 16118
 + 18 , 2025 , 14482
 + -1 , 2295 , 13722
 + 2 , 2565 , 13842
 + 22 , 2835 , 14646
 + 27 , 3105 , 14852
 + 50 , 3375 , 15784
 + 70 , 3645 , 16600
 + 74 , 3915 , 16778
 + 53 , 4185 , 15950
 + 45 , 4455 , 15640
 + 41 , 4725 , 15490
 + 39 , 4995 , 15418
 + 42 , 5265 , 15548
 + 42 , 5535 , 15558
 + -5 , 5805 , 13678
 + 44 , 6075 , 15648
 + 61 , 6345 , 16342
 + 66 , 6615 , 16558
 + 59 , 6885 , 16292
 + 28 , 7155 , 15058
 + 27 , 7425 , 15024
 + 35 , 7695 , 15352
 + 47 , 7965 , 15842
 + 53 , 8235 , 16094
 + 41 , 8505 , 15624
 + 42 , 8775 , 15674
 + 44 , 9045 , 15764
 + 45 , 9315 , 15814
 + 40 , 9585 , 15624
 + 12 , 9855 , 14506
 + 22 , 10125 , 14910
 + 37 , 10395 , 15518
 + 52 , 10665 , 16130
 + 61 , 10935 , 16504
 + 57 , 11205 , 16358
 + 34 , 11475 , 15446
 + 29 , 11745 , 15252
 + 32 , 12015 , 15380
 + 38 , 12285 , 15628
 + 40 , 12555 , 15718
 + 38 , 12825 , 15646
 + 16 , 13095 , 14770
 + 23 , 13365 , 15054
 + 47 , 13635 , 16024
 + -83 , 13790 , 10160
 + -57 , 14015 , 8936
 + -31 , 14195 , 7720
 + -19 , 14330 , 5946
 + -27 , 14420 , 3370
 + -54 , 14433 , -4422
 + -107 , 14343 , -8818
 + -142 , 14208 , -12502
 + -87 , 14190 , -8072
 + -24 , 14145 , -3308
 + -77 , 14010 , -3098
 + 11 , 14010 , 424
 + 78 , 14010 , 3122
 + 91 , 14010 , 3664
 + 71 , 14010 , 2880
 + 36 , 14010 , 1488
 + 7 , 14010 , 328
 + -2 , 14010 , -32
 + -9 , 14010 , -314
 + -8 , 14010 , -276
 + -5 , 14010 , -156
 + -2 , 14010 , -36
 + -2 , 14010 , -36
 + 0 , 14010 , 44    ​
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 3 , 14010 , 120
 + 0 , 14010 , 0
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + -2 , 14010 , -80
 + 0 , 14010 , 0
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 4 , 14010 , 160
 + 1 , 14010 , 40</​asi>​
 +
 +All those numbers may not look particularly useful, but they have a lot of information about the system dynamics in them.  Using //​HyperTerminal//​’s file capture capability, we can save the dumped information to a file and plot the results in a charting program like Microsoft’s Excel.
 +
 +[{{ ms2k_optimal_alignment_2.jpg?​direct&​300 |Click to Enlarge}}] ​
 +
 +The data shows the move trajectory, the error from desired path, as well as the drive signal given to the motor mover. ​ For this move, there were six ramp-up and down points on the way to full velocity. ​ Backlash of ~450 counts was enabled, the finish error was 1 encoder count, and the drift error was 2 encoder counts. ​ During the time of maximum acceleration,​ there is also the most error. ​ The short ramp (six cycles) contributes to the error (about 17 microns peak error from the theoretical path). ​ Once the move is under way, the average error settles down to about 50 counts (4 microns). ​ You can see the retrograde motion caused by the anti-backlash routine starting at about the 59th time step.  There is a fair amount of overshoot and then the move settles in to find its final position. ​ The move would clear the busy status at about step 77, but then it drifts outside the drift error range and cannot settle for another 45 time steps.  ​
 +
 +The user is advised that servo tuning can be a painstaking process, so only try new settings if you are unhappy with the default ones shipped from the factory.
 +
 +==== Checking Internal Errors ====
 +
 +
 +The controller is designed to work with a wide variety of parameter settings, but there certainly could be conditions where the choice of parameters causes motion errors of one sort or another. ​ To aid in diagnosing these problems, the MS-2000 controller has an error buffer of the last 256 error conditions it has encountered since last power up.  The error codes can be accessed by the command:
 +
 +**DU Y ** [dump error codes]
 +The buffer is cleared with:
 +
 +**DU X** [clear buffers] ​      
 +Error codes are dumped to the screen with the last error code shown first. ​ The table below lists the meanings of the error codes, as of the date of this publication.
 + 
 +
 +
 +{{page>​error_codes}}
 +
 +
 +
 +
 +{{tag>​ms2000 tiger tech_note}}
Address: 29391 W Enid Rd. Eugene, OR 97402, USA | Phone: +1 (541) 461-8181
ms2000_optimal_alignment_procedures.txt · Last modified: 2019/04/18 23:34 (external edit)