Control of Thorlabs K10CR1 cage rotor device blocking entire VI

[Oldbhoy]

Hi all,

Rather specific issue but I wonder if anyone has had similar problems. Trying to determine if this is expected behaviour in Labview or if something else is at play.

I'm using a K10CR1 motor device from Thorlabs (https://www.thorlabs.com/thorproduct.cfm?partnumber=K10CR1/M) in a microscope beam path to control some polarization optics. Thorlabs provide the device drivers, which can be accessed in LabVIEW using .NET controls.

I've placed a snippet below to show the basic device pairing, based on a pdf guide provided by Thorlabs (link to pdf: https://www.thorlabs.com/Software/Motion%20Control/Kinesis/Kinesis-labview.pdf ). Once paired, the device is homed when the software starts, and the user can command the device to move to a certain angle.

This device is being controlled as part of a larger LabVIEW package which controls a number of devices via serial/usb connections etc. I've designed the software in an event-driven, producer-consumer style messaging system, and there are a number of different threads controlling various aspects of the system.

Up until now, the design meant that all hardware could be controlled asynchronously, with no blocking of the user interface when devices are being accessed. Whenever the K10CR1 is accessed however, it appears to block the entire VI. This is despite the fact it's in a sub-thread of the program, and so the event and message-passing loops are completely separate.

I dont know much about accessing devices through .NET, but is this expected behaviour? Is this an aspect of LabVIEW or more likely something to do with the Kinesis drivers themselves? And is there a way to circumvent this blocking?

Thanks very much for your help

[astro_naut]

Hi,

Are you getting any error? 

You can try monitoring the processe : How to Use Process Monitor to Capture a LabVIEW Crash - National Instruments

[astro_naut]

Also check this thread

https://lavag.org/topic/15998-explanation-of-labview-execution-systems-and-thread-priorities/ 

[Jjohnn]

I have been doing LabVIEW coding for several different Kinesis device families.  The vast array of .Net functions and lack of documentation is maddening.

I wrote code using a .Net object constructor on the block diagram instead of one in a front panel container, which may have added to my problems.

Most of the Kinesis devices seem to take a while to connect and configure.  It may be that your code is being held up by one of these delays.

I found a c-code example in the Kinesis help files for most of the device families I was using.  They usually had timer delays between certain function calls during connection and configuration.

I used these examples as a template for my LabVIEW code and my code began working as expected.  I  wired the LabVIEW Stall Data Flow.vim (found in the timing palette) into the error in/out between the functions calls that had timer delays in the C-code and set the delays to match the C-code examples.  Presumably LabVIEW will relinquish time during the delays (not sure).

Not sure if this will help...

[neogilab]

Hi Oldbhoy,

Would you mind sharing the VI file?