You can see the bus released when it gets back to a +0.4V or similar between the messages, as the result of the fail-safe bias. I did not replace the power supply of the master and slaves, I replaced a power supply for different purposes. And though I see that the new power supply is causing my trouble I just do not understand why.

I'm confused by your post #15 Oscope captures. RS422/485 should nominally have 2.5 volts as a virtual ground. If I'm interpreting your scope capture, it's swinging positive and negative with as you say 0.4v the nominal ground reference. What am I missing here? As long as you're staying within in the common mode ability of the receiver, RS485 is extremely error free bit rate. But that does require your ground references between the bus transceivers to have a low impedance reference to this common ground. If DC currents and spikes from switched loads is causing IR drops that exceed the common mode receiver's ability, then you will have bit errors. What size ground wire is connecting the +5/+12 supplies from their source? And what current spikes are the remote slaves switching. Or am I totally misunderstanding your problem here? If the remote slaves are connected to some local ground that could have negative effects if that has large offsets between these units. This could be offsets from the AC mains power ground currents (neutral wire offsets).
On edit, is the scope ground reference giving some offset to the bus signal?

 

I'm confused by your post #15 Oscope captures. RS422/485 should nominally have 2.5 volts as a virtual ground. If I'm interpreting your scope capture, it's swinging positive and negative with as you say 0.4v the nominal ground reference. What am I missing here? As long as you're staying within in the common mode ability of the receiver, RS485 is extremely error free bit rate. But that does require your ground references between the bus transceivers to have a low impedance reference to this common ground. If DC currents and spikes from switched loads is causing IR drops that exceed the common mode receiver's ability, then you will have bit errors. What size ground wire is connecting the +5/+12 supplies from their source? And what current spikes are the remote slaves switching. Or am I totally misunderstanding your problem here? If the remote slaves are connected to some local ground that could have negative effects if that has large offsets between these units. This could be offsets from the AC mains power ground currents (neutral wire offsets).
On edit, is the scope ground reference giving some offset to the bus signal?

All bus captures were taken using a differential probe negative connected to RS485 A, positive connected to RS485 B terminals. So not between GND and RS485 A, for example. All the GND and power wires are AWG17 (1mm²) at this 35-40m length. Since the GND wires are shared, there must be a voltage drop. I do not know exactly how much, but since I measure 4.5V on the 5V line, I assume a maximum of 0.5V.

I had it running for more than a year, without problems. (Even if the signal levels were degraded, as show in post #15, I had no bit errors.) My problem is shown in my post #1. How the fluctuation of the 12V voltage (and probably current) level can cause such a distortion? If it results to a fluctuation say 1V on the GND level, I should see that fluctuation by measuring on the GND and 5V connections. But I can see a fairly stable 4.5V. It is clearly seen that I have bit error (post #1), because the slave signal does not go negative when transmitting zero. How is it possible when I have a fairly stable 4.5V on the transceiver?

(I checked the voltage levels by connecting the scope ground reference to the GND. Maybe this is the reason why I see the 5V stable during this time?)
(I go and check the power levels using the differential probe....)

 

All bus captures were taken using a differential probe negative connected to RS485 A, positive connected to RS485 B terminals. So not between GND and RS485 A, for example. All the GND and power wires are AWG17 (1mm²) at this 35-40m length. Since the GND wires are shared, there must be a voltage drop. I do not know exactly how much, but since I measure 4.5V on the 5V line, I assume a maximum of 0.5V.

I had it running for more than a year, without problems. (Even if the signal levels were degraded, as show in post #15, I had no bit errors.) My problem is shown in my post #1. How the fluctuation of the 12V voltage (and probably current) level can cause such a distortion? If it results to a fluctuation say 1V on the GND level, I should see that fluctuation by measuring on the GND and 5V connections. But I can see a fairly stable 4.5V. It is clearly seen that I have bit error (post #1), because the slave signal does not go negative when transmitting zero. How is it possible when I have a fairly stable 4.5V on the transceiver?

(I checked the voltage levels by connecting the scope ground reference to the GND. Maybe this is the reason why I see the 5V stable during this time?)
(I go and check the power levels using the differential probe....)

It would be good to see the signals relative to local ground, to see if you're outside the CMRR of the receiver's local reference. If you use the differential probe, with one lead on the local ground and the other on signal (Phase A, then phase B of the RS485) that may give some insight to why you're seeing a bit error. You may have to monitor this to capture what ever your remote slave units are doing over time. I'm guessing you're exceeding the CMRR of the RS485 transceiver. Is the UART flagging a framing fault or other error in the status register?

I've been working with RS485 currently with a power meter that uses that bus (KWS-AC301L from AliExpress seller), and found that I needed a Saleae pro 8bit logic analyzer to make sense of the bus traffic (the Oscope capture range to decode the async serial was too short for 30 seconds of bus traffic, found a used one on eBay, still $175 but worth it). It was more to figure out the MODBUS-RTU bus traffic, as the power meters have a PC program to display the data, and I want to remote read them and wirelessly send data to a collection PC for file storage. For reference MODBUS does not use parity in the async protocol.
I'm not dealing with remote power supply offsets, but I was seeing bit dropouts, as the UARTS were loosing data. (software bug).

 

It would be good to see the signals relative to local ground, to see if you're outside the CMRR of the receiver's local reference. If you use the differential probe, with one lead on the local ground and the other on signal (Phase A, then phase B of the RS485) that may give some insight to why you're seeing a bit error. You may have to monitor this to capture what ever your remote slave units are doing over time. I'm guessing you're exceeding the CMRR of the RS485 transceiver. Is the UART flagging a framing fault or other error in the status register?

I've been working with RS485 currently with a power meter that uses that bus (KWS-AC301L from AliExpress seller), and found that I needed a Saleae pro 8bit logic analyzer to make sense of the bus traffic (the Oscope capture range to decode the async serial was too short for 30 seconds of bus traffic, found a used one on eBay, still $175 but worth it). It was more to figure out the MODBUS-RTU bus traffic, as the power meters have a PC program to display the data, and I want to remote read them and wirelessly send data to a collection PC for file storage. For reference MODBUS does not use parity in the async protocol.
I'm not dealing with remote power supply offsets, but I was seeing bit dropouts, as the UARTS were loosing data. (software bug).

OK, I used the differential probe to check the power, seen attached. The 5V now has a 0.5Vpp wave on top, so this must mean that some device near the master connects the GND to protective earth. When I used normal probe I probably allowed current to flow on protective earth wires.

I also checked the RS485 A and B lines referenced to ground. As I understand, the B terminal should be more positive when a zero signal is sent. However this clearly moves back to 1V, which looks to be the minimum voltage. It is easy to see, because during the communication I have much more zeros than ones. But this also happens on A terminal when one is transmitted. It tends going back to 1V. If I have at least 4V at the transceiver, this should just not happen. I guess.

 

I've been working with RS485 currently with a power meter that uses that bus (KWS-AC301L from AliExpress seller), and found that I needed a Saleae pro 8bit logic analyzer to make sense of the bus traffic (the Oscope capture range to decode the async serial was too short for 30 seconds of bus traffic, found a used one on eBay, still $175 but worth it). It was more to figure out the MODBUS-RTU bus traffic, as the power meters have a PC program to display the data, and I want to remote read them and wirelessly send data to a collection PC for file storage. For reference MODBUS does not use parity in the async protocol.
I'm not dealing with remote power supply offsets, but I was seeing bit dropouts, as the UARTS were loosing data. (software bug).

The data is very simple, so in my case I can clearly see it on the scope. Even when the signals are weak, it tries to send the right thing. But when both RS485 A and B terminal moves back to 1V (referenced to GND) and the voltage difference ceases, then obviously the master is unable to receive data. It is clearly seen that it timeouts (releasing the line for a while).

 

OK, I used the differential probe to check the power, seen attached. The 5V now has a 0.5Vpp wave on top, so this must mean that some device near the master connects the GND to protective earth. When I used normal probe I probably allowed current to flow on protective earth wires.

I also checked the RS485 A and B lines referenced to ground. As I understand, the B terminal should be more positive when a zero signal is sent. However this clearly moves back to 1V, which looks to be the minimum voltage. It is easy to see, because during the communication I have much more zeros than ones. But this also happens on A terminal when one is transmitted. It tends going back to 1V. If I have at least 4V at the transceiver, this should just not happen. I guess.

What happens when you put the A and B line on the same scope view, and see where they cross differentially, as well as all the noise. Is it possible that noise is making it past the comparitor input for the bus, and causing some false clocks into the UART? That noise is pretty darn wicked.
For reference here's a screen shot capture of the Saleae. It captures with an analog ADC, then translates it to a digital signal.

The A0 is connected to the A phase, and the A1 to the B phase of the bus.

I can zoom out on the logic analyzer and catch a mess of bus traffic.


I would be very worried about that bus noise you're seeing, and what they do when the differential bus comparitor is triggered by this. I've seen lots of weird UART problems over the years with noise on the square edge transistion clocking in unwanted bits, and causing data upset, in my case parity was turned on, so the data was thrown away, and bus sync was lost.
I wonder what is causing that. Might want to try some small capacitors if you can find a quiet ground to couple that noise too.
I'm not trying to sell you on the Saleae, it's pricey for a one off problem. But I wanted to show a quiet bus operation and proper voltage swings.

 

What happens when you put the A and B line on the same scope view, and see where they cross differentially, as well as all the noise. Is it possible that noise is making it past the comparitor input for the bus, and causing some false clocks into the UART? That noise is pretty darn wicked.
For reference here's a screen shot capture of the Saleae. It captures with an analog ADC, then translates it to a digital signal. View attachment 257101

The A0 is connected to the A phase, and the A1 to the B phase of the bus.

I can zoom out on the logic analyzer and catch a mess of bus traffic.
View attachment 257100

I would be very worried about that bus noise you're seeing, and what they do when the differential bus comparitor is triggered by this. I've seen lots of weird UART problems over the years with noise on the square edge transistion clocking in unwanted bits, and causing data upset, in my case parity was turned on, so the data was thrown away, and bus sync was lost.
I wonder what is causing that. Might want to try some small capacitors if you can find a quiet ground to couple that noise too.
I'm not trying to sell you on the Saleae, it's pricey for a one off problem. But I wanted to show a quiet bus operation and proper voltage swings.

As seen on your image, you also have around 3.5V voltages on phase A and B depending on the zeros or ones transmitted. This is also I see with the master and also the slave can do it with a separate power supply, as seen in post #15. So this is the right level.

When I check the bus with the probe on A and B, I basically check the differential voltage (same if I checked both signals referenced to GND), and it is clear that the slave sometimes does not go to negative when zero is transmitted. This obviously leads to error.

My idea is that the transceiver is not responding to the low supply linearly. When it has 5V, it puts the 3.5V on the line, but when it has 4V it would not put 2.5V, but much lower voltage. So it amplifies the supply error, this is why I see much bigger amplitudes on the line, compared to what I see on the power supply. This could be proved, but now I focus on fixing the 12V supply to eliminate the errors. What I learnt is that the transceivers need a good stable supply, so the right thing to do in the future to prepare the power locally.

Anyway, thank you for all your comments, it is good to see that there are pro software around if you really want to analyze the line.