Serial problem with LabWindows/CVI 8.0.1

[Patrawak]

I use LabWindows/CVI 8.0.1 in Borland C++ compilation mode under Windows XP Pro.

I try to update an very old serial link code, with feedback (RS Modbus),

which is perfectly works since 10 years in LabWindows/CVI 4.0.1 / 5.5.1 / 7.0.

The principle seems to be very simply :

- OpenComConfig(COM1, "COM1",9600,NONE_PARITY,8,1;512;512);

- for a reading or a writing mode:

  * ComWrt (COM1, Buffer[], Count);

  (* Delay)

  * ReceivedCount=GetInQLen (COM1); // by a loop with a "timout" and a Delay

  (* Delay)

  * if ReceivedCount enough

    then ComRd (COM1,Buffer[], ReceivedCount );

  * then special echo treatment on the "Buffer" for an acknowledge, and/or a data value (for a reading mode)

Sometime (80 %), all works correctly.

Sometime (20 %), the ONLY fact to go and run the "GetInQLen" function create a "none debbugging error"

and close the unproperly my LabWindows/CVI application.

I have reduced the problem with the "Delay" implementation, but it is not enough.

Can you help me please ?

Thanks a lot in advance for your help !

[Mert_A.]

It sounds like you are running into a race condition which is causing a crash in your program.  I'm not sure I understand the details of the problem, but if you can post a small example program that reproduces this crash, I can look into it further.  Also, it would be helpful if you could tell me the exact file version of C:\Windows\system32\cvirte.dll, just to confirm that it is 8.0.1 as you expect.

If this is indeed a race condition, then it likely involves the background writer thread that results from specifying a non-negative output queue size.  As a workaround, you can try passing -1 as the output queue size in OpenComConfig and see if that solves your problem.

Please do post back so I can help investigate.

Thanks.

Mert A.
National Instruments

[Patrawak]

Dear sir,

First, thanks a lot for your help.

Your right about the issue of LabWindows/CVI, it is 8.1.0.271 and not 8.01.

Yesterday with all the details, me and my friend have found on this forum,we have made more tests.

Today, we have always some few problems, but not the crash of our application.

First, we have try the change the technology, by NI-VISA.

It is works perfectly for 2 of my 3 machines.

  - OK for Eurotherm (Modbus protocol), and Alstom VTN COM  (Special modbus protocol).

  - NOK for Alstom MV 3000 C (????) (Modbus protocol, idem Eurotherm) :

     The first part of the message is correct (address, parameter, function R/W),

     but not the last part (data for reading, CRC).

So, we came back in the old protocle (RS-232).

- We have try to not use the "GetInQLen", only the "ComRd" in a loop.

 That it has resolved part of the problem (0% to 20% : OK).

- We have try the "-1" in the output queue size.

  I confirm that it has resolved a great part of the problem (20% to 60% : OK).

  Especially our crash application.

  But not all, especially in a heavy flow messages communication.

  Always and again with the Alstom MV 3000 C.

  Sometime, the echo message seems to be the previous answer,

  event the FlushInQ and FlushOutQ instruction.

- We have added some delay between each RS actions.

 That it has resolved part of the problem (60% to 70% : OK).

- We have added "ProcessSystemEvents" before the "GetInQLen".

 That it has increase the problem at each mouse moving (70% to 0% : OK).

In my example :

- See the "ConfigurerCom" to initialize the Modbus protocol

- See the "FermerCom" to close the Modbus protocol

- See the "LectureUneVoieRTU" to read a data by the Modbus protocol

- See the "EnvoieCommandeRTU" to write a data by the Modbus protocol

Again, thanks a lot for your help.

[menchar]

You should also be aware that NI appears to have substantially changed the rs-232 library in the 8.1 run time engine, and this is causing problems with many implementations.  While it may be true that the new serial library is, in fact, fully standards compliant, and that problems are with poorly implemented serial ports, I think NI is doing us a disservice by not being more forthcoming about the serial library changes.  As a practical matter, in the real world, not all com ports are implemented as well as they could be.

I suppose we can all run experiments and reverse engineer the changes.  Effectively, that's what you're doing here.  Or, just don't use the newer CVI releases.  I can't imagine that NI really wants to freeze developers using the rs-232 library at rev 8.0 or earlier because they've changed the serial library, even if, strictly speaking, the problem lies with other, non-NI stuff.

