Electronic – Connecting RS-485 devices transparently

communicationrs485serialserial-bus

I have a main computer that has a RS-485 board. It communicates with its sub systems via this comminication board.
I have also a test computer thas connected to main board via RS-485 channel. It will be used for test and update the sub systems using this RS-485 channels.

I want the main computer behave transparently to test computer so that the main computer wouldn't know about test algoritm. I don't want to update the main computer when the test algorithms change.
If I'd designed my hardware I would use a FPGA to connect test computer to sub systems physically so that the test computer would connect the sub systems directly and the main computer wouldn't know about tests, but I use standart computer and a communication card.

What would you do to connect the test computer and the sub systems without adding test related algorithms to main computer.

block diagram

Best Answer

Well, there are a lot of possible solutions... but you haven't given enough information really on what the communication looks like between the test computer and the subsystems. Is this entirely up to you on what to implement? I'm going to assume it is, but the solution would probably change if the protocol over RS485 is already defined or selected.

Most communications protocols at this sort of level will contain some type of addressing built in.

If you're comfortable with sending binary structures around, then just define a structure that every message starts with that contains:

  • The length in bytes of the entire message
  • The address of the subsystem you are trying to talk TO
  • The address of the subsystem you are talking FROM (optional)
  • The command you are trying to issue to the subsystem

You would start every message with this header, then pass any needed data, and finally you would optionally (but it's highly recommended on RS485-style links) send a checksum or CRC of the header and data.

The main computer at that point doesn't need to do anything but read the message header, see the length, and pass that to the appropriate subsystem. It doesn't even have to know where the addresses are... you could simply broadcast the message to all three subsystems. As the commands change and the data changes the message format does not... so the main computer's logic can remain the same.

The response from the subsystem should be in the same format.

It's useful to put the address of the FROM node in so that the subsystem knows who to reply back to. In some situations that's never going to change so you can hard code that. I usually prefer to put the FROM node address in anyway as you never know how the network topology might change later on.

On last thing. Since you're calling this the "main computer", I'm assuming you may be talking about a real PC. With real PCs running a modern OS like Windows, OS/X, or Linux you're going to have latency in how quickly the application on that computer can respond... so build appropriately large timeouts into your protocol. Many serial-based protocols are a real pain in the butt on modern PCs due to tight timeouts allowed on responses, etc. You probably couldn't pass MODBUS through a modern PC in the way you describe, for example... at least not without either special serial device drivers or violating the timing (which is sometimes okay for fixed solutions) By the time the main computer read the response from the test computer, broadcast it to the subsystems, got the responses, and rebroadcast that to the test computer several hundred milliseconds could elapse.