Multidrop bus on Windows

I often work on embedded firmware for MCUs connected by a multidrop master/slave RS485 bus.

Moreover I try to compile the same code with mingw compiler, simulating the hw. Of course, I simulate the serial bus connection (UART) by using a COM port on Windows. This allows me to speed-up testing, debugging and so on.

So I can launch many simulators of the same device or different devices. If they are two, I can use null-modem emulator (such as com0com) to make a point-to-point connection between the two devices.

What I'm trying to do is to launch three o more device simulators, each opening a virtual serial port, and let them talk together as they are on a real RS485 bus.

What I'm searching is a software that retransmit all data received on one serial port to all other serial ports under control.

Device 1 COM11 COM12 Device 2 COM13 COM14 Device 3 COM15 COM16

This bus simulator should open COM12, COM14 and COM16 and retransmits all data received on one port to all other ports.

I know I can write this myself, however I'm sure someone already wrote something similar to reuse.

Reply to
pozz
Loading thread data ...

Why don't you stub the RS485 comms with some kind of network pub-sub layer? Perhaps using IP-multicast? I don't know offhand of a straight-forward (non-commercial) pub sub library, but probably there are a few out there... Maybe DBus? I wouldn't use serial comms for simulation. Hope that helps, Best Regards, Dave

Reply to
Dave Nadler

It should be about a two dozen lines of Python with pyserial.

But surely your PC simulators don't have to use serial ports? They can communicate by named pipes, TCP/IP connects, or whatever.

Reply to
David Brown

I know.

I sometimes connect a simulator to a real device, so I need to use a real COM port.

Reply to
pozz

I sometimes need to connect a simulator to a real device, so I need to use COM port.

Reply to
pozz

If you intend to use a typical 14500 compatible UART on a PC, there are issues with Tx/Rx switching in half duplex multidrop RS-485.

Reply to
upsidedown

It is a /long/ time since I have used "real" UART devices on a PC. I almost invariably use FTDI chip's USB UART cables and converters. These have no problem with RS-485 direction switching - I've run them at 3 MB. (As usual, life is much easier with Linux than with Windows for such things - in particular, you have no messing about with drivers, and no run-away comms port numbering.)

Reply to
David Brown

Can you abstract it a bit in the code? Your simulator code could use pipes or network sockets, and you can have a single extra program that can act as a hub between these sockets and one real RS-485 serial port. It just seems inefficient to have lots of serial ports on a computer with null modem cables connecting them together.

Reply to
David Brown

Also, Exar make a USB-RS485 converter and drivers; I used these some years back to interface test code to a 485 bus.

Reply to
Dave Nadler

Should be 16450. Those do not have an interrupt when the last stop bit of the last character has actually shifted out of the UART shift register, only when he last character has been moved from the Tx FIFO to the shift register. It still takes a full character time before the character has actually been shifted out and the transmitter can be disabled and set to tri-state.

Some implementations put the Tx into tri-state some bit times too early and the last character is corrupted, typically having the last bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe' termination) . Others turn off the Tx too late, when the opposite end has already started to send the reply and the first character is lost or the whole message is garbled (start bit missing).

I once tried some USB to serial converters, one crashed the Windows.

An other mixed the enumeration when two or more such converters were plugged into USB ports in different order, sending communication to wrong serial lines with potentially lethal consequences.

These days I prefer ethernet to serial converters with proper Rx/Tx hardware switching. These work fine and you get 100 m range and galvanic isolation for 'free'.

