The other thing I realised is that it should not need jog turning off as the stage is not moved. Like when you run an acquisition from the Acquire! window. But I guess when using automate its always assuming the stage is moving. Would it be difficult and of interest to anyone else - if when beam deflection selected it checked if the stage was at the analysis coordinates before calling stage move?
Hi Ben,
Interestingly I used to check to see if the current stage position was already close to the target position when I supported a number of old instrument interfaces using direct control of stepper and servo motors. I never added such a test for the Cameca interface because the stage position is defined in integer microns and so if you move to a Cameca stage position, that is where you are, and so if you send a command to move to the same stage position, the instrument will simply ignore the command!
I realize that the JEOL is different because it returns fractional millimeters, but I guess I assumed there was something similar in the JEOL firmware (was there on the 8900/8200/8500?), that checked to see if the current stage position is "close enough". However, I can see that it might initiate a stage jog even if it is close enough to the actual target position.
I also guess that you can turn off the firmware stage jog from the JEOL software? Also since you mentioned acquisition from the Acquire! window, did you know that you can use the Imaging window in Probe for EPMA to manually deflect the beam position and acquire manual data from the Acquire! window on that deflected beam position? Try it on a fluorescent sample and see for yourself. Note that the deflected beam position is displayed in the Acquire window with a little circle and cross... this same beam deflection display is also utilized for automated beam deflection from the Automate! window.
Finally there is also a parameter in the MOTORS.DAT file called "backlash tolerance" which is used to decide if a software (not hardware) backlash is necessary based on the current and target position (and motion direction). So this parameter could also be utilized for deciding if a stage move is necessary at all...
The "MotBacklashTolerances" are defined in fractional units where 0.002 is 0.2%. For the software backlash feature the code compares the motion distance, to the backlash tolerance fraction of the total stage axis range, to avoid issues where the position is close to 0,0 (as can be the case for Cameca instruments!).
For example if "pos" is the stage position to move to, and "RealTimeMotorPositions" is the current stage position:
If Abs(pos! - RealTimeMotorPositions!(motor%)) < Abs(MotHiLimits!(motor%) - MotLoLimits!(motor%)) * MotBacklashTolerances!(motor%) Then So I could implement a check like this for a normal stage move, but we need to think about this carefully. Do we want this behavior for all stage moves, or just stage moves from the Automate! window? For example, someone might be depending on the current behavior to be sure that a stage jog is *always* performed before each acquisition, even if it's in the same position. Or we could only perform this stage move check if we are using beam deflection from the Automate! window...
What do you (and everyone else) think about this?
john