High-speed polling using property nodes

[Jonghao]

I am making a program to control a Thorlabs linear stage (LTS150).

I want to poll the current position of the stage as frequent as possible. (about 5ms)

However, the Thorlabs stage control/position acquisition is done using property/invoke nodes through APT or Kinesis.

To my knowledge, reading and writing values from property/invoke nodes is done in the single-threaded user interface thread.

Time-consuming front panel processes such as object highlighting might take some time to execute in the UI thread, which in turn slows down the position data acquisition.

I tried using "defer front panel updates" property to stop front panel update during acquisition, and then allowing updates at once after the acquisition.

However since the "defer front panel updates" is itself a property node, doing this repeatedly in a loop also takes some time.

Is there a way to avoid such problem?

If I make a sub VI including the position acquisition invoke node, will it solve my problem?

I am not sure about this but if the front panel of the sub VI is not open, the invoke node might not run in the UI thread. (I may be wrong)

[mcduff]

---

@Jonghao wrote:

I am making a program to control a Thorlabs linear stage (LTS150).

I want to poll the current position of the stage as frequent as possible. (about 5ms)

However, the Thorlabs stage control/position acquisition is done using property/invoke nodes through APT or Kinesis.

---

It is my understanding that Thorlabs has a .NET API that you are accessing for control in LabVIEW. These property nodes/methods look similar to the ones you use for control references, but they are not the same. For calling external code, you can tell LabVIEW to call it in any thread if it is thread safe, otherwise it is called in the UI thread. I do not know how to do the same or check for .NET nodes like the ones you have from Thorlabs.

[Jonghao]

---

---

---

For calling external code, you can tell LabVIEW to call it in any thread if it is thread safe, otherwise it is called in the UI thread.

---

Thank you for the reply. 

Can someone tell me how this is done?

I am not seeing any settings which let me to decide which thread to run.

EDIT:

I figured it out on how to set it to any thread for "call library function".

However, I am still wondering on how to do simillar thing for the .NET property/invoke nodes.

[tst · Accepted solution]

Whatever happens, you don't have direct control of threading in LV. As mentioned, for C DLL calls you can specify running in the UI thread or in any thread, but it doesn't let you control which thread it will run in and there is no parallel option for .NET.

What you can do is indeed move the code into a subVI and change the execution properties of that VI to run in a different execution system and at a higher priority. This still isn't controlling which thread it's in (and some things are forced into the UI thread anyway if you have UI updates), but it is an option for possibly having it execute in a different thread.

Note that in any case, Windows is not a real-time OS and you don't get any guarantee about whether you will have the CPU available or how long the execution actually takes. I would suggest starting with a simple example where you check only how fast you can poll without anything else running. You might find out that you can't reach your 5ms target anyway.

Also, I would check the API to see if there might be a function for reading a buffer of positions. If there is, you might be able to let the controller itself hold the data and read it with fewer calls. Another option is a serial protocol that Thorlabs has for some of the devices, but I haven't worked with it, so I don't know the details.

I can say that their .NET API was a bit of a pain (for example, I haven't been able to get it to work reliably without using the .NET UI control for initializing the object and I had to have *ALL* of their DLLs in the main project folder or in the EXE's folder even though they have a program which supposedly lets you get just the required DLLs).

[rolfk]

.Net nodes do not have such an option. The .Net assembly tells LabVIEW if it’s classes are thread safe and LabVIEW simply believes the assembly setting since the creator of that assembly is hopefully knowledgeable enough to set this right.

Some don’t worry however and simply set it to require single threading. It is the safe and easy thing to do and saves lots of testing 😀

[Jonghao]

@tst

I tried putting the polling portion of my code(including the position invoke node) into a sub VI.

It turns out that the result is the same even though I set the priority to time-critical, and execution system as data acquisition.

You are also true that I might not be able to reach my 5ms target.

I checked the minimum polling interval and it shows that polling interval is always a multiple of 16ms.

I suspect this is due to the latency timer of the FTDI chip used in Thorlabs controllers, which is set to 16ms by default.

Unfortunately, it seems that there is no function that lets me reduce this value, nor they have the buffering option you mentioned.

