How can I know how much time it takes to turn around a 485 port that's in two-wire "auto-tx" mode?

[BSeegmiller]

When talking to one of our devices that expects to reply rapidly to a packet of data, the first few bytes back to the 435 card are sometimes lost. I haven't had this problem with a BlueHeat card (8-opus), nor with a B&B protocol converter. Our device replies as soon as it can, usually within one or two characters' time. This is at 115200 baud. Probably the 8430/4 (or -31) card.

[Chris_Rake]

Turn around time with vary greatly between different vendors. NI RS-485 cards typically have times on the order of a couple of bit-times. This can be measured with a scope and a couple of bias resistors - the line will return to the biased state once the transceiver turns off.

[BSeegmiller]

Okay. Installing termination greatly helped (duh!).

A related question: we're using the auto-mode of the RS-485. Trying to use the control-DTR just is odd. Does Win2K not allow sequential control of I/O lines and data throughput? What I mean is that a) raise DTR, b) send data, c) drop DTR. What I see on the scope is a brief blip on the data line, not even a full character sent out (this is at 115200 baud). The OS is W2K. LabVIEW is 7.1 (but what about 6.0?).

Many thanks

[Chris_Rake]

Unfortunately the driver doesn't serialize the data and modem lines, so some software timing will be required.

[BSeegmiller]

Rats. During some hyperactive browsing for modem-control lines and 485 equipment after seeing the problem, I seem to remember that W2K had better synchronization, but I've also read earlier (few yrs ago, pre-LabVIEW) that Windows generally didn't do modem lines well, but that was the earlier versions. This was pre-W2K, perhaps pre-NT 4.0.

Why is it that the modem-control is there in the driver if it doesn't work well under W2K? I'm going to hazard a guess that under LV RT, it works as would be expected.

We will continue to balance the lines until I make comparisons to Blue Heat cards, or the B&B & Telebyte devices 😕

Often, it's only the first couple of packets that get mangled.

Hmm, are there examples of softwa
re timing? How well does it work? The one-millisecond resolution of the clock wouldn't seem to be too useful, as that's too slow.

Thanks

[BSeegmiller]

Chris!

I just discovered something! This new system has LV 7.1, and I just had moved the VIs that were working on our 6.0 (6.0.2) system (both W2K), and I noticed that on the 7.1 system the read from the device is terminating on a new-line!! I have TermChar Enable = False, Suppress End Enable = True, and Send End Enable = False. It's behaving as if TermChar Enable were true. There's a sequence byte that increments every packet, so every 256 packets, the read ends short.

I am going to examine this some more. It may not be turn-around problem at all, although the DTR-controlled turn-around still intrigues me.

Bob

[Chris_Rake]

Hi Bob,

Just to rule out the hardware - have you been able to verify that the RS-485 line is being released by the PCI-8431 in time for your device to reply?

Can you post your vi?

[BSeegmiller]

How should I verify the timing? The scope snapshot seems to show that the line is released in time for the device to reply. We may have a problem with one of the ports on the board, but more on that down the road.

Here's a VI that didn't work -- it always terminated on a new-line, until I monkeyed with the VISA session tool of NIMAX. I found I had to set the Serial End Mode for reads to None or LastBit. I hadn't had to do that before, because the other termination settings seemed to work under 6.02. DTR seemed to have something to do with it, too. See what you can make of it. Are there updates to 7.1?

Thanks,