Electronics > Projects, Designs, and Technical Stuff

Automated test equipment for production testing

<< < (3/4) > >>

spudboy488:

--- Quote from: IanS on July 08, 2019, 02:23:08 pm ---If you wish to have reliable multi-drop look at RS485 but then you'd need a protocol where master sends a message received by all receivers but only one receiver replies.

--- End quote ---

This is actually quite easy to implement (If I was able to figure it out, then yes, it is easy) and I've used it on a few different projects.

In my case, I have 1 device that is the master. It communicates to a handful of slave boards. I use the UART of all the devices but use a duplex RS485 driver rather than RS232. The key is to get a driver where the transmitter has a disable pin. The master transmitter and receiver are always enabled. The receivers on the slaves are enabled but the transmitters are disabled. Each slave is given an "address".  All the slaves are constantly listening for traffic coming in on their UARTS. I came up with a really simple packet structure consisting of STX, address, # of bytes to follow, payload. You can get more elaborate (checksums, etc.) but this worked for me. Each slave receives and process the packet but only does something with it if the address matches. If the address matches, the slave enables its transmitter, sends the response packet, and disables the transmitter. If the address doesn't match, it clears the receive buffer and waits for the next message.

 

SiliconWizard:

--- Quote from: spudboy488 on July 09, 2019, 12:03:29 pm ---
--- Quote from: IanS on July 08, 2019, 02:23:08 pm ---If you wish to have reliable multi-drop look at RS485 but then you'd need a protocol where master sends a message received by all receivers but only one receiver replies.

--- End quote ---

This is actually quite easy to implement (If I was able to figure it out, then yes, it is easy) and I've used it on a few different projects.

In my case, I have 1 device that is the master. It communicates to a handful of slave boards. I use the UART of all the devices but use a duplex RS485 driver rather than RS232. The key is to get a driver where the transmitter has a disable pin. The master transmitter and receiver are always enabled. The receivers on the slaves are enabled but the transmitters are disabled. Each slave is given an "address".  All the slaves are constantly listening for traffic coming in on their UARTS. I came up with a really simple packet structure consisting of STX, address, # of bytes to follow, payload. You can get more elaborate (checksums, etc.) but this worked for me. Each slave receives and process the packet but only does something with it if the address matches. If the address matches, the slave enables its transmitter, sends the response packet, and disables the transmitter. If the address doesn't match, it clears the receive buffer and waits for the next message.

--- End quote ---

Also did something similar (with an added CRC), and it's relatively straightforward indeed. As long as you implement this strict Master-Slave topology, there is no risk of collision (if there is a collision, this is clearly a bug), so this is rather simple. What I did though is use a single differential pair, so that was half-duplex and the master transmitter had to be disabled when listening to slaves.

spudboy488:

--- Quote from: SiliconWizard on July 09, 2019, 12:54:58 pm ---Also did something similar (with an added CRC), and it's relatively straightforward indeed. As long as you implement this strict Master-Slave topology, there is no risk of collision (if there is a collision, this is clearly a bug), so this is rather simple. What I did though is use a single differential pair, so that was half-duplex and the master transmitter had to be disabled when listening to slaves.

--- End quote ---

I went duplex so the master can send a command to the slaves (basically a reset) if one of the slaves isn't responding. I kept it out of the earlier post for clarity.

jmelson:
You absolutely MUST have a guaranteed break-before-make operation of the relays.  Possibly some kind of circuit with extra contacts so that only one relay at a time can be closed.  Or, have some resistor network at the test points so that failed or mis-programmed relays won't cause destructive currents.

Jon

SiliconWizard:

--- Quote from: spudboy488 on July 10, 2019, 11:37:14 am ---
--- Quote from: SiliconWizard on July 09, 2019, 12:54:58 pm ---Also did something similar (with an added CRC), and it's relatively straightforward indeed. As long as you implement this strict Master-Slave topology, there is no risk of collision (if there is a collision, this is clearly a bug), so this is rather simple. What I did though is use a single differential pair, so that was half-duplex and the master transmitter had to be disabled when listening to slaves.

--- End quote ---

I went duplex so the master can send a command to the slaves (basically a reset) if one of the slaves isn't responding. I kept it out of the earlier post for clarity.

--- End quote ---

The potential problem is not with a slave just "not responding". Implement a time-out on the master's side. Done. It's with a slave holding the bus by getting stuck and never disabling its transmitter... thus preventing the master to send further commands from then on.

This is not a big problem though: I implemented "hard" time-outs on both sides, so that a slave could never "hold" the bus for longer than a given amount of time no matter what happens. Absolutely no issue.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod