Re : Serial problem with LabWindows/CVI 8.0.1

[Mert_A.]

Sounds like you don't have much to go on at this point; if you later learn something that can help us make a fix, please do let us know.

Regarding the FlushOutQ behavior, the bytes already in the output queue will either all be written or none will be written.  The crash I talke about earlier in the thread occurs when an unfortunately timed flush sets the output queue size to 0, and we try to shift the remaining bytes in the queue. When we calculate the number of bytes to shift, we get a negative number which underflows and we end up trying to move a huge block of memory. Hello, GPF.

Mert A.
National Instruments

[jr_2005]

---

@Mert A. wrote:
Well, the CVI RS-232 library is written on top of the Windows SDK, so driver-level behaviors like stop bit handling are below its scope and should not be affected by an upgrade from 8.0.x to 8.1.x.

Mert A.
National Instruments

---

Well I don't think this is entirely true: for example I would expect the CVI library to call the SDK function SetCommState() at some point. The DCB structure thus passed to Windows to configure the port includes a field fAbortOnError. It is entirely possible that previous CVI library versions could have set this field to ignore device errors (including framing errors), while a new library might have a stricter regime and set the field such that the low level driver does check for such errors, in conjunction with ClearCommError().

Then again, it could be something else altogether...

JR

[Patrawak]

Dear Mert,

Link you ask me the 06/20/2007, follows my email :

Patrick BRESSAN
Software Department Responsible
Society CAPRA
Email : softdept@capra.com

To be clear, on the same PC with the same OS (Windows XP Pro SP2),

if I install LabWindows/CVI 7.0, my example works perfectly with the 3 differents devices (with the RS library).

In the same day, iIf I take out LabWindows/CVI 7.0 (and drivers), and put LabWindows/CVI 8.1 (and drivers).

The same code does not works (with the RS library).

For me, that is really and only a problem of National Instruments.

Be sur about that.

Today to works on my customer benches with LabWindows/CVI 8.1, I must send the same message

between 1 to 6 times (that takes a lot time) to be sur to have a good feedback

(always the same function, the same code).

In LabWindows/CVI 7.0, only once was necessary. 

N.B. : Come back in LabWindows/CVI 7.0 is impossible.

Thanks a lot.

[menchar]

Yup - looking at the SDK comm port calls that's a plausible scenario, JR.  Maybe Mert can assure us that isn't what's happened
But I think it's unlikely, as even if the 8.0 library does not abort on error (and if 8.1 does), and "undetected" low level errors were occuring, the CRC in our messaging would fail on 8.0 as well.

We don't normally check for parity / framing / overrun errors if we're using a CRC.

It's a dilemma at times whether or not to use an NI library / function or code to the Win32 SDK directly.  If it's an area that I know well, I tend to code to the SDK and pass on the NI method.  If there's behavior that matters and you can't tell what NI did in their code, you can spin your wheels trying to run down problems by reverse engineering the NI behavior.  On the other hand, if the NI function works, and there are no behavioral nuances to worry about, it's often simpler to use.  I've never felt the urge to use the Win32 SDK Comm functions directly in CVI.  The CVI rs-232 library looks like it has pretty good coverage of the Comm calls/functionality.

I am still curious as to what NI changed to adapt the serial library for a "real time" target.  This is key to understanding the problem from a top down perspective.  Somebody at NI surely knows exactly what changed and what effects it may have imposed on Windows serial i/o at a lower level.

Menchar

[Mert_A.]

Because the PharLap real-time operating system does not include a serial driver, supporting the CVI RS-232 library on that platform involved implementing on top of NI-VISA, which uses the NI-Serial driver.  In order to ensure that the two implmentations behaved as similarly as possible, the VISA-based implementation was interwoven with the existing Win32 implementation.  Doing so required some seemingly innocuous refactoring and other minor changes, though it turns out this has affected behavior in some cases.

As far as whether errror checking/enforcement got stricter somewhere, it's possible, but I would not expect that to be the case.  It's something we'll keep an eye out for while we reexamine the changes.

Mert A.
National Instruments

[Mert_A.]

Patrawak,

I have a possible explanation for why you sometimes never see an echo, assuming it only happens when you use ComRd instead of GetInQLen to poll the input queue.  In your code, you have a loop that repeatedly calls

NbCarRecu=ComRd(NumCom, MaReponse, NbCar);

If the response is received in multiple pieces, and there is a delay of 0.5 seconds (your timeout) between them, ComRd could return after reading only part of the response. If this happened, then your loop would not break until the max iterations had been reached, because (NbCarRecu<NbCar) would never be true.  Your program would interpret this as not having received an echo.  It seems unlikely that there would be a 0.5 sec delay between pieces of the message, but you can easily test this by increasing the timeout to something like 5 seconds, or by using GetInQLen.

So far, I have been unable to find an explanation for why you would be getting "stale" echos up to 5 times in a row.  It would help to clarify some details about the devices and your setup. 

