Author Topic: Debugging a RS485 connection  (Read 1566 times)

0 Members and 1 Guest are viewing this topic.

Offline tcurdtTopic starter

  • Contributor
  • Posts: 15
  • Country: de
Debugging a RS485 connection
« on: May 27, 2023, 06:33:48 pm »
I just cannot get this darn RS485 connection to work.

I have a YL620A VFD that speaks modbus and I am trying to read/write some parameters.
It's been a while but this was working on the bench. It no longer works in place.

I have factory reset the unit. Then set the baud rate to 9600 with 8N1.

I wasn't totally sure if the GND connection is needed but connected it as well.

The cable is shielded and connected to the housing.
That said - it used to work fine even without.
At least without the VFD running the motor.

Now it's a bit unclear which direction to connect A+B.

In one direction the RX LED is constantly on.
I am getting timeouts when reading.

In the other direction the TX LED is showing the requests being sent but it seems nothing gets received.
I am getting protocol corruption errors instead.
I suspect that's the correct wiring.

Unfortunately I don't have my oscilloscope at hand.

Any pointers or suggestions on how you would debug this?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Debugging a RS485 connection
« Reply #1 on: May 27, 2023, 07:11:15 pm »
Random things to try:

* Yes, you need the GND wire
* You need termination at both ends.
* You may also need biasing (misleadingly called fail-safe biasing in literature, but has nothing to do with failing safely, is required for normal operation) somewhere on the bus. Look it up!
* A/B nomenclature is messed up, different manufacturers follow different labeling. The only way is try swapping A/B until it works. Even if it's only two possibilities, the combination state space with everything else is large.
* Try different baudrates,
* number of stop bits,
* parity (no, even, odd)
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 5897
  • Country: ca
Re: Debugging a RS485 connection
« Reply #2 on: May 27, 2023, 09:59:11 pm »
full duplex or half duplex ?
 

Offline tcurdtTopic starter

  • Contributor
  • Posts: 15
  • Country: de
Re: Debugging a RS485 connection
« Reply #3 on: May 27, 2023, 11:23:44 pm »
Termination on both ends - even on short (as in 30cm) cables?
Maybe the VFD and the adapter already have termination built-in 🤔

Wouldn't I also need VCC for a bias network? I only have A, B and GND.

The RS485 to USB adapter is just wired 1:1.
It's just A, B and GND and should be half duplex.

 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13746
  • Country: gb
    • Mike's Electric Stuff
Re: Debugging a RS485 connection
« Reply #4 on: May 27, 2023, 11:39:22 pm »
Termination on both ends - even on short (as in 30cm) cables?
Not needed, but adviseable to have at least one terminator
RS485 is always half duplex, RS422 is full duplex - the diagram above implies that it has options for either. may also need a config/dipswitch setting to ell it which is in use
Quote
Wouldn't I also need VCC for a bias network? I only have A, B and GND.
Yes, but only at one place. You shouldn't normally need it as the transceivers  will usually go to an idle state on an undriven bus.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Georgy.Moshkin

  • Regular Contributor
  • *
  • Posts: 146
  • Country: hk
  • R&D Engineer
    • Electronic projects, modules and courses on Arduino and STM32
Re: Debugging a RS485 connection
« Reply #5 on: May 27, 2023, 11:41:40 pm »
I would 1) try to swap A and B
2) try to use other model of rs485 to usb converter
3) check with a scope if possible, if 485 interface converter designed improperly, there is a tiny possibility that removimg termination resisyor will make it work (I've seen this only with non-powered 232 to 485 converters though)

Offline tcurdtTopic starter

  • Contributor
  • Posts: 15
  • Country: de
Re: Debugging a RS485 connection
« Reply #6 on: May 27, 2023, 11:56:33 pm »
I would 1) try to swap A and B
2) try to use other model of rs485 to usb converter
3) check with a scope if possible, if 485 interface converter designed improperly, there is a tiny possibility that removimg termination resisyor will make it work (I've seen this only with non-powered 232 to 485 converters though)

1) Indeed - but swapping A and B I already did. See my original post. It's either timeout or corrupt protocol.
2) I had problems with a control board talking to the VFD and then switched to the usb converter. So that's already two clients having problems. And that very usb converter worked at some stage with that VFD.
3) I wish I had my scope around :-/

