Multidrop bus on Windows

You are saying that if you plug two identical USB serial port cables into t he same USB port you will get two different COM port numbers? I don't see that with FTDI devices. I don't see any connection to serial number, rathe r to the type of cable. FTDI will get a COM port number and another of the same type will get the same COM port number, but plug a CH340 cable into t he same USB port and you'll get a new COM port number.

I have seen variable sets of low numbers reserved all the way up into the t eens.

Single cable between them. I think I also tried using my home network but got zero traction with that. The old system I used was a cable between two Win2k desktops.

--

  Rick C. 

  -- Get 2,000 miles of free Supercharging 
  -- Tesla referral code - https://ts.la/richard11209

Is this the reason why Modbus RTU documentation defines slave address range 1 .. 247 (oxF7) ?

That is how we handled this 30 years ago. ;-)

Hmm, had the same experience with FTDI just recently. In extreme conditions, I must admit. But it did crash.

That "lock" seems rather soft indeed. A converter may have the same COM number for a while. But then, after you haven't used it for a while, it suddenly has a different number. For a while I put stickers with the number on some converters, but that was useless as they changed after a while.

The real fun starts when you use FTDI chips on your own board and don't program them with a serial number. Every time you plug them in, the number is increased and if you do that with 4-port versions, the number rapidly go over the 100. (Last time I did this was a long time ago and on W7, may have changed now)

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

You will visit the Dung Pits of Glive soon.

I have worked with several different PLC serial protocols. Modbus RTU is the only one I know of that does not have a specific start character in the telegrams - for all others, "noise" characters at the start of a telegram will be happily ignored.

That is not true. If you want to be able to communicate with the fussiest of devices on either side, you need to match the timings. That means the master can't have breaks inside a telegram, or send out a new request too soon before the end of the last reply. (Those are the only two timings of relevance to Modbus RTU.) Equally, most Modbus masters and slaves are quite relaxed about their checks and in practice lax timings on a slave will not often be a problem. I simply don't see the asymmetry you mention.

It /is/ the case that an 0xff character could be the start of a Modbus RTU telegram, and therefore you need to be careful about using one as an extra interrupt-generator for switching the RS-485 bus.

Agreed. (The FTDI note is a kind of "hack" solution, that they only suggest for specific cases like a PC used for testing cards with their devices on them.)

Yes.

Without specific udev rules (i.e., using the common standard rules), there is a simple and predictable naming system - you get /dev/ttyUSBxxx, where xxx is a number. When you attach a device, you get the next available number. For simple uses, that can be enough. But when using serial ports a lot, it is helpful to have rules that match your own needs - whether that be giving specific names to specific serial devices, or specific types of devices, or specific physical ports, or whatever combination you like.

Thinking more about this, it might depend on the devices. Many newer FTDI chips have ROM and/or EEPROM built in, and come with a serial number. But older ones relied on external EEPROM and you put in a serial number yourself when you program them. With blank devices, there is no serial number and therefore no way to distinguish them until they are programmed. (And they should be programmed with a unique serial number - that is a requirement of USB.)

Most of the time I am using ready-made cables from FTDI (especially the USB to 3.3V TTL serial cables - they are hugely popular for us in development). These of course have serial numbers.

Certainly when you have different USB manufacturer ID or product ID, you should get a different comms port.

And maybe something has changed, or varies with different FTDI driver versions, Windows versions, history of drivers and devices on the particular machine, or something. Comms port numbers on Windows always seems to be a bit of a guessing game.

I haven't seen that myself, but I don't find it hard to believe!

You might, perhaps, need a cross-over cable for a direct connection. Otherwise it is a matter of giving the two machines fixed IP addresses on the same network. Then IP networking should work. I haven't tried this with Windows machines, but I don't see any reason why you should have trouble. I certainly don't see any need for third-party software.

If you prefer, any cheap router will do the job. Just connect both PC's to LAN ports on the router - you don't need anything connected to the "Internet" port on the router, or any setup. Each PC will get an IP address by DHCP and they can communicate.

(You might need to partially disable the local firewall junk on the Windows PC's to let them listen to each other. And if you have any third-party "security" crapware, it's best to get rid of it.)

That could be the case. Or they might have other reasons - sometimes I wonder what the Modbus designers were thinking for some of their rather arbitrary decisions.

I believe so. It is a /long/ time since I have done such programming, but I seem to remember Win32 calls to put the serial driver in "auto-RTS" mode suitable for RS-485. I can't say I know how it was implemented.

Apart for reduced troughput, the master can safely insert a crude delay (such as 10 ms OS tick) before sending out the request, so there is at least a 3.5 character time silent period ahead of the request. This will ensure that all slaves can reliably detect a pause between frames (even if not addressed to your slave). You could even skip the extra delay when sending multiple requests to the same slave, but it definitively needed when first accessing one slave and then send next request to a new slave, so that the new slave will reliably separate the response from the old slave and the next request addressed to your slave.

After sending the request, the master should disable the transmitter and let the fail-safe termination drive the bus into idle state. There is a timing window up to 70 bit times (3.5 master character times +

3.5 character slave preamble) for the master to go from Tx to Rx. In practice, this window may have to be limited to 10-20 bit times for more or less standard slave implementations.

OTOH the master Tx should not be turned off more than 1 bit time before the end of last stop bit of last character, so that the last stop bit will actively drive the line to mark "1" state and then let the fail-safe termination passively take over the idle "1" state.

On the slave side, each slave must be able to detect when a response from an other slave has ended and when the master is sending a new request to you. This requires accurate timing. Otherwise the slave will concatenate the two requests and the CRC will hopefully fail and after timeout, the master have to do a resend.

Agreed that implementing Modbus RTU timing accurately is hard, especially at high speeds. With the QUICC I/O coprocessor (on MC68360 and some PPC), this can be done relatively accurately. Multiple segments can be chained and sent out in sequence and when last segment is sent, this will then interrupt the main processors. In the first segment send 4 dummy characters with Tx driver disabled, in the second send actual message with Tx ON and in the third segment send 3 dummy characters with Tx OFF. On Rx, set the Idle timeout to 2 character times.

This will produce a 4 character preamble with 3 character trailing and

2 character Rx end detection, compared to 3.5 character preample, 3.5 trailer and Rx 1.5 pause detection as specified in the standard.

The strange is that I saw this limitation only quite recently (maybe a decade or so) ago.

Modbus/TCP Unit number (=slave address) field can be 0 - 255. This is useful especially for Modbus/TCP to Modbus RTU gateways.

For native Modbus/TCP devices, which is essentially point to point, the recommended unit number is 255.

Lol, I would have been able to tell pretty easily if that were the trouble.

Yes, Windows always makes things so easy. Parts would work and then stop w orking. At one time I was able to run either laptop from the other using t he remote console feature or whatever they call it when your screen, keyboa rd and mouse operate the remote machine. Then it wouldn't work in one dire ction. File sharing wouldn't work. I spent hours digging around on the In ternet but most web sites just give the same, lame first level instructions on how to set it up and nothing on trouble shooting.

Didn't work any better.

Totally off.

That was months ago when I was setting up some PCs for work and the easy wa y to copy stuff would have been by Ethernet. Instead I ended up using USB memory sticks. Windows sucks.

--

  Rick C. 

  -+ Get 2,000 miles of free Supercharging 
  -+ Tesla referral code - https://ts.la/richard11209

There are no timing requirements for when a master sends a request, or for when the slave replies, other than the minimum 3.5 character delay. These pauses are not part of the protocol specification.

You can't skip the 3.5 character delay - whether you are sending to the same or a different device. Any delay beyond that is entirely up to the device sending. (This is the same for masters and slaves.)

Slaves are not allowed to reply before the 3.5 character time break. There is no protocol-specified maximum delay time.

That is obvious.

It does not need to be done by accurate time - often approximate timing is sufficient. And slaves can happily read and check telegrams that are not addressed to them (such as replies to the master) and use that for synchronisation.

It can be a bit fiddly, and would be easier with a concrete start-of-telegram character, but it is not /that/ hard.

People do it all the time on all sorts of microcontrollers. There is no need for overkill on the processor power. These might be good choices of processor for other reasons, but for common baud rates (19.2 kbaud is standard, above 115.2 kbaud is very rare) you can work happily with a little 8-bit microcontroller.

I don't know if I have ever heard of a Modbus implementation being done in such a complex manner.

You turn on your driver, send out the telegram, and turn off the driver again. If you are trying to do this on an ancient Windows system, it is a bit of a pain - fortunately, that hasn't been needed for decades. When the slave receives the telegram, it interprets it, figures out the reply telegram, waits if necessary (and who cares if it is 3.5 character times or 10 ms?), turns on its driver, sends out the telegram, turns of the driver.

There is no need to make a mountain out of a molehill, or use high-end communication controllers that are designed for things like Profibus (with 12 MBaud on RS-485, and hideously complicated timing and processing).

I expect so. But I thought I'd better mention it just in case - maybe others are reading these posts.

Sarcasm, I assume? Windows makes /some/ things easy - but then the next version will complete change the way it is done.

