.NET invoke node "set wavelength" function freezing LabVIEW

[Sean_S]

Hello LabVIEW community,

This is my first time posting to the forum.

Hardware: Newport Oriel CS 260 monochromator, NI MyDAQ, Hamamatsu HC 120-05 photomultiplier tube, Dell PC i5 with 8 gigs RAM

Software: LabVIEW 2017

This is my first time using LabVIEW. I am doing a project in my physical chemistry program to develop an interface for a Newport Oriel CS 260 monochromator to turn it into a scanning spectrometer. The end goal is to produce a high resolution spectrum of iodine vapor, but that is besides the point. I have completed the goal of developing the interface but I am running into one issue that I cannot figure out and neither can my professor who I am doing the project for. I am using a .NET invoke node to access the "set wavelength" function within a loop to create the ability of a scan. As the scan progresses it will inevitably freeze. When I select the Highlight Execution button to see what is going wrong I see that everything is fine except for the Set Wavelength invoke node. It is highlighted to show that data has flowed into it but nothing is flowing out. The two outputs, reference out and error out, are grey and the program is now frozen. I cannot abort execution of the VI, there is no error message, I must use task manager to end LabVIEW, then restart the program and the monochromator to attempt another scan.

As far as troubleshooting goes I have switched computers, which increased the average length of the scans I can achieve before freezing, but freezing is still inevitable. I have placed a time delay in the loop. I have tried switching the preferred execution system to user interface, this changes the nature of the crash. Instead of just freezing it causes the whole block diagram to grey out and a (not responding) appears at the top of the screen by the title of the VI.

At this point I have no idea what to do. In advance I appreciate anyone taking the time to read and reply, if I need to provide an extra information or attachements please let me know I will do so promptly. Thank you!

-Sean

[Gregory]

Welcome to the forums!

It looks like Newport distributes "Mono term" software written in LabVIEW, have you tried that already instead of the Cornerstone DLL?

It could be freezing because of a bug in the DLL, but let's pretend that's not the case right now. I would recommend using shift registers for the input and output pairs of your for loop. Otherwise, if your for loop runs zero times (N=0) you will lose the reference. Have you tried longer than 10ms wait times?

I can poke around your code a little more if you upload for LV 2016 or earlier. If you are using a project (.lvproj) just go to File >> Save for previous version... If you're not using a project, create one and drag all your files in their first.

[Sean_S]

Hello and thank you for the response!

I just spent some time toying with the mono term software. I had to download it from the Newport website and it did not come with all the necessary files to run the VI. I will attempt to work with this again when I have some more time. 

I am using shift registers for all input/output pairs in all my loops. I have tried increasing the wait time in every loop in all VI's up to 1 sec and it does not fix the problem. 

I have attached a LabVIEW 16 project with the main program, all sub Vi's and the DLL. I hope I did that correctly, I am unfamiliar with the LabVIEW Project format. I apologize if I messed that up. Thank you very much for taking the time to help!

-Sean

[JÞB]

There is a .net GC Collect method.  Sometimes it can be helpful. 

My knowledge is limited to practical experience. 

[tyk007]

My understanding is that when you run in Highlight Execution mode you are asking LabVIEW to forget about its inherent multi-threading capabilities and run exclusively in the User-Interface thread. That includes .NET assembly calls, like that Invoke node, in presumably the 'Cornerstone.dll' assembly (I don't have LV2017 either).

So I suggest that the User Interface thread is being consumed by the .NET call, is not returning in a timely fashion, and is thus unable to respond to any of your commands on the UI. So I would contact the supplier to see if they can assist you. In the interim however:

I had a look at the source for the "bool setWavelength(double wavelength)" method I can see that it could be a communications or compatibility issue with the device:

• It enables a handshake and waits for a response (this could take up to 500ms - waitTime = 10ms and dev_timeout = 500ms)
• It sends a command "GOWAVE xxx" where xxx is the value you provided. If there is not a reasonable response (a response that starts with a '0') or if there is no valid response then it could wait a long, long time to get said response. I suspect that this is where you are getting stuck.
• It disables a handshake and waits for a response (this could take up to 500ms)setWavelength method getResponse method

However it does also have some measure of debugging built in, provided another thread can be spared to do so. It appears as if debugging messages are pumped to an internal field "lastMessage" and retrievable through the getLastMessage method. The messages are not buffered and are overridden as a new one is created, so it is important to retrieve the latest message before it is overridden.

getLastMessage method

If you have Visual Studio (Community version would suffice) then you could use that to debug the call provided you have installed a dis-assembler. Otherwise, if you have just LabVIEW, then you need to set up a crude test so that you can call that getMessage method in parallel to your other setWavelength call, retrieve the last message (string) and save that into a buffer so that you can look at the entire history.

[Sean_S]

Thank you for the reply/advice, I will look into this!

[Sean_S]

Thank you very much for taking the time to look into this issue im having. I will have a meeting with my lab partner and professor soon to discuss the aspects and possible solutions you have brought up.

I really appreciate all the feedback on this post!

-Sean