Couldn't I just measuring the resistance between A and B to find out if a termination is already in place?
I guess on an idle connection the voltage difference between A and B should be zero? Is there a defined voltage to ground?
Or is there any other test to see if the RS485 on the VFD just died?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Debugging a RS485 connection
« Reply #7 on: May 28, 2023, 07:33:55 am »
Termination on both ends - even on short (as in 30cm) cables?
Maybe the VFD and the adapter already have termination built-in 🤔

Wouldn't I also need VCC for a bias network? I only have A, B and GND.

The RS485 to USB adapter is just wired 1:1.
It's just A, B and GND and should be half duplex.

(Attachment Link)

If you have neither termination nor biasing, then idle state is high-impedance and picks up any random noise, even in good conditions. You rarely see a functional RS485 with no biasing nor termination at all. The receiver just sees random data all the time.

Maybe termination is internally available? RTFM or measure with a multimeter. An idle bus should read 50-60 ohms or so with the two terminations.

Termination may be enough to seemingly fix the issue as it brings the line impedance down by pulling the two lines semi strongly together. Whether it is enough then depends on the actual transceiver ICs used (their hysteresis levels) and amount of noise in the environment (i.e., might fail in presence of lot of noise). To make it more reliable even under normal conditions you then need to either add biasing or use special snowflake (biasing-free) transceivers on ALL nodes. Latter isn't usually possible as RS485 is meant for interconnecting existing devices with design not under your control. Even then, RS485 noise performance is an order of magnitude worse than often claimed.

No Vcc available? Can't bias then. Still need biasing as you usually do? Tough luck, it won't work at all or reliably. RS485 is a total disaster and utter failure, and you need to understand it and cope. It is sometimes said to be resilient in noisy conditions even with poor wiring, but in reality performance is total crap because of the biasing brainfart. Noise performance seems good on paper during transmission but real protocols like Modbus completely depend on detecting start conditions during line idle, and even with biasing the noise margin is an order of magnitude less than during transmit, some tens of mV. Without biasing, noise margin is negative i.e., if anything works at all, it's all due to luck.

CAN bus fixed all that crap in one go even though it uses very similar signalling by combining biasing and termination in two resistors per bus. And yes, if you try to run CAN with no termination at all, it will fail, too, and it has nothing to do with lacking termination - it's due to lacking biasing (double duty of the resistors).

And RS485 by definition is half-duplex. 1:1 (A->A, B->B, GND->GND) wiring might be a problem because the USB adapter might use different A/B notation compared to the device. As I said, there are two conflicting definitions so only way is to test swapping A/B. The problem here is, if you also test some other things, you need to repeat A/B swapping for each test case, i.e., run through all the combinations.

RS422 is fine because it's a single unidirectional link where transmitter can be kept active all the time so noise performance is excellent and no biasing is needed.

RS485 in industrial hardware environment is like Java or XML were in software world - a good job opportunity to keep field engineers who fix stuff that break employed.
« Last Edit: May 28, 2023, 10:50:32 am by Siwastaja »
 
The following users thanked this post: Wolfram

Offline WattsThat

  • Frequent Contributor
  • **
  • Posts: 766
  • Country: us
Re: Debugging a RS485 connection
« Reply #8 on: May 28, 2023, 11:40:07 am »
First, try a different usb<>485 convertor. You can have a bad or crappy 485 transceiver chip that can significantly reduce noise immunity. This can easily found with a scope so without one, substitution is all you have. I’d strongly suggest doing whatever you can to get your hands on a scope to test, it’s where you should start. Even one of those $30 eBay kit scopes will tell you what you need to know in this particular situation. For low speed serial communications, they’re all you need.

Based on the fact that things stop working only when the drive is modulating, I’d take a hard look at both input and output grounding. There are three ground/shield wires required (two that are ideally part of a VFD specific multiconductor cable). If you don’t use shielded VFD cable, you’ll have a nice high voltage noise generator and it will be impossible to get things noise free without proper grounding. Grounding is two types, functional grounding and safety grounding. The first two connections described below are functional grounds and provide both radiated and conducted noise mitigation. The third wire is safety only.

Ground/shield wire from grid source to frame of drive. Next, the drive frame to motor ground terminal. Lastly, a separate ground wire from motor frame to an earth rod, building ground or equivalent. This wire is a simple single conductor, not part of a shielded cable.

The last wire is only for personnel safety, the first two are for safety but more importantly, noise abatement. The continuous shield/ground connection from motor to drive and drive to source is all important for noise reduction as VFD’s generate some hellacious EMI due to the high voltages along with very high dv/dt. Without proper cabling, VFD’s can create or suffer from many well known but often ignored issues.

While it is a much deeper dive than required in this situation, a good hands on practical guide to VFD cabling can be found here:

https://library.e.abb.com/public/64a0f2f7292bcfd7c1257b3a003993ea/EN_Grounding_and_cabling_rev_C.pdf

 

Online tooki

  • Super Contributor
  • ***
  • Posts: 11500
  • Country: ch
Re: Debugging a RS485 connection
« Reply #9 on: May 28, 2023, 03:32:05 pm »
RS485 is always half duplex, RS422 is full duplex

And RS485 by definition is half-duplex.

This is incorrect.

While half-duplex, 2-wire RS485 is certainly far more common, 4-wire, full-duplex RS485 absolutely does exist. And while it is designed to be compatible with RS422 devices, it’s not RS422. The voltage levels are different (with RS485 being more tolerant on RX but tighter on TX), so while a 4-wire RS485 device complies with RS422, the reverse is not true.

See figure 3.2 and the surrounding text in https://www.ti.com/lit/an/slla272d/slla272d.pdf
 

Offline tcurdtTopic starter

  • Contributor
  • Posts: 15
  • Country: de
Re: Debugging a RS485 connection
« Reply #10 on: May 29, 2023, 12:32:37 pm »
I also tried again with another shorter cable (15cm) also switching around A/B.
Still the same behaviour.

Since I didn't bring a scope this time (argh!) the only thing I came up with is to measure the resistance between the lines (while disconnected).
It seems like the adapter and the board has termination built in.

Is there a way to tell if the the RS485 transceiver in the VFD left me for good?

 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Debugging a RS485 connection
« Reply #11 on: May 29, 2023, 12:36:15 pm »
Get a scope, that's the best way to see (A) if master is sending anything, (B) if the slave is trying to do anything after the master stops the poll message.

Is there some interface (DIP switches, LCD UI etc.) to configure the Modbus slave address of the inverter? If not, have you tried going through all (some 250 or so) valid slave addresses?
 

Offline tcurdtTopic starter

  • Contributor
  • Posts: 15
  • Country: de
Re: Debugging a RS485 connection
« Reply #12 on: May 29, 2023, 12:56:03 pm »
Get a scope, that's the best way to see (A) if master is sending anything, (B) if the slave is trying to do anything after the master stops the poll message.

Yeah, I will have to bring a scope next time around.
Apparently I was too optimistic.


Is there some interface (DIP switches, LCD UI etc.) to configure the Modbus slave address of the inverter?
If not, have you tried going through all (some 250 or so) valid slave addresses?

I have explicitly configured the slave address to 1 on the VFD.
So that should not be the problem.

But I guess there is no harm to go through all of the addresses anyway.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf