TassyJim said  

I did a multidrop serial for a while but only while I was waiting for some RS422 modules to arrive.
It worked well with 3 slaves but I forget what baudrate I used. Probably 38400.
Cables were cat5 with the maximum distance about 8 metres.

Schottky Diodes are preferred for speed.

Jim

Good info, Jim.

I was going to mention Schottky due to the lower volt-drop which may/may not be an issue.

8 metres is encouraging because I'm looking at <0.3m  

If you only want 300mm or so, would not I2C be perfect for this as mentioned by other members?  You shouldn't even need range extenders for that short a distance.  Perhaps I am missing something - I often do!  

I've had remarkable success with just plain serial over CAT5/CAT6 cable.
I have one setup that just has standard UART - no RS485 or RS422 - running 2400 baud over about 30 meters of cable, and it never misses a beat.

In hindsight, today I would design using RS485 or RS422, but at the time, standard UART over 20-30 meters of twisted pair worked perfectly, so it can sometimes be amazing how far you can push protocols over cable, that were never really designed to cover those kinds of distances!  

  Mixtel90 said  

... and you'd be back to wired OR. :)

For a network of n nodes every AND gate needs n inputs. \

n-1

  Grogster said  

If you only want 300mm or so, would not I2C be perfect for this as mentioned by other members?  You shouldn't even need range extenders for that short a distance.  Perhaps I am missing something - I often do!  
 

Absolutely right; I2C is absolutely solid up to 1 metre and I have not seen any failure at 2 metres.  There are many reports on various electronics forums of people pushing it further beyond the manufacturers' specifications; it really depends upon the use of decent cabling and a low-noise environment.  Still, if you need to send I2C crazy distances in a huge welding workshop then Texas Instruments has the answer...
See here:
https://www.ti.com/lit/ug/tiduei0/tiduei0.pdf

Can be replaced by one resistor and 4 diodes.

A current source could be something like this.
.
Edited 2022-03-13 18:44 by Mixtel90

Heck, thanks for going to the trouble, Mick. I had the AND-gate thing all wrong in my head.

I2C is not really an option because I have adopted the Network Machine Control (NMC) protocol as used by a product that is offered by Saelig.

I want everything that I do to be compatible with this network.  

Well, it's not as if you have to find space for the UARTs nowadays.  :)

I suspect the UART system will have the same disadvantage as I2C. Falling edges are fast, but rising edges are relatively slow. You can combat that to some extent by using a lower value of pullup, but you have to stay within the capacity of the weakest device on the bus. A CC source lets you set that current quite precisely and it will stay close to it even through supply variations. Over a short distance it's very likely to be overkill so I wouldn't worry about it.

I currently have Propeller to Picomite constantly exchanging packets @ 460KBaud, running since Thursday. Heading to the shop, shortly to stick a Shottky in-circuit.

I normally run it @ 115KBaud.




Craig

Hi Craig, All,

Have you considered CAN-BUS?

I have no personal experience with it myself but it is extensively used in Cars, given what they monitor in a car I am sure that managing 30 nodes would be do-able.

No idea what chips or cost this approach might add to your design.

Regards,

Mick

I usually use AND gates in this way:

  dMajo said  

I usually use AND gates in this way:

That is the way to do it !
The interconnects require a 3 wire cable, so the same system as RS485 can be used. You have firm drivers (the 74HC08) for each line. And all nodes are identical (except address in software). If you want to take this to a bus over longer distance you might want to use smit trigger AND gates and add some low pass filter (RC) at the input to get rid of spikes.

De accumulated delay in all HC08's must be compensated in software (the "turn-around" time cannot be 0) but in general nodes running MMBasic will not be fast enough to suffer from it.


Another alternative has been brought up in the "Beckhoff" thread Tinine started. The UART out can be muxed with UART in under control of the mite. That way you create a ring, where only slaves that recognise their address feed into the ring. The advantage of that topology is that every output is only connected to ONE input. You can use a 74LVC1G157 as mux.


Edited 2022-03-14 17:01 by Volhout

And for those who want to use I2, this is fine stuff to read.

I2C bus bufferig techniques

  bigmik said  

Hi Craig, All,

Have you considered CAN-BUS?

I have no personal experience with it myself but it is extensively used in Cars, given what they monitor in a car I am sure that managing 30 nodes would be do-able.

No idea what chips or cost this approach might add to your design.

Regards,

Mick

Hi Mick,

Yeah I have used CAN-BUS in the past. Involved a Hilscher device and programming was horrendously complicated.
I was going to have a rant about fieldbus systems but CAN makes sense for vehicles to minimise wiring (weight).
Really not a fan of any standard fieldbus, actually and I come across all varieties in applications where they are of no practical benefit.

Modbus, Profibus, TwinCAT, EtherCAT and today I am trouble-shooting a machine with SUConet (at least they got the first three letters right ).

This 4-wire NMC feels like I am reading/writing to an ISA-Bus card under DOS; address+command+data+csum. Small packets and it simply works  

Craig

@dMajo
@Volhout

This is cool info, guys. Many thanks  

Craig

  Tinine said  

This 4-wire NMC feels like I am reading/writing to an ISA-Bus card under DOS; address+command+data+csum. Small packets and it simply works

Except for CRC instead of checksum (if that's what's implied), how does this differ from MODBUS?

CAN is typically very simple, although that doesn't stop some organisations making it a pain.

30 nodes is modest.

John

And if you need longer bus runs (10 to 25 meters (perhaps more depending on baudrate) between nodes, each green bus segment) you can use this configuration.
It uses RS232 levels between distant nodes and TTL levels between local (close) nodes.
Between each local block and the other the RS232 signal is regenerated. Take care for ground equipotential.



Sorry for the quickly made drawing using images from this thread.
Edited 2022-03-15 05:55 by dMajo

  lizby said  

  Tinine said  

This 4-wire NMC feels like I am reading/writing to an ISA-Bus card under DOS; address+command+data+csum. Small packets and it simply works

Except for CRC instead of checksum (if that's what's implied), how does this differ from MODBUS?

Modbus dates back to 1979. I don't talk "coils"  

I see it as more of a PLC thing. With NMC, I can tightly coordinate (interpolate) 16 axes with an accuracy that would require a temperature controlled environment to justify.

I really don't worry about error checking, although I use a checksum.

Ancient technology is only here because it's a standard. If CNC were invented today, no-way would godawful G-code be considered.

But truth-be-told; I refuse to do anything Modicon because the "Father of the PLC", Dick Morley, called me an idiot on Compuserve    

Craig  

While the MODBUS standard talks about "coils" (which certainly confused me), the use of MODBUS on the Renogy solar controller I'm looking at has nothing to do with coils--it is (for the most part) simply a way of reading and setting 2-byte registers, and the message contents (standard MODBUS) are exactly as you describe the 4-wire NMC (I'm not speaking of the electronics)--1-byte address, 1-byte command, data (including possibly a one-byte length (# of words of data)). Then comes the CRC (and fortunately, there are two methods on fruitoftheshed.com for calculating the CRC--the table-lookup one which I have tried comes up with the same value as the examples in the Renogy manual).

(Note I'm not trying to argue about the electronics, about which I know nothing--just pointing out that the message contents are the same.)

Oh sure, I was going to acknowledge that; at the end of the day, it's only data and we can do with it whatever.


The CRC overhead is unacceptable to me because we are talking balanced line transceivers. I don't want to compensate for bad electrical engineering with such nonsense as retransmits, etc.

The exact same electrical circuitry is what robots and machine-tools rely upon.

Feedback from incremental encoders is almost exclusively 5v pulses, two channels with a phase offset of 90 degrees to indicate up/down count.

The controller depends solely on this signal integrity because there is no protocol and therefore no error checking.

Were signal integrity not reliable, we would see robots smashing entire car bodies into the floor and machine-tools, at best producing scrap and at worst, self destructing. It doesn't happen often enough to be an issue.

I understand those who promote CRC but as the saying goes "nobody got fired for buying IBM".

Craig