Turning a motor on that uses RS485 modbus communication

[ZeTeX]

Hello,

I have a DC motor model m3g084-fa22-16, like in this video:


The motor uses RJ-45 connector, with RS-485 communication protocol, to control the RPM and to start the motor on-off, from a control board.

However, I need to find a way to turn the motor on/off without RPM control, and without the RS-485 communication from the board, or at least find the data used to turn the motor on.
The reason for this is that the control board is not working, and it is replaced completely with a mechanical solution, not electronics, in a combi steamer. But replacing the motor to a simple asynchronous AC motor is quite expensive, and since the DC motor works, it might not be necessary.

basically, make it so the motor works just by a switch, that turns it on and off. But there is no manual instruction for the motor on the web, and I'm not sure how it could be done.

One way might be to "sniff" the data the control board sends to the motor with RS-485, and then send the data using a micro-controller for example.
if so, would buying an RS485 to USB converter on eBay, and downloading software to show the data, connecting to other working control board and sniffing the data the control board sends via the protocol and then sending this data by an Arduino for example, would work?

Thanks.

[ZeTeX]

No ideas?

Sent from my LG-H815 using Tapatalk

[Ian.M]

 I wouldn't gamble on a RS485 to USB converter getting the job done as you wont get anything useful in the PC terminal program if the bus uses an odd-ball baud rate or encoding/framing.

Got a DSO, preferably with protocol decoding that includes async and sync serial formats?   If so that will do nicely to 'sniff' the bus, and identify the encoding or framing being used over the RS-485 physical layer.  If the encoding/framing is one the scope's decoder supports, you'll be able to identify the commands to send directly.

If you don't have a protocol decoder post the best quality scope screenshots you can and ask for help working it out.   If you don't have a scope, get a cheap Salae Logic 8 clone (to use with the open source Sigrok software) and a RS-485 transceiver breakout board to convert the bus to logic signals.  You'll need the transceiver anyway for the Arduino.

[ZeTeX]

I wouldn't gamble on a RS485 to USB converter getting the job done as you wont get anything useful in the PC terminal program if the bus uses an odd-ball baud rate or encoding/framing.

Got a DSO, preferably with protocol decoding that includes async and sync serial formats?   If so that will do nicely to 'sniff' the bus, and identify the encoding or framing being used over the RS-485 physical layer.  If the encoding/framing is one the scope's decoder supports, you'll be able to identify the commands to send directly.

If you don't have a protocol decoder post the best quality scope screenshots you can and ask for help working it out.   If you don't have a scope, get a cheap Salae Logic 8 clone (to use with the open source Sigrok software) and a RS-485 transceiver breakout board to convert the bus to logic signals.  You'll need the transceiver anyway for the Arduino.

I have a scope, Rigol DS1054.
However, I noticed a slight issue. it turns out there is no standard pinout for RS485 RJ45. How can I know which 2 pins are +/-RX and +/- TX?

[ajb]

Can you reverse engineer the PCB?  There are tons of RS485 transceivers on the market, but mostly they're SO8 packages that will be somewhere near the connector.  Note that there may be only one bidirectional pair, or there may be two separate pairs for transmit and receive.  If there are separate fixed-direction pairs there will be two separate transceivers or a separate transmitter and receiver (in the latter case, they might be SOT6 packages instead of SO8).

Otherwise, probe the various pin combinations and see if you can find valid idle voltages anywhere, and if that doesn't work, you're only option is to start poking it and see what happens. 

Ideally, though, you want to find a working system and monitor its bus transactions, that's hands down going to be the easiest way to figure out how to control the motor.

[ZeTeX]

Can you reverse engineer the PCB?  There are tons of RS485 transceivers on the market, but mostly they're SO8 packages that will be somewhere near the connector.  Note that there may be only one bidirectional pair, or there may be two separate pairs for transmit and receive.  If there are separate fixed-direction pairs there will be two separate transceivers or a separate transmitter and receiver (in the latter case, they might be SOT6 packages instead of SO8).

Otherwise, probe the various pin combinations and see if you can find valid idle voltages anywhere, and if that doesn't work, you're only option is to start poking it and see what happens. 

Ideally, though, you want to find a working system and monitor its bus transactions, that's hands down going to be the easiest way to figure out how to control the motor.

it's a big PCB that is designed specifically so it will be hard to reverse engineer. You'd expect that for a motor designed by a good German company there will be some data on the site, but there isn't any data, maybe because they make the motor especially for "rational". But "rational" doesn't provide any info and don't answer back in the e-mail I sent them.

There is indeed SO8 near the connector. its an "SN65LBC180 Low-Power Differential Line Driver And Receiver Pair". Looking at the datasheet there are 4 pins: A, B, Z, Y. But I don't see at the datasheet what every letter means. I'm not even sure what this IC does. there is some type of clear coating on the PCB, so I can't probe easily because it does not make contact.
http://www.ti.com/product/SN65LBC180

[T3sl4co1l]

ComTestPro may prove handy if you get communication working.

Tim

[ajb]

There is indeed SO8 near the connector. its an "SN65LBC180 Low-Power Differential Line Driver And Receiver Pair". Looking at the datasheet there are 4 pins: A, B, Z, Y. But I don't see at the datasheet what every letter means. I'm not even sure what this IC does. there is some type of clear coating on the PCB, so I can't probe easily because it does not make contact.
http://www.ti.com/product/SN65LBC180

That's your transceiver.  The A/B/Z/Y notation isn't 100% consistent regarding direction and polarity, but the logic diagram in that datasheet shows what's going on.  A and B are inputs into a buffer, so those are the receive lines.  Z and Y are the outputs of a buffer, so those are the transmit lines.  Z and B have inversion dots, so those are the inverted sides of their respective differential pairs.  So next you just need to figure out how those pins map to the connector.  It should be possible to remove enough conformal coating to get meter probes on the connector and the IC pins, and then a continuity test should show you what's what.  Note that the transmit and receive pairs on the IC could be connected to each other if they only bring out a single bidirectional pair.  There may be protection/filter components between the IC and the connector, but these should not interfere with a basic continuity test.

[rf+tech]

ZeTeX,

RS485 (and 422) use differential signaling, for improved common mode interference rejection (and other benefits) over that of single-ended RS232. Running RS485 in single-ended mode defeats this advantage.

In differential mode, both halves, Tx+/Tx- and Rx+/Rx- of both transceivers must be functional. If, say, TX- on the controller side is dead, the motor side transceiver will not respond to the controller.

First thing to test, if you haven’t already, is the electrical interface between the two ends. Take an RJ-45 patch cable, cut it in two. Strip a bit of insulation from each conductor, then solder the cut conductors back together. The splices create convenient access points to sniff communication.

Set up the scope with two probes and look for differential signals. For each low-to-high transition found on one conductor, a matching high-to-low transition on another conductor should be observed. (Do mind where the probe earth leads are connected.)

With a little effort, all four signals should be observed: Tx+ Tx- Rx+ Rx-    and you're set for protocol decoding.

If any one of these four signals is missing, the fault may simply be the transceiver (SN65LBC180) on one of the two ends. 

RF+ Tech

[ZeTeX]

I did some testing.
A and B are not connected to any pin in the RJ45 connector.. weird.
Z and Y are connected. I connected the scope to the Z and Y pins, from the control board, and noticed some data was begin sent from the control board. However the motor was not connected at all, it was only connected to the scope. I can connect it to the motor, but the control board won't turn the motor on because there must be 2 motors and I only have 1 for testing.

I can provide a picture of the data with the timing between pulses and pulse length if needed, I'm not sure how to decode it, or even if I should.
but that means I only found 2 wires, which are the transmit from the control board to the motor..

I'm in a problem.. I must get other motor and make sure I can run them using the control board, or else there won't be the data that makes the motor turn on..

[rf+tech]

Okay, good start, but this is odd that A B inputs seem to be unused. Let’s just say that “fire and forget” without feedback is not expected bus behavior.

Two-wire RS485 would use one Tx and one Rx on the controller and all nodes. Recheck the RJ-45 connections to the chip. Either A and Y, or B and Z, would be required for two-wire communication.

The next steps should be to trace out the copper track paths from transceiver A B inputs looking for any additional components that might be in series to the RJ-45. Establishing the bus as either two-wire, or four-wire, is first priority.

As for needing a second motor connected, the video shows a single motor node and single controller. The empty RJ-45 connector on the motor node is for daisy-chain connection to additional motor node(s). A second motor node would certainly aid identifying which of the two parts are defective.

Since RS485 supports multi-point networking, each node is required to have a unique address.

Now the question becomes “how is the node ID set on each motor (DIP switches or EEPROM?) and has this particular motor lost its ID setting, or have an incorrect ID?”

Much time can be wasted studying the protocol only to find the problem extraneous. Also, it is not of much use to look at the controller, without the motor connected. How can one learn if the motor node is trying to reply with an error code, or garbage data?

More information about the specific application can provide additional clues and better guide troubleshooting.

RF+ Tech