Is it possible to send a break character in RS485 2-wire AUTO mode?

[Coatesy]

I am trying to send a data stream to a device connected to a 4-port NI RS485 Serial card. So far I am unable to send any break characters using ComBreak(); and I cannot yet determine why - I have managed this in Echo mode but I need it to work in Auto mode. My data is transmitted using 230400 baud, 1 start bit, 1 stop bit, 8 data bits and even parity. Any help will be great, thanks.

[JonBowers]

Hi,

I have been having a look into this and its seems that there is some difference in implementing the break function. I connected an the TX lines of an RS485 port up to a scope and in four wire mode there was no problem in sending the break. In two wire DTR Controlled with and without echo the break is sent as long as flow control is set to DTR/DSR. In two wire Auto I did not see the break no matter what flow control was used.

Did you specify any flow control?

Regards

Jon B
Applications Engineer
NIUK

[Coatesy]

I apologise for not stating I am running in half-duplex mode only. I have obtained the same results as you, and have tried to set the DTS line in software, along with the wire modes. In 4-wire and 2-wire with and without echo I can send data to the device using the break-packet sequence and the device responds, but only 1 byte is sent. It is as if the computer takes control of the line before the data is fully transmitted back to the computer.

The connected hardware has been tested in its final configuration and it has been shown that the commands I am trying to send to it through CVI do yield a valid result. I am not ruling out a programming error on that side but I'd be suprised if that is the case :-P.

Does your experiment suggest that Labwindows/CVI or the hardware is incapable of sending break sequences in 2-Wire Auto mode, and if so is this deliberate?

Thankyou for your help, it is greatly appreciated.

[Stuart_R]

Hi Peter,

I was going to send you an email but thought its a better idea to post here so that the community has visibility of the issue.

As I have seen the code that you have been using, I would rule out programming error as there didn't seem to be anything obvious. We've actually been using a piece of LabVIEW code for testing this out and that is structured very similar to the C equivalent.

It would look like a hardware limitation rather than anything else, especially if we are both seeing the same results. I'm going to try and find out more detail and get back to you when I have something.

Is there anyway that the microcontroller can be reconfigured so that instead of the break command signalling the start of a 'packet' some other method can be incorporated?

Anyway, I'll see what else we can find out and get back to you soon.

Thanks,

Stuart

[Coatesy]

Unfortunately it is impossible to remove the break character from the protocol as the project is getting near to completion and a lot of other hardware utilises it. In hindsight I would have preferred to do it another way but then that wasn't my decision. Thanks

[SachaE]

Hi,

  just to keep you updated, the developers in the US are still working on a fix for this situation at the minute.

Sorry for the delay, but given your situation with the project deadlines, there's little we can do here until they've developed a solution.

Thanks

Sacha Emery
National Instruments (UK)

[SachaE]

Hi,

  as a possible suggestion, the developers have asked if you can you try raising the DTR line manually?

Should be done from a visa set attribute call like

viSetAttribute (objHdl, VI_ATTR_ASRL_DTR_STATE, VI_STATE_ASSERTED);

Please let me know if that helps.

Thanks

Sacha Emery
National Instruments (uk)