BSC 201 Stepper Motor Controller control using send_comm functions about pylablib

[AlexShkarin]

Dear Manny,

The issue is in the message ID. The message ID for homing is 0x0443, you can see it in the upper right corner of the command description, next to the command names. The reason it's reversed in the 6-byte TX structure is because the protocol is little-endian, which means that out of the 2-byte ID it sends the lest signifcant byte (the last 2 hex digits) first, and the most signifcant byte second, in effect flipping the order. Hence, the correct command for homing would be stage_theta.send_comm(messageID=0x0443).

Similar applies to all other commands and examples in the documentation: whenever they give the byte-sequence examples with multi-byte values, the least significant byte goes first. This is important to keep in mind when using commands that send additional data using send_comm_data method, e.g., long version of MGMSG_MOT_MOVE_ABSOLUTE (message ID 0x0453). Its TX structure is as following:

It needs 6 bytes of data: 2 for channel ID and 4 for the distance, and both of these values have LSB (least significant byte) first. To generate these, you can use Python struct module. For example, to move to position 10000 on channel 0, the command would be

# "<" means little-endian, and "Hi" means a 2-byte unsigned integer followed by a 4-byte signed integer (see struct documentation)
data = struct.pack("<Hi",0,10000) # channel 0 and position 10000
stage_theta.send_comm_data(messageID=0x0443, data=data)

By the way, why do you use BasicKinesisDevice instead of KinesisMotor with this device? Are there some issues with the KinesisMotor class? Which library version are you using?

Sincerely,

Alexey.

[Em607867]

Dear Alexey,

Thanks so much for the detailed response and explanation of the little-endian protocol. I used the correct command as described above but still no action on the motor and also no error messages.

I also tried to tweak values of param1 but nothing seemed to result in motion of the stage connected to the controller.

Also, while running some other functions in the BasicKinesisDevice, like get_number_of_channels(), I get error messages.

I also get this error message when I use KinesisMotor with this device; (image below)

Additional information:

1. I am using library version 1.3.0 - I believe this is the most recent version
2. The BSC201 is a single channel controller.
3. I am running the functions and controlling the stages through a parallels windows VM on a MacBook (everything runs fine so this shouldn't be a problem)

Thanks again for your support on this and please let me know if you have any other suggestions

Regards,
Manny

[AlexShkarin]

It looks like the device ignores commands. That's why homing command does not do anything, and all requests time out (the PC waits for a reply, but the device does not send anyhting back). I had one other user report this behavior as well, but we could not figure it out at the time.

Upon further look into the manual, it seems like it might be a destination address issue. To check this, we can try several commands with different addresses: the standard 0x50, the rack controller 0x11, and the first motor boards 0x21. We can start with the following set of commands:

stage_theta.send_comm(messageID=0x0434, dest=0x11)  # home motor
stage_theta.send_comm(messageID=0x0434, dest=0x21)
stage_theta.send_comm(messageID=0x0434, dest=0x50)
stage_theta.send_comm(messageID=0x0223, dest=0x11)  # blink lights
stage_theta.send_comm(messageID=0x0223, dest=0x21)
stage_theta.send_comm(messageID=0x0223, dest=0x50)

Could you try these 6 commands separately and see if any of them cause any reaction from the module? The first command (0x0434) is the same homing command as before, and the second (0x0223) is an "identify" command, which should cause the unit to light up, blink an LED, or something similar.

In addition, just to make sure that the device is fully oprational, can you confirm that you can communicate with it from the native software (Thorlabs APT or Thorlabs Kinesis), if it works for your PC setup?

[Em607867]

Alexey,

I tried all 6 commands with the different destinations and the device still seems to be ignoring the commands. No action or error messages.

I also confirmed the device is fully operational with the native Thorlabs Kinesis equipment and was able to perform all basic operations including homing and blinking functions above.

Are there any other forums where I can maybe get in contact with other users that may have faced these problems with specific stages to share knowledge/solutions?

[AlexShkarin]

Unfortunately, I don't know of any particular places where you can find information about such specific stages and issues. It is possible we can contact Thorlabs directly, but I'm not sure they would address such issues seeing how they're now more focused on the newer frameworks.

Another potential solution I saw after some search is related to RTSCTS flow control signals (which, apparently, it cares about, while most other Thorlabs devices don't). Hence, you can try the following sequence of commands:

import time
dev=Thorlabs.BasicKinesisDevice({"port":"40217214","rtscts":True})
time.sleep(0.1)
dev.instr.instr._flow=256
dev.instr.instr._setFlowControl()
time.sleep(0.1)
dev.instr.instr.flushInput()
dev.instr.instr.flushOutput()
time.sleep(0.1)
dev.instr.instr._flow=0
dev.instr.instr._setFlowControl()

That should cycle the specific low-level flow control signals in the device communication. After that the device might become responsive, and start reacting to all the usual commands, e.g. dev.send_comm(messageID=0x0434) for homing or dev.send_comm(messageID=0x0223) for blinking. I would appreciate if you could try these approach and see if it produces any effect.

[Em607867]

I just tried this and it worked!

Both functions worked. For the channel specific commands, I had to set the channel number (param 1 = 1). I will go ahead and try other commands from the APT manual and create some custom functions to automate the connected hardware.

Thanks so much for your assistance with this Alexey!

Best Regards,
Manny

[AlexShkarin]

Dear Manny,

Thank you for the update!

I've added this fix to the new library version 1.3.1. It's already available on PyPI and will be pushed to conda forge in the next day or so. I would appreciate if at some point you could update your pylablib version and see if BSC201 now works "out of the box", ideally even directly using the KinesisMotor class.

Sincerely,
Alexey.

[Em607867]

Hi Alexey,

I updated the library version and the BSC201 now works "out of the box" with APT commands and connects with KinesisMotor class. I tried most of the basic functions and they all work properly.

Thanks so much again for the support with this!

Best Regards,
Manny