Some early ethernet to serial converters waited a looong time before forwarding the last Rx character to ethernet. Some had adjustable time settings with minimum settings of 10 ms :-(. This did make these devices useless for high speed half duplex traffic. Modern versions forwards the last character after one or few character time idle period detected on the Rx serial line.

Reply to
upsidedown

On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4, snipped-for-privacy@downunder.com w rote:

o

I'm surprised no one thought of dealing with this issue by appending an opt ional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char. Treat it as optional and if the start bit is lost, no problem. If it is received it gets tossed, no problem.

I recall working on a system that had this problem. I don't recall how we dealt with it. I seem to recall digging into the interrupt handler but tha t was over 30 years ago. With the info I gained I did write a driver for t he timer interrupt and the counter that drove the speaker. I would read an 8 bit DAC sample and use it to pulse width modulate the speaker pulse trai n. The timer interrupt was used to time the 8 kHz sample rate if I remembe r correctly. It was seriously crude, but in those days a "multimedia" pack age was pretty pricey and many government computers didn't have it even if they needed it. This was a cheap way to play modem sounds for educational purposes on whatever PCs they had handy. I had actually done this for my o wn amusement using a modem sound as my test file. When one of the managers heard modem sounds coming from the lab he had to see how that was happenin g. He knew only a couple of PCs in the office had multimedia kits installe d. He was amazed. lol It's so simple, I guess some people just don't thi nk about stuff like that. For me it was play.

The Chinese brands don't have great drivers. The Chinese fakes of quality brands are pretty crap. I don't know of any that are so bad they crap out the PC though.

Probably not the sequence, but rather the USB port. When you plug a serial device into a USB port it gets a COM port number. That number is now "loc ked" (in a soft way) and won't be reused unless you force it. Plug the sam e serial device in another USB port and it will get a new COM port number. The good point is you can select a COM port number without going into the setup by picking the USB port you plug it into. The bad point is you need to remember which COM port is associated with which USB port.

If you want, you can even pick an COM port number overriding any "in use" C OM numbers as long as you know they aren't being used by hardware. Not sur e why, but Windows seems to want to reserve some low COM port numbers to st art.

It's great if your device has an Ethernet port. I don't know what it takes to set up the connection, but I know it was a bear to get two Windows 10 P Cs to talk to each other over Ethernet, things like fill sharing. Years be fore I use a web site WOW.com (World of Windows networking) or maybe it was WOWN.com, I forget. It had the straight skinny on getting Win2k working a nd made it easy. After Win2k MS seems to have made Ethernet harder and har der with each new generation. Meanwhile WOWN.com was sold and the new guys didn't care about content, they just milked the traffic for advertising.

Maybe I'm not recalling it right. I see a site at wown.com which vectors t o

formatting link
But searching for "world of windows ne tworking" finds a site,
formatting link
tm which looks like what I remember. Oh, well.

Paper tape compatibility? lol

--
  Rick C. 

  - Get 2,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

Serial communication is often used to connect devices from different vendors, so it is out of the question to alter a standard protocol.

Reply to
upsidedown

On Thursday, October 3, 2019 at 12:39:47 AM UTC-4, snipped-for-privacy@downunder.com w rote:

optional char of all ones to the end of the message and adjusting the proto col to simply ignore this single char. Treat it as optional and if the sta rt bit is lost, no problem. If it is received it gets tossed, no problem.

What standard protocol? You mean the one that doesn't work?

But that was the problem we faced. Several boxes had been built, some paid for by the government, some on a company's dime, but this detail had escap ed them all and no working system could be built. I really don't recall wh at happened. It may have been that we added a timer to the controlling PC to disable the drive, but I'm pretty sure there was at least one box that d idn't wait long enough for that to work reliably. The slaves have to wait long enough to start their transmission to be sure the master driver is tur ned off. I suppose the dummy character still has that issue as well.

I remember asking how each vendor had been able to deliver a component they could demonstrate would work. I suppose they rigged something on the PC t o work with their own box while not being totally compatible with the other vendor's boxes.

I also remember there was no spec on the whole thing like a bus protocol. It only specified things like the contents of the data packet. Watkins Joh nson was one of the vendors who made their box using government money and h ad at least one flaw in the protocol (I think it was their product that wou ld turn on so quickly after receiving the command it would actually step on the final stop bit). But their business model didn't allow them to fix th e problem unless the government paid for it.

I think to work reliably an RS-485 bus needs biasing resistors for when no one is driving. This bus didn't have that. I expect they didn't have it i n any of the slaves and the PC didn't accommodate it. They chould have use d two connectors on each slave unit for passing the signals through to the next slave and the final slave could have the terminating resistors plugged into the final daisy chain connector. Is it GPIB that works similarly to that? Or maybe I'm thinking of SCSI with several complex bus types to allo w high speed operation at the time.

--
  Rick C. 

  + Get 2,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

There are dozens PLC serial protocols that supports multidrop and the timing issue may effect them all.

The most common PLC serial protocol these days is Modbus RTU. While it has some nasty timing requirements, the master side can take some slack in timing, but this doesn't apply to Modbus slave, which needs to handle timing correctly.

Use some other UART than the 16450 family. Since default PC serial ports are RS-232 only, you need some external converter driving the bus. Alternatively use an ISA/PCI card with proper UART and RS-422/485 drivers on board.

The original RS-485 standard specified the optional 'fail.safe' resistors. The quotes are from the standard text.

Most multidrop protocols have start and end characters or sequences, so the receiver can ignore line noise before frames or late echoes after frames, but timing errors can eat the start or end byte. Modbus RTU doesn't have start/stop characters but relies on pauses between frames. For this reason, the bytes had to be sent in one sequence without too long gaps between bytes. Pauses longer than 1.5 character times indicate that this is random bus noise without fail-safe resistors or late echoes due to reflections in an unterminated bus. Thus Modbus RTU has also been designed to work on a bare bus or with a properly terminated bus with proper fail-safe resistors.

Reply to
upsidedown

There was a common trick of sending an extra 0xff character beyond the telegram you wanted to send, and when you got the interrupt as that moved into the transmit register, you turned off the RS-485 driver. This had a risk of letting a start bit, or part of a start bit, get through - but for most protocols that was not an issue as it would be ignored by the receiver.

Still, it is /much/ nicer with a device like the FTDI chips that handles the drive enable timing automatically.

There is a big challenge with these kinds of devices and serial port numbers in Windows. Windows gives a new comms port to each new device it sees, and sometimes to the same device on a different USB bus. It should not mix up the numbers - but it is very easy for users to do so - if you have two devices and they are on comms port numbers 45 and 57, which is which?

Programs that are aware of the USB nature of the ports can make this a lot easier - it's not hard to use Win32 calls or the FTDI DLL's to identify serial numbers of devices or the physical placement on bus and hub trees.

Or you can use Linux, which makes it a lot easier to do that kind of thing.

Ethernet to serial converters can be useful, but have their own complications - you have a lot more jitter in timings, and you have challenges about identifying and addressing them on the network.

The RS-485 driving issue is no different from what you get with USB RS-485 converters - the bus driver is enabled if and only if you are transmitting.

This is always going to be an issue. It is an issue with USB too, but less so than with Ethernet.

I have run USB serial ports at 3 Mbaud. No Ethernet to serial converter is going to send the last character within one or two character time periods at these speeds. (Nor will USB devices, but they'll be closer and less varied.)

Reply to
David Brown

I know that's the way /I/ handled it, decades ago when it was a problem. I assume it was standard practice.

(As a side issue, I wrote a program on Win3.1 which needed fast regular processing at about 1 kHz. The Windows timers were at 50 or 60 Hz, which was not nearly fast enough. But if you opened an unconnected serial port at 9600 baud, enabled interrupts on transfers, and sent one character at a time - you had interrupts at approximately 1 kHz. This thread brings back happy memories!)

When we have the choice, we invariably use FTDI devices - made in Scotland.

On older PC's, from the younger days of USB, I saw PC's crashing as the result of ground loops through the USB drivers. We had trouble with that in one test system, long ago - the solution was an independent ground wire from the PC chassis to the card, connected before the USB was plugged in.

That is not the case, at least not for FTDI devices (and several other manufacturers). Plug a different device (different serial number) into the same port, and it will get a new comms port number. Plug the old one into a different port, and it might get the old number, or it might get a completely new number - I have seen both effects, and can't remember the controlling factors.

FTDI has application notes about registry entries you can change to get the "comms port number follows physical port" effect, primarily for use in test systems.

(Or you can use Linux with a few udev rules and get whatever number and naming system you want.)

Ports 1 to 4 are reserved for the standard physical comms ports (even though they haven't been standard for a /long/ time on new PC's).

How are you trying to connect the PC's ? Just a single Ethernet cable between them, or putting them on an existing network?

(You are right that MS seems to make many tasks, like networking, harder for each generation of Windows.)

Reply to
David Brown

This is true for most protocols, but not with Modbus RTU, since if the start bit gets trough, it calculates the frame length incorrectly and tries to locate the CRC from the wrong position.

So does some UARTs in a PCI cards.

The serial number trick works, but requires an unique serial number .e.g. with a separate serial number chip or some Flash memory to store a (hopefully) unique serial number at first use.

Relying on device position in a hub tree is a no no thing, since more hub levels may have to be added if more USB devices are inserted.

Use fixed IP-addresses in a private address area such as 192.168.x.y.

For accurate timing, do not use TCP between PC and converter. UDP will give a more predictable timing or just raw MAC framing, but this is much harder to use on Windows.

A converter based on the QUICC co-processor (found on MC68360 and some PPC models) should be able to handle a few fast serial lines. But of course, these processors are an overkill for such simple task.

Reply to
upsidedown

Modbus requires a break before the start of the telegram - at least 3.5 character times. A slave that checks this will not be bothered by the noise.

Failing that, it is not uncommon to avoid address 255 and consider a start address of 255 as noise.

But it certainly /can/ be an issue, and should be considered when designing a system.

Yes. But those are often not directly compatible with standard ports.

Any USB serial converter you buy should have a unique serial number. If they don't, then try buying from a reputable source instead of something that fell off an eBay truck.

It is a "yes yes" thing for many people in many environments, because it is obvious and convenient - it's just like plugging your RS-232 line into "com1" at the back of an ancient PC.

The options are there, and it's up to you to pick the ones that suit best.

That can work - or it can lead to complications and conflicts. And it either means /very/ expensive converter devices with some way of viewing and setting the IP addresses, or chicken-and-egg time-wasting for configuration.

Raw MAC framing is out of the question for Windows. UDP is a better than TCP/IP for low latency (but loses you the joys of redirecting your traffic over ssh links, VPNs, the internet, etc.), but it is certainly far from real-time.

Yes, that is overkill.

Reply to
David Brown

Does windows support half-duplex mode on the less-ancient versions of the 16x50? I've used varous brands of 16850 UARTs and the half-duplex mode always worked fine on them.

--
Grant Edwards               grant.b.edwards        Yow! I'm not an Iranian!! 
                                  at               I voted for Dianne 
 Click to see the full signature
Reply to
Grant Edwards

I've worked for a "serial-port" company for 20 years, and port numbering foul-ups are a non-stop source of problems for Windows customers. Still.

That is indeed the "right" answer (IMO). I usually have 5-10 USB serial devices plugged in to my desktop at any point in time, and it doesn't matter what order/port I plug them in. Thanks to a handful of udev rules, they always get repeatable and predictable names.

--
Grant Edwards               grant.b.edwards        Yow! Could I have a drug 
                                  at               overdose? 
 Click to see the full signature
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.