Apparently the library changes were in support of "real time" targets. 

If we knew some of the general characteristics of the changes NI induced in serial port behavior, we could better anticipate what we might have to do to get our various devices working.

I suspect that interframe timing has been shortened up - according to the rs-232 spec, you can start a frame immediately after the stop bit of the preceeding frame - and this is crossing up some of these devices that don't expect that.  Adding a stop bit on the sending side might help if that'sthe case.

rs-232/422/485 just isn't as exact of an interface as, say, IEEE 488, and I think greater accomodation by NI is needed to help us get past this. 

Why not offer an 8.1 runtime engine that doesn't use the newer serial library?  Make it a build option - "legacy" rs-232 library performance if you need it.

Menchar

[menchar]

I must have touched a sore spot with somebody at NI

[Patrawak]

Dear Mert,

Have you some ways of solutions about my problem from RS library (relative to my code previously sent)? Or some ideas to minimize risks of crashes? NI advices?

For explanation, we had to update and add new functions in our softwares test benches in CVI 8.1 for our customer (Valeo: 11 test benches qualifying products, automotive alternators, for their own customer PSA) and we have to supply softwares with high reliability and availability.

That's in this way that we have to find solution without risks of crashing...

Thanks a lot in advance for your help and for your advices.

[Mert_A.]

Patrawak,

If I understand, your code works correctly with two of your serial devices, but not with another one (Alstom MV 3000 C), and whether you use NI-VISA or the RS-232 library to control the communication, you have the same problems with that device.  If this is the case, then there is nothing I know to suggest to get it working.  I am not familiar with the various devices, so there is little light I can shed on the issue.  The only suggestion I can make is that if older versions of the CVI runtime engine (and RS-232 library) were working for you with all three devices, you might have to fall back on using an older version.  I am surprised, however that an old version of the runtime engine would work, when NI-VISA would not.

I'm sorry if I can't be more helpful.

Mert A.
National Instruments

[Patrawak]

Dear Mert,

Like I write you, my example works perfectly with the 3 devices with CVI 4.0.1 / 5.5.1 / 7.0,

with RS library ("GetInQLen" or "ComRd"), but not with CVI 8.1 ???

I did not test the VISA library with the 3 devices with CVI 4.0.1 / 5.5.1 / 7.0, only with CVI 8.1.

If I resume, with CVI 8.1, the problem is not the same if I use the RS library and the VISA library with the 3 devices.

- RS library with the 3 devices, I have the same problems with each device :

  * If I do not use -1 in the output queue size, I have many CVI crash in few time,

  * I have not the good feedback message (many time is the previous one),

    or sometime I have never feedback message.

- VISA library with the 3 devices, I have a problem with only one device :

  * Sometime I have never feedback message.

  * The 2nd part of feedback message is not correct.

I could not go back and install again CVI 7.0 because I use some new functionalties of CVI 8.1.

But if you able to give me a runtime with CVI 8.1 included RS library CVI 7.0, the light will swiche on agin ;-).

Thanks a lot.

[Mert_A.]

Patrawak,

The CVI 8.1.x runtime engine has a known race condition which can cause crashes when the output queue length is not specified as -1 (in OpenComConfig).  I recommend you make this change in your application, which will prevent the crashes and should not otherwise change the semantics of its operation.  Beyond that, your problems seem to be limited to your feedback messages being incorrect, or completely absent.  Without thoroughly debugging your application, I can't tell you what is going on with the echo.  The fact that the original messages are consistently sent correctly, and that there are echo issues even with NI-VISA lead me to suspect it is not an issue with the RS-232 library.  There may be other members of the community that may be able to share their experience and insight, like menchar has.  Or for a deeper investiagtion, you may wish to call NI's support department.  If you provide me with your email address, I may be able to send you a temporary solution.

Mert A.
National Instruments

[rjohnson]

I'm following this thread with interest.  

We use significant amount of RS232 devices and use CVI to run them through automated tests.

I know how frustrating intermittent RS232 problems can be.   they've made me want to pull my hair out.

Thankfully, I havent had any problems in this area with CVI, although I am using 8.0.1 (and 7.1 prior).

is this a common problem in 8.1?