LabView COM acess problem

[Eric Forton]

I access a RS485 programmable controller via a RS232 converter.
I wrote LabView routines that work efficiently on my laptop (WinMe) and on another computer (Win98se) (one at a time, of course), but NOT on a third PC (win98se), wich is required to control my device because other hardware is installed on it.
The diagnostic is the following:
Proprietary program from the constructor is working on that computer;
Com port is seen by NI-MAX; I can write on the port (bytes written output is non-zero)
My device doesn't see anything, and doesn't respond.
I checked again with the proprietary program, no settings were changed on the controller.
I tried again on other computers: it works under LabView and the proprietary prog.
I tried
after restarting the computer, and with LabView running alone: doesn't work.
O tried to install a card with additionnal COM ports: the card is installed, proprietary program runs on any of the new ports, wich are seen by NI-MAX, but nothing encouraging under LabView...

Any idea, anyone?

[Ben]

"Any idea?"

Check the deatisl of your 232 to 485 converter. Some use the handshaking lines to control transmit and recieve.

Check the default flow control settings of things like DTR, RTS, etc on the machines that work and compare with the one that does not.

Ben

[Chris_Rake]

You should also be using VISA, as it will help assure consistant behavior between OS'es.

[Eric Forton]

Hello Ben, hello Chris,

First, thanks for your answers.

I had a look at the port settings, and these seem to be the same as on "good" computers. I guess if the problem had been there, I'd also encounter problems with the non-LabVIEW program...

Also, I use VISA in my VI (you can have a look at the file).

Thanks anyway!
Eric.

[Ben]

Hi Eric,

I just wrote a driver for a Yokogawa temperature controller about 2 months ago.

You may want to shut-off the checksum in the controller, and just skip that part when writing.

Ben

[Ben]

Also,

If the converter does not use DTR/DSR make sure you disable that using VISA.

Ben

[Ray K]

Have you tried running a simple loopback on the third PC to verify LabVIEW can communicate with the serial port? (Short pins 2&3)
Loopback Test for Serial Port

If it can communicate, run NI-SPY on the working and non working computer and to see what command fails. If you have visual studio you can run this program I wrote to quickly show you the differences between two spy captures.
Compare the Differences Between Two NI Spy Captures

Ray K
NI Applications Engineer

[Eric Forton]

Hello,

Thanks for all these advices.

As you recommended, I first tried the loopback software. It works fine indeed.

After this, I compared the spy captures on 2 PC's, with my software.
The writing sequence works fine on both, but the differences appear when I attempt to find the number of bytes at the serial port:
On the non-working pc, there's one step missing!
(step 21 in captureok.txt => in capture.txt, step 21
correspond to step 22)
Of course, after there's no reading, and the program ends fine, but with no data.
Do you think it's a problem in my VI library? (in VISA bytes at port, wich is not used by the loopback program)
Maybe it's worth a try just to reinstall it?

[Ray K]

Hello Eric,
Add a wait before reading the number of bytes at the port. If you expect a particular number of bytes, you can also loop until that exact number of bytes are at the port. Your new computer is probably faster and is executing your code faster. You are reading the number of bytes at the port before any of the bytes get there.
Ray K
NI Applications Engineer

[Eric Forton]

Hello Ray,

No, I don't think this is the problem... In fact the code runs OK on the faster computers!

Furthermore, I put a wait before reading the # of bytes at port... I even tried waiting times up to 10 or 20 seconds (on my laptop, I have to wait 300ms for the longest response possible).

This is really puzzling me.

What I've seen in the spy captures (look at my latest comment on answers) is the there's a step missing on the "non-working" PC (I think it's the bytes at port command that doesn't respond, but if I try to read a couple of bytes without this bytes at port routine, I don't get anything anyway)
=> I'll try to re-install the serial communication routines (maybe there's stg wrong there), but I'm not really convinced about the meth
od.

My code is already on the discussion forum in previous answers.

Thanks for your help anyway, I'll keep the comments up to date if I find stg.

Eric.