RS485 timing between switching to transmit mode, and sending of first bit

[Mads]

We are using the RS485 port on a cFP-2220 in 2-Wire Auto mode, and a client of ours has a master on the line that sometimes is unable to read the messages we send properly. We know that the messages are sent and can be received withour errors by other devices multidropped on the link, but this particular device fails to do so.

The client is claiming that their problem is that the RS-485 interface on the cFP-2220 is sending the start bit too quickly after grabbing the line. When they look at the line with an oscilloscope they measure that the cFP-2220 interface goes into transmit mode and then sends the first bit after 120 microseconds. Their equipment is for some reason unable to detect this bit unless this time is extended, and they want it to be as slow as 650 micorseconds.

Now I'm not an RS485 specialist, and I have not yet been able to dig up anything that proves or disproves that the cFP-2220 behaviour is borderline. So I'm wondering if anyone else has seen this before, and/or know of a way to get around it? My guess is that we do not have control over this, but perhaps we do...is there a configuration for it that can be set somewhere?

[cedhoc]

Hi MTO,

To be honest, my RS-485 knowledge is also limited, but I would suggest you to look at the following:

1. Can you check with your customer that it is not a biasing issue ? Check the following link --> http://digital.ni.com/public.nsf/allkb/0679387DD41986D18625770500662E24?OpenDocument

2. If the first link does not help, maybe you can try to switch from 2-Wire Auto mode to 2-Wire DTR Controlled mode (http://digital.ni.com/public.nsf/websearch/E905D94CF3C0601D862565EF004D5D7F?OpenDocument).

With this mode, you have to enable the driver in software by asserting the DTR line. You can then put some delay between the activation of the driver and the transmission of the data.

In Auto mode, there is, to my knowledge, no possibility to modify this delay.

Kind regards,

[Mads]

Thanks for the feedback Themanual approach using DTR does provide a solution.

We found out that with 2-wire Auto there is absolutely no idle time between the switch to transmit mode and thestart bit. Nothing....

Which seems quite dangerous. It might explain why some equipment is unable to read the traffic withour errors. I would love to hear from NI if thatis how it is supposed to be.Here is how it looks with auto:

There is no transition, the start bit just comes straigt away, followed by a 10000000.

Now, keeping everything else constant (termination etc.), we are indeed able to set the time by controlling DTR. If we set DTR to asserted 10 ms prior to VISA Write, and wait 50 ms afterwards before setting DTR to unasserted, we get this:

This looks much nicer.

Now one other thing that bothers me with this is that when you do a VISA write it sill return immediately, so if you just use data flow to set the DTR to unasserted you end up cutting off the transmission before even a single byte has been transmitted. This effect is illustrated above by the fact that the transmit mode stops about 50 ms after the start of the transmission, not 50 ms after the end...

To avoid corrupting the transmission we have to calculate th time it will take to actually push the given message out on the port at the given baud rate (based on its length), then insert a wait between the VISA Write and the DTR property node that corresponds to that time....It would have been much safer and more flexible if the DTR propertydid not execute untilthe write operation was safely completed.

Here is a nice illustration of what we are talking about by the way, the lack of zone B and E (B being the most important one...):

http://www.chipkin.com/rs485-on-a-scope/