Single RS232 < sending and recieving from 2 Rs232 devices - Page 1
Forum section: electronics / beginners

author: whatifmynamewasbaldwin
author_rank: Newbie
timestamp: February 23, 2021, 05:33:07 am
content: Hi All,As you can see I am posting in the beginners section because im very much a beginner trying to attempt something probably quite advanced (for me atleast).As the title said:Single RS232 < sending and recieving from 2 Rs232 devicesI have a machine that takes measurments that usually outputs a rs232 signal which is interpreted by either:an "output box" that converts into voltagesor an Internet box that sends the data onto the internetThat by itself would be simple to make a cable that sends the signal to both. Were it gets complex is both devices interogate the machine to ask for data ~ every 30 seconds or minuteand I assume this would cause a data clash.Can anyone point me in the right direction as to what the best way to find a solution would be.. (is it even possible)thanks for your suggestions / helpjust found thishttps://stackoverflow.com/questions/40258346/connect-two-serial-port-into-one-serial-port/40270472which is very simular to what im trying to achieve

author: perieanuo
author_rank: Frequent Contributor
timestamp: February 23, 2021, 07:25:59 am
content: it can be done, but for somebody with some experience manipulating comm data transmission maybe, i suggest you change tactics and use another way of interfacing232 is normally point to point and no more, changing into star config takes some knowledge and possibility to modify the hw and the sw on those devices

author: ledtester
author_rank: Super Contributor
timestamp: February 23, 2021, 07:40:28 am
content: QuoteWhat kind of machine is this? Is it an Arduino?I would just put a microcontroller (like an Arduino) or a Raspberry PI in the middle of everything.Everybody (machine, output box, Internet box) only talks to the MCU/Rpi which forwards data to wherever it needs to go.

author: Rerouter
author_rank: Super Contributor
timestamp: February 23, 2021, 07:46:51 am
content: Option 1 - CTS / RTS are used, and you can use this to setup a priority queue, e.g. device 1 is talking, so you abuse these signalling pins on the other device to say its not quite ready yet, then release them when it is readyOption 2 - Caching micro, a micro talks direct to your device, caches up the replies reguarly enough for your application and have it answer the other 2 devices in its stead.

author: wizard69
author_rank: Super Contributor
timestamp: February 23, 2021, 01:34:48 pm
content: More information will be required to determine the best course of action. However I really doubt that this is a beginners solution.What catches my eye is why are they (you) using RS232 to produce an analog voltage? That right there is odd. So what is going on there.Probably the best course of action here would be to use a single board computer to replace both devices. With no data as to what is happening, nobody can even say how complex that would be. Your best bet would be to hire an engineer with strong software development skills.Various approaches are possible if you are going in one direction and don't have competing protocols. If you can get by with a 3 wire interface to both devices you can use one of the handshaking lines to toggle between devices. That requires a PCB and some electronic switching. However this is master / slave approach and would not work for what you are describing.Beyond all of that how sure are you about this voltage conversion? It would not be uncommon to use spare pins on an RS232 DB connector for an analog output. I've seen this on many implementations where the RS232 connections are on the same connector as other outputs.

author: grumpydoc
author_rank: Super Contributor
timestamp: February 23, 2021, 02:58:52 pm
content: Quote from: wizard69 on February 23, 2021, 01:34:48 pmPresumably there is a protocol and a DAC involved.Quote from: whatifmynamewasbaldwin on February 23, 2021, 05:33:07 amWhat is this "machine"? PC? Dedicated hardware? Commercial? Home Brew?You can't get one device talking to two others over a single RS-232 without some software support somewhere, at least outside of a situation where just connecting one TX output to two RX inputs gets you where you want to be. In any more general case I would question the wisdom of trying, given that RS-232 is totally the wrong bus topology for this.As has been suggested an R-Pi or similar with *three* RS-232 interfaces will be the most straightforward, though you will need to know details of the protocol that the devices are using.

author: tunk
author_rank: Super Contributor
timestamp: February 23, 2021, 03:03:58 pm
content: If it's a PC, wouldn't it be easier to add a port, e.g. an USB-RS232 dongle?

author: grumpydoc
author_rank: Super Contributor
timestamp: February 23, 2021, 03:05:59 pm
content: Quote from: tunk on February 23, 2021, 03:03:58 pmHardware-wise, yes, I'd think so.But it depends whether the measurement software can be altered to use two RS-232 ports.We don't know that it's a PC though.

author: fourfathom
author_rank: Super Contributor
timestamp: February 23, 2021, 03:46:25 pm
content: If you can accept that occasional collisions (overlapping transmissions) will result in lost messages, you might be able to essentially "diode-or" the outputs of your transmitters: TX output connects to diode anode, diode cathodes connect to common "RX bus", RX bus has a resistor pull-down to -V (or zero V, whatever low-level voltage your devices use).This will work in a fashion, but collisions will result in mangled data so you will want a fairly robust error-detection protocol. The RS232 character parity bit will not be adequate by itself. Minimize collisions by randomizing transmission times and reducing transmission duty-cycle.Another way to manage collisions on a shared-bus system is to have all bus participants diode-connect their TX output to a single shared bidirectional bus. Each node has its receiver directly connected to the bus as well. This way each node can detect collisions and implement some sort of "ACK/NAK" or perhaps re-try algorithm, or one node can serve as a master, and interrogate the slaves, which only speak when spoken to.Obviously, any of these methods require software to be written.

author: rstofer
author_rank: Super Contributor
timestamp: February 23, 2021, 05:33:39 pm
content: If two clients access the host for entirely different transactions, something has to make sure each transaction is complete before allowing another transaction from either client. It gets even more complex if both clients are asynchronous with no interlocking.If we know what a transaction looks like, it might be possible to do this with an Arduino or other device with 3 ports. Suppose a transaction looks like:client: "send me <something>" CR, LF <- here the CR, LF signifies end of incoming commandhost: "ok, here it is", CR, LF <- here the CR, LF signifies end of responseOur new 'man in the middle box' accepts data from the client and accumulates the string until it sees the CR,LF that signifies the command string is complete. Then it looks to see if the other client is not in process before it seizes the output port and does the entire transaction including receiving data from the machine and passing it on to the client. Then it releases the output port and waits for the next transaction.Basically, the two client ports will operate asynchronously working through queues.The downside is that we need to know what every type of transaction looks like in order to tell when it is complete.You can try the wired OR configuration of tying the ports together electrically but as soon as the second client stomps on the first client's data, you will give up on this approach. There needs to be some way to synchronize the traffic.This type of program screams for FreeRTOS to manage the shared host port and send/receive data from the two client ports. Clearly, it can be done without an RTOS but it is easier with one.

author: rstofer
author_rank: Super Contributor
timestamp: February 23, 2021, 06:13:45 pm
content: If I were doing this with the 'man in the middle' approach, I would probably look at the mbed lpc1768 ARM board with FreeRTOS using the online compiler/libraries.It's been around for a while but I have a lot of experience with the family and this board in particular:https://os.mbed.com/platforms/mbed-LPC1768/While I was looking at the mbed site, I went to the Compiler section and created a project with FreeRTOS already ported to the LPC1768. The hard part of porting FreeRTOS is already done, it is just a matter of writing the rest of the code. And that is far from trivial if everything is to be done with queues, semaphores and interrupts.But, yes, it is possible and the solution would be robust as well as clean.Not necessarily relevant here but all it takes to implement Ethernet is a MagJack connected to the 4 Ethernet pins. There is already a library that implements Berkeley Sockets. I used this several years ago and it works quite well. It uses the lwIP protocol stack.The Raspberry Pi doesn't have enough serial ports nor does the Arduino UNO. The Arduino MEGA has 4 ports and the LPC1768 has 3 ports.There is a FreeRTOS library for the Arduinos so it isn't really necessary to get into the mbed arena but implementing interrupt driven serial port code may be a bit of a challenge. There are many Google hits for 'arduino mega interrupt serial'.

author: ledtester
author_rank: Super Contributor
timestamp: February 23, 2021, 06:42:57 pm
content: QuoteJust use some USB-RS232 converters

author: fordem
author_rank: Regular Contributor
timestamp: February 23, 2021, 08:40:45 pm
content: Quote from: whatifmynamewasbaldwin on February 23, 2021, 05:33:07 amTo answer your question, we would need to know how these "boxes" do what they do.RS232 is a communication standard, it essentially sends a string of bits/bytes one behind the other - there is no way to convert that into voltage - but having said that if the output box requests data from the measurement box, through whatever unique communication protocols, then the measurement box will know what data to respond with, and the output box will know what to do with that data. This could also work the other way, the measurement box could be where the intelligence is and it sends command & data to the output box.An "internet box" can be one a large number of device - starting with the most basic - a modem - I first used the internet via dial up modem with an RS232 connection to my computer - in this case the "internet box" has no intelligence and all the smarts are at the measurement box side. Going to the other extreme, the internet box could also be a webserver getting input data from the measurement box via the RS232 interface.UPS manufacturers do this sort of thing all the time - I've used "internet boxes" from APC & Eaton that connect to the UPS via RS232, and take the measurements made by the UPS and put those in a webpage.Without knowing how the coms between the devices work, all the folks here can do (me included) is make uninformed guesses, and SWAG.