ComRdByte with long timeout in seperate thread called with CreateThread freezes other threads

[Erwin Timmerman]

My application measures on samples that are moved around during measuring by a manipulator. This manipulator is controlled by a RS232 connection.

The basic measure procedure is, I start a DAQ thread, and I start up a seperate thread that moves the manipulator around, like "go left for 100 steps, go right 100 steps, go left.... etc". The manipulator gives back a certain character on the RS232 bus to indicate it has finished moving. I check for that character before giving it another command. Like "go left, wait, go right, wait, ..." The com timeout is set to 2 times the time that the move is expected to take.

The procedure that waits for the character is the following:

int WaitForChar(char Character)
{
char ReceivedChar = 0;

SetCtrlVal(CommPanel, WaitLedCID, 1);
while (ReceivedChar != Character) {
ReceivedChar = ComRdByte(Manip.ComPort);
if (ReceivedChar<0) {
SetCtrlVal(CommPanel, WaitLedCID, 0);
return (int)ReceivedChar;
}
}
SetCtrlVal(CommPanel, WaitLedCID, 0);
return 0;
}

However, when waiting, the wait thread suspends or severely slows down all other threads until it is finished. Even setting the thread priority to lowest doesn't help.

To make things more complicated, on several systems the application runs OK (the threads don't interfere with eachother, the other threads don't slow down), but on a fast system running XP the problem occurs. Which just so happens to be the measuring system...

I think this problem is related to another problem I posted over a week ago, about GPF's occuring when discarding panels that were loaded and deleted immediately in a thread called by CreateThread. This also worked fine on a slow W2k computer and crashed on a fast XP system.

At the time RikP, a NI tech thanked me, he could recreate the problem on one of their computers as well, and said he would keep me posted on this, but I guess they are still working on the problem (if this really is a bug it might be quite a hassle to find out what's really going on).

*Is* there a bug in LabWindows in connection with the windows SDK and fast computers running XP? I hope I didn't open a can of worms here... as more and more people will be using fast computers the problem will start to pop up all over the place, with programs they already use and worked fine on older computers.

I would like to have an update on the problem, if not on this board then through email, as it is affecting several parts of my programs already and the problem keeps spreading to more and more commands. Re-writing them all to work around the problems is quite a hassle, so I would like to know if there's a solution in the making any time soon.

Greetings,

Erwin Timmerman.

[JuanCarlos]

Hi Erwin,

First things first... I recreated the problem you mention in your other posting using CVI's threading functions and the GPF seems to be gone. Please take a look at the attached example.

This question may be too late, but is there a reason why to use SDK functions for threading instead of CVI's functions? CVI has a very complete set of functions that make things easy and are fully tested in the environment.

After testing the GPF stuff I modified the code to read something from the COM port with a long timeout value. Again I saw no effect on the second thread performance. You can use the example to demonstrate it. Again I'm using CVI's threading functions, not the SDK functions directly.

Please take a look at this code and give it a try.
I would appreciate if you could post the simplest code possible to replicate this performance issue. I can't assure you that it will be worked on since it involves SDK calls and not CVI functions; however I'll give that a try.

I hope this helps.

Keep me posted!

Juan Carlos
N.I.