Are the laptops going into low-power modes, or something like that? (Yes, I know that may be another silly question.)

It sounds like you have tried most of the things I can think of for now. Have you tried VNC rather than RDP?

And of course, you can always switch to Linux.

Of course not. A fixed delay of say 10 ms is sufficient to produce _at_least_ a 3.5 character pause.at speeds above 9600 bit/s. While in principle, a single 10 ms pause would be sufficient also at 4800 bit/s, the OS delay is not synchronized with the character stream.

In practice, most slaves after sending the response go _immediately_ into Rx mode, so the master could send the next request immediately. This works very well in practice.

Modbus point to point connections work well, without observing accurate timing.

How many of those thousands of different Modbus slave devices actually follow this ?

If the master sends the next request within 1.5 character times after the previous slave response has ended, all slaves will combine the previous response and next request to a single frame.

With any half duplex protocols, watching for the latencies is critical to get a reasonable scan rate with multiple slaves. I once had nearly one hundred actuators on each 230k lines (due to slew rate limited 250 kbit/s transceiver chips on both master as well as slave) to get a few cycles every second. The processor also handled generating controls for all these actuators. After trimming out most latencies, it become obvious that hundreds of amps drawn by the actuators at once would kill the power supplies, so the control signals had to be staggered:-).

While some code is required on QUICC to set up the system, sending a master frame is very simple. Just update the actual length to segment

2 and enable transmission. The next time the master program needs to react is when the 2 character time idle timeout of the slave response has expired.

Why would anyone try to do such tricks on brain dead IBM PC hardware.

For multidrop master, the critical thing is when the transmitter is turned off. For a slave, the how easily the 1.5 character (or more) time pause is detected.

Profibus-DP at 12 Mbit/s is nasty even electrically in a multidrop system with frequency compensated T-connectors :-). At 1.5 Mbit/s even barbed wire works reasonably.

Agreed that the timing requirement is nasty, but would be quite hard to achieve for instance 4 ms bus cycle times with multiple slaves in software only.

So you put in two ticks of pause, giving you 10-20 ms delay. Or you synchronise, or use some other timer system. Or you accept that if you need low-latency, low-jitter, high speed communications, then Modbus RTU was not the ideal choice.

It is likely that a slave will go into receive mode quite quickly after finishing transmission - agreed. I don't know about you, but when I write code for a Modbus master, I still have a brief delay before sending the next telegram.

Yes, that usually makes things very simple.

A good many, I expect, have some delay. If nothing else, it is common to get in the telegram, crc-check it, parse it, the figure out how to handle it. In many cases this can take time (though in some cases it is just a read or write to memory). A good slave implementation will probably create the reply telegram in a memory buffer before starting the reply at all - you want to make sure your reads and writes are atomic, and mess with creating replies on the fly. All this will naturally cause a delay on the small, cheap devices usually used on Modbus slaves.

No, they won't - not if they parse and check the telegrams as they come in (as some slaves do).

Look, if you are going to use a standardised protocol, follow the standard. Assume that any other devices on the bus also follow the standard. Otherwise the whole exercise is pointless.

In my experience it is usually easier to have tight control of your latencies with a small microcontroller than with a big one. My comment still stands - people do this all the time, on small microcontrollers.

Look at the title of the thread.

Agreed.

Yes, some do it. It is easy in a point to point system, in which you know if master only or slave only frames are expected. The same applies to a multidrop master.

However, a multidrop slave has to determine if it is a response from an other slave or a request from the master and hence know when the end of telegram is expected. Can you do it for all function codes ? Some ad hoc code is sufficient for the most common function codes, but is it possible for all.

Yes - at least, for all standard function codes.

In most Modbus systems, only a very few function codes are ever used, which makes it all a little easier.

I've seen it done without timing by using a state machine (including running CRC) to keep track of the response from the other slave and detect its end even without a gap.

--
Grant

One way of doing this is to have a 270 byte history buffer.

Immediately after a new byte is received, assume it is the last byte of the CRC. Assume the 4th newest byte is the start of a frame and calculate the CRC heck for this frame.

If it fails, start one byte position older and calculate new CRC for this longer frame. Repeat this towards the end of the history buffer.

However, if there is a CRC match before reaching the end of the history buffer, make a heuristic validity check (function code, count etc.). If this check is OK, synchronization has been obtained and lighter framing can be done in the future. If the heuristic fails, this was a premature CRC mach, continue searching towards the older starting points.

However, if no match has been found, the most recent received byte was not the second byte of the CRC. Wait for next character and repeat the processing with the history buffer.