Problem with RS 232 communication

[Scribeus]

Hi,

I'm programming a soft that have to communicate simultaneously with 5 devices through the RS232 port.
I'm using a 8 serial RS-232 PCI Card with an Octopus cable.

All devices are working correctly independently, but when i try to communicate with three or more devices simultaneously, the computer freezes after a time that vary from any seconds to 1h30. After the bug, i have to restart the computer because the mouse and keyboard are not more responding.

For this moment I think that the problem is due to the interruptions of the RS-232 ports in the PCI card, but I'm not sure! I don't understand why the software is working correctly during a more or less long time and then it freezes the computer...

Did you have already this problem or have you another idea to fix it?

thanks for your help

[tbob]

There could be a variety of reasons. Buffer overruns, CPU time being completely taken by one process, race conditions, all of these can cause lockups. Are you using hardware or software handshaking? Please post your code or a sample of it that causes the problem.

[Scribeus]

hi tbob,

I have to communicate with 3 kinds of devices (3 massflow controllers, 1 power Rf Generator and 1 adaptive pression regulator).

For the three massflows, there is a hardware handshake, but for the two other ones i have to do my own handshake with labview! But for the moment i didn't use any handshake. Could it be the origine of my problem? I don't think so... I think that if the buffer are overruns, i would have an error message on the screen and not a total computer freeze.

Yesterday, the soft worked correctly during more than 2h30 and after that it freezed again.

maybe i will try with handshake

[Scribeus]

I don't understand what is it "race condition"...

so i missed to join a part of my vi...

I have a master loop that have three levels of subvi's...

All the soft contains almost 20 subvi's so it's too heavy to transmit it here...

So i join the top-level vi and a third level subvi that show how i use the RS232 interface.

[Scribeus]

and the second subvi

[tbob]

First, I'll explain what a race condition is. Let's say you have two while loops running in parallel. One loop writes to a local variable, the other loop reads from the same local variable. Does the write take place before the read or does the read take place before the write? There is no guarantee which will occur first. In your main vi (Depositor), you have too many loops running in parallel. One loop writes to local variables (your interrupt loop with event structure). Then in the lower loop where you send setpoints to the MMX4000, you have the same local variables at several different sections. Did the event that wrote to the local occur before the local was read by the second loop? Maybe the first local in the second loop was read, then the event wrote to the variable, then the second local in the second loop was read. Do you understand what race conditions are now? You need to re-write your vi to try to include everything in as little number of loops as possible. Maybe a state machine would work best. See examples of state machines and how to program them.
Here are other hints for improvement. In the lower loop where you send setpoints, instead of having the same local variable (Write Setpoints and Enable LED) three or four times, just have one variable with wires going to three or four places. That way the variable is read only once, and this helps to eliminate race conditions. Also, in your interrupt event structure, you are performing the same action (Write Setpoints) for several events. Those can all be combined into one event. Go to Edit Cases Handled by this event, and click on the plus button. You can select many events to trigger the same action. This makes it easier to read and maintain. I wish I had more time to help you by re-writing the vi into an easier method while eliminating race conditions, but I don't have that much free time. Try the state machine where one state would be to send setpoints, one state would be to read values from the different generators, VATs, and whatever, and one state to read Menu inputs, one state to handle exiting the program, etc... Try it yourself first, and if you need more help, just ask.
Bonne Chance, et laissez les bons temps rouller!

[Scribeus]

Hi again tbob,

first of all thank you for your explanations...

I tried to use state machine as you said me on your last thread, but the problem is still the same... no amelioration!!!

So i join to this thread my new top-level vi and if you have anither ideas, you're welcome to advertise me!

Well, i'm almost sure that the problem is due to the HW and not the SW but now i think my vi is more readable as before (so i hope...)

[tbob]

You forgot to attach your new top level vi.

[Scribeus]

Oh, sorry...

here you are...

[tbob]

Your main vi looks better than before. The state machine helps to understand it better. In your state index=0, you call Subvi Read Actual Gas Flow.vi at three different places, all in parallel. The same vi gets called three times all at once. You should put Error In and Error Out in your subvi, then wire Error Out from the first call to Error In on the second call, and Error Out from the second call to Error In on the third call. This way, you are guaranteed that the second time the vi is called only happens after the first time is over, and so on. I think in your index=1 state, you have the same problem. I don't know that this will fix your problem. If your computer still locks up, you might want to try to communicate with one device only, then add another device, and so on until you find where the lock up occurs. Maybe you have a problem in one of your subvi's. I hope this helps.