1. Do your devices only send data in response to a message, and only once per received message?
2. The example you posted writes a command only once, when a button is pushed.  In your acutal appliction, do you have a loop that attempts a write repeatedly until the echo is correct?
3. Both LectureUneVoieRTU and EnvoieCommandeRTU seem to do similar things: they call ComWrt to send some message, then they wait for an echo.  Is there a difference that is relevant for me to understand?

Would it be possible to configure the communication to use 2 stop bits?  That might help determine whether framing is a factor.

Mert A.
National Instruments

Message Edited by Mert A. on 06-22-2007 06:05 PM

[Patrawak]

Dear Mert,

My main is to use a GetInQLen function without any delay.

But with the various bugs and crashs, I have try to find an other solution

with the ComRd function.

Even with a great time out with the ComRd and GetInQLen functions,

the NbCarRecu stay always at 0.

Never between 1 to NbCar-1.

Unfortunaly for me.

Not in my example, but in my final application, tobe sur of that,

I have create a spy file for each RS function.

I have already think about what you write and the fact that I could

reveived a part of the message.

But it is never the case, NbCarRecu=0 or NbCarRecu=NbCar, nothing else.

It is not a perfect example, just severals various code application.

I have a loop for waiting the echo (NbTentatives), and an other to try

to send again the message (NbFois) in case of no sucess in the first one.

I have 2 kinds of message :

- To pass an order or to write in a parameter (EnvoieCommandeRTU) :

  I send the message and the device must answer me that same message more 1 caracter.

  If it does, that wanted to say that it understood the message.

- To take a mesure or to read in a parameter (LectureUneVoieRTU) :

  I send the message and the device must answer me that same header message more the data.

I can not change the configuration, beacuse I have several devices in the same RS-485 line.

Some are not configurable ones.

I have also an other information, for the one which to not work with NI-VISA in my customer site.

In my society, I have the same device but alone on the RS-485 line.

And the NI-VISA function works with it in CVI 8.1.

I must make more tests in the following days.

[menchar]

More info on the problem we're seeing with CVI 8.1 communication with a Xilinx UartLite IP Core serial port implementation in an FPGA.

For lab use, the FPGA designers were using a freeware utility "Tera Terminal" to communicate with the device over the com port.  I noticed they were inserting a 1 msec delay in between each character when writing from the PC to the device! 

When I asked "why are you inserting a 1 msec delay in between frames on a com port running at 115,200 bps?" they said, "1 msec is the smallest interframe delay available with Tera Terminal" (!).  They would have used a smaller delay if they could have they said (!)

This re-inforces my guess that the Xilinx implementation is weak and CVI 8.1 is now able to squirt out enough frames in rapid succession that it breaks the UartLite.  Or, as may be more likely, the UartLite IP Core implementation is OK, but the next layer of in-house FPGA design is weak and isn't able to pick up every frame off the UartLite.

Menchar

[menchar]

More info-

We recently acquired a Xilinx implementation that uses UART Lite IP core, from another organization, and it works just fine with CVI 8.1 RTE at 115,200 bps.  So I think the ills we were seing with CVI 8.1 RTE on the Xilinx com port are our implementation problems, not something wrong with the CVI RTE.

However, we did encounter yet another weirdness with CVI  and serial I/O, though this may mostly be an OS issue.

I tried configuring an ordinary PC serial port (COM1) with a 50,000 byte input buffer and no output buffer.  It's connected to a device that generates data nearly continuously.  I peridically install a callback to look for a specific character, and to read (and discard) the inqueue contents when the inqueue gets half full if the character hasn't been received.

So long as some other application has opened and configured the serial port since PC bootup, the CVI app works just fine.  The OpenComConfig call with the 50,000 input queue returns with out error.  The special character is reliably detected by the callback.

However, if the CVI app is the first to configure the com port after boot, all of the serial I/O fails, without any error indication, including all output.

I changed the OpenComConfig call to request 4096 bytes inqueue, and then everything succeeds, even if the CVI app is the first to run after boot.  8192 bytes of inqueue fails as before.

The OS is WinXP SP2.

Can anyone explain this behavior?  Should I consider bypassing the CVI rs-232 library and coding directly to the Win32 API?  Are there API error returns getting masked by the CVI library?

Thanks,

Menchar

[Mert_A.]

Hi Menchar,

I'm glad we finally got some fairly convincing evidence that the troubles you were having were not a bug in the CVI RTE, though I realize that an upgrade problem is still an unpgrade problem, regardless of where it comes from.  I'm sorry about that.

As for your new issue, I don't think any Windows API errors are being ignored.  Specifically, I confirmed that the call to SetupComm that configures the buffer sizes is properly being error checked.  The CreateFile call is being checked for INVALID_HANDLE_VALUE as well.  It does not look like the Windows API is reporting any kind of error to the library.  I would suggest writing some bare-bones Windows API code to test whether the problem is with the system, or with the RS-232 library.  When you say that all I/O fails, do you mean that nothing appears to arrive at the port, and nothing that is seemingly written ever reaches the other end of the serial cable?  If you're using a output queue (worker writer thread), I'd try calling GetOutQLen to see if your output isn't stuck sitting around in the queue for some reason.

Mert A.
National Instruments