Guess I have to do the hard way and try the serial communication method.

Thanks for the reply.

[LLindenbauer]

---

@Jonghao wrote:

I checked the minimum polling interval and it shows that polling interval is always a multiple of 16ms.

I suspect this is due to the latency timer of the FTDI chip used in Thorlabs controllers, which is set to 16ms by default.

Unfortunately, it seems that there is no function that lets me reduce this value, nor they have the buffering option you mentioned.

If you are using Windows, that setting is accessible in the device manager for the Virtual COM Port (or directly in the registry as seen here: https://forums.ni.com/t5/LabVIEW/Can-I-change-default-settings-for-Windows-Serial-Latency-times/m-p/... ). Of course, the Thorlabs driver might overwrite the value, but you can give it a try. Also, FTDI has an API of their own to programmatically configure their chips (D2XX and D3XX https://ftdichip.com/drivers/d2xx-drivers/ ), if you have to go that route.

[Jonghao]

@LLindenbauer

Yes, I am using Windows and I have already changed the latency value to 2ms in the device manager.

I also double-checked the registry to make sure the change is indeed done.

However as you mentioned, it seems that the Thorlabs driver overwrites the value, hense the 16ms minimum polling time.

I am trying to use the FTDI API you mentioned to somehow "recreate from scratch" the Thorlabs functions.

That way, I hope I can realize same functions without having it run at the UI thread.

Thank you.

[rolfk]

---

@Jonghao wrote:

I am trying to use the FTDI API you mentioned to somehow "recreate from scratch" the Thorlabs functions.

That way, I hope I can realize same functions without having it run at the UI thread.

---

That's only an option if you have the actual protocol description of the device. What exact API you would have to use depends on what the Thorlabs device presents itself for. If it pretends to be a RS-232 serial device, you would actually use the VISA functions with the FTDI VCP driver (standard available in Windows if the hardware manufacturer doesn't use its own Product and Vendor ID in the chip).

If it is instead using some kind of direct hardware interface such as I2C or SPI or the parallel bitbang method, you would indeed need the FTDI D2xx driver and possibly the MPSSE driver on top of it to access the device.

However if the device is using one of the lower level interfaces it is very unlikely that you can find any Programmer Reference Manual that describes how you could communicate with the device yourself. If it is a virtual RS-232 device, and you can find the according Programmer Reference Manual from Thorlabs, you are "almost" done. You "only" have to implement the according commands and response parsing on top of VISA and all is fine! But nowadays many manufacturers treat their Programmer Reference Manual as if it is the most precious information that could be found for their hardware and they will only give it to you if you sign away your house, car and all your children to them. 😁 If you even can get hold of a support person who knows what a Programmer Reference Manual means. 

[Jonghao]

@rolfk

Fortunately, I found the reference manual for my device.

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

After that I tried both methods (VCP and D2xx).

I connected the COM input for the linear stage into VISA functions, but it seems that I can't write to the COM port.

The connection itself seems fine (I also checked with MAX VISA test panel), but whenever I send bytes according to the manual, it returns nothing to the read function.

Also immediately after writing the command, the device becomes unrecognizable and I was not able to communicate with the device even using the .NET API which I used originally.

This is strange because even though it is not responding, the connection seems normal in the device manager and the MAX VISA test panel.

Only unplugging and replugging the power line of the linear stage fixed the error.

My theory is that this has something to do with enumeration which is mentioned in page 32 at the manual above. (not sure)

Anyway, I moved on to the D2XX method and downloaded the corresponding driver.

I also found the manual regarding the FTDI D2XX driver.

https://ftdichip.com/wp-content/uploads/2020/08/D2XX_Programmers_GuideFT_000071.pdf

The enumeration was done as stated in the Thorlabs manual.

I used Call Library Function to call D2XX functions in the DLL to LabVIEW, and it worked as I expected.

The good news is that the reading can poll more frequently (2~5ms) as the latency timer I mentioned earlier is not overwritten now.

It may take some time to convert the whole linear stage control program with .NET APIs into D2XX functions, but at least I think it is possible.

I'm glad that Thorlabs provided the reference manual without making me sell my house! lol

Anyways thank you for the detailed reply.