-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Absolute movement causes the stage to move continously in wrong direction #83
Comments
This indeed looks pretty strange, especially considering the fact that the first move to 3mm has no problems, and the commands sent to the device should be identical in both cases. Can you check that this issue does not arise in the Kinesis software and is specific to pylablib, to exclude hardware problems? Do you know what condition causes this issue? Does it always arise when moving backwards? Or only past a specific point? Also, it looks like the final position is 67mm, which is past the stage 50mm travel range. Do you know how this happens? Does the motor try to run agains the stop point, even when the limit switch is engaged? Can you check (at least, roughly), that the calibration is correct, e.g., that moving to 25mm position places the stage in the middle of its range? Regarding the ON/OFF light: you can try using the Sincerely, Alexey. |
The function
I have confirmed the issue does not occur when I control the stage using the Kinesis software. Also, the issue does not occur if I first let Kinesis software connect to the stage then I disconnect. Below are steps to replicate.
If I connect to stage with Kinesis software before connecting via Python, I notice the output of the >>> stage.get_full_info(-10)
{'velocity_parameters': TVelocityParams(min_velocity=0.0, acceleration=19.99985352990614, max_velocity=20.002642021804558), 'jog_parameters': TJogParams(mode='step', step_size=0.5, min_velocity=0.0, acceleration=0.4999907901918369, max_velocity=1.000132121556562, stop_mode='profiled'), 'homing_parameters': THomeParams(home_direction='reverse', limit_switch='reverse', velocity=1.000132121556562, offset_distance=0.1), 'gen_move_parameters': TGenMoveParams(backlash_distance=0.01), 'limit_switch_parameters': TLimitSwitchParams(hw_kind_cw='break', hw_kind_ccw='break', hw_swapped=False, sw_position_cw=3.0, sw_position_ccw=1.0, sw_kind='ignore'), 'position': 0.0, 'status': ['tracking', 'digio1', 'enabled'], 'cls': 'KinesisMotor', 'conn': {'port': '70877XXX', 'baudrate': 115200, 'bytesize': 8, 'parity': 'N', 'stopbits': 1, 'xonxoff': 0, 'rtscts': True}, 'device_info': TDeviceInfo(serial_no=70000000, model_no='BSC203', fw_ver='2.3.4', hw_type=32, hw_ver=2, mod_state=0, nchannels=3, notes='APT Stepper Motor Controller'), 'channel': [1], 'scale_units': 'user_step', 'scale': (409600, 21987328.0, 4506.08300032), 'stage': None}
Right now it seems the issue arises whenever I try to move backwards. The reason the final position in my example is at 67mm is because the stage continuously moves forwards without stopping. It goes beyond the limit and keeps trying to move forward until I manually stop it. Calibration is correct, I confirmed moving to 25mm puts the stage in the middle. Also I have confirmed this issue occurs on both channels of the BSC203 controller. In addition, I have another DRV014 stage and the issue occurs on that also. Thank you for your help and creating this library. I hope we can determine the source of this issue. |
Seconding this issue on the BSC203 controller with DRV208 stepper motors. |
Thank you for the detailed description! Unfortunately, I do not have access to BSC20x controllers, so I can only deduce something based on the Kinesis simulator. It looks like there could be a couple of things going on:
stage.send_comm(0x0018,dest=("channel",1))
print(stage.query(0x0060,0,dest="host"))
stage.send_comm(0x0018,dest=("channel",1))
stage.send_comm(0x0210,1,1,dest=("channel",1)) in the beginning to see if the channel will get activated.
print(dev.query(0x0214,dest=("channel",1)))
for comm in [0x0414,0x0417,0x042B,0x0427,0x043B,0x0446,0x0451,0x0441,0x0424,0x052A,0x04E7,0x04F5]:
print(dev.query(comm,1,dest=("channel",1))) and then compare them with the result after you run the Kinesis software (i.e., when the bug does not manifest anymore). If you do, let me know the results, and we can try to figure out which one affects the behavior. Sincerely, Alexey. |
I am facing an issue with pyLabLib giving unexpected behavior when trying to control a Thorlabs DRV014 50mm stepper motor stage connected to BSC203 controller. After homing, I move the stage to desired absolute positions. For example, from 0mm to 3mm, then 3mm to 7mm, then 7mm to 3mm. On the 3rd absolute movement (i.e. 7mm to 3mm), the stage starts moving in the forward direction without stopping instead of going backwards and stopping at 3mm. Below is my code to replicate the issue.
I also notice the Enable light is not ON, I have to physically press the ON button to enable the channel. However, the pyLabLib is able to properly connect and interact with the stage even when the enable is OFF. If I launch the Kinesis software, it automatically enables the channel to ON.
Python 3.11.9
pylablib 1.4.2
The text was updated successfully, but these errors were encountered: