High-speed polling using property nodes

[rolfk]

---

@Jonghao wrote:

@rolfk

Fortunately, I found the reference manual for my device.

https://www.thorlabs.com/Software/Motion%20Control/APT_Communications_Protocol.pdf

---

I'm impressed. My dealings with Thorlabs in the past were mixed. They have great hardware and their domain specific expertise in optics and motion are really good. The electrical and software side of things was however often a lot more tricky. And getting technical relevant information from them seemed very hard. Either the support did not understand what I wanted, or could not understand that someone would want to talk to their hardware on low level instead of using their ready made .Net software (that did frequently crash and could not be used on a Linux system either).

[tst]

---

@Jonghao wrote:

Fortunately, I found the reference manual for my device.

https://www.thorlabs.com/Software/Motion%20Control/APT_Communications_Protocol.pdf

Yes, that's the serial protocol I referred to.

Can you post exactly what you did to get it to work (ideally including code)?

I only remember that when I looked at it there were some complications which made me decide not to invest any time in getting it to work, as the .NET API was working and I didn't even have direct access to hardware at the time. Knowing what I have to do to get the serial protocol to work would make it easier to decide whether to transition to it in the future and not have to deal with the .NET API.

[Jonghao]

@tst

A breif explanation for the attached code. (LV 2015)

You need the FTDI driver (FTD2XX.dll) for this code, which is normally included in the Thorlabs APT or Kinesis software.

The 90 04 01 00 50 01 is the Request status update command,

and I read the position data from the status it returned using producer-consumer loop design.

The value 409.6 is the conversion ratio between encoder count and actual length(mm) and it may vary with each stage.

I set the latency timer of the USB-serial port to 2ms on the device manager for faster updates.

This results in the polling interval of roughly 4ms on average.

My original purpose was to prevent the polling from running in UI thread, and I think I achieved the goal.

The code shows that the polling interval is independant of front panel activities (dragging, clicking, or typing).

I hope that more people will be able to gain low-level control over Thorlabs hardware by referencing my code.

Any questions on the code are welcome.

[RIObotics]

Hi Jonghao, just curious, what would be your ideal speed for polling the position of the stage?  1ms (1kHz?)  Why would you need such high polling speed?  Would it be possible to attach another encoder to the stage, and use a data acquisition device?  (Well, this way is more expensive and troublesome, but just curious as to what your use case was.)

[Jonghao]

@RIObotics

As I mentioned in my original post, I aimed 5ms for polling interval.

I need such high speed because I am building a measurement system which logs the current position of the stage at high rate.

Adding an encoder is a good idea but as you mentioned, it is quite expensive and the position accuracy of the stage is good enough without an encoder for my purposes.

[tst]

---

@Jonghao wrote:

@tst

A breif explanation for the attached code. (LV 2015)

---

Yes, All the DLL calls are definitely more complicated than just using VISA and implementing the protocol. I remembered that there was some complexity, but didn't remember the details at all.

Thanks, I will file this away in case I ever do decide to use this (and the specific project where this was relevant is in LV 2015, so it's convenient that there's no need to backsave).