Over exuberant multithreading in LV8.6 causing i/o problems?

[Alexybeetle]

This is a new problem that appears in LV8.6 but not LV8.5.1.

I am using third-party labview instrument driver software to access some equipment via the RS232 serial port.  This software uses a non-reentrant subvi (BusCommand.vi) to control access to the communications port from a number of different high-level vis, and I have been using this subvi in my own control software which is also running in parallel. 

The communications subvi has some error handling built in which will throw up a message box if there is a problem with communication.  

When a separate window is launched from the original top level vi using the VI server, and this new vi also accesses BusCommand.vi, it produces an error, similar to what happens if two processes are trying to access the serial port at the same time.  Needless to say this is a big problem, as the protection afforded by the non-reentrance is what keeps the whole thing working properly.

I have tried adding semaphores to the communications subvi, but this doesn't seem to work.

I have a feeling that the new version of Labview is trying to be as parallel as possible, and BusCommand.vi is being launched in different threads at the same time, which is causing problems, particularly since it is running on a quad-core processor.

Is there a way to force a particular VI to stay in a single thread (other than flagging it as non-reentrant)?  I don't want to modify the third party software if I can help it, as that would invalidate their technical support (who are now aware of this problem), but I need it to work, and run sensibly alongside my software!

[Alexybeetle]

By the way, the most common error message is

"RS232 BusCommand.vi
Error -1073807253 occurred at an unidentified location

Possible reason(s):

VISA: (Hex 0xBFFF006B) A framing error occurred during 
transfer."

[Albert.Geven]

If  you are running both programs in the same LabVIEW development environment, you have indeed found a problem.

But if you are running in two projects, maybe LabVIEW can have both vi's running in parallel and I also don't like it.

Can you explain a bit more about the exactt situation?

[Alexybeetle]

Yes I am running them both in the same development environment.

 The situation is as follows:

There is an instrument with many remote controlled valves and settings, which is controlled via RS232, or manually by physically pushing buttons.  There is a "Main panel.vi" which reads all of the instrument settings, and allows the user to remotely control various switches etc. directly on its front panel.  To change other settings, when a button is pressed on "Main panel.vi" it launches a separate vi "settings panel.vi" using VI server, and returns to its previous activity. Settings panel.vi also reads from the instrument, and if you modify a setting and press OK, it sends the new settings and shuts its own panel.

Both  "Main panel.vi" and "settings panel.vi" call  a single, non-reentrant subvi "BusCommand.vi" (by inline node, not vi server) to do all communications with the instrument.  All goes smoothly until "settings panel.vi" is closed (this seems to be important).  After that, Buscommand.vi kept giving timeout and framing errors.

I tried using the following logging file dropped into BusCommand.vi which wrote to a text file what the call chain was:

 (n.b. the first call=true case just has the file refnum input disconnected)

Now the interesting thing about this was the resulting log file showed no calls from "settings panel.vi" until I rewrote it to open and close the file reference on each call.

I realise I was a bit hasty upgrading to 8.6 (but I didn't want to wait for 20 minutes for a statechart to compile!), but I would really like to find a workaround for this since my own code is all in 8.6 and I don't seem to be able to save for the previous version properly.  I am using source control, but I have added a lot of new things since I upgraded from 8.5.1 to 8.6 so I don't want to have to roll back and start again (which would involve a lot of slow statechart compiling).

I have tried surrounding the BusCommand.vi code in a single iteration timed loop set to manually use processor 0, but that doesn't seem to make any difference.

Alex 

Quickpost this image to Myspace, Digg, Facebook, and others!

[Albert.Geven]

try to not Close the settings panel but simply hide it, somewhere next the screen.

It looks like closing this panel sends a break signal on the serial line. That could cause a framing error.

[Alexybeetle]

Well I can't really do that unfortunately, as it is built in to the behaviour of the third party software and I don't want to muck about with that too much.  The closing is done programatically by the settings panel.vi itself, and should be sensible.  Also why would anything have changed in 8.6?

[Albert.Geven]

It should not have changed in 8.6 but it has as you noticed. All I'm trying to do is to find out what has changed.

Can you post the settings panel ?

[Alexybeetle]

---

Alexybeetle wrote:

Now the interesting thing about this was the resulting log file showed no calls from "settings panel.vi" until I rewrote it to open and close the file reference on each call.

---

Sorry you should ignore that, I checked again and there were calls from both vi's logged.

[Alexybeetle]

I'd rather not post it on a public forum, as it is proprietary software, and part of a much larger suite.  I have contacted NI directly by email though.  

Message Edited by Alexybeetle on 11-25-2008 05:03 AM

[Alexybeetle]

Change Settings.vi shuts itself down by calling the attached subvi, and passing its own name to it.  The viRefbuffer.vi checks that it is not needed elsewhere I think, if it returns true, then the calling vi is not aborted.

This subvi is run after a structure containing the communication code finishes executing.

Quickpost this image to Myspace, Digg, Facebook, and others!