Designing model train layout I/O and PWM speed control

[ilium007]

This is a follow on from the discussion in a previous thread:

https://www.eevblog.com/forum/projects/io-connector-advice/

For my project (large model railway) I had originally looked at using TPIC6C595 shift registers to drive 60+ LED's as well as relays to drive points solenoids due to their current sink ability, and 74HC125 input shift registers for all inputs. These would run alongside the 74HC125 quad buffers on the shift registers (TPIC6C595 and 74HC165) to give them tri-state ability to run them on the SPI bus alongside other SPI devices. I already had the code written for it and had it all working on the breadboard ! I binned it all because I thought the MCP23017 was a more elegant solution ! After reading through the above thread I'm going to go back to my shift register design.

The MCU will run in to fan out issues driving too many shift registers so I need a buffer IC, the 74HC125 is a quad buffer but I'm not sure how many of the inputs/outputs need to be buffered on the TPIC6C595 and 74HC165 IC's.

Do I buffer CLK, DATA, LATCH and OE ?

*** I just realised that the TPIC6C595 does not have a LATCH *** I need to do some more research.

Baring the latching issue above, the 74HC125's OE pin would be driven like an SPI SS pin I'm guessing ?

[ilium007]

It looks as though the RCK (Register clock) pin is the same as the LATCH pin on the 74HC595 which I have used before.

There is a fair amount of thermal via action going on here !

[phil from seattle]

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

[Ian.M]

Yes.  In the other topic you mentioned this is being driven by a Teensy, so you would simply copy all your relay states to a multi-byte buffer and call SPI.transfer(buffer,count) to send all the relay data to the chain of shift registers.

[ilium007]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

[ilium007]

Yes.  In the other topic you mentioned this is being driven by a Teensy, so you would simply copy all your relay states to a multi-byte buffer and call SPI.transfer(buffer,count) to send all the relay data to the chain of shift registers.

Exactly - I was just unsure of the pin out names for the TPIC6C595 as they differ from the 74HC595 ie. LATCH is RCK and OE is G.

[phil from seattle]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

You received bad advice.  Fan out only happens with 1 output to many inputs.  Each Shift-out pin will provide drive to the next input.

Here's a graphic:

[ejeffrey]

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

The data lines are daisy chained but the clocks are connected in parallel.  That said, a fanout of 8 for a SPI clock line should be no big deal, assuming you are running the shift clock at a normal frequency. 

[ilium007]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

You received bad advice.  Fan out only happens with 1 output to many inputs.  Each Shift-out pin will provide drive to the next input.

Here's a graphic:

That makes sense, thanks. So for the SPI output to the TPIC6C595's I don't really have to worry about fan out problems, I have MOSI driving the first TPIC6C595 directly and I could have 50 of them daisy chained from there - no fan out problem.

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

The data lines are daisy chained but the clocks are connected in parallel.  That said, a fanout of 8 for a SPI clock line should be no big deal, assuming you are running the shift clock at a normal frequency. 

So now I want to expand to 100 TPIC6C595's (extreme example) - MOSI has no fanout issue but SCLK and the latch would ? So should I just include a 74HC125 quad buffer and buffer all connections - MOSI, MISO, SCLK and SS (digital pin used to select OE on the buffers) ?

For the 74HC165 inputs I would run in to problems here because (extreme example) if I had 100 IC's talking on MISO to the one MCU MISO pin.

I have been reading a fair bit about SPI and tri-state requirements for devices on the same bus. I came across this image (https://www.dorkbotpdx.org/blog/paul/better_spi_bus_design_in_3_steps):

I'm assuming in this diagram that device #2 doesn't have the ability to put it's MISO pin into high impedance mode where the other two 'SPI compliant' devices can and therefore they can co-exist on the same SPI bus - but what about MOSI ?



The tri-state issue only occurs on the MISO line - why is that ? If I had a device on the SPI bus that did not tri-state its MISO pin when its chip select was disabled I can see the need for the tri-state buffer, but what about MOSI ? Why isn't that the same ?

Is it because there is only one master device therefore on the MOSI line there can never be a collision of a 1 and a 0 ie. a short circuit, but on the MISO line, if a device outputs a 1 when another outputs a 0 there could be a problem. Input devices ignore the traffic on the MOSI line via their SS / OE pins.

[ilium007]

So from further reading it seems that there are two different issues I am dealing with through the use of buffers - again, extreme example of 100 TPIC6C595's and 100 74HC165 IC's:

• fan in limitations on MISO lines and fan out limitations on the CLK line and SS line (for latching the shift registers)
• MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

If I were to require 100 x output shift registers and 100 x input shift registers how would you connect the buffers ?

[C]

in your Good SPI bus design photo

For the micro all signals are outputs but the blue line MISO which is an input.
One output can be connected to many inputs with out a fight.
#1 & #3 have blue line outputs that tristate when not selected by CS.
#2 needs an added gate.

What is not stated is how many bit shift register each of the devices have.
For SPI you want a multiple of 8 bits.
Device #1 could have a shift register 64 bits wide, could be 128 bits wide or any multiple of 8
It does not have to match bit width of other devices.

For an output CS going inactive could latch the output data.
For an input CS going active could latch the input data.

[C]

this post is one device

Look at figure 14 from this data sheet
http://www.ti.com/lit/ds/symlink/tpic6c595.pdf

If you did this each added TPIC6C595 adds 3 connections to MCU. You would run into fan - out problems

Now draw a vertical line between the two TPIC6C595 in figure 14
You have four signals crossing the line.
The line is the 74HC125 quad buffers ic
Four inputs & four outputs. The max load on before circuit is one when you add one 74HC125 & one TPIC6C595.

Now look at the timing of circuit.
If you had 100 boards each with a 74HC125 & TPIC6C595 in series the timing stays good.  Each buffer delays the four signals so that when a signal changes stays close to constant with respect to the other signals.  Data sheet states typical delay of a 74HC125 is 11 ns. You put a signal in and with 100 boards in series, the change comes out 100 x 11ns later from last board, a total delay of 1100ns. But if  clock signal changes 20ns after the data signal change at the end of chain the clock signal will still be changing about 20ns after the data change. The about is due to the differences in each buffer & the difference in cable.


Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change. 10Mhz divided by 8 clocks per board divided by 100 boards and your are updating your leds 12,500 times a second. Think a much slower rate will do.
With 100 boards you would have 100 bytes of data. By expanding to 400 bytes you could have 4 levels of brightness if the update rate was fast enough.

With buffers on each board you can add some distance between boards.
Do you want all the wires for your led's coming to a central point or a much neater spread of boards where each handles 8 leds.
A buss of 6 wires would connect the buffers, power, ground & four signals.
Would be good to have two connections for output power of TPIC6C595.
To make wiring easer, you might not want to use every output.

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So output data using one SPI port in master mode.
Receive input using a second SPI port in slave mode.
You can then connect the input chain clock in to a clock from the SPI master output chain to get the 8 clock pulses needed.

[rs20]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

The 74HC165 chip doesn't have a MISO pin. If you try to press its Q pin into a MISO pin, then yeah it won't be tristated via CS because it's not a MISO pin.

Anyway, if I was driving LEDs, I would just leave the Q pins disconnected. There's no point in routing that data back to the MCU. If you're using other shift registers for input, then dedicate those to input alone.

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

[ilium007]

Thanks for the detailed reply @C - its going to take some time to digest all of this.

[ilium007]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

Thats exactly what I intend on doing, but if the cascaded chain of 74HC165's is on the same SPI bus as other devices the MISO pin from the cascaded chain needs to be tri-stated - yes ?

I don't have the ability on the iPad to draw what I am talking about - I will try and draw a block diagram of what I am proposing later tonight when I get to a computer.

[ilium007]

this post is one device

Look at figure 14 from this data sheet
http://www.ti.com/lit/ds/symlink/tpic6c595.pdf

If you did this each added TPIC6C595 adds 3 connections to MCU. You would run into fan - out problems

Now draw a vertical line between the two TPIC6C595 in figure 14
You have four signals crossing the line.
The line is the 74HC125 quad buffers ic
Four inputs & four outputs. The max load on before circuit is one when you add one 74HC125 & one TPIC6C595.

Now look at the timing of circuit.
If you had 100 boards each with a 74HC125 & TPIC6C595 in series the timing stays good.  Each buffer delays the four signals so that when a signal changes stays close to constant with respect to the other signals.  Data sheet states typical delay of a 74HC125 is 11 ns. You put a signal in and with 100 boards in series, the change comes out 100 x 11ns later from last board, a total delay of 1100ns. But if  clock signal changes 20ns after the data signal change at the end of chain the clock signal will still be changing about 20ns after the data change. The about is due to the differences in each buffer & the difference in cable.


Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change. 10Mhz divided by 8 clocks per board divided by 100 boards and your are updating your leds 12,500 times a second. Think a much slower rate will do.
With 100 boards you would have 100 bytes of data. By expanding to 400 bytes you could have 4 levels of brightness if the update rate was fast enough.

With buffers on each board you can add some distance between boards.
Do you want all the wires for your led's coming to a central point or a much neater spread of boards where each handles 8 leds.
A buss of 6 wires would connect the buffers, power, ground & four signals.
Would be good to have two connections for output power of TPIC6C595.
To make wiring easer, you might not want to use every output.

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So output data using one SPI port in master mode.
Receive input using a second SPI port in slave mode.
You can then connect the input chain clock in to a clock from the SPI master output chain to get the 8 clock pulses needed.

I'm thinking of designing these boards with 64 I/O on the one board - that way a single 74HC125 would buffer the 8 x IC's (either TPIC6C595's or 74HC165's).

From your response I presume I should be buffering all 4 lines:

• SRCK (SPI CLOCK)
• RCK (LATCH)
• MOSI (or MISO for the inputs); and
• CE (SPI SS)

Responding to your previous comment, each register takes 1 byte so each I/O board would by 8 bytes of data. These I/O boards could be cascaded, each new board would take another 8 bytes from the one MOSI data line from the uC.

I got lost a little bit re. the timing. I realise that it is a good idea to be buffering all 4 lines so that timing stays in sync due to the 11ns delay through the buffer.

I didn't quite understand this comment or any of the timing info you supplied after that (sorry, I'm still new to this):

Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change.

I didn't understand this either - I assumed to read the inputs from the 74HC165's I could still do this with the uC in SPI master mode:

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So yeah, still a little bit confused....

[rs20]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

Thats exactly what I intend on doing, but if the cascaded chain of 74HC165's is on the same SPI bus as other devices the MISO pin from the cascaded chain needs to be tri-stated - yes ?

Only if you want to read something back from the shift registers -- but if, for example, you are only driving LEDs with your shift registers, then you don't need or want to read anything back at all, and therefore there's no reason to connect the final Q/"MISO" line to anything at all.

[danadak]

Just a thought but I think you could do do this in a muxed fashion
with a single chip to do all 60 leds, as well as the relay driver
out, and various inputs, with a SPI interface. PSOC 5LP

In fact possibly thru DMA design primarily all HW.

Additionally could be done DMX, I2C, UART, USB, One wire, SMBUS,
as well as SPI.

If you wanted to stay with SR approach design permits custom component
realization inside PSOC, thru verilog or schematic capture. Although I think
you would run up against chip power rail current limits (if not muxed).

Just a thought.


Regards, Dana.

[ilium007]

Only if you want to read something back from the shift registers -- but if, for example, you are only driving LEDs with your shift registers, then you don't need or want to read anything back at all, and therefore there's no reason to connect the final Q/"MISO" line to anything at all.

I will be using the 74HC165 shift registers to capture the inputs from the 35 switches so I will need the tri-stated MISO line.

[C]

when you want to connect a lot of chips in series, step one is the series connection between the chips.
The TPIC6C595 could have 5 signals in the series connection.
SER IN comes from the previous chip.
The remaining 4 are parallel connected. A parallel connection like this can have fan out problems. Will get back to this later.

In figure 14 the SRCLR pin is pulled high. Read 8.3.2, and note that as wired in figure 14, using the clear input would turn on the LEDs. With no clear input, you have random data on output at power up until the MCU has initialed proper levels by a serial shift of all bits followed by pulse on RCK.  But note with control of G you can turn off outputs so random data in latch should not be a problem.
 
If this is ok then you have 4 signals between chips to daisy chain.

You add buffers to reduce fan-out load but also to clean up the signals.

Step two is the interface width mpu to drive these signals properly.
A quick look suggests some work when connected to SPI & some might not.

Serial in could connect to MOSI
Serial clock could then connect to SCI clock

RCK does not match up to a SCI signal.
As shown on page 9, "Voltage Waveforms" this pin wants a pulse after shifting all bits out.
G also does not match up.
So use two pins of MCU for RCK & G

If you have something else connected to SPI port then CS needs to prevent clocks to RCK when not selected.
This gives MPU to buffer to TPIC6C595 with the SPI CS controlling the OE of buffer to RCK

I'm thinking of designing these boards with 64 I/O on the one board - that way a single 74HC125 would buffer the 8 x IC's (either TPIC6C595's or 74HC165's).

This is putting a lot of connections to one board and in process adding a lot of wire to get from board to leds.
If you are going to have PC boards made, more smaller boards could be cheaper.

Timing
"INPUT SETUP AND HOLD WAVEFORMS" page 9 SRCK & SER IN
If you read up on SOI, tsu = th with both = 25% of clock
 tsu + th = 50% of clock
 
Now if SRCK has a period of 110ns
The signals are delayed 11ns per buffer. After 10 buffers the signals align again with one bit delay in time.
Now think of what would happen for above if one signal went through 5 more buffers the the other. You would have data changing at same time as clock,.
If SRCK is slower it would take more buffers to get one bit time delay.

For Input chain
If you think it through, you could get a huge fan-out with two levels of buffers.
The problem with this is long signal runs with boards around the layout.
With buffers in series, you can use a slower clock to collect input data. With slower clock the 11ns per buffer becomes a smaller % of clock time. 
With MPU driving the clock input and MPU reading the data output of buffer chain.
In the above drawing Tsu is changing from 25% with each added buffer.

So to put it all together
Using the MOSI & SPI clock lets you output data faster. You still need two more pins for RCK to latch data & for G

For input nothing stops you from using signal that goes to RCK to latch the input data many times and not read the inputs.
Then after X outputs of RCK you could use and additional pin to clock the 74HC165 shift registers  at slower rate and one more pin to read the data using bitbang mode.
For input 10 to 20 reads of inputs is probably fine. If you are using switches to supply the inputs to the 74HC165 you could have some contact bounce.

This totals 6 pins on MPU.
The higher output rate would let you dim the leds if you wanted to.

 

[ilium007]

Thanks again for your time and detailed reply. I had drawn this up before I read your response. It is just for the outputs on the TPIC6C595 fed from the uC.

Each 'cascade' of TPIC6C595's (and there will only be one cascade because each board will be serially connected to another) will have one SS pin on the uC, this digital pin will also control all OE inputs on the quad buffer IC to bring each pin out of its tri-state high impedance mode.

LATCH_IN and SS_IN in the schematic below are just digital outputs on the Teensy 3.6. MOSI_IN and SCLK_IN are the hardware SPI pins on the Teesny 3.6.



I am still processing the part about timing and I haven't yet got to the input stage to think about them.

One other issue I am going to face is the Teensy 3.6 I'm using is 3.3v and the TPIC6C595 chips are 5v. I am going to require level conversion - I am hoping there is a 74HC125 alternative that does buffering and level conversion 3.3v -> 5v but then I will need something that will do the 5v -> 3.3v for the MISO input from the 74HC165's.

[Ian.M]

Actually RCLK can be treated as a SPI /SS signal - shift out N bytes of data for a write-only daisychain of N TPIC6C595 chips with RCLK low and latch it onto the outputs when RCLK goes high.   You don't even have to gate SRCLK with /SS on a shared SPI bus as any garbage shifted in while its /SS is high is pushed out by the N data bytes before it can be latched.

Few applications need the G output enable signal or the CLR reset signal under MCU control, so you typically only have to buffer SRCLK and RCLK.  The slight timing skew by not buffering SEROUT is negligible over short interconnects, as SEROUT is synched to SRCLK at each device so the relative skew cant accumulate

Also its fairly pointless buffering them for *EVERY* TPIC6C595.  You only need to buffer if the daisy chain goes off board or if the fanout of the  previous buffer (or MCU output pin) would be exceeded.   

As it will be a lot cheaper in prototype quantities to make a smaller relay board, and have lots of them rather than making one big biard as a one-off, I'd put one TPIC6C595 and one 74LVC2G34 (possibly with series resistors on its outputs to limit the slew rate), eight relays and eight antiparallel diodes across their coils on each board.

Unidirectional level translation is trivial: for 3.3V=>5V upwards translation use any 74HCT gate powered at 5V as TTL thresholds are 3.3V logic compatible.  For 5V=>3.3V downwards translation, as long as you keep the load on the 3.3V side down to one gate input and minimal track length, you can use a resistive potential divider, possibly with a few pF of speed-up capacitance across its upper arm to compensate for the load capacitance and square up the edges. 

If you need anything better look at the 74LVC1T45 (single) and 74LVC2T45 (dual) level translators with independent VCC pins for their two sides.

[ilium007]

Actually RCLK can be treated as a SPI /SS signal - shift out N bytes of data for a write-only daisychain of N TPIC6C595 chips with RCLK low and latch it onto the outputs when RCLK goes high.   You don't even have to gate SRCLK with /SS on a shared SPI bus as any garbage shifted in while its /SS is high is pushed out by the N data bytes before it can be latched.

Few applications need the G output enable signal or the CLR reset signal under MCU control, so you typically only have to buffer SRCLK and RCLK.  The slight timing skew by not buffering SEROUT is negligible over short interconnects, as SEROUT is synched to SRCLK at each device so the relative skew cant accumulate

Also its fairly pointless buffering them for *EVERY* TPIC6C595.  You only need to buffer if the daisy chain goes off board or if the fanout of the  previous buffer (or MCU output pin) would be exceeded.   

As it will be a lot cheaper in prototype quantities to make a smaller relay board, and have lots of them rather than making one big biard as a one-off, I'd put one TPIC6C595 and one 74LVC2G34 (possibly with series resistors on its outputs to limit the slew rate), eight relays and eight antiparallel diodes across their coils on each board.

Yeah, I was only going to have one buffer per board (up to 8 shift registers but will be lower given the advice in this thread).

So what pins do I absolutely need to buffer for fanout reasons ? RCLK, SCLK ? I understand MOSI (SER_IN) won't require buffering, SS probably doesn't given what you said about G (OE) not being required (I think it should be tied low not high via the pullup as shown in my schematic)

[Ian.M]

You need to buffer ONLY those signals that would otherwise be wired in parallel to the whole daisychain.  Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

With PCB area being the dominant cost for prototypes (often 10x of a board is a negligible cost increase over 1x) it doesn't make a lot of sense to put many shift registers on the same board.  The extra cost of right angle M and F headers and PCB mount spade lugs and  4x the number of buffers will almost certainly be cheaper than larger boards.  Its also easier to test!.

It *may* make sense to put two shift registers on the same board, depending on the size of the relays, and any steps in cost vs board area.   Its different economics if you are using padboard or stripboard - then you need to pack as many as possible on one standard size board

[ilium007]

You need to buffer ONLY those signals that would otherwise be wired in parallel to the whole daisychain.  Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

With PCB area being the dominant cost for prototypes (often 10x of a board is a negligible cost increase over 1x) it doesn't make a lot of sense to put many shift registers on the same board.  The extra cost of right angle M and F headers and PCB mount spade lugs and  4x the number of buffers will almost certainly be cheaper than larger boards.  It *may* make sense to put two shift registers on the same board, depending on the size of the relays, and any steps in cost vs board area.   Its different economics if you are using padboard or stripboard - then you need to pack as many as possible on one standard size board

Understood. I will look at the economics of the board sizes. Only one type of board will be a relay board and 8 relays is all I require for this project so that one is easy. The other boards will be a N-channel MOSFET output board to trigger the 26 solenoids (pulse current is approx 3A !), so maybe a 32 output board (4 x TPIC6C595's and 1 x buffer), and a board just for driving the LED's on a control panel, approx 50 LED's all within close proximity so maybe 2 x 32 output boards just for LED's (similar to the MOSFTE boards just without the 2N7002 output MOSFETS and flyback diodes (the TPIC6C595's will sink enough current for the LED's).

I want to be able to use these designs later on for other projects so I'm trying to build things as generic as possible.

[ilium007]

Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

I had thought of being able to dim all LED's on the control panel so that when the room lights are dimmed I could then dim the control panel so that 60 LED's didn't light the room up. PWM on the G pin is a good idea ! I might include this just in case I want to go down this path. I'll look for a quad buffer version of those level translators mentioned above.

[C]

large model railway
drive points solenoids

Some people would like a quiet slow points change for their model.
You could do this with an RC Servo if you want this.
The same circuit could also move crossing gates.

[ilium007]

They are Peco points which my father has already purchased the 26 x Peco solenoids for. There are 4 other dual gauge tracks that I have already built slow moving servo actuators for.

[Ian.M]

For indicator LED driving, you'd be better off with a MAX7219 or MAX7221.  Each can drive a 8x8 matrix of LEDs with 40mA at 1/8 duty cycle, doesn't need current limiting resistors for each LED and has an overall brightness control register.   They can also drive seven segment displays, and you can mix  BCD decoding and raw matrix on the same chip - e.g. four digits + a 4x8 matrix. Cheaper Chinese clones of these chips are usually of acceptable quality.  They are popular in the Arduino community, so you'll easily be able to find libraries for them.

[ilium007]

These boards are not just driving LED’s. I’d rather build a generic board that can be used for other things, not just driving leds. The TPIC shift registers are nice because of their current sink limits that mean I can drive leds at 20mA each concurrently as well as drive relays. I don’t want to get in to matrix driving leds.

[ilium007]

This is all RS Components here in Australia lists for a non-inverting level shifting buffer (same part mentioned in this thread):



And its on backorder until April next year....

[Ian.M]

As I said earlier, *ANY* 74HCT  simple logic gate will do for upwards translation as long as you can wire it as a non-inverting buffer, and for downwards translation, you can use a potential divider - 1K5 upper resistor, 3K3  lower resistor with about 10pF across the upper resistor should do nicely as long as its close to the 3.3V level input.

It looks like Mouser Australia currently has stock of both 74LVC1T45 and 74LVC2T45.

[ilium007]

You need to buffer ONLY those signals that would otherwise be wired in parallel to the whole daisychain.  Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

With PCB area being the dominant cost for prototypes (often 10x of a board is a negligible cost increase over 1x) it doesn't make a lot of sense to put many shift registers on the same board.  The extra cost of right angle M and F headers and PCB mount spade lugs and  4x the number of buffers will almost certainly be cheaper than larger boards.  It *may* make sense to put two shift registers on the same board, depending on the size of the relays, and any steps in cost vs board area.   Its different economics if you are using padboard or stripboard - then you need to pack as many as possible on one standard size board

Understood. I will look at the economics of the board sizes. Only one type of board will be a relay board and 8 relays is all I require for this project so that one is easy. The other boards will be a N-channel MOSFET output board to trigger the 26 solenoids (pulse current is approx 3A !), so maybe a 32 output board (4 x TPIC6C595's and 1 x buffer), and a board just for driving the LED's on a control panel, approx 50 LED's all within close proximity so maybe 2 x 32 output boards just for LED's (similar to the MOSFTE boards just without the 2N7002 output MOSFETS and flyback diodes (the TPIC6C595's will sink enough current for the LED's).

I want to be able to use these designs later on for other projects so I'm trying to build things as generic as possible.

The problem with Mouser is the $24 flat shipping charge on orders under $60 ! RS does free shipping on all orders but has no stock !!

I will look further at the voltage divider, what are the drawbacks vs an IC ? Surely there must be benefits in using the IC.

[Ian.M]

The voltage divider has minimal drive capability - even 2" of track to a single input could be a problem if its too close to the SPI clock output.

It would be worth looking through RS's site for stocked 74LVC1Gxx non inverting gates, then check the datasheet as 5V tolerant inputs (when the gate's Vcc is 3.3V) are common in that logic family.

2N7002 mosfets would be too wimpy for driving the points solenoids. You have two options there - either 74HC595 driving the gates of logic level power MOSFETs, or PNP power transistors as emitter followers to boot the TPIC6C595 output current capability.   If you are clever with your PCB design, you could have one TPIC6C595 board layout that depending on how you populate it could have relays, PNP power transistors ore current limiting resistors for LEDs.

One concern with driving points solenoids is burning out their coils if the output stays on.  There are two ways of mitigating this - either put a large electrolytic capacitor + a resistor across it in series with the coil common so once the capacitor has discharged the resistor limits the remaining current, or add a current sensor in the positive feed to all the solenoids on that interface board, and if the current stays on too long, reset the TPIC6c595.

[ilium007]

I am using a capacitor discharge unit to drive the output for the solenoids, I think it reduces its output current after activation but these are only ever pulsed on. I’m using a different DPAK2 package MOSFET for the solenoids - NTD5867NLT4G. I’m using the 2N7002 MOSFETs to drive relay coils only.

[phil from seattle]

The problem with Mouser is the $24 flat shipping charge on orders under $60 ! RS does free shipping on all orders but has no stock !!

Are you not in the US? I opt for USPS delivery from them for small orders and it's usually like $4. Most of my orders are less than $60.

[ilium007]

The problem with Mouser is the $24 flat shipping charge on orders under $60 ! RS does free shipping on all orders but has no stock !!

Are you not in the US? I opt for USPS delivery from them for small orders and it's usually like $4. Most of my orders are less than $60.

No - I'm in Australia, I think we have the worst postage costs in the world !!

[Ian.M]

I am using a capacitor discharge unit to drive the output for the solenoids, I think it reduces its output current after activation but these are only ever pulsed on. I’m using a different DPAK2 package MOSFET for the solenoids - NTD5867NLT4G. I’m using the 2N7002 MOSFETs to drive relay coils only.

Yes, a capacitor discharge circuit avoids the risk of burnout, if the MCU crashes at the wrong moment or corrupted data is shifted into the solenoid interface and not updated quickly enough. 

Its probably worth updating *ALL* the outputs every time the firmware executes its main loop - SPI is pretty efficient so even with a reasonably low click speed, (e,g a few hundred KHz) it should be possible to update them all in under a millisecond, so the overhead isn't too bad.  That wa any glitches that cause incorrect output states get rectified a small fraction of a second later.

What relays are you using (or what is their coil resistance)?
If you cant drive them direct from a TPIC6C595,  then you can probably do a 74HC595 board with footprints for 2N7002 and your DPAK2 MOSFETs.

[ilium007]

I am using a capacitor discharge unit to drive the output for the solenoids, I think it reduces its output current after activation but these are only ever pulsed on. I’m using a different DPAK2 package MOSFET for the solenoids - NTD5867NLT4G. I’m using the 2N7002 MOSFETs to drive relay coils only.

Yes, a capacitor discharge circuit avoids the risk of burnout, if the MCU crashes at the wrong moment or corrupted data is shifted into the solenoid interface and not updated quickly enough. 

Its probably worth updating *ALL* the outputs every time the firmware executes its main loop - SPI is pretty efficient so even with a reasonably low click speed, (e,g a few hundred KHz) it should be possible to update them all in under a millisecond, so the overhead isn't too bad.  That wa any glitches that cause incorrect output states get rectified a small fraction of a second later.

What relays are you using (or what is their coil resistance)?
If you cant drive them direct from a TPIC6C595,  then you can probably do a 74HC595 board with footprints for 2N7002 and your DPAK2 MOSFETs.

I haven't decided on relays yet. I started looking at data sheets and costs yesterday and some of these get quite expensive per unit. I took advice from the previous thread and will do 12v relays. I am switching PWM current on train tracks so a DPST would work but they were more expensive than DPDT and had the same footprint. The coil resistance was about 300 ohm on all of them so about 40mA - I figured the 2N7002 behind the TPIC6C595 would be overkill - the TPIC6C595 could probably just do it by itself.

This was the relay I was thinking about using - 360 Ohm coil resistance / 33mA current draw:
http://au.rs-online.com/web/p/non-latching-relays/6803830/

The relays will switch the parallel track power to energise a different segment of the track - current draw of a single train on the tracks was measured at about 1A being driven by a 20kHz PWM Pololu MC33926 based driver:
https://www.pololu.com/product/1212

I like the idea of one board design that will accomodate all options. I think I will do 32 channel boards and save space for 8 optional relays on the board controlled off one of the 4 TPIC6C595 ICs that would give the 32 channels.

[ilium007]

It would be worth looking through RS's site for stocked 74LVC1Gxx non inverting gates, then check the datasheet as 5V tolerant inputs (when the gate's Vcc is 3.3V) are common in that logic family.

You are right - there are a heap that will work for this scenario. Given I am having to level shift the 3.3v I will have to buffer all SPI lines I assume, SCLK, RCLK, SS and MOSI/MISO I will need a quad buffer - this one looks like it will work:

SN74LVC126AD
http://www.ti.com/lit/ds/symlink/sn74lvc126a.pdf



On the input cards that have the MISO line I will still need a single buffer IC with Vcc at 3.3v that will accept the 5v input such as the 74LVC1G125DRLR which is in stock at RS:
http://au.rs-online.com/web/p/buffer-line-driver-combinations/6626605/

[Ian.M]

No. you cant use a SN74LVC126A for the MCU output lines that need to shift up to 5V levels, as its max Vcc is 3.6V.   Use something from the 74HCT family that's non-inverting and not open drain.

For the input lines, you can use 74LVC1G125 powered at 3.3V. 

I recommend putting the level translating buffers on the MCU board.   On the shift register boards, only use 5V buffers.

[ilium007]

No. you cant use a SN74LVC126A for the MCU output lines that need to shift up to 5V levels, as its max Vcc is 3.6V.   Use something from the 74HCT family that's non-inverting and not open drain.

For the input lines, you can use 74LVC1G125 powered at 3.3V. 

I recommend putting the level translating buffers on the MCU board.   On the shift register boards, only use 5V buffers.

Ok understood. I read the data sheet wrong.

[ilium007]

No. you cant use a SN74LVC126A for the MCU output lines that need to shift up to 5V levels, as its max Vcc is 3.6V.   Use something from the 74HCT family that's non-inverting and not open drain.

For the input lines, you can use 74LVC1G125 powered at 3.3V. 

I recommend putting the level translating buffers on the MCU board.   On the shift register boards, only use 5V buffers.

Ok understood. I read the data sheet wrong.

I looked at the data sheet screen shot I posted above and it says Vcc max is 6.5v doesn’t it ? I’m confused now !

[Ian.M]

See section 6.3 Recommended Operating Conditions for the voltage range it will function at.   Section 6.1 Absolute Maximum Ratings only tells you what it will survive without dying, not if it will function at that voltage.

[ilium007]

See section 6.3 Recommended Operating Conditions for the voltage range it will function at.   Section 6.1 Absolute Maximum Ratings only tells you what it will survive without dying, not if it will function at that voltage.

Ahhh ok

[ilium007]

I have looked at the 74HCT IC’s and the venerable 74HC125 came up and the data sheet also covers the 74HCT125 that was recommended above. I’m not sure why I need the HCT series given the HC will run at 5v and accept min Vin of 0v. It looks to me that the 74HC125 would work for the 3.3v input.



I found this data on another site:

https://electronicsclub.info/74series.htm

The 74HC family has High-speed CMOS circuitry, combining the speed of TTL with the very low power consumption of the 4000 series. They are CMOS ICs with the same pin arrangements as the older 74LS family. Note that 74HC inputs cannot be reliably driven by 74LS outputs because the voltage ranges used for logic 0 are not quite compatible, use 74HCT instead.

The 74HCT family is a special version of 74HC with 74LS TTL-compatible inputs so 74HCT can be safely mixed with 74LS in the same system. In fact 74HCT can be used as low-power direct replacements for the older 74LS ICs in most circuits. The minor disadvantage of 74HCT is a lower immunity to noise, but this is unlikely to be a problem in most situations.

For most new projects the 74HC family is the best choice. The 74LS and 74HCT families require a 5V supply so they are not convenient for battery operation.

So why do I choose HCT over HC IC’s ?

Sorry for all the questions.

[Siwastaja]

HC's have "normal CMOS" input thresholds halfway between GND and VCC, and unambigious range between about 30% and 70% of Vcc (slightly depending on the part, of course). I.e., when powered from 5V, to get "zero", you need to input < 1.5V, and to get "one", you need to input > 3.5V. The latter requirement makes it unusable for level conversion from 3.3V, as you'd need at least 3.5V input signal for reliable "one". So it typically works only by luck on the lab table until you put ten units on the field...

HCT parts, on the other hand, offer so-called TTL levels (one of the most misused terms ever, so now we are talking about the correct definition) on their inputs, which means they guarantee that anything over 2.4V is interpreted as "one", even with a 5V supply. That's why you can use a 74HCT buffer (or any other gate) to do a level conversion from a 3.3V to 5V.

Fancier level conversion parts exist, but if it's just unidirectional 3V3 output to 5V on a logic PCB, a HCT buffer is a good solution.

[ilium007]

HC's have input thresholds halfway between GND and VCC, and unambigious range between about 30% and 70% of Vcc (slightly depending on the part, of course). I.e., when powered from 5V, to get "zero", you need to input < 1.5V, and to get "one", you need to input > 3.5V. The latter requirement makes it unusable for level conversion from 3.3V, as you'd need at least 3.5V input signal for reliable "one". So it typically works only by luck on the lab table until you put ten units on the field...

HCT parts, on the other hand, offer so-called TTL levels (one of the most misused terms ever, so now we are talking about the correct definition) on their inputs, which means they guarantee that anything over 2.4V is interpreted as "one", even with a 5V supply. That's why you can use a 74HCT buffer (or any other gate) to do a level conversion from a 3.3V to 5V.

Fancier level conversion parts exist, but if it's just unidirectional 3V3 output to 5V on a logic PCB, a HCT buffer is a good solution.

Great - I get it now. I just re-read the data sheet and found the reference to the threshold 1/2 way between GND and Vcc.

Thanks for your patience guys !

[ilium007]

I've just put a breadboard together with 2 x TPIC6C595 and 1 x 74HC125 (I'm testing at 5v as I don't yet have the Teensy 3.6 so the 74HC125 will work).

I have set up the 74HC125 buffer to handle SRCK and RCK and I'm just driving the OE inputs on the buffer with a digital pin off the Teensy++ 2.0 at 5v - so only using two buffers on the IC initially.

It was mentioned previously to do the level shifting on the uC board, which I will do when the time comes, and do buffering at 5v on the IO boards I am building, makes sense also.

This question is around buffering of the OE pins (that I am currently driving direct from the uC). Each IO board I build will have a buffer IC that requires OE pins on its buffer IC to be driven - I don't want to do this from the uC to every IO board in parallel. I wan't to give the SS signal to the first IO board and then buffer it along the chain of IO boards. How does this pin get buffered between boards given the SS signal from the uC will have to trigger the OE on the first IO board's 74HCT125 that is also buffering the very same SS signal - it will be using the SS feed to enable the buffer to buffer itself. I'm not sure if this makes sense, I have drawn a quick schematic to try and explain.



On the left I have SS_IN on pin 12 from the uC board at 5v, this same signal also feeds the OE pin 13 to then buffer itself out on pin 11. The OE on pin 13 will also feed the OE on pins 10 and 1. The buffered SS output on pin 11 is daisy chained to the next boards OE pins and SS buffer and the cycle repeats.

I am trying to avoid fan out issues from the uC board which may occur if I am running SS feeds to many IO boards.

[Ian.M]

For the 74HC125 control line output buffers simply tie all their /OE pins to 0V.   You *NEVER* need or want to tristate the output buffers.

The last input board in the chain (nearest to the MCU) needs tristate control of its data out, driven by /SS, but the others don't.   Put that /OE on a separate pin of the inter-board connector so you can connect it to /SS at the MCU and ground it at the connector for the next board.

[ilium007]

OK - thanks

No smoke is coming out so thats a good thing !

https://youtu.be/8aBOuiYHxXk

[ilium007]

For the 74HC125 control line output buffers simply tie all their /OE pins to 0V.   You *NEVER* need or want to tristate the output buffers.

The last input board in the chain (nearest to the MCU) needs tristate control of its data out, driven by /SS, but the others don't.   Put that /OE on a separate pin of the inter-board connector so you can connect it to /SS at the MCU and ground it at the connector for the next board.

Lets just say I had some other device on the same SPI bus that listened on the MOSI line for data (let say a hypothetical SPI display device) and I didn't want my chain of output boards receiving the data destined for the display, would this be a case to disable the buffers OE pins on the output chain instead of just tying them all to GND. This would put my output chain into tristate mode for SRCK, RCK and MOSI lines and they would ignore the data going to the display.

It probably wouldn’t affect anything because the next time I feed in x bytes of data and latch the chain all the erroneous data would have been shifted out.

Just an example but I'm interested in understanding how other devices could co-exist on the same SPI bus.

[Ian.M]

It doesn't matter what gets clocked along the chain as long as /SS isn't pulsed.  However if you are running the display much faster and don't want the EMI and possible glitch issues of running over-speed data and clock down the chain, then yes you *COULD* gate SPI SCLK and MOSI with /SS, using the /OE pins on the buffers, but it would be essential to have pullups or pulldowns on the buffer outputs to maintain both signals at a valid logic level, the same as their normal 'idle' level while they are disabled by /SS high.  If you get the SCLK idle level wrong, you get an extra active clock edge either on the falling or rising edge of /SS which could cause problems.

IMHO this sort of gating should be done on your MCU board - do it at the level shifter and have one 74HCT125 quad buffer as the upwards level shifter and a 74LVC1G125 as the downwards level shifter per external shift register board connector.  As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.  That also lets you mix 5V and 3.3V SPI slaves, as the master bus is 3.3V and it only gets shifted up to 5V for the 5V slaves.   3.3V peripherals can be buffered  and gated the same way, just substitute a 74HC125 run at 3.3V.  Design your board so you can populate either a pullup (to the '125 Vcc) or a pulldown for MOSI and SCLK buffered outputs as you'll need to be able to make the idle states consistent with the SPI mode of the peripheral on that connector. 

[C]

When you have many devices and only want to work with one, you select it in a way so only one is active.

For a memory chip, one way is chip select.

To select on SPI
  You need to things
   The tri-state of MISO so that only one is trying to talk to mpu.
   The Stopping of MOSI data being used at wrong time.
   
  If SRCK dies not happen then a data Input change to chip does not matter.
  If RCK does not happen then Data in the shift register does not get latched. .

So garbage data in shift register does not matter if no RCK
Data changing on Shift register input does not matter is no shift register clock

You asked about display and this. It could also be two or more separate chains of this.

You might have
   SPI display
   SPI chain for console
   SPI chan for track
SPI ...

Each would have a select input.
   The select input  would enable output to MCU and
   enable RCK & SRCK clocks to chain
   MOSI data would not be used with no SRCK

So step one, look at many separate chains of your boards, can you control them one at a time.

If nothing happens between MCU and first serial output chip, then additional chips(boards) also see no change. 
Changing the select input should do nothing but enable clocks to happen, no logic level change on clock input.

Adding an additional SPI device should be simple.
 Check that fan-out to drive more SPI inputs is not a problem.
 Give the MCU a way to control the added select line.
Add software for additional SPI device.

Ian.M is stating same with more detail

One important detail in Lan.M's not to be missed.

Speed differences between things connected to the MCU's SPI port.
The MCU is talking to all at same time.
One version of your boards could use very slow version of logic. Trying to clock this version to fast and you get garbage.
  You have two choices, slow every one down to this safe speed for all
 OR
 Prevent this version of seeing any of the high speed changes.

 

[David Hess]

I will just describe how I did it with less complexity and 4 signal lines.

I used only 74HC165s for inputs and 74HC595s for outputs with no other logic.  The shift/-load pins on the 74HC165s were all tied in parallel with the load pins of the 74HC595.  The clock pins were all tied in parallel.  All 74HC165s and 74HC595s were daisy chained between the serial output and serial input pins of the controller.

So with shift/-load/load held high, new serial data is clocked through all of the registers, then shift/-load/load is toggled low momentarily to latch data out of the 74HC595s and latch data into the 74HC165s, then the serial data is clocked again to read the 74HC165s which should be located at the end of the chain for best performance.  If only a read from the 74HC165s is desired, then duplicated output data has to first be copied to the 74HC595s but that is what shadow registers are for.

The whole thing was way more than fast enough to control 8 7-segment digits (64 bits) plus a full keypad (16 bits) in real time from a PIC which was busy doing other things.  Access could be synchronously timed for minimum noise if necessary which is why I did not use a multiplexed display.  If I did it today, I would probably replace the whole thing with the least expensive 28-pin PIC or similar and program it for multiplexed operation unless the lowest noise is required or the highest reliability.

[ilium007]

It doesn't matter what gets clocked along the chain as long as /SS isn't pulsed.  However if you are running the display much faster and don't want the EMI and possible glitch issues of running over-speed data and clock down the chain, then yes you *COULD* gate SPI SCLK and MOSI with /SS, using the /OE pins on the buffers, but it would be essential to have pullups or pulldowns on the buffer outputs to maintain both signals at a valid logic level, the same as their normal 'idle' level while they are disabled by /SS high.  If you get the SCLK idle level wrong, you get an extra active clock edge either on the falling or rising edge of /SS which could cause problems.

IMHO this sort of gating should be done on your MCU board - do it at the level shifter and have one 74HCT125 quad buffer as the upwards level shifter and a 74LVC1G125 as the downwards level shifter per external shift register board connector.  As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.  That also lets you mix 5V and 3.3V SPI slaves, as the master bus is 3.3V and it only gets shifted up to 5V for the 5V slaves.   3.3V peripherals can be buffered  and gated the same way, just substitute a 74HC125 run at 3.3V.  Design your board so you can populate either a pullup (to the '125 Vcc) or a pulldown for MOSI and SCLK buffered outputs as you'll need to be able to make the idle states consistent with the SPI mode of the peripheral on that connector.

Which line are you referring to as /SS ? It is the RCK (latch) line ?

[Ian.M]

@David Hess,

That's great for a limited number of shift registers all on the same board. However I'm surprised you put the 74HC165s in the same daisychain as the 74HC595s - that's fairly pointless unless you are going to shift the output data all the way round so it can be checked against what it was meant to be to catch glitches in a high EMI environment.

The problems start when you have many boards and interconnects in each daisychain  + other SPI devices, hence the more complicated (but expandable) solution 'C' and myself are proposing.

@ilium007,
If you are using '595 style SIPO shift registers, that latch their data on the rising edge of their store clock, then yes that's SPI /SS.   If you are using PISO shift registers for input it gets a lot more complex as you need to latch the inputs into the shift register as /SS goes low so may need some glue logic on the first board to generate a strobe for the chain with the right timing.

[David Hess]

That's great for a limited number of shift registers all on the same board. However I'm surprised you put the 74HC165s in the same daisychain as the 74HC595s - that's fairly pointless unless you are going to shift the output data all the way round so it can be checked against what it was meant to be to catch glitches in a high EMI environment.

The problems start when you have many boards and interconnects in each daisychain  + other SPI devices, hence the more complicated (but expandable) solution 'C' and myself are proposing.

I wasn't recommending my solution so much as describing it for edification; the load signal may be shared for inputs and outputs even in a minimum logic design.

Like I said, except where the absolute minimum noise is required or the highest reliability, I would use a multiplexed design now but that may not be convenient for your application.

[ilium007]

As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.

So /SS is the RCK, or latch, line, is it also being used to control /OE on the buffers ? /OE is active low so when high it puts the buffer gate into high impedance mode. So if /SS isn’t latching it is low, this would mean the buffer gate are active but then go high impedance when the shift registers are latched ?

[ilium007]

If you are using PISO shift registers for input it gets a lot more complex as you need to latch the inputs into the shift register as /SS goes low so may need some glue logic on the first board to generate a strobe for the chain with the right timing.

How much more complex ??!! I will be using 74HC165’s PISO shift registers for the inputs. Does this get complex because of what I mentioned previously, the /SS line is disabling the /OE on each buffer.

I’m starting to think I should have just persisted with the MCP23x17 IC !

[Ian.M]

Not vastly more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse for SH/nLD immediately after the falling edge of /SS.   You also have tristating the final data out to take care of if there are other SPI inpuut or IO devices and you may want to run /SS to all the ClkInh inputs to stop them shifting when not selected.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.  Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

[Buriedcode]

Forgive me if I get something wrong, I really haven't read the whole thread, just skimmed (always dangerous) but I if you simply wish to have lots of inputs, and lots of outputs, then I see no need to tristate anything.

This is especially true if you are using a teensy, which has more than one SPI port, you can dedicate an SPI port to output and input shift register (74HC595 for output and 74HC165 for input).  I'm not sure why there is talk of buffers, tristating, and extra logic. Sure you'll need an extra latch pin, but this doesn't have to be part of the SPI port.. often people bitbang the SS/CS line anyway.  You'll also need an extra line for the 165's to latch in their inputs to the register.  I would daisy chain the 595's to MOSI, and the 165's to MISO.  There are a few ways to do this, but having tristate buffers for each shift register so that you can read in from the 165's without writing/updating the output register seems over kill.

I think perhaps you're concentrating too much on the SPI spec rather than just using SPI to drive shift registers (which can have different control lines to actual SPI). The SPI port, in master mode, is just being used as a sift register and clock generator. 

From what I have read - again could be wrong! - there is some confusion because there are lots of terms that can be inter-changable depending on the application, /OE, /CS, /SS, latch, Rclk, clock enable etc..
Diagrams are much better.

[ilium007]

Not a lot more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse immediately after the falling edge of /SS.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.
Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

I have absolutely zero understanding as to how any of what you said would actually work ! I am happy to go and research some more. If this can be done in software I can continue trying to get a board design done but if it relies on hardware changes I will need to stop and gain some more knowledge first. I haven't read anywhere about people running into timing issues with the PISO devices - they all just say chain them together, latch them and the read the MISO on SCLK ! I thought this was going to be a somewhat simpler solution compared to the I/O expanders !

[ilium007]

Forgive me if I get something wrong, I really haven't read the whole thread, just skimmed (always dangerous) but I if you simply wish to have lots of inputs, and lots of outputs, then I see no need to tristate anything.

This is especially true if you are using a teensy, which has more than one SPI port, you can dedicate an SPI port to output and input shift register (74HC595 for output and 74HC165 for input).  I'm not sure why there is talk of buffers, tristating, and extra logic. Sure you'll need an extra latch pin, but this doesn't have to be part of the SPI port.. often people bitbang the SS/CS line anyway.  You'll also need an extra line for the 165's to latch in their inputs to the register.  I would daisy chain the 595's to MOSI, and the 165's to MISO.  There are a few ways to do this, but having tristate buffers for each shift register so that you can read in from the 165's without writing/updating the output register seems over kill.

I think perhaps you're concentrating too much on the SPI spec rather than just using SPI to drive shift registers (which can have different control lines to actual SPI). The SPI port, in master mode, is just being used as a sift register and clock generator. 

From what I have read - again could be wrong! - there is some confusion because there are lots of terms that can be inter-changable depending on the application, /OE, /CS, /SS, latch, Rclk, clock enable etc..
Diagrams are much better.

I'm not proposing one buffer per shift register, I am talking about one buffer per 8 shift registers and being able to expand this to 100 or 1000 shift registers. The buffer IC's are there to control fanout and voltage level shifting from 3.3v to the 5v operating voltage of the TPIC6C595 shift registers.

Diagrams are much better.

I am trying to get to the point of drawing a diagram but I am now so lost by the whole design I don't know where to start.

[ilium007]

Not vastly more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse for SH/nLD immediately after the falling edge of /SS.   You also have tristating the final data out to take care of if there are other SPI inpuut or IO devices and you may want to run /SS to all the ClkInh inputs to stop them shifting when not selected.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.  Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

What is:

strobe pulse for SH/nLD

[Ian.M]

The people just strobing the '165s to latch their inputs then shifting in the result aren't trying to use them with multiple SPI slave input or I/O devices  The alternative to the circuit I  mentioned to generate the strobe pulse from /SS is to provide a separate strobe from another pin of your MCU.

SH/nLD is SHIFT / not(LOAD), the pin that when taken low transfers the inputs to the shift register.   Different manufacturers datasheets will use different names, but they are all functionally equivalent for any 74xx165.

[ilium007]

The people just strobing the '165s to latch their inputs then shifting in the result aren't trying to use them with multiple SPI slave input or I/O devices  The alternative to the circuit I  mentioned to generate the strobe pulse from /SS is to provide a separate strobe from another pin of your MCU.

SH/nLD is SHIFT / not(LOAD), the pin that when taken low transfers the inputs to the shift register.   Different manufacurers datasheets will use different names, but the are all functoionall;y equivalent for any 74xx165.

If I did use a seperate pin on the MCU as a seperate strobe wouldn't I end up back in a fanout issue with *many* PISO shift registers ?

I think my problem is at present I just don't understand the problem I am attempting to fix ! I don't understand the timing issue that requires this delayed strobe pulse.

I am trying to find anything on the internet at the moment that explains it but it seems as though no one else has documented this issue !

[Ian.M]

You need to latch the inputs with a brief low going pulse before you can start shifting the data into the MCU.  Unfortunately that's not how the timing of a SPI /SS signal works as it stays low for the whole transfer in a multi-slave setup, + you need it low for the whole transfer to drive /OE for the tristate buffer on the last shift register's data out.   

You deal with the fanout issue by buffering it every few shift registers down the chain same as you did for the other signals apart from the serial data.

[ilium007]

I am going to have to try and draw it up. I am totally confused now. I am also looking at the SPI library (https://github.com/PaulStoffregen/SPI) and I don't know whether it is controlling the SS pin when the SPI.transfer is called.

I had no idea it was going to turn into this level of complexity.

[Ian.M]

See https://www.pjrc.com/teensy/td_libs_SPI.html#ss for dtails of how to handle the /SS pin driven by a Teensy master and the rest of that page for Teensy SPI in general.

The level of complexity is dependent on how much 'stuff' you have on the SPI bus, and also how expandable you want to make it.  A couple of '595s and '165s off a 5V Arduino(ish) board is fairly trivial, as the fanout permits them to be driven direct, and no level shifters are required.

[ilium007]

Can we work through one section at a time ? Output buffers first ?

Left block - shows the MCU board buffer being used for 3.3v to 5v level conversion, its OE pins tied to GND as it is always enabled. 4th buffer input tied to GND as it is unused. SRCK, RCK(SS) and MOSI buffered.

Middle block - RCK being used for SS / OE on buffers. SRCK, RCK(SS) and MOSI buffered. SRCK and MOSI with pull down resistors to set idle state when buffer is disabled by RCK.

Right block - represents xx number of output boards. Each one with SRCK, RCK(SS) and MOSI buffered.

Is this what we have spoken about to date in this thread ?

All components are numbered to allow reference to any mistakes.

**schematic was wrong - see post below**

[ilium007]

My previous schematic was totally wrong.

If I use the SS buffer OE ping tied to GND on the output board that buffer will always be active, I then pass the SS signal in to the first board and it gets buffered along the chain.

This SS buffered output is then used for the OE pins on the other two buffers:

[C]

Think about your last drawing

If you had a 5V SPI display you could share MOSI & SCK
But you would need a SS for a 5V display

If you wanted to use two sets of boards chains you would also need an additional SS so you could select chain one or chain two

So on your MCU output buffer
SS should be labeled SS #(n)
the un-used pin 2 could be a second SS #(n)

[ilium007]

But the schematic is correct yes ? I could cascade a bunch on TPIC6C595's off the end of the first one and then, as you say, have another SSn connection for, say, a display. I send SS1 HIGH (the cascaded boards) and bring SS2 (for the display) LOW. This was the MOSI, SRCK and SS are in tristate for the cascaded boards and SS2 brings the display online and it shares MOSI and SRCK from the MCU board.

I have 2 x TPIC6C595's running off a 74HC125 in front of me based on that schematic. I don't have another SPI device as yet to test the other use case.

In the diagram the "MCU OUTPUT BUFFER" sits on a seperate PCB to the cascaded TPIC6C595 boards. The buffer on the MCU board is doing 3.3v to 5v level conversion as well as assisting in reducing fanout issues for whatever amount of SPI devices I have connected to the SPI bus.

[bson]

For MRR use I'd look into CANbus.  Single wiring loop, addressable devices, priority transmission, broadcast mode (nice if you want to tell everything on the bus to reset! now!), can handle lots of devices, good noise immunity, well understood, and something pretty much every scope and USB LA can decode.

http://openlcb.org/openlcb-and-lcc-documents/layout-command-control-lcc/

If I were you I'd latch onto that!

[ilium007]

MRR ? I still want to be able to use these TPIC6C595 devices as they have excellent current capability for what I’m using them for on this project.

DCC is another whole can of worms I’m not getting in to ! It’s my fathers train layout and I’ve looked at DCC in the past and it’s on another level I don’t want to get involved with. I want to continue on the path of large scale basic I/O as I can use these learnings in other projects other than model railways !

[C]

For 74HCT595 in dip package

Pin 9 is serial data output and should connect to next 74HCT595 pin 14 serial data input

You might also want to add better/more labels to make drawing more under standable

[ilium007]

For 74HCT595 in dip package

Pin 9 is serial data output and should connect to next 74HCT595 pin 14 serial data input

You might also want to add better/more labels to make drawing more under standable

Sorry. This was just a quick hack up drawing, I’ll post a proper schematic later. I just wanted to know if I was on the right track for the output boards.

[bson]

MRR ?

MRR = model railroad

[ilium007]

MRR ?

MRR = model railroad

Hahah ok

[ilium007]

This is the updated output board idea with proper TPIC6C595 component in schematic - in the final schematic there will be 4 of the TPIC6C595 IC's per board.





Below is the input board and associated MCU board buffers / level shifter.

Starting at the MCU board:

• 74HCT125 used to shift voltage from 3.3v to 5v
• MOSI is included. I probably didn't have to, I just thought I could put it on the board connector
• I included a LATCH pin (digital I/O on the MCU) to perform the HIGH - LOW - HIGH pulse to load the input registers
• A seperate SS_2 pin is used to trigger OE on buffers and take the MISO input out of high impedance mode
• SCK is buffered out as well

On the input boards:

• Final schematic will show 8 x 74HC165's and 1 x 74HCT125 per board for 32 inputs
• The label numbering may be a bit confusing - I tried to show the number of buffers each signal has gone through
• SS_2_0 feeds the first buffer from the MCU board and outputs SS_2_1 which is used to turn on OE on all other buffers (at the same time as the MISO buffer is taken out of high impedance)
• CLK_1 input produces the CLK output for each 74HC165
• LATCH_1 loads each shift register
• CLK_INH is tied to GND - reading the datasheet I think this is what I am meant to do, with CLK_IHN LOW the data will shift out on the CLK pulses
• The final SER output feeds back into the QH which would then have its SER feed the next QH and so on back to the first 74HC165 before the MCU

Will including the extra digital pin for LATCH (IC U2 pin 12) alongside SS_2 (IC U2 pin 9) avoid the timing issues Ian.M mentioned earlier ?

I got the SER and QH pins mixed up, I’ll update tomorrow

[Ian.M]

When drawing schematics for boards that are going to be daisychained, *PLEASE* put all the host connections on one side and the next board interconnect on the other side.
There is a general convention for schematics that the flow should be left to right, so I would suggest drawing the output boards as if they were in a chain to the right of the MCU board, and the input boards as if they were to the left of the MCU.

It will help understanding to draw as much as possible of the schematic using individual logic symbols rather than IC physical pinout symbols - the schematic is not and should not be the wiring diagram.

[C]

I agree with lan.M
Poor drawings will waste a lot of your time.
Remember that some day you might need to relearn how a circuit works to fix, repair or change it.

On input board
If you enable and disable the parallel load to shift register then that Load pin could be shared between two or more input chains.

[Buriedcode]

I have done something similar with 595's and 165's, started with small boards with 8 in, and 8 out, but expanded to 64 of each (8 shift registers), this used SPI and some basic 'glue logic'.  It used the /SS line as a both a clock enable (when its low) and load (low-high transition).  It could also read in the inputs to the input shift register one  a high-low transition, making it pseudo-SPI compatible, but ended up using a separate IO for that.  I'll have to dig out the schem.

I can see why you'll need 3.3-5V conversion, I was assuming (wrongly) that the TPIC6C595 had TTL inputs, and might as well make them tristate-capable.

I would add some pulldowns (or pull ups) on inputs, because if you're going to have separate boards, you'll have inputs floating, which are protected but still would be best practice to keep them in a known state. 

[ilium007]

I agree with lan.M
Poor drawings will waste a lot of your time.
Remember that some day you might need to relearn how a circuit works to fix, repair or change it.

On input board
If you enable and disable the parallel load to shift register then that Load pin could be shared between two or more input chains.

Ok. Point taken, I’m learning here. I didn’t think they were that bad.

[ilium007]

I have done something similar with 595's and 165's, started with small boards with 8 in, and 8 out, but expanded to 64 of each (8 shift registers), this used SPI and some basic 'glue logic'.  It used the /SS line as a both a clock enable (when its low) and load (low-high transition).  It could also read in the inputs to the input shift register one  a high-low transition, making it pseudo-SPI compatible, but ended up using a separate IO for that.  I'll have to dig out the schem.

I can see why you'll need 3.3-5V conversion, I was assuming (wrongly) that the TPIC6C595 had TTL inputs, and might as well make them tristate-capable.

I would add some pulldowns (or pull ups) on inputs, because if you're going to have separate boards, you'll have inputs floating, which are protected but still would be best practice to keep them in a known state.

Thanks. I’m not sure what’s meant by the term ‘glue logic’ that’s been mentioned a couple of times now in this thread.
I’ll look at getting the pull down resistors in there as well.
If you could find your old schematic that would be appreciated.

[ilium007]

When drawing schematics for boards that are going to be daisychained, *PLEASE* put all the host connections on one side and the next board interconnect on the other side.
There is a general convention for schematics that the flow should be left to right, so I would suggest drawing the output boards as if they were in a chain to the right of the MCU board, and the input boards as if they were to the left of the MCU.

It will help understanding to draw as much as possible of the schematic using individual logic symbols rather than IC physical pinout symbols - the schematic is not and should not be the wiring diagram.

So from what you are saying, in KiCad I have to redraw each component to show its internal logic. The TPIC6C595 will look as follows:



I have not seen a single schematic involving the TPIC6595 on the internet while I have been researching this that shows that detail inside the little schematic box for the shift register. But if that’s what I’m supposed to be doing I will draw up the component in KiCad.

[Ian.M]

No.  That's TOO MUCH detail.  See the ANSI logic symbol on page 1 of the datasheet (though personally I detest ANSI logic symbols when working at gate level - you loose so much 'at a glance' comprehension because everything is a *~*~ing rectangle).

However for ease of drawing I'd use a plain rectangle with pins named according to the datasheet INSIDE it, and  grouped by function.  Put the eight load outputs evenly spaced at the top (as they are open drain^*), data in left edge center, data out right edge center, and control inputs bottom edge on the left.  Where to put the power connections is arguable: I'd use left edge near the top for Vcc and the right edge near the bottom for Gnd.

Use the usual convention of a small circle on the outside of the symbol at all inverting inputs (and inverting outputs), and a small triangle (pointing inwards, base on the edge) to indicate edge triggered strobes or clocks.  On its own, that indicates rising edge triggered.  With an external circle for inversion, its falling edge triggered.   

If you want to wire from the schematic, bracket the physical pin number at the end of the pin name, separated by a space.

You should also look at page 5 of the Philips 74HC595 datasheet for inspiration, (especially fig.5 for how to indicate internal function if you need to), though it doesn't use inversion circles and edge trigger triangles consistently.

* The usual convention is the 'flow' is down and right.  That doesn't mix well with  component level schematics with the +V rail at the top and Gno or -V rail at the bottom.  As the TPIC6C595 outputs are open drain, it makes for a neater schematic if they are belw the loads they are driving.

[ilium007]

No.  That's TOO MUCH detail.  See the ANSI logic symbol on page 1 of the datasheet (though personally I detest ANSI logic symbols when working at gate level - you loose so much 'at a glance' comprehension because everything is a *~*~ing rectangle).

However for ease of drawing I'd use a plain rectangle with pins named according to the datasheet INSIDE it, and  grouped by function.  Put the eight load outputs evenly spaced at the top (as they are open drain^*), data in left edge center, data out right edge center, and control inputs bottom edge on the left.  Where to put the power connections is arguable: I'd use left edge near the top for Vcc and the right edge near the bottom for Gnd.

Use the usual convention of a small circle on the outside of the symbol at all inverting inputs (and inverting outputs), and a small triangle (pointing inwards, base on the edge) to indicate edge triggered strobes or clocks.  On its own, that indicates rising edge triggered.  With an external circle for inversion, its falling edge triggered.   

If you want to wire from the schematic, bracket the physical pin number at the end of the pin name, separated by a space.

You should also look at page 5 of the Philips 74HC595 datasheet for inspiration, (especially fig.5 for how to indicate internal function if you need to), though it doesn't use inversion circles and edge trigger triangles consistently.

* The usual convention is the 'flow' is down and right.  That doesn't mix well with  component level schematics with the +V rail at the top and Gno or -V rail at the bottom.  As the TPIC6C595 outputs are open drain, it makes for a neater schematic if they are belw the loads they are driving.

Ok thanks - I will take a look at it all.

What about my messy circuit design, does each board reflect what we have spoken about in this thread ? Will the input board with the LATCH and SS pins overcome the timing issue (I still don't fully understand the requirement for the strobing mentioned earlier in the thread) ?

I found this page past night that explains, I think, the RC circuit to supply the pulse to the parallel load pin on the shift register. I can avoid having to implement this if I consume an additional pin from the MCU to do the parallel load can't I ? Although I do like the simplicity of the RC derived pulse, I just don't know how to calculate the time decay and how the tolerances of the components affect the timing.



http://www.openmusiclabs.com/learning/digital/input-matrix-scanning/hacks/

[Ian.M]

I'd have to pick through the logic in detail to comment on it properly.  At the moment I'd have to print them out and go through it with a pencil and the datasheets open to check - If you redraw the symbols by function rather than physical pinout, one can usually trace he signals without reference to the datasheet, unless the pin names are particularly cryptic, or you have no idea of that chip's function .

One thing to note - I wouldn't use 74HCT logic for anything except the first level-shifting buffer as it has much worse noise immunity than 74HC logic @5V Vcc and logic levels.

[ilium007]

I'd have to pick through the logic in detail to comment on it properly.  At the moment I'd have to print them out and go through it with a pencil and the datasheets open to check - If you redraw the symbols by function rather than physical pinout, one can usually trace he signals without reference to the datasheet, unless the pin names are particularly cryptic, or you have no idea of that chip's function .

One thing to note - I wouldn't use 74HCT logic for anything except the first level-shifting buffer as it has much worse noise immunity than 74HC logic @5V Vcc and logic levels.

OK - I'm redrawing it all now.

[ilium007]

Put the eight load outputs evenly spaced at the top (as they are open drain^*), data in left edge center, data out right edge center, and control inputs bottom edge on the left.  Where to put the power connections is arguable: I'd use left edge near the top for Vcc and the right edge near the bottom for Gnd.

Use the usual convention of a small circle on the outside of the symbol at all inverting inputs (and inverting outputs), and a small triangle (pointing inwards, base on the edge) to indicate edge triggered strobes or clocks.  On its own, that indicates rising edge triggered.  With an external circle for inversion, its falling edge triggered.

Is this acceptable ?

[Ian.M]

Yes. that's a lot easier to follow.   I'd move the name to the middle and add some descriptive text:

TPIC6C595
Open Drain Power SIPO

One may have to look up the pin names, so if you really want to make your schematics self-explanatory, for non-standard symbols, include the pin function tables from the datasheets *somewhere*on the schematic, maybe on an extra page, each with the symbol you have drawn for it.

That parallel load circuit from openmusiclabs.com looks very hacky.  Here's what I was proposing, using 3/4 of a 74HC132.

[ilium007]

I think I get it now ! Would you implement the three extra components vs using one extra digital I/O on the MCU ? Thats assuming my diagram that uses a seperate SS and SH/LD input would even work.

[Ian.M]

The strobe generator circuit leaves you with a clean SPI interface at the cost of three parts and a little board area.  If you are trying to squeeze costs, only populate it on the input board nearest the MCU.   On the other boards a PCB jumper (cut on the first board) would select the pass-through strobe from the first board, and you would not populate the three parts. 

The alternative of a MCU pin to drive the strobe costs you an extra gate on the level shifting buffers and an extra pin on the SPI  expansion board connector.

It all depends on how tight you are for MCU pins and whether or not you want the MCU board's expansion board connectors to be fully interchangeable, and whether you are happy for the first board in each SPI peripheral chain to be special.

Both options need support in the code.  The circuit needs a delay between /SS going low and the start of the SPI transfer to be, say 2us for safety or longer if you increase the time constant.   The MCU pin needs you to pulsed low for a suitable time, returning high before /SS is taken low.

N.B. *DON'T* use non-Schmitt gates with RC delays - you can get some *very* nasty glitches on the output if it doesn't get through the transition region quickly enough.  If you need long(ish) delays, the circuit above can be excessively vulnerable to noise so use a proper monostable chip e.g 74HC221 Dual Monostable (non-retriggerable).

[ilium007]

I've just grabbed a 74HC132 to do some testing with. I like the idea of making a 'standard' SPI interface so that the board connectors can be used with 'standard' SPI header connections. I'd rather all boards be identical so will just populate the parts on each board.

[ilium007]

This mess is a working input shift register board prototype. In there I’ve got 2 x 74HC125 (all I had and this is 5v) emulating the buffer on the MCU board and a buffer on the input board, the 74HC132 / RC circuit doing the SS -> SH/LD trickery and 2 x 74HC165’s cascaded for 16bits of input. I have verified in a serial console that the button presses are detected and sent out on the MISO line.



I just need to work out where the pull-ups / pull downs need to go - I’m not sure if they go on the MCU board SPI output headers or on the output headers on each expansion board (assuming the latter).

Thanks for all your help so far ! I think I’m ready to start designing boards !

[Ian.M]

Only the MCU board level shifting buffers can tristate so only their outputs need pullups or pulldowns.   The only expansion board pin you have to worry about is Data_In on the input board as you need to jumper it to ground on the far end board of the chain.  Make sure its next to a ground pin on the inter-board connector so that's easy to do.

[ilium007]

Only the MCU board level shifting buffers can tristate so only their outputs need pullups or pulldowns.   The only expansion board pin you have to worry about is Data_In on the input board as you need to jumper it to ground on the far end board of the chain.  Make sure its next to a ground pin on the inter-board connector so that's easy to do.

I'm assuming thats the MOSI pin on the input board chain ? Why does the cascaded MOSI need to go to GND ?

[Ian.M]

Because otherwise the far end  board's Data_In is flapping in the breeze, and floating CMOS inputs are a *BAD* *THING*.    The input boards don't use MOSI at all and you may not even connect that pin unless you decide to wire it straight through so you can mix input and output boards in the same daisychain, e.g. to scan a key matrix, (although if you do that in a long chain, beware of timing skew between MISO or MOSI and SCLK).

Have you considered what input protection circuit to use for the input board's parallel input pins?   While 'raw' CMOS logic level inputs can be appropriate in the control panel they would be very risky on the layout.  You'll probably want 12V inout levels for the layout.

[ilium007]

Because otherwise the far end  board's Data_In is flapping in the breeze, and floating CMOS inputs are a *BAD* *THING*.    The input boards don't use MOSI at all and you may not even connect that pin unless you decide to wire it straight through so you can mix input and output boards in the same daisychain (although if you do that in a long chain, beware of timing skew between MISO or MOSI and SCLK).

The 'far end' board is the last one in the chain ? Furthest from the MCU ? It will be the only one with its 74HC165 pin 10 "SER" disconnected and should have  it tied to GND.

I have drawn a quick and nasty schematic (using my freshly created 74HC165 drawn to Ian.H standards ) showing two boards with an inter-connect - disregard everything else thats missing from it, I have drawn it just for this discussion. Picture each 74HC165 in the diagram as being 2 or more 74HC165's. The far right board is the last one in the chain (inter-connect are the blue lines), is this 'MISO' inter-connect pin the one being tied to GND to ensure the last 74HC165 pin 10 "SER" is tied to ground ?

[ilium007]

Have you considered what input protection circuit to use for the input board's parallel input pins?

This morning I learnt about Quadruple Positive-NAND Gates With Schmitt-Trigger Input IC's for the first time.... 

I have not thought about input protection circuits

I am not sure what the risks are...

[ilium007]

One other thing I hadn't really considered was power. I could feed in 5v via the SPI connector and this would power the boards, shift registers, buffers and status LED's, but it would also have to cater for the current sink for all of the outputs.

I am thinking about creating 16 outputs per board:
  - worst case scenario driving 16 relays at 35mA coil current each
    - 16 x 0.035A = 560mA + power consumption of the on-board IC's, status LED's etc - approx 200mA
      - 750mA per board approx.
  - I want to design for 128 outputs per chain
    - 8 x output boards
      - 6.0A total for the chain of boards.

I see a couple of options.

Option 1: I need a 12v feed to each board to drive the relay coils so I could put a cheap linear regulator and a couple of capacitors on each board to give 5v. I'm not sure how much heat will be generated by a linear regulator dropping 12v to 5v and sinking the 750mA per board. I would use Molex 77 254 connectors as the inter-connect current would be well under their rated 4.0A

Option 2: Use the larger Molex KK 356 connectors which allow 7.0A - this would provide all 5v power all the way along the cascaded chain of boards. Each board would then have a seperate 12v feed for the relay coils and I would use a high capacity switch mode power supply on the main MCU board to provide 5v / 3.3v power for everything. But 7.0A through tracks on the output of a 1oz copper PCB.... I'm not sure about that !

I think Option 2 is the better option. Thoughts ?

[Ian.M]

Way up thread I suggested 1/4" PCB mount spade terminals for the high current power and ground wiring.  Also I suggested crimping up a 'backbone' wire for  each that loops fromone female crimp connector to the next as that will be a quick and easy method of high current power and ground distribution along the chain, that avoids high currents on any individual PCB. 


A TPIC6C595 has a worst case current consumption from its logic supply of 5mA when being clocked at 5MHz.  Below 1MHz it will be sub 1mA, and the logic ICs will be similar or lower, so there are no issues with running logic power over the same cheap small headers as the SPI signals.   If you are concerned about the total current for LED indicators (even using high efficiency LEDs, which can be acceptably bright at under a mA), you can always specify extra power and ground pins.  More ground pins also helps with signal integrity.

[ilium007]

Way up thread I suggested 1/4" PCB mount spade terminals for the high current power and ground wiring.  Also I suggested crimping up a 'backbone' wire for  each that loops from one female crimp connector to the next as that will be a quick and easy method of high current power and ground distribution along the chain, that avoids high currents on any individual PCB. 
A TPIC6C595 has a worst case current consumption from its logic supply of 5mA when being clocked at 5MHz.  Below 1MHz it will be sub 1mA, and the logic ICs will be similar or lower, so there are no issues with running logic power over the same cheap small headers as the SPI signals.   If you are concerned about the total current for LED indicators (even using high efficiency LEDs, which can be acceptably bright at under a mA), you can always specify extra power and ground pins.  More ground pins also helps with signal integrity.

Sorry - I've read through this thread so many times today, I don't know how I missed that.

If the TPIC6C595 IC's are getting their Vcc and GND via the small headers / interconnects how do they sink current via the heavier spade connector 'backbone'

[TomS_]

If the TPIC6C595 IC's are getting their Vcc and GND via the small headers / interconnects how do they sink current via the heavier spade connector 'backbone'

Place one terminal in your positive power plane and the other in the ground plane. You can then feed power to the board by either or both.

[ilium007]

If the TPIC6C595 IC's are getting their Vcc and GND via the small headers / interconnects how do they sink current via the heavier spade connector 'backbone'

Place one terminal in your positive power plane and the other in the ground plane. You can then feed power to the board by either or both.

Ok - and all grounds are tied together off each supply ? 5v, 3,3v and 12v

[Ian.M]

Yes, all grounds tied together.   5V logic power isn't on a spade - it doesn't need to be as worst case you have about 5mA for chips and maybe  16mA (8x 2mA) for high efficiency indicator LEDs per board, so for a 12 board chain that's still only about 0.25A. (assuming 8 channels per board - count multi-shift register boards as if they were as many individual boards)

Put the 5V regulator on the MCU board and feed it 12V and Ground using spade connectors.  You'll probably want to use a switching regulator as with multiple chains, the logic 5V current can be quite substantial.  The alternative is a L78S05 2A rated linear regulator and a heatsink big enough to handle 15W dissipation without excessive temperature rise.    Another option that avoids the switching regulator or big heatsink would be to only distribute 12V and put a 5V 100mA 78L05 or similar on each board.  I'd still use the spades for 12V even for input boards as each could need up to 100mA of wetting current (see below). 

You'll have to decide what current polyfuse to put on output boards - do you fuse the channels individually to attempt to protect the TPIC6C595 (as the Abs Max peak output current  is 250mA this is unlikely to work), or do you simply fuse the 12V to the board at 1A so worst case it only takes out the chip (which you may decide to socket) and doesn't melt the wiring?

Have you considered what input protection circuit to use for the input board's parallel input pins?

This morning I learnt about Quadruple Positive-NAND Gates With Schmitt-Trigger Input IC's for the first time.... 

I have not thought about input protection circuits

I am not sure what the risks are...

For the inputs, if you get it wrong you blow the shift register chip, and possibly other chips connected to it.   If you get it less wrong, EMI pickup gives you false input readings.

If its coming from the layout, I suggest you use 12V signalling.  ON is >9V, OFF is <3V.  A potential divider 15K lower arm, 22K upper arm will do that nicely with no issues up to a maximum voltage of 13V.   Above that, unless you clamp it the CMOS input protection diodes will start to pass current (undesirable) so you should also have a 5% 5.1V Zener, anode to ground  across the lower resistor, and a 1K resistor between the divider tap and the actual CMOS input.  With 1/4W resistors, that will survive up to +/- 70V with no issues and if you apply AC mains, as long as the ground connection is low impedance, there is a good chance that only the 22K resistor will blow.  For EMI filtering a 1nF to ground at the CMOS input pin is advisable.

Then you get into stuff like switch wetting current.  Unless a switch or relay has sealed, mercury wetted or gold plated contacts, it will probably be unreliable unless you have enough voltage across it when open and pass enough current through it when closed to break down any oxides or other slight contamination as it closes.  A rough rule of thumb is minimum 10V, 10mA.   

Therefore you will need the option to fit a 1K pullup to +12V or pulldown to ground, to supply the wetting current, at the input so there is a low impedance at the input to reduce the effect of EMI.   Use a through hole resistor and don't mount it dead flat on the board as a 1/4W 1K resistor will burn with as little as 16V across it. Glass or ceramic beads on the legs make good standoffs to get the clearance.  If you want it easily configurable, use a three pin jumper to select between 12V, Gnd (and open) on one end of the resistor, with the other to the input terminal.   If you are going to use screw terminal blocks, its probably easier to simply insert the resistor in the terminal block with the switch wiring. All switch wiring should be twisted pair, with one wire to each side of the switch.   Fit a 500mA polyfuse in the 12V feed (for switch pullups)  on each input board to protect against wiring disasters and decouple the 12V pullup rail with a 10uF 25V cap. 

[ilium007]

Thanks for this ^^^^^^^

I will look at power tomorrow. I am learning so much through this project, thank you again for all your help.

[C]

A while back lam.M & I both talked about drawings wasting time.
Little things can make a big difference and it takes time to learn them.
Not trying to pick on you, but just show very small detail as example.

I know what a 165 is an how it works, so knowing this look at this and do you see what you expect?


First quick look and no serial input connection, took a while to find it.
Other things here also delayed the find.

You have a very simple drawing but have a lot of separate detail areas to work with.

Power & Ground    Put next to each other and leave a gap between other details

SPI  here you have 3 or 4 signals, again a detail

You have SPI In & SPI out. Again a detail but here Knowing that Serial in goes to first 165 and daisy chains was lost. It does not stand out so it's easy to see.

Your eye can easily follow group of lines. You need differences to stand out.
Here you have a chip that is drawn for Left to right flow. If the whole drawing was left to right flow then it would be easer to understand, BUT some time you will have a need for a drawing like this. For example a drawing that had 167 & 595 chips.
So what can/could you do?
Simple things, move your 5 horizontal lines down so top line is where your SS line is now. 
Move Power and ground to be next to each other. Keep in mind that you will have a 3rd power wire per chip and need to make it stand out a little from the two shown

Change the gap between power and SPI signals.
make the direction of MISO and MOSI really stand out in the pattern by when they go vertical. MISO going vertical to the right  before the chip is a good hint here. A gap in the MISO bus under the 165 is a hint. so bring pin 9 connection down to left of 165. Here you need a cross like you have of 9 & 10, put it closer to chip and further from bus. make cross stand out.

A little thing like moving pin 8 vertical closer to chip makes a difference.

Your 132 does not follow the left to right. In on left side of box, out on right side of box and then up to pin 1.

--
Now you are working detail on power and connections. More detail that needs to stand out when you take a quick look that that drawing to find something.

-----
Lets see if I can help some with delays.
Some times you get berried in the details  You need to keep looking at big picture 

If you can get in mind the big picture & the small picture you have a better chance.

A while back a news item stated a " minor accident on LA's freeway would have traffic backed up and slowed for 9 hours," & "you could walk faster"
People walking have this problem if there are a lot of people in a line.
What is missing is the Sync signal to get all to start move at same time

One often missed thing.
You are talking via sat to some one. Your baud rate is X but it takes time to get to sat and back down. For easy numbers say 1 sec.
From this example you have X times 2 bits stored in AIR.
Storing bits on a wire was done a long time ago. Search Delay Line if you care.

Now jump to electronics
You have a bunch of inverters connected in series. From data sheet you see time to change. 
Again using simple numbers, change takes 10.  So with 100 inverters in series you change input to ONE and get ONE out of last 1000 later.
You can still change input faster then this total delay, you just have to stay in the limits of a inverter.
Now Your input changes fast, Inverter output might change faster or slower on output.  After 1000 inverters your nice fast square wave could look line a sign wave.

A while back, lan.M talked about Schmitt input on logic.
If the above inverters have Schmitt inputs, each would be doing it's little part in making that logic change faster. The sign wave output happens at a higher frequency.

Now replace the inverters with a non inverting buffer. You still have the delay!

If you draw the clock signal (the inverter input or buffer) on paper and then make a copy on a transparency.
Each inverter/buffer shifts the transparency by some amount. 
You could number the changes see that current input is x newer then output

Now the 165 has a delay!
To hide the delay the clk input shouts out STEP NOW to all the bits in shift register.  As you add more clk inputs to 165's the shout gets smaller.
One way to make shout work better is to do it when peak should happen on data input.

First you have when a bit happens on output. Think of your first output chip replaced with a 165. You would have to shift out bits for all output chips before getting to 165 bits.
You would not do this as to update outputs you would also have to send 8 more bits after the output bits to get output bits in proper position.
If you put 165 as last chip then you send 8 output bits & get 8 input bits.
Until you have matching number of input & output bits you have to send or receive extra bits.

If you have nothing but TPIC6C595's & 165's in chain and NO buffers, you are good.
The design of chips have all shift registers stepping at same time.
But ( always a but ) your input signal times must be good.

If you add buffers in series you have to think about delays as shown in Inverters in series above.
Now what could you do?
With a big loop where you have buffer delays going out and the all the way back, you have a problem. The cure is easy if you use clock out to sample the input bits.
A SPI Master only has a send clock and not a send clock and receive clock.
A SPI Slave only has a receive clock.
If you had to have the big loop with buffers you could send with the SPI Master and receive with the SPI Slave.  The master generates the clock that the slave uses after delay. 

You are splitting the OUT from the IN. A simple step that removes OUT delay from picture. The timing at the SPI Master will be good, but you have to allow for the buffer delays working back.
Think of many transparencies stacked. The nice thing is that a slower clock rate removes the transparencies.
Think of a computer reading memory. Data needs to be at computer to read. A miss of 10ns gives computer garbage. Speeding up memory or slowing computer by 15ns  gives a 5ns safety margin and working computer.

Now to lan.M
In is posts to this thread in answering your questions and making suggestions are a LOT of important details.
I would suggest reading this thread many times and ask your self "why did he say that"

I really like this one

Then you get into stuff like switch wetting current.  As a rule of thumb, unless a switch or relay has sealed, mercury wetted or gold plated contacts, it will be unreliable unless you have enough voltage across it when open and pass enough current through it to break down any oxides or other slight contamination.  A rough rule of thumb is minimum 10V, 10mA.

Happened to me in the 70's, system used real high dollar low current switches that were suppose to last 100 thousand to 1 million switch cycles. Every thing known at time to make switch last longer.
In an effort to protect the switches, designer lowered the current to far to lower limit. New switches worked but got faulty 10,000 to 20,000 cycles later, One resistor of wrong value. Think it was 10 cent resistor vs $15 switch. If you are repair man, bad switch replace switch.
Try telling management  " if you harm switch more by switching higher current it will last longer".

If its coming from the layout, I suggest you use 12V signalling.  ON is >9V, OFF is <3V.  A potential divider 15K lower arm, 22K upper arm will do that nicely with no issues up to a maximum voltage of 13V.

A different way to do this is use RS232 chips like
MC1488N SN75188N MC1489N SN75189N
but you then need a negative supply

---------
Now think ahead a bit
so far you have standard SPI interface.
The Teensy 3.2, 3.5 & 3.6 all have a CAN Bus interface.
CAN Bus is a nice way to connect many CPU's together.
You could have many Teensy in system connected via CAN bus.
You could use one to control track and then add two more with each controlling one operator interface.
Now problem with this is high cost of Teensy
SPI & CAN Bus interface can be found on many chips.
Even the ESP32 has SPI & CAN Bus & Arduino

So what I am suggesting is not to get locked into idea that one has to do it all.
Easy to make many copies of a board.
Easy to make many copies of software.
Not hard to have many input or output chains of the boards here.
Not hard to leave off parts mounted to boards
Some times not hard to use different parts on a board to get a little different function.

[C]

I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

Might want to look at
First Look: APA102 RGB Pixel Addressable LED #1


Think of a color led string connected to SPI
Does not solve problem where you need small leds

[ilium007]

I am going to work through the reply's one by one and over some time as I am researching all the valuable points made by each contributor.

For the inputs, if you get it wrong you blow the shift register chip, and possibly other chips connected to it.   If you get it less wrong, EMI pickup gives you false input readings.

If its coming from the layout, I suggest you use 12V signalling.  ON is >9V, OFF is <3V.  A potential divider 15K lower arm, 22K upper arm will do that nicely with no issues up to a maximum voltage of 13V.   Above that, unless you clamp it the CMOS input protection diodes will start to pass current (undesirable) so you should also have a 5% 5.1V Zener, anode to ground  across the lower resistor, and a 1K resistor between the divider tap and the actual CMOS input.  With 1/4W resistors, that will survive up to +/- 70V with no issues and if you apply AC mains, as long as the ground connection is low impedance, there is a good chance that only the 22K resistor will blow.  For EMI filtering a 1nF to ground at the CMOS input pin is advisable.

Disclaimer: The schematics below are just showing a single  74HC165 input - I know they are incomplete

The inputs are quite simple, push button switches on a control panel (not sure what was meant by 'coming from the layout') and a few IR detection circuits running 5v logic. I had initially assumed I would just use a 5v logic to provide a LOW (10k pulldown to GND) and HIGH signals to the 74HC165's as below.



What is the benefit of 12v signalling vs 5v ?

What are we designing protection against ? Is it breakdown of a power supply that puts AC on the low voltage DC circuit ?

From the quote above I have drawn this partial schematic:



On to wetting current on relays. I am not sure if my approach to this track switching is going to work (I haven't prototyped it yet as I don't have relays). I am using an off the shelf Pololu MC33926 Motor Driver Carrier, https://www.pololu.com/product/1212, to drive the track PWM.



I will have three of these for three seperate tracks that can be driven at one time. There are a number of sections of track that need to have the PWM signal from one of these H-Bridge PWM motor drivers switched on or off. This is what I was going to use the relays for. I couldn't use an N-Channel / P-Channel MOSFET as the polarity changes on the PWM signal depending on direction selected by the user. I couldn't think of any other way to control the PWM signal to different sections of track.

A basic schematic of the relay switching:



I have thought about the use of pull-up / pulldown resistors for contact wetting but don't know how this will work given the polarity of the PWM signal changes based on motor direction selected.

Will a relay work for the PWM output from the motor driver to the tracks and if so should I just purchase gold plated relays. I only need 8 of them.

I should also mention that at present I am using a 12V 47A / 5v 7.0A HP server power supply in case that information is helpful for the AC protection discussion.

[Ian.M]

Edit: Thanks ilium007, for switching to attached images.  Preserved for posterity:
First, for images less than the attachment size limits, its best to host them here as attachments.   Otherwise anyone who wants to download or view the full sized image without the forum resizing it to fit the page has to wrestle with the external image hoisting site. Also image hosting sites frequently change their usage T&Cs or delete old images, so externally hosted images frequently vanish a few months or years later, damaging the content of old topics, and making them far less useful. 

If you need to post an image inline to refer to it, attach it, post the post, then go back and edit the post IN A NEW TAB, so you can easily copy the link URLs of the non-expanded attachment thumbnails from the original tab, for inclusion in the IMG tags in your post.  I normally pre-insert broken image tags:

[img]/img]

as placeholders so all I have to do is paste the URL between the ] and the / then hit [  and save the changes.  Please don't inline large filesize images as it chews through Dave's hosting bandwidth and the user's download bandwidth every time someone opens that page of the topic.  Them as wants to see them can simply click the attachment.

Partial schematics are fine.   When you draw the final one, for repeated stuff like inputs and relay circuits you can simply draw one channel in a block and indicate its repeated N times. The points each instance connects to should be named with a name that includes the instance number so you can see which connections 'belong' together.

Your first schematic is OK if the switches are on the same board as the CMOS chip and they have gold or carbon loaded elastomer contacts.   If they have silver or other metal contacts, decrease R6 to 1K t get at least a few mA wetting current.  If they are on a front panel, a 10K resistor between the board input (and the top end of R6) and the CMOS input fpr at least minimal protection against transients and over-voltage.  N.B. the extra 10K series resistor is *NOT* compatible with bipolar TTL inputs.

For the second circuit, if it isn't a Gold, mercury wetted or carbon loaded elastomer contact switch, you need that 1K resistor from the left end of R5 to ground to provide the wetting current.  I'd also recommend a 1nF cap from the bottom of R7 to ground for EMI filtering.  That gives you a low pass filter with a 3dB corner frequency of 16KHz which should be enough to keep radio signals out of your inputs.  If you are experiencing severe EMI issues, you could increase the capacitor to 10nF without any issues.   With those mods, its designed to protect against the high impulse voltages that are commonly found around your layout. e.g. if there is a loose  connection somewhere a simple points solenoid or train motor could easily put a short spike or inductive 'kick' of several hundred volts on the 12V supply the switch is connected to, and the normal operation of your layout could easily induce spikes of tens of volts amplitude in your switch wiring.

Now lets consider schematic three.   The relays are switching motor power, not low current control signals.  They do not need and should not have gold plated contacts as the plating wont stand up to high current arcing during opening or closing.  Solid Silver alloy contacts would probably be the most durable, though appropriately rated base metal contacts would come close.   As they are switching significant current and voltage, they don't need any resistors for extra wetting current though RC snubbers (which need to be calculated for the expected load current) or 20V bidirectional TVS diodes across each contact pair would probably be advisable to reduce arcing and prolong the relay contact life.

It's probably worth putting a rightangle header on the Polulu motor driver board and a mating rightangle connector at the edge of your MCU board so they can plug directly together to minimise wiring.  The driver output to the relays and the track wiring should use twisted pair of adequate gauge for the maximum current to minimise EMI so the motor PWM doesn't get into everything else.   I would suggest using socketed  relays mounted off-board - they'll be easier to wire and if one goes bad it will be cheap and easy to replace.   If you turn off the motor drive PWM before switching the relays you can get away with 5A ones.

Edit: you missed the third image (relays).  I still had it cached so here it is.

[ilium007]

OK thanks - I'll fix up the image links.

Looking at the other points made as well. I put all the relays on the big schematic I'm working on so that they all come across in the netlist in KiCAD PCB editor. I'm not sure what would happen if I were to only draw one of them.

Looking at the 74HC165 datasheet it says (I think) that max "High-level input voltage" VIH is 6.0v. The voltage divider on 12V would supply 7.135V wouldn't this exceed the 6.0V VIH of the 74HC165 ?



The pushbutton switches will connect to a front panel away from the input board. I think I will implement the voltage divider pending confirmation my 7.135V calculation is correct and that it will not damage the 74HC165 inputs:

[Ian.M]

I'm not a Kicad user, but it looks like you need to use hierarchical sheets to hold the block that you want to repeat.  See http://uhaweb.hartford.edu/kmhill/suppnotes/KiCadDia/KiCadHierarchy01/KiCadHierarchy01.pdf.  If you get stuck with that you should probably start a new topic in the EEVblog EDA subforum.

The abs max input voltage may be 6V, but for CMOS, to avoid malfunctions,you should design to the range Gnd-0.3V to Vcc+0.3V.

However 22K upper, 15K lower divides the input voltage by (22+15)/15 = 2.47, so at 12V in it will only give the CMOS input 4.86V.  Any spikes exceeding +13V or below -0.7V will be handled by the 5.1V Zener keeping the CMOS input within its safe limits. (The -0.7V undershoot, and any rise above 5.7V due to large +ve spikes is permissible as the 1K resistor between the Zener and the input limits the internal input protection diode current to a small fraction of a mA.)

By interpolation, the minimum voltage V_IH to guarantee a logic '1' @Vcc=5V is 3.5V.  Multiplying that by 2.47 gives 8.65V so unless you are dropping over 3V in your wiring it will read the input correctly.     

[ilium007]

The abs max input voltage may be 6V, but for CMOS, to avoid malfunctions,you should design to the range Gnd-0.3V to Vcc+0.3V.

However 22K upper, 15K lower divides the input voltage by (22+15)/15 = 2.47, so at 12V in it will only give the CMOS input 4.86V.  Any spikes exceeding +13V or below -0.7V will be handled by the 5.1V Zener keeping the CMOS input within its safe limits. (The -0.7V undershoot, and any rise above 5.7V due to large +ve spikes is permissible as the 1K resistor between the Zener and the input limits the internal input protection diode current to a small fraction of a mA.)

By interpolation, the minimum voltage V_IH to guarantee a logic '1' @Vcc=5V is 3.5V.  Multiplying that by 2.47 gives 8.65V so unless you are dropping over 3V in your wiring it will read the input correctly.   

Ahh - I did my voltage divider calc incorrectly.

[ilium007]

The -0.7V undershoot, and any rise above 5.7V due to large +ve spikes is permissible as the 1K resistor between the Zener and the input limits the internal input protection diode current to a small fraction of a mA

I moved the 1k to the left of R5 to provide the wetting current, should I have had another 1k between the zener and the 74HC165 pin 11 input ?

[Ian.M]

That's looking good apart from C8.  Connecting a cap between ground and ground is    *STUPID* - move it to between pin 11 of the IC and ground where its meant to be.

Also, as a matter of style, please move the SER data in pin to the center of the left edge of the 74HC165 symbol.  Then they will daisy-chain more clearly with the MCU board at the right hand end.   That means the SPI control signals are breaking convention and going right to left, but its preferable to having the data flow backwards.  Adding a note '<== SPI clock & control <==' immediately below the grouped control lines would then prevent confusion.

Its a pity the parallel input names don't include the bit number.  I suggest annotating the symbol at the two end inputs with 'b0' and 'b7'   SPI is transmitted MSB first, so get it the right way round!

[ilium007]

Thanks !! I did question myself when I put that cap there. *facepalm*.

I’ll fix up the component as suggested. All I need to do now is find some appropriate poly fuses and get them on the diagram.

[ilium007]

It may or may not be of interest but here is Dads train layout and some of the very detailed Queensland Rail locos I am building this for !

[C]

Motor driver control of track blocks
You have a computer so you could get real fancy if you can create correct code.

You could control inputs of motor controller using logic.
Using relays to control outputs

You can find some relay boards that have single pole double throw relays SPDT
Using these you could stop the train but un switched track side would still be swinging.

Using DPDT you can switch both sides of track.
one relay connected to track gives choice of A or B
Two relays choice of A or B or C
Three relays a choice of A or B or C or D
This last would give off or one of three motor controllers.

Now you could put a motor controller in place of Track in above example.

Think of a checker board
Horizontal rows are track blocks.
Vertical rows (columns) are motor controller
Using the relays you can increase the rows.
The checker on the board is a  full time connection.

Now think about input to motor controller
You can switch inputs using software or logic or both.
You could have a second checker board to select inputs to motor controller.

You could hide from operator that you changed what motor controller is controlling a
train.
Keep in mind that a relay takes time to change, so an A to B change becomes A, off, B with off being a short time.
To swap controllers hidden you would also need to match settings to controller. With logic this could be very fast.

Using solid state relays the off time between A & B gets real small and you can change often.

With a motor controller per block you have best control and probably highest cost when not having motor control in engine.

Now to make the puzzle even more fun or a larger pain you could have one track block connect to another track block with a relay.

Now if one engine by going down the track changes from one motor controller to another, the inputs to the two motor controllers should have outputs the same. A meter would read 0 volts across the gap in a track.

This might help some

[Ian.M]

OK, now I know what's planned in more detail, I'm not convinced that relay switching is the way forward.   Lets suppose you have one controller and eight track segments. For each motor controller you need four relays in a tree to switch it to eight track segments :  DPDT - 4PDT - 2x 4PDT.   Three of those relays are the more expensive 4PDT type.  You also need 1/5 of a dual TPIC6C595 board so that's a few more bucks.      Its absolutely pointless to have the relays unless you have at least one more controller, so the minimum investment for eight track segments is eight relays + driver, and two controllers

Polulu do a dual version of that motor controller board: #1213 Dual MC33926 Motor Driver Carrier at $29.95, which compared to the single version #1212, saves you $3 per driver.

It may be worth biting the bullet and investing in one controller per track segment and getting rid of the controller to track segment switching relays.

There is however one MAJOR fly in the ointment.  Because of their internal current limit PWM and deadtime control, you cannot parallel active MC33926  H-bridges.   There is a high risk of shoot-through resulting in a repetitive brief uncontrolled short between the power rail and ground, leading to overheating and possible destruction of the H-bridges.
You can however parallel an active MC33926 with an inactive one that has its outputs tristated.   This means that to get a smooth handoff between adjacent track segments, you need a DPST bridging relay at each inter-segment gap, equipped with a current sensor so your MCU can detect when the loco crosses the gap^*.   Once the loco has crossed the gap, the MCU can, between PWM pulses, tristate the previous segment's H-bridge, and enable the new segments one, without missing a beat, then open the bridging relay.  It should then immediately prepare the next segment by tristating its H-bridge, and closing the bridging relay at the next gap.

If you switch to another H-bridge controller chip that does permit paralleling, you can do away with the bridging relays.  Simply drive adjacent segments H-bridges with *EXACTLY* the same signal until you are certain the loco has fully crossed the gap.   If the MCU yu are using has sufficient PWMs that can run off exactly the same timebase, this can be done purely in software, otherwise you may need switching logic.  Probably the easiest option there would be an analog switch matrix to switch N PWMs to M track segments.  You can get the Microsemi MT8816 8:16 crosspoint switch array for as little as $10.  It isn't SPI compatible, unless you add an external shift register and a little glue logic, but that isn't a show-stopper.   That would let you switch eight control PWMs to 16 track segments.  Each switch in the matrix is individually addressable so to switch PWMs to a singe output without conflicts requires two operations - one to turn the previous PWM off, and one to turn the new one on.   Expanding to 8:32 would be as simple as adding another MT8816.  It will switch 5V logic signals while running from 5V so no exotic supply voltages are required.

After all that, do take a step back and consider that its probably cheaper to go full digital with DCC control and fit a commercial DCC decoder to each loco.  You can roll your own command stations and booster boards to drive the track.

[ilium007]

OK, now I know what's planned in more detail, I'm not convinced that relay switching is the way forward.   Lets suppose you have one controller and eight track segments. For each motor controller you need four relays in a tree to switch it to eight track segments :  DPDT - 4PDT - 2x 4PDT.   Three of those relays are the more expensive 4PDT type.  You also need 1/5 of a dual TPIC6C595 board so that's a few more bucks.      Its absolutely pointless to have the relays unless you have at least one more controller, so the minimum investment for eight track segments is eight relays + driver, and two controllers

Polulu do a dual version of that motor controller board: #1213 Dual MC33926 Motor Driver Carrier at $29.95, which compared to the single version #1212, saves you $3 per driver.

It may be worth biting the bullet and investing in one controller per track segment and getting rid of the controller to track segment switching relays.

There is however one MAJOR fly in the ointment.  Because of their internal current limit PWM and deadtime control, you cannot parallel active MC33926  H-bridges.   There is a high risk of shoot-through resulting in a repetitive brief uncontrolled short between the power rail and ground, leading to overheating and possible destruction of the H-bridges.
You can however parallel an active MC33926 with an inactive one that has its outputs tristated.   This means that to get a smooth handoff between adjacent track segments, you need a DPST bridging relay at each inter-segment gap, equipped with a current sensor so your MCU can detect when the loco crosses the gap^*.   Once the loco has crossed the gap, the MCU can, between PWM pulses, tristate the previous segment's H-bridge, and enable the new segments one, without missing a beat, then open the bridging relay.  It should then immediately prepare the next segment by tristating its H-bridge, and closing the bridging relay at the next gap.

If you switch to another H-bridge controller chip that does permit paralleling, you can do away with the bridging relays.  Simply drive adjacent segments H-bridges with *EXACTLY* the same signal until you are certain the loco has fully crossed the gap.   If the MCU yu are using has sufficient PWMs that can run off exactly the same timebase, this can be done purely in software, otherwise you may need switching logic.  Probably the easiest option there would be an analog switch matrix to switch N PWMs to M track segments.  You can get the Microsemi MT8816 8:16 crosspoint switch array for as little as $10.  It isn't SPI compatible, unless you add an external shift register and a little glue logic, but that isn't a show-stopper.   That would let you switch eight control PWMs to 16 track segments.  Each switch in the matrix is individually addressable so to switch PWMs to a singe output without conflicts requires two operations - one to turn the previous PWM off, and one to turn the new one on.   Expanding to 8:32 would be as simple as adding another MT8816.  It will switch 5V logic signals while running from 5V so no exotic supply voltages are required.

After all that, do take a step back and consider that its probably cheaper to go full digital with DCC control and fit a commercial DCC decoder to each loco.  You can roll your own command stations and booster boards to drive the track.

The loco crossing track segments and non-matching PWM signals was one of the things I knew was going to bite me !!  I haven't bought any more than the single MC33926 driver to date that I used for testing. There will be 3 seperate speed controllers, one of these will be totally seperate, the yellow highlight in the diagram, the orange outer segment is the main loop and the green is the third segment. I think this is correct but I need to go back tomorrow and double check so don't waste any time doing anything from this diagram ! I had shelved the speed controller plan to come back to later and was only really looking at relay requirements for switching the PWM signal to track segments but if I can do it without relays, and I would rather not use them, I will.

DCC is out of the question unfortunately as the locos are all hand built (about AUD$500 each) and have no space inside the resin bodies to fit the DCC components - this is the first option I looked at. The smaller N gauge trains are even smaller inside.

I am going to look in to supplying PWM signals based on the parallel timing and see if I can work around the issue. Thanks for the heads up !

Its the loco crossing from the orange to green segment that is the issue with the PWM signals getting crossed up, the orange sections after the orange points all run off the same PWM speed control so are less of a problem - again 99% certain this is the case and will check tomorrow.

Its hard to make out in the mud map, but the perpendicular lines crossing the tracks are insulating fish plates that don't allow the track segment to conduct, the vertical arrows are line power inputs that supply a PWM signal (these were all done before I came to sort out the control side of things).

Now... I'm not a train set guy so I'm doing my best to document Dad's requirements ! The orange segment will control the main outer loop and the two other inner dashed loops will allow trains to be parked in sidings, not running, whilst a train is on the orange outer loop. When the PWM signal is transferred to either of the dashed inner orange segments the parked trains can be moved out on to the outer loop. If a train was on the outer loop it can be brought in to one of the inner orange segments and the other one brought out - all operating of the one "orange" speed controller.

At the same time another train could be moved around on the inside green segments from the second "green" speed controller. If there is no other train on the outer orange loop the train could be brought from the green segment out on to the orange loop.

The yellow loop is controlled by the third "yellow" speed controller and is independent of the other two. It has two additional sidings controlled by the "yellow" speed controller which would also allow a train to be sitting in each dashed yellow siding whilst a third train was running around the outside loop. To get either of those trains out, the train on the outside loop would go into the yellow siding off to the bottom left of the yellow loop, the points changed allowing one of the trains in the yellow dashed siding to be brought out on to the yellow loop.

Confusing.... yes. I'm not a train guy, I'm a pilot... I know planes !

So the 6 x DPDT relays were to switch PWM signal to the orange inner dashed segments as required as well as the yellow dashed segments on the independent loop. This still leaves the "fly in the ointment" problem of the orange PWM signal meeting up with the green PWM signal of which I was never using relays to address.

[ilium007]

You can however parallel an active MC33926 with an inactive one that has its outputs tristated.   This means that to get a smooth handoff between adjacent track segments, you need a DPST bridging relay at each inter-segment gap, equipped with a current sensor so your MCU can detect when the loco crosses the gap^*.   Once the loco has crossed the gap, the MCU can, between PWM pulses, tristate the previous segment's H-bridge, and enable the new segments one, without missing a beat, then open the bridging relay.  It should then immediately prepare the next segment by tristating its H-bridge, and closing the bridging relay at the next gap.

One more fly in the ointment (maybe)... I noticed a few weeks back that some of the locos have two motors, front and rear, that are joined through their wheels. So when the loco crosses a track segment from a powered to non-powered segment of track the front wheels go on to the unpowered track but the rear wheels, still on the powered track, "push" the loco across the insulators where it would then stop. In the example quoted above, the front wheels would cross over on to the segment powered by one PWM signal whilst the rear wheels where powered by the other PWM signal but internally the front motor is wired in parallel to the rear.

[ilium007]

If you switch to another H-bridge controller chip that does permit paralleling, you can do away with the bridging relays.  Simply drive adjacent segments H-bridges with *EXACTLY* the same signal until you are certain the loco has fully crossed the gap.   If the MCU yu are using has sufficient PWMs that can run off exactly the same timebase, this can be done purely in software, otherwise you may need switching logic.

The Teensy 3.6 has plenty of PWM outputs and hardware timers that I could use. 2 of the 5 hardware timers have 8 PWM pins each. I'll start looking for a H-Bridge chip that will allow the paralleling.

Pololu also do a VNH5019 based breakout, https://www.pololu.com/product/1451, that evidently does support parallel operation, looking in to that now.

Both this board and my existing MC33926 board have a current sense pin that outputs an 140 mV/A analogue output which I presume I could use for the current sense.

I should point out that I picked the MC33926 as it was capable of 20kHz PWM which I wanted to use, the VNH5019 is also capable of this.

[C]

Instead of new thing might work

Would be better to have more details and get to this change should work.

Are those just pretty pictures or does it work now?
What can it do now?
What controls the engine now.
How is track wired now.
More details the better.

If the engines can not be changed, need to know what the engine needs to work.
What is it using now.

You stated that

DCC is out of the question unfortunately as the locos are all hand built (about AUD$500 each) and have no space inside the resin bodies to fit the DCC components - this is the first option I looked at. The smaller N gauge trains are even smaller inside.

Some motors do not like some signals and long term use harms the motor.
The more details, the lower the chance of harm.

Look at big picture
You want to control old engines.
You want to update old control system.
Do you really care the how if it works if new control is better then old and does not harm engines?

Look at simple led's for example
One bit can control on or off.
With 3 bits and RGB color led you have 7 colors
With 3 connections and RGB color led Three PWM signals gives you lots of colors.

At some point with lots of RGB color leds it's cheaper and better to use special led controller chip.

Final step is
The APA102 is a RGB color led with internal controller chip.
The controller chip logic is built in a way that lets you have long strings of APA102 with out needing buffers.
If you watched that video, it uses 4 8 bit values to control led.
The APA102 uses two inputs for control, data & clock.

The WS2812B RGB led uses one signal where time and level controls led.

So back to engine

Safe for engine motor could be a DC voltage with positive one direction and negative other direction.

So a lot of details of what exists now is good first step.
Power source details all the way to engine.

 

[ilium007]

These are just pretty pictures at the moment, nothing is working as yet. This has been a 30 year project for my Dad and the first time he has had a chance to build a train layout.

Nothing controls the complete layout now, we have been running the loco's on a 40 year old Thrysistor speed controller on one active loop of the board.

None of the yard switching is seperate so only one train has been run at a time during the lay down of the tracks.

Track has "droppers" (one to each track) from the top of the board to the bottom at the points indicated by vertical arrows on the "pretty picture"  previously posted.

The locos run on a 12VDC power supply, previously this was just a 240V -> 12V transformer with a variable speed control. Recently I prototyped a 20kHz PWM solution that used a non-linear speed curve that I developed that ran all locos without issue around the track.

I have no technical details of the electric motors in the locos - some of these were purchased when I was a 15 year kid (19 years ago).

Do you really care the how if it works if new control is better then old and does not harm engines?

Not really, but as previously stated I am using this as a hobby / learning experience. If I wanted to buy off the shelf components I would have just gone a dropped $$$ on a full DCC system and told Dad to go and buy new trains. Thats not what I am trying to achieve here.

Safe for engine motor could be a DC voltage with positive one direction and negative other direction.

Probably correct, but I don't have the skills to build a non PWM speed control circuit. I have no formal electronics engineering education or background. I have looked at many non PWM circuit designs that I could just copy that would give a 0v -> 12v  with a FWD / REV switch but I am not sure how I choose one to simply copy. I still run into a few issues with this arrangement, ie. someone (my 4 year old) running a train from one track in FWD to the next segment in REV = smoke.

I'm happy to continue on the path of getting a PWM solution working, learning along the way and yes, probably spending more money that buying something off the shelf.

[Ian.M]

I can see a problem with that layout.  There aren't enough insulating fish plates.  It needs them in the two orange tracks just to the left of the points in the top left right corner so you can hold a train at a signal on the track that isn't selected  by the points.  That would also require a power feed to the right side of the outer loop.

You also need to understand the difference between live frog and dead frog points, and their impact on which branch track gets powered.  See http://www.brian-lambert.co.uk/Electrical.html#Points.  I'm not sure what the P and D marks at the points code - maybe its live vs dead frog?

At the moment I count 6 power feeds to the orange track (ignoring the questionable one) and none to the green.  With a feed to the green + an extra feed as I just proposed for the right side outer loop, that's eight feeds.   If you use 8 H-bridges that can be paralleled  you can control each independently or sync them up for continuous loop running.   There are four more feed points in the inner layout, so if you want to avoid relay switching, you'd need 12 H-bridges.  Their cost is heavily dependent on the   Maybe look at the dirt cheap classic L298 dual H-bridge.  It can drive up to 2A each, or 3A (3.5A repetitive peak) when paralleled as a single H-bridge.    I believe the rule of thumb is up to 1A per loco, so unless you are planning on running double-headed trains, you could probably get away with half the number of L298s as yiu have feed points.  They are less efficient than modern MOSFET H-bridges so you need a bit more than 12V in to allow for the losses + a big heatsink, but if you can salvage the heatsink, six L298s (or eight to allow for future expansion) + the afore-mentioned MT8816 crosspoint switch, would be a very good option for four control channels with switched current sensing feedback so the controller always 'sees' the peak current of all the L298 sections that channels is driving.  Add a comparator for fast shutdown local to each L298 and it would be short-circuit proof.

Re 'kindness' to old motors of PWM signals - there's no reason why you couldn't add L-C filtering to the H-bridge outputs to average the PWM signals.  just keep them symmetrical - use a pair of equal inductors  in series with the H-bridge outputs and a capacitor between them just before the wiring goes off to the track.  SOME ripple is beneficial for permanent magnet motors - it combats stiction and aids reliable low speed running, but reducing the HF content will reduce motor heating and also peak voltages that might cause rotor insulation breakdown.

Edit: Sorry for the left/right confusion. See below.

[ilium007]

I can see a problem with that layout.  There aren't enough insulating fish plates.  It needs them in the two orange tracks just to the left of the points in the top left corner so you can hold a train at a signal on the track that isn't selected  by the points.  That would also require a power feed to the right side of the outer loop.

It was a mistake on the diagram, there isn't a set of points there. The outside orange loop runs all the way around and is insulated where I have now drawn the black lines across the tracks.

You also need to understand the difference between live frog and dead frog points, and their impact on which branch track gets powered.  See http://www.brian-lambert.co.uk/Electrical.html#Points.  I'm not sure what the P and D marks at the points code - maybe its live vs dead frog?

Yes - I omitted the P/D nomenclature. This mud map was just for my initial design. P is a Peco point which is a dead frog (points make and break the track circuit), D was for "Dual Gauge" point - the orange track is actually dual gauge (makes no difference to this conversation - I noted there becuase htese are points I'm moving with servos) and the dual gauge points are all live frog types hence the insulating fishplates after them.

At the moment I count 6 power feeds to the orange track (ignoring the questionable one) and none to the green.

Missed the green power feed off the diagram ! Because they are all dead frog points the points will make and break the contacts to each track segment when they are switched. Orange track outside loop really only needs 1 PWM feed (Dad just put the others in because... I don't know why!).

With a feed to the green + an extra feed as I just proposed for the right side outer loop, that's eight feeds.

I believe I only require 3 PWM H-Bridges (shown on updated diagram below), one for each of orange, yellow and green and a DPST relay for each dashed segment plus the one solid segment in orange and yellow sections as shown.

The problem of parallel H-Bridges only appears in the sections in the red boxes doesn't it ?

Re 'kindness' to old motors of PWM signals - there's no reason why you couldn't add L-C filtering to the H-bridge outputs to average the PWM signals.  just keep them symmetrical - use a pair of equal inductors  in series with the H-bridge outputs and a capacitor between them just before the wiring goes off to the track.  SOME ripple is beneficial for permanent magnet motors - it combats stiction and aids reliable low speed running, but reducing the HF content will reduce motor heating and also peak voltages that might cause rotor insulation breakdown.

I will look in to this - I had seen reference to the L-C filtering in my initial research some months back.



I'll head over to Dad's tomorrow and redraw this whole thing a bit nicer and confirm that it is all correct.

[C]

Your  4 year old  says to you " Daddy I tried to do a head on collision with two engines, it did not work"
A sign of good control system.
Building system can cost more but you gain in knowledge and control.

Little details can matter.
You know that engine gets power from track.
Here the HOW can be important.
With out details the safe answer is any one or more wheels on each side.
(#1)With this detail you could have one wheel at front and one wheel at back of engine supplying power.
(#2)You could have a axle at front and axle at back with sides connected.
Not knowing where train is in block leads to
Not powered next block or matching power.
With not powered
#1 would stop and #2 would power the block until all wheels are in new block.
You can sense both states with proper circuit. In addition to smoke prevention control system gains train in block info.
A voltage sensor to each rail would work here.

With  matching power
you have a current change to one or both current sensors connected to block rails.
 
If you add two of both types of sensors to a block then you do not care what wheels engine uses as all engines are safe.
Using less than 4 sensors you have to specific wheel connections.

To prevent smoke the electronics needs information so that it can prevent smoke.
An example is a good bench power supply that has a current limit.
Too much current, turn off power supply = no smoke.
A better choice for trains is limit current to very low value so that you can sense if engine backs up.

Using the sensors you collect facts. Some the hardware uses, some the software uses. All preventing the smoke.

So you know High frequency PWM can cause heat in motor.
The old variable speed control with  Thrysistor could be partial part of AC cycle, this would be low frequency PWM.

So  you now have my simple answer
&
lan.M's with more detail

[Ian.M]

Ok, that's pretty much what I thought apart from the P vs D confusion. Also you wouldn't know it but due to dyspraxia I can totally confuse right and left. I was referring to adding insulating fishplates top RIGHT, but typed left. 

To get anything into or out of the green sidings you'd have to either switch both to the same controller or precisely sync the PWMs.    The mod I suggested earlier to isolate both branches of the top right orange points would make it much more versatile as then you could switch the inner orange tracks to the green controller for ease of shunting while still running a train on the outer orange loop.

If 2A is enough current per train, half a L298D + ancillary components will almost certainly work out cheaper than a reasonable quality socketed relay.

You could also poll the track for train positions using the current sensor without moving anything - just briefly apply a very narrow duty cycle PWM to each section in turn and look at its current sense signal to see if there is a load present.   However you'd do better to have some sort of active sensing (e.g. optical) guarding critical points like where sidings join a track that can be configured as a continuous loop so it can E-stop the shunting controller if a cack-handed train movement is about to result in a conflict or crash.

[C]

When you go over to dad's
really look at the track for insulators in the rail.
The more you have the more you can sense.
Might want to take an ohm meter and measure track joints.

Look at yellow spots where you put DPST
Guess is that is engine parking spots.
lan.M suggested using controller to do low current sense if train is parked.
If one side of DPST is off, you could change off to low current sense from a power supply to detect train.

[MarkF]

I thought it may be helpful if I present my HO layout and design.  Some design details are discussed in another thread.  IMHO the large shift register design is the wrong way to go.  One, the long time it takes to update the I/O and the fact that you must update all of it (no partial updates).  Two, the railroad layout is a noisy environment and it only takes a little noise on the clock line to offset your entire I/O bits.

My computer interface centers around a DLP Design module which is quite old and expensive. The basic I/O is parallel address and data buses.  You may want to modify the addressing to allow more I/O (boards).

• Computer USB Interface Board (IO-1.png)
• Track Power Board (3 boards to 30 track blocks)(IO-2.png)
• Relay Driver and Senor Board (3 boards)(IO-3.png)
• Track Driver Board (30 boards)
• Tortoise Slow Motion Turnout Board (45 boards)

The Track Power board generates a combination of a PWM waveform for low speed control or a pure DC voltage for high speeds.  Each PIC16F876A controls 2 track blocks with direction control and track short (train wreck) sensing.  Each PIC has speed settings, error flags and firmware version query responese to the main computer.

Each Relay/Sensor board has 15 relay drivers (ULN2003) and 15 TTL level sensor inputs for block occupancy detection.

Track Crossing indictors (lights or LEDs) are with the extra contacts on the switch machine.

Wireless Hand Throttles (not shown) based on the nRF24L01+ RF module will allow up to 5 users at one time.

  Don't know if this helps your design.  Just food for thought.

[ilium007]

I thought I'd spend some time this morning having a look at I/O options other than the shift registers. This IC caught my eye - the NXP PCA9698. It has 40 I/O channels and very nice current sink ability:

The PCA9698 provides 40-bit parallel input/output (I/O) port expansion for I²C-bus applications organized in 5 banks of 8 I/Os. At 5 V supply voltage, the outputs are capable of sourcing 10 mA and sinking 25 mA with a total package load of 1 A to allow direct driving of 40 LEDs. Any of the 40 I/O ports can be configured as an input or output.

I am going to look briefly at driving one via RS485 to the I/O board and then I2C to the PCA9698 on the board only.

The PWM control was doing my head in so I'm switching my attention back to I/O !

Back in the other thread Ian.M gave me similar advice !

If you want to be able to do long runs between boards, consider putting local intelligence on each relay board (or cluster of relay boards) and using RS485 line drivers and the MODBUS protocol, then you can setup a multi-drop bus over readily available twisted pair cable and power them over the same cable. e.g  if you use Ethernet cable, with one pair for data, and three pairs for power/ground, you can deliver 1A to remote boards with no issues.  Local regulation at the remote board is strongly recommended.

I'm looking at the MODBUS protocol now to see if I am going to have the skills to implement. I could put something like the PCA9698 or the TPIC6C595/74HC165 shift registers on a remote board with an ATMega and talk to them remotely with MODBUS over RS485.

[David Hess]

I do not know if it has been mentioned but the ground loops from mixing the signal and power ground can cause problems and may even be destructive if a high current circuit opens.  Basic precautions should be taken like current limiting for logic signal inputs and outputs and I might preemptively use optical isolation.

[ilium007]

I do not know if it has been mentioned but the ground loops from mixing the signal and power ground can cause problems and may even be destructive if a high current circuit opens.  Basic precautions should be taken like current limiting for logic signal inputs and outputs and I might preemptively use optical isolation.

OK thanks, more research required. One thing I need to learn more about are common grounds, and then how to seperate ground planes between signalling and power circuits.

[ilium007]

So I have spent another whole day researching this.... I have concluded that a more robust interconnect is probably warranted (due to noise / interference) and RS485 seems to be an obvious choice here. If I go with RS485 I will need a protocol to talk over that hardware, MODBUS, SNAP and ICSC protocols all came up in my searches.

MODBUS seems to be quite complex for what I want - all I require is to send a bunch of outputs HIGH/LOW and read a bunch of inputs back to the main MCU. SNAP (http://www.hth.com/snap/) and ICSC (https://github.com/MajenkoLibraries/ICSC) both have little representation on the internet in the Maker scene. This part of the design would be a sticking point for me as I have never implemented or worked with any bus protocol.

At the risk of ruffling feathers I went back and looked at the MCP23S17 IC as well  Hear me out ! If I were to put a small low cost MCU on the expander board, ARM (Teensy LC) or AVR (ATMega 328p) - not sure yet, I could talk from it to the local MCP23S17's via SPI (keep everything on the board traces) and then talk to the remote boards via RS485 - MCU to MCU over some sort of bus protocol. There seem to be many projects online where people are successfully using the MCP23S17.

If I went down this path I would require additional components to increase current sink capability of the MCP23S17 such as the ULN2803 Darlington array (4 per board) or an N-channel MOSFET based approach (32 x 2N7002 per board).

I am not sure if this is a better / more robust approach than the shift registers over an SPI line that run underneath the layout board but it sounds more robust and less prone to interference. Again, I am keen to implement a solution that I can use for other remote I/O projects.

How does one choose a protocol to run over RS485 ? If I did it this way I would run 2 x MCP23S17's on each board giving 32 I/O per remote board (plus whatever I/O is on the MCU).

Would I still be doing a frequent poll of the remote input boards and if so, would the overhead of RS485 and whatever protocol I use mean it would then take too much time to request a slave to send its 32-bit input state back to the main MCU ? Given RS485 is a MASTER -> SLAVE system I could not have a slave MCU initiate a data transfer when someone pressed a button because it would end up in collisions on the serial line.

Looking forward to hearing peoples opinions on this approach 

[C]

You have an event bus

Use CAN this is what it is built for
Cars are very noisy

With RS485 you have problem when can device talk
Problem CAN does not have this problem and gets job done.

[ilium007]

CAN bus seems very complex.... I'll start looking in to it though.

[C]

Would I still be doing a frequent poll of the remote input boards and if so, would the overhead of RS-485 and whatever protocol I use mean it would then take too much time to request a slave to send its 32-bit input state back to the main MCU ? Given RS-485 is a MASTER -> SLAVE system I could not have a slave MCU initiate a data transfer when someone pressed a button because it would end up in collisions on the serial line.

CAN lets you use the power of the slaves

CAN is not complex if you understand it.

First the can controller handles problem when two what to talk
They use fancy names but you could think of that CAN transceiver chip as being like an open collector output in TTL logic   Two outputs on is not a problem.
 CAN transceiver has output of what is happening on the wires and the CAN controller listens to it's self talk.
Think of what happens when two people try to talk at same time, you back off.an try again. 
The CAN controller that wins when more then one tries to talk has the highest priority and keeps talking. It's simple, the logic is such that it is only one that  seeing what it is saying.

Re look at it this way
  You have an input out on the track that just changed.
That input has a type, so you have some bits for the type.
That input was collected by a slave, you have slave bits
That input was one of many like inputs, you have input number.
The CAN ID bits is
Input_type, slave#, input#
The CAN Data
  need one bit for on/off   there are 8 bytes max
  If data is a number like temp, voltage, current  send the number as data.


A good CAN microcontroller will let you program or reprogram the chip over the can bus.  One CAN controller could reprogram all the CPU's in the system.

If you have looked at YouTube
You might have seen where  a ESP32 wifi controller was reprogrammed over the air by  Arduino IDE

If that ESP32 has the code to program over CAN you could re-program all.

Your Teensy has a CAN controller in it.
With code to program over CAN you could re-program all.

[ilium007]

Thanks for the reply, I'm reading the wiki article on CAN bus now.

[C]

Remember this

Your  4 year old  says to you " Daddy I tried to do a head on collision with two engines, it did not work"
A sign of good control system.

Two of the slave microcontrollers see the problem.
Both at same time try to scream out a high priority CAN packet.

Just a normal every day thing for CAN, highest high priority CAN packet UN damaged went on CAN bus and all could receive it.

The delay is waiting for previous on wire packet to complete.
   Then is why a CAN packet is small.
 Waiting for even higher high priority CAN packet to complete.

So you have to think,  if something like a create smoke event could happen, you want it's CAN ID to have a higher priority then a "this block is occupied"  packet.

CAN is an EVENT bus with  priority, and was built for this all the way down to the wires.
IT is not some way to talk on bus with events tacked on top.
Ethernet fits in this category of "NOT Built for events".

[Ian.M]

CAN is complex, but if the MCU manufacturer has a good protocol stack for it, that removes much of the pain - call a few functions to initialise it and transfer data, and register some callbacks for event handling.

However, if you are sticking with RS485, a MCP23S17 gives you 16 bits of I/O for $1.26.  You still need to add a MCU to talk <whatever> protocol over RS485 and control the MCP23S17 via SPI.   If you don't want to have to reinvent the wheel you'll need one with a hardware UART and SPI port, so you can use an off-the-shelf library for a standard protocol and for the MCP23S17

An ATmega2560 MCU gives you about 80 I/Os (you loose a few to the crystal, Reset, and the UART for the RS485, and costs you about $12.   That's only $6.25 more than the cost of five MCP23S17,  but you still haven't subtracted the cost of the MCU required by the MCP23S17 chips, or the cost of the board area they occupy so the real price difference is only a couple of bucks, and it may even come out in your favour.   If you use the Arduino IDE with the off-the-shelf Mega2560 board definition, you only get 54 pins, but with a custom board definition you can easily use the whole lot.

Polling will be fast enough - after all the MODBUS protocol was originally created for industrial automation, and running control panel buttons and indicators and far more time critical stuff like limit switches is a large part of that.   

To request a read all 80 pins of the ATmega2560 and get the reply could take as little as 13ms using the MODBUS RTU protocol at 19.2 Kbaud. 76 polls a second would saturate the bus, but half that would be more than adequate to provide a responsive user experience.  Put some smarts in the keyboard/panel MCU code so it queues keystrokes and you can poll it maybe as little as ten times a second, especially if it updates panel indicator lights locally, and shave a few bytes off the reply packet length.

Add another RS485 transceiver for a second slave to master serial port and  have it report its address and the keystroke, (not MODBUS protocol) and its even quicker, though in a multi peripheral MCU environment the auxiliary 'alert' bus is effectively multi-master so you then need code to listen to its own transmission, and if its corrupted, you have a bus collision so back-off (wait) for a random period and try again.  Repeated collisions should double the maximum back-off period each time, but the extra delay should be reset by a successful transmission.

If you need hard realtime event signalling without the complexity of CAN, each slave needs a dedicated interrupt line back to the master.    Or if its acceptable to poll several devices when an interrupt is received they could share an interrupt input.   There are some details that need to be taken care of for reliable signalling (i.e. *NOT* running single ended logic level signals down long wires), but there's no point discussing that if you don't need it.

[ilium007]

I like the idea of multi master communication with CAN bus over 2 wires. I’ll concentrate more research on that protocol.

The ATmega2560 is more expensive than the much more capable Teensy 3.6 (with 58 digital I/O and 58 interrupts). For the remote boards I could use the cheaper Teensy 3.1, still Cortex M4 based and has a single CAN module with good library support. All it needs is a 3.3v CAN transceiver.

I’ll spend some more time looking at the CAN code before I buy some parts to prototype.

[C]

CAN is only complex if you hake it so.
ilium007 has control, there is no need to match whole system to some CAN standard of how to talk.
CAN is a simple stream of BITts. Complexity comes from not using it the way it was designed to function. Or some standard poorly rewritten.

There have been many model train systems with CAN as control bus. Doing what ilium007 wants.

ilium007
Open your eyes a bit and look around.

Look at cost of an ESP32 on a board.
Look at cost of other boards that do CAN with controller inside MPU like your Teensy.
AVR CAN is high cost with low CPU power. I would not do simple PICs chips even with low cost chips.

If you are building the pc board and putting a micro controller on the board,
You have many choices from ST (STM32), NXT and lots of others.
But not dip chips.

You could go big time and use a $10 PSOC-5LP board.
Free programming environment 32 bit cortex & some FPGA if needed.

Think even the STM32 can be programmed now from   Arduino IDE now
If you look ST has a lot of low cost boards you can get.

[C]

ilium007
Think simple

You have one of many inputs change on one of your boards.
MPU reads the bit or value
looks up in a table and sends a stream of bytes to CAN Bus output buffer.

Simple CAN output driver sends the byte stream(packet).
Fancy CAN output driver sends the highest priority stream of bytes(packet) first

Simple CAN input driver gets a packet, a byte stream and puts it in a table.
This is an interrupt process.

A timer causes a input table check
Simple CAN table check calls a sub.
Fancy  CAN table check looks for highest priority and calls a sub.

Some CAN packets could need many subs and could create more CAN packets.

example
Operator changes switch
CAN packet sent
Track switch controller reads packet and changes a track switch.
Sends a CAN packet
Operator indicator controller reads packet and changes led.

Simple list processing, something a CPU is good at.

A CAN Packet causes a List to be processed.

An Event is the changing of an input or new value from a sensor causes a list to be processed.
Or a CAN packet event.

If a device creating a CAN packet also needs to local process packet it can be a simple add to receive table. this lets local & others cause same change using same code.

Want to add a crossing gate? That is a block sensor packet or a sensor that caused a CAN packet saying train is close to crossing.
 
Want to add sound effects? You have all the current CAN packets. You add to a list if you need something new.

[Leo Bodnar]

If you go CAN, plan well ahead on how you are going to manage assignment of unique IDs, especially if you use multiple nodes of the same type.
Serialising unique devices and managing dynamic CAN ID assignment is the most unpleasant of all CAN features.
CANopen has LSS and LMT but it's too heavy for a simple project like this.
Leo

[ilium007]

If you go CAN, plan well ahead on how you are going to manage assignment of unique IDs, especially if you use multiple nodes of the same type.
Serialising unique devices and managing dynamic CAN ID assignment is the most unpleasant of all CAN features.
CANopen has LSS and LMT but it's too heavy for a simple project like this.
Leo

I'm looking at this today, I don't quite understand how to implement message ID's for a particular message type. Let's say I have multiple block detection IR sensors that have to send a message back to the main MCU via CANbus. Do all of these have the same CANbus 11-bit ID ? What happens when 2 IR sensors send a message at the same time ?  Is a CANbus ID tied to a message type or is it used as a sort of node ID address ? I don't think it is the latter as the arbitration process could then block a node from sending because its ID is higher than another.

I'm finding it difficult to find a good tutorial on the topic as most people who have written about the topic just want an MCU on CANbus to eavesdrop their cars CANbus !

[C]

the easy answer is all CAN ID are unique

You never want two different CAN bus devices sending the same CAN ID
If you do then you have a bus fight.

Are you going to have more than 2000 different event?

Make it easy on your self
If each IR sensor has its own CAN ID then then your control system is easy.
The Can data is the state

Say you have an operator controller
Can ID would be what engine and can data what value
   

[ilium007]

Excellent, that helps ! I’ll buy some hardware and start testing.

[C]

Your Teensy must be connected to a CAN transceiver chip to function with CAN bus.

Look at previous post where I gave an example for a CAN ID

If you have have two boards that work with IR sensors
ID must be unique,

By having the complete What in the CAN ID your software is easy to write.

If you gave each board it's own ID then your software would have to do more work
Simple decode of what just became a two step process.

If board also controlled say track switches to keep ID's in a range you have to give the board a second CAN ID

Think you will find that If you really need more then the 11 bits the software side would be much easer to do using the extended CAN ID

Now if you have many boards for the same thing, It all can be the same except for  a byte changed to give each their own ID range.

Of this  byte you will most likely use just a few bits.

[ilium007]

So 11-bit ID’s give me 2048 possible events. I need to look at how the mailbox filters work but let’s say I break up the address space into blocks. 0-99 are for IR sensors, 100-199 for input switches. If two buttons are pressed and the CANbus controller puts two messages on the wire, the one with the lower address ID wins arbitration and it’s message goes out. How do you choose which buttons get which address or doesn’t it matter for an implementation of my size ? I am trying to relate it back to my car. If each door lock button has a unique message ID that it puts on its CANbus packet, how did the engineer decide which door lock had the lowest ID ?

[C]

First you do not have IR sensors
  The IR sensors are doing something for you

You do not have input switches
  The switches are doing something for you.

So Panic Shutdown switch is different then a change track switch.

Now think about this, The code is the same only the ID changes.

That is why you look up the ID from a table so the code does not change.

[ilium007]

So I’m looking at this wrong.... I thought a switch would be detected by the remote MCU which would send a CANbus message that said “switch5 HIGH”. But what you are saying is that the remote MCU board would have the logic to send a CANbus message that said “activate solenoid 5” - the remote MCU would be programmed with that logic so the switch is no longer in input that is processed by the main MCU but an event that triggers an action.

Where can I learn more about how these bus’s work ? I need some better grounding on the theory of messaging on bus’s before I waste any more of people’s time.


Sent from my iPad using Tapatalk

[C]

You are starting to get it

In the past you had a Teensy that cost $30
at that price you think have it do as much as possible

If you look you can find many boards & CPU's that can do CAN

Just looked on AliExpress
found a STM32F103C8T6 ARM STM32 Minimum System Development Board Module
$1.63

At this price you can easily think of using a lot of them

High dollar leads to central processing. Software gets harder to create
Hardware costs goes up to get best use.

A little history, might help
Most CPU's work with 8 bit data at some point.
When you wnat to talk between CPU's you need more then 8 bits so you can easly identify what is data and what is control/status

A UART gives you an 8-bit data stream.
Takes a lot of software processing to get to point where you have more then 8 bits.
HTML, XML has special characters that when found in data are replaced so that the special characters can become framing start/stop
A modem uses PPP to get tcp/ip over a 8bit stream.

HDLC SDLC are protocals that function over Universal Synchronous Receiver  / Transmitter. Bit-stuffing was used.
IBM had huge networks using this. You have a know start of frame. With this known you can state first x bytes are control followed by data.
Ethernet has a hardware defined start of packet

The old Z80 SIO could do HDLC/SDLC might want to read up on this.

USB, CAN,  Ethernet, SATA, SAS, HDMI and a few others have hardware framing or hardware packets.

Hardware framing or hardware packets makes software a lot easer

See you online will start new post



 

[C]

So
  CAN was developed back in the 80's to cure some problems.

Proper control of bit-stuffing lets you have a stream of bits that can not happen in data. Very low level add bit to stream. On receive bit streams that break the bit-stuffing rules are special. CAN bus uses some of these.
START of Frame is one

Back then all standards used large packet sizes. You might think of a CAN packet as being an INTERRUPT. To get this type of response, packets have to be small.

To do the shared bus bus you need something like open collector logic.

To handle high noise you need differential signals.

To get many transmitting at same time and end up with a good packet you need a rule of when to stop using the bus.
Would guess that for this they had some knowledge of vector interrupt system used on some systems.
The back off could have been from One-Wire

Bosch just used common sense taking what was needed to create CAN.

So low level is just simple common sense.

So I’m looking at this wrong.... I thought a switch would be detected by the remote MCU which would send a CANbus message that said “switch5 HIGH”. But what you are saying is that the remote MCU board would have the logic to send a CANbus message that said “activate solenoid 5” - the remote MCU would be programmed with that logic so the switch is no longer in input that is processed by the main MCU but an event that triggers an action.

NO not quite correct
The CAN message did NOT say “activate solenoid 5”
The CAN message said "this event just happened"
   the receiver of message looked up message and got “activate solenoid 5”

That one CAN message could cause many things to happen all over the CAN network.

device 1 "this event just happened" = -> “activate solenoid 5”
device 3 "this event just happened" = -> “activate LED  12”
Device x "this event just happened"
        =-> Do 1
        =-> Do 45
        =-> Do 155

Might want to read about merg cbus   google it

[ilium007]

Ok thanks again. I’ll keep reading. The reason I wanted to go with the Teensy was that I can still use the Arduino IDE and I’m not 100% comfortable with C++. If I went with PIC or the STM32 variants I really need to be better with C++

[C]

Look on YouTube

Arduino IDE & ESP32

STM32F103C8T6
Arduino IDE & STM32

[TomS_]

The alternative is a L78S05 2A rated linear regulator and a heatsink big enough to handle 15W dissipation without excessive temperature rise.

I would try one of these:

https://power.murata.com/data/power/oki-78sr.pdf

Pin compatible drop in replacement for linear regulator, 1.5A output, no heatsink required.

They are more pricey than a linear regulator, but you save on all things heatsink.

[ilium007]

Nice !

[TomS_]

If I go with RS485 I will need a protocol to talk over that hardware, MODBUS, SNAP and ICSC protocols all came up in my searches.

Whats wrong with good old fasioned "RS232"? If the micro already has a UART then it would be a piece of cake to implement.

I guess technically RS232 specifies the voltage levels, but if you use either a logic level USB-serial adapter on the computer side or something like a MAX232 to convert the +/- voltages to logic level (i.e. basically just the UART), and connect those logic levels directly to a pair of RS485 transceivers (one held in TX mode and the other in RX mode for full duplex communication) and the same setup on the microcontroller side, theres no reason to implement more complicated protocols or schemes?

[C]

Whats wrong with good old fasioned "RS232"? If the micro already has a UART then it would be a piece of cake to implement.

USART was never designed to be a network interface
Not talking micro to PC

This is many micro's connected.
To get a USART to work is a complicated high overhead software mess

[rs20]

If I go with RS485 I will need a protocol to talk over that hardware, MODBUS, SNAP and ICSC protocols all came up in my searches.

No, the only difference between UART/RS232/RS485 is voltage levels, and thus translation between the three is done trivially with level shifting hardware. Whether you add complexity by adding protocols on top of it is your own decision -- you can just have simple text commands or whatever.

USART was never designed to be a network interface
Not talking micro to PC

Who cares what it was designed for? The question is, will it work.

This is many micro's connected.
To get a USART to work is a complicated high overhead software mess

I'm not necessarily familiar with the proposed usecase here, but to describe having an extra little header that represents the meaning "only micro #5 respond to this" as "a complicated high overhead software mess" seems... a bit over the top.

[ilium007]

The MERG CBUS implementation is exactly what I’m after. I’m reading through all of their information.The producer / consumer model is perfectly suited to this scenario.

[C]

USART was never designed to be a network interface
Not talking micro to PC

Who cares what it was designed for? The question is, will it work.

This is many micro's connected.
To get a USART to work is a complicated high overhead software mess

I'm not necessarily familiar with the proposed usecase here, but to describe having an extra little header that represents the meaning "only micro #5 respond to this" as "a complicated high overhead software mess" seems... a bit over the top.

The "a bit over the top." is trying to use one tiny simple part of the whole thing as proof of over the top.

 ilium007
Been a long time since I even looked at cbus.
From that is also some other things you need to pick out.
Think you could add keep it simple.
Keep it simple to add to.
 

CAN is a good foundation to build on for what you want to do.
If you work with CAN to get job done.

If you have been programming for a while, you will need to keep an eye on your self that you are not making it more complicated then it should be.

" event producer / event consumer "
For your train model most of the time will be be a "Value changed event"

Plan ahead some
An Extended frame format needs few changes to allow both.

Your software should check the CAN packet input.
If you start with idea that every CAN packet it bad then you only need to add test for this is correct.
For example
  start with packet marked bad
When you receive an Extended frame format packet.
Base frame format check leaves it bad
Extended frame format check makes it good

Receiving a base frame format packet
Base frame format check leaves it good
Extended frame format check makes it bad

After all tests process the good
By ordering the tests
base is good and this part of base is good

In the process tests are identifying what type of packet.

Extended frame format with some bad bit values remains bad.

Keep in mind
You are not wasting time scanning input with what is on CAN bus.  You have all that done before it gets to CAN

With only changes, something could die and you not know it.
Think this is handled by the
"Remote transmission request (RTR) " bit

Where a consumer has not heard of a change in a long time.
That one bit change would let one non producer request a resend of last value from the producer.

[fourtytwo42]

Just to add my pound of flesh to this ongoing saga, wayyy back in 1995 I had a railways system based upon many PIC16C84's that used a one wire transmission system at 1200bps bit bashed. Some pic's were hand controllers (throttles) others were control panel display's and others were signal boxes or area controllers. The protocol was after Ethernet carrier sense multiple access (CSMA) random backoff. Messages were sent with a geographical address of say a section or point number rather than to a specific processor, each processors software build determined what geographical addresses it served. Trains were given ID numbers that the block signaling transferred around the layout, these were displayed on control panel mimics and hand controllers could log into a train number to alter its speed etc.
This all pre-dated DCC was very exciting at the time but gradually I got fedup with debugging it, the most common problem being dirty track causing lost trains and some messages getting corrupted even though they were always sent at least twice. Some of these issues would be much easier to resolve with the higher memory capacity of today's PIC's.
As for the hard protocol it was single ended rather than balanced but with a ground shift tolerance of around 5 volts, a combination of zeners and transistors being used to interface two pic pins to the singe wire bus.
Food for thought perhaps

[ez24]

... to this ongoing saga  ....

Interesting so I want to watch 

[ilium007]

That one CAN message could cause many things to happen all over the CAN network.

device 1 "this event just happened" = -> “activate solenoid 5”
device 3 "this event just happened" = -> “activate LED  12”
Device x "this event just happened"
        =-> Do 1
        =-> Do 45
        =-> Do 155

Might want to read about merg cbus   google it

So the main MCU is both a producer and a consumer ? I mean, if device 1 puts an event on the wire that says “activate solenoid 5” there has to be a device that consumes that message and then acts on it. The device that consumes it could be another remote board that is configured to listen for that particular event ID or it could be a central MCU that has all the look up tables for what event triggers what device. Which is better ? A central MCU with all the logic or pushing the logic out to the output boards so when they receive the event: “activate solenoid 5” the appropriate output board activated solenoid 5 ?

[C]

BOTH
The idea is to have many MCU's using CAN

When you have a new MCU
It will have a CAN boot loader
Or
No CAN boot loader. In this case you will have to add one.

The reason is that some time you will need to update your program on a device and with out this you have have to use a second method to update program.

So PC talks to a CAN device and that CAN device updates any others via can.

To keep your program simple, you want your system's actions to be controlled by the tables CAN uses to control the system.

Here you a central CAN MCU to update the tables via CAN

To spread the load, you move event to a board if possible. 

So for most the first step for new MCU is blink
With CAN
blink
over CAN remote blink
over CAN remote program
over CAN remote program and then blink
over CAN remote program and run train basic
Small steps that build
With out the remote program you would put off a program change, often leading to a hack work around.

So you might have something fancy that needs central computer, but try to have device(s) do the work.

[Rerouter]

For my own projects in the past, I went with RS485 based apon J1708/J1587 protocol, as it already has conflict resolution and priority baked in.

I then borrowed the basic protocol, and changed the requested / broadcast data chunks to my own definitions,

This protocol also has another benefit, you already have a way baked in to send a lot of data, which I chose to use as a bootloader operation, Send the ID, a verification key (hard coded) and then the bootloader with a CRC per 2KB block.

In this system, most nodes chime in with there data at regular intervals, with no intended reciever, simply broadcast to all, but it also has a request system if you need a particular nodes data faster

The only main thing left was, being lazy I made an auto-ID routine, where if an ID conflict was detected, the device would request a rollcall, and take the next free ID, and use that ID until its next power cycle, but still able to return its original ID from eeprom via command.

I was lazy and left out what happens if all ID's are taken, but I have the bootloader option if it ever comes to that.

[ilium007]

Was you project open source ? I would be keen to have a look at the code.

[TomS_]

if device 1 puts an event on the wire that says “activate solenoid 5” there has to be a device that consumes that message and then acts on it.

I think you might mis-understand this.

Device 1 doesnt say "activate solenoid 5", because it probably doesnt even know solenoid 5 exists - and it shouldnt really know about anything outside of itself. Its also a very specific instruction. For additional actions to occur that are unrelated to solenoid 5, device 1 would also need to send those specific commands, which means it may need to know about a lot of things.

Rather:

Lets say device 1 is connected to a sensor of some sort. Lets say the sensor is on the approach to a level crossing. A train passes through this sensor, and device 1 sends out a message: "Ive just detected a train!".

Device 2 is connected to some kind of motor which is attached to a boom gate at the level crossing. Device 2 sees this message from device 1, and based on its rules/logic, it interprets the message from device 1 to mean "lower the boom gate".

Device 3 is also in the mix, only it is responsible for flashing the lights at the level crossing. When it sees the message from device 1, it starts flashing those lights because that is what the message means to it.

There are advantages and disadvantages to doing things in such a way. Advantages include speed of response to events. Everything receives the message at the same time and everything can act on the message in parallel. A disadvantage is that the logic that controls your layout is spread throughout the layout, so debugging and making changes might be more difficult, and you'll need to maintain a lot of little source files for each micro with their rules and logic.

With a centralised system, the logic is contained in one place, maybe on a PC/raspberry pi, or another micro. The advantage of this is that it becomes a lot easier to make changes to and debug the logic because it is all in one place. The disadvantage is that things cant happen in parallel. The message has to be sent to the central "processor" who then decides what to do, and then dispatches multiple single actions to the particular devices that need to perform those actions.

Depending on the layout, its size, complexity, propensity for changes, those who will be operating it and their abilities to maintain what ever is implemented etc ... a distributed (maybe even set and forget) system might make sense. Or a centralised system, even a hybrid of the two might make sense.

Its a bit of a "how long is a piece of string" kind of thing.

FWIW I love model railways, and would love to build one myself and load it up with electronics, so Ive certainly got my ideas about how to do things, but there has already been sooo much going on in this thread Ive been a bit hesitant about throwing even more in to the mix.

[C]

Hi TomS, You wrere doing real good Until you went fubar with this.

There are advantages and disadvantages to doing things in such a way. Advantages include speed of response to events. Everything receives the message at the same time and everything can act on the message in parallel. A disadvantage is that the logic that controls your layout is spread throughout the layout, so debugging and making changes might be more difficult, and you'll need to maintain a lot of little source files for each micro with their rules and logic.

Device 2,
Should really read, Device 2 sees this message from device 1,
is in it's "lower the boom gate". list and lowers gate.

So Device 1 could be Left side sensor
Device X could be Right side sensor

Any time you want Device 2 to "lower the boom gate".  you are just adding a message to the."lower the boom gate". list of messages.

So if you have a device with 8 binary (On/Off) outputs, You have 16 lists with message numbers. To be complete You might want to know this has happened so you 16 locations that
are sent when output changes.

To make it easy to change
You have a few maintenance messages.
Add this message to this message list.
Remove this message from this message list.

Device 1 port 1 a binary port(On/Off) your 0 state = send message(x0), 1 state = send message(x1).

Your needed control logic becomes just more list processing.
For some the logic block will need to remember state.

Need to do train setup correct
crossing sound or lights should happen first before gate lowers

so at later date when you add Device 3 to do the lights
you change the message device 2 uses to "lower the boom gate"  from device 1's message to device 3's message.

[ilium007]

if device 1 puts an event on the wire that says “activate solenoid 5” there has to be a device that consumes that message and then acts on it.

FWIW I love model railways, and would love to build one myself and load it up with electronics, so Ive certainly got my ideas about how to do things, but there has already been sooo much going on in this thread Ive been a bit hesitant about throwing even more in to the mix.

I’d certainly be happy to hear your thoughts on this ! I know the thread has gone off track (pun intended) and should probably start a seperate conversation about control systems. I’m actually getting ahead of myself, the conversation started because I was looking at the use of relays to switch the PWM track signal !

[C]

ilium007

You started having some electronic problems  on SPI in two areas.
A chain of many boards you have noise and fan-out problems
A buffer helps here.

When you add distance between boards to save wire length of the many connections a buffer becomes a must. To handle a lot of noise you need differential drivers & receivers or some other fix.

RS485
  Only one transmitter can be active at a time.. Some MPU's do not have hardware to turn-off transmitter when last byte sent from serial. More hardware or pin and software.
Only one Transmitter leads to scanning. Having large packets leads to more delays.
Most MPU serial ports have a 9-bit mode but PC does not have. 9-Bit mode lets you make packets. No hardware packets and software may need to scan every byte sent and change some.

More & more software load on each MPU just to use RS485 as bus. Poor for a real time control bus but great for large data moving.

CAN Bus
Foundation is events with priority and small data & Differential bus. Great for a control buss as no scanning delays or waiting for large packets.


The Problem is that a lot of people have not used a bus like this and try to use any reason to not use it.
Often when it is used the keep it simple goes out the country.

The big problem for some is idea of big data on CAN. One of the first areas for this is programming firmware over CAN. If you check with maker of MPU most have a way to do this. It is not a deal breaker.

One advantage of CAN is that each new thing talking via CAN bus can add it's MPU power to system, often with little to no change to existing system.

Often forgot is that if you can change a BIT and specify the address, the limit is how big is address range. Arm is 32 bit address, 4 bytes. CAN has up to 8 bytes in each can packet. So with time all could be changed.
Use More CAN ID's and gain speed.

For your train
For input
   The MPU sees a change and sends a CAN message.
For Output MPU receives a CAN message and makes a change.

If you read about CBUS you saw this.

Logic is one or more CAN message(s) with saved state.
This CAN message sets this state var in MPU
After CAN message has state then the stored state is scanned and could send a CAM message.

Most MPU's these days can read & write to an SDCARD so in addition to each MPU's EErom & Flash setting power up state you could have a sdcard set the state.

A whole new system could be on one sdcard. New firmware for devices, new starting state & new control tables.

Huge amounts of special code can be unnecessary
Read previous post that covers bits
Bytes is just a small change

The only hard thing is not having two devices send the same CAN ID message. Simple to give each device an ID with initial programming.
There are even ways to do this if each device has a unique
 identifier.


 Keep in mind that if you have a good packet based system it can carry a different packet based data stream in it's packets. For CAN with only 8 byte packets this will be slow.

Remember that USB is packet based and often is transport for other packet systems. A USB drive or USB network adapter.






 

[ilium007]

CANbus is certainly looking like the communication method I need to use. I have spent a fews days reading about it and now I need to prototype it. I have plenty more questions on the topic.

Back the the PWM speed control. I have received a response from Pololu and the VNH5019 based driver module I was looking at can't be run in parallel evidently.

To recap - the scenario I am facing. The train is running from right to left in the diagram. Orange track is powered by one PWM driver, in this example 70% duty cycle and the green track is powered by a seperate PWM driver at 30% duty cycle - both using the same 20kHz hardware timer. The trains have front and rear motors connected to the tracks via their wheels and both motors connected in parallel (going to clarify this 100%). When the front train wheels touch the green track they essentially bridge the two PWM drivers together and this can lead to 'shoot-through'.

So I need a way to stop the orange PWM driver and start the green PWM driver.



Ian.M made a suggestion previously that I that I need to re-visit - that is using a bridging relay:

It may be worth biting the bullet and investing in one controller per track segment and getting rid of the controller to track segment switching relays.

There is however one MAJOR fly in the ointment.  Because of their internal current limit PWM and deadtime control, you cannot parallel active MC33926  H-bridges.   There is a high risk of shoot-through resulting in a repetitive brief uncontrolled short between the power rail and ground, leading to overheating and possible destruction of the H-bridges.
You can however parallel an active MC33926 with an inactive one that has its outputs tristated.   This means that to get a smooth handoff between adjacent track segments, you need a DPST bridging relay at each inter-segment gap, equipped with a current sensor so your MCU can detect when the loco crosses the gap^*.   Once the loco has crossed the gap, the MCU can, between PWM pulses, tristate the previous segment's H-bridge, and enable the new segments one, without missing a beat, then open the bridging relay.  It should then immediately prepare the next segment by tristating its H-bridge, and closing the bridging relay at the next gap.

If you switch to another H-bridge controller chip that does permit paralleling, you can do away with the bridging relays.  Simply drive adjacent segments H-bridges with *EXACTLY* the same signal until you are certain the loco has fully crossed the gap.   If the MCU yu are using has sufficient PWMs that can run off exactly the same timebase, this can be done purely in software, otherwise you may need switching logic.  Probably the easiest option there would be an analog switch matrix to switch N PWMs to M track segments.  You can get the Microsemi MT8816 8:16 crosspoint switch array for as little as $10.  It isn't SPI compatible, unless you add an external shift register and a little glue logic, but that isn't a show-stopper.   That would let you switch eight control PWMs to 16 track segments.  Each switch in the matrix is individually addressable so to switch PWMs to a singe output without conflicts requires two operations - one to turn the previous PWM off, and one to turn the new one on.   Expanding to 8:32 would be as simple as adding another MT8816.  It will switch 5V logic signals while running from 5V so no exotic supply voltages are required.

(a) did I get the diagram correct based on Ian.M's suggestion ?

(b) If I understand correctly as the train moves right to left the right hand PWM driver is supplying the PWM signal, if the user commanded the train to cross from the orange segment to the green segment the relay would be closed (not as shown in picture) and the orange PWM driver would be supplying current to the green segment. Once the current in the orange track has dropped to 0 I would know the train is off that segment so then I could tristate the orange PWM driver outputs, activate the green PWM driver outputs and open the bridging relay. Obviously doing the same thing on the other end of the segment.

The part that has me thinking is the timing - this is a 20kHz PWM signal (run from the same hardware timer) therefore I have 50uS to do the current sense, send that by CANbus, have another board receive the CANbus event, tristate the outputs on each PWM driver and close a relay.

50uS is a really short amount of time !

How do I do current sensing ? The MC33926 provides a 140uV/A analogue output that I could use, I am not sure if its output will be fast enough to provide the 0 current sense to use for switching. If I don't use the MC33926 for current sense, how else can I instantaneously measure current ? I looked at current transformers (used in DCC) will only work on an AC signal. I have seen guys solder tiny SMD resistors across the axles of trains to provide a current draw but not sure how they are then sensing this and how fast it is - I have to do the switchover in 50uS.

I am not tied to the MC33926 - I'm happy to look at the LM298 the Ian.M suggested as well. Obviously I wont get any fancy current sense output from them so the current sense part of the design is probably the most critical at this point.

[Ian.M]

That's why you don't do the bridging relay control over CANbus. 

Opto-isolated control signals between adjacent track segment controller MCUs would be the way to go, with each MCU controlling one or a group of track segments, associated bridging relays and train position sensors.  Multi-segment controllers would run a task for each segment.

The CANbus interface would be to assign a power level and direction to a train number, specify the segment it is currently in and specify if it is to bridge to the next segment.  That segment would power the train as long as it continues to draw current. Inactive segments would be tristate.  If requested, the bridging relay in the direction of travel would be closed.  When a segment detects that all the current is being taken via the bridging relay, it signals the next segment to take over, which then handshakes back for the active segment to go tristate and release the relay, in that order , and then goes active itself, reporting back via CAN bus that it has the train.

You'll need to devise some interlocks such that attempting to close a bridging relay between two active segments, or over-current on any segment, or a train detected closely approaching an intersegment gap without a closed bridging relay, all E-stop the whole layout track power and hold internal state for the master controller to interrogate for a crash dump.

[ilium007]

So is my diagram correct re. the position of the bridging relay ? I'm driving the coil via the MCU ? I have seen some other diagrams where they were driving the coil when the track segment was connected to the previous track via the loco (if that makes sense). I'm still not sure how I am to do the current sensing.

[Ian.M]

Bridging relay coil controlled by the loco would be a LOT harder to do.

Current sensing could be done a number of ways e.g. a coil on a gapped toroidial core in series with one pole of the relay contacts, and a hall sensor in the core gap, or a low-ohm resistor as a current shunt and amplify the voltage across it etc.

Although ideally you'd do the switchover in one PWM cycle, you could let the traiin coast with both controllers tristated for about a millisecond and I doubt anyone would notice the stutter.

[ilium007]

Ok. I like the toroidal core option. Aside from now researching toroidal coil wire size and number of turns I guess I also need to think about a fly back diode on this coil just as I would on a solenoid coil.

[Ian.M]

You'll like the core option a lot less after you've fractured a bunch of them trying to gap them with a diamond cutting disk.

[C]

First remember the kid & smoke.
Control logic failures
Two active sections.

An insulated section a little longer then engine makes things much safer.

[ilium007]

I’m looking at this layout trying to work out how a DPST relay would work. Wouldn’t I require a complete segment of track isolated in both directions and then a DPDT to supply power to the middle segment from both directions ? I’m at a loss as to where the current sense would be done. If it was in series with the relay pole then it would still draw current from the outter segment whilst in the middle segment as per the quick diagram attached that I did whilst I was looking at the layout this afternoon.

[ilium007]

An insulated section a little longer then engine makes things much safer.

This is exactly what I’m proposing above. An insulated segment longer than the longest loco. I’ve checked the layout this afternoon and there is plenty of space for two segments in the ‘green’ section (original diagram).

[Ian.M]

Put ONE current sense in series with ONE relay pole common.  You'd also need a current sensor for one side of every other track power feed, so you can detect when the loco power pickup wheels have fully left the previous section.

However IMHO its all overkill - just use H-bridges that can be paralleled with fast acting low side current sensors that toggle a flipflop that tristates the H-bridge on over-current.   The filter inductors will prevent the current building up too fast for the over-current protection, and if you reset the flipflop at the start of every PWM cycle it will limit the current to a peak of the setpoint and an average of about half that till the fault is cleared (e.g. the loco has fully crossed into the section with a different PWM duty cycle.)   To handle idiocies like two adjacent sections set in opposite directions with a train running up to the joint, when the protection trips, if the fault doesn't clear in a couple of seconds, E-stop the layout as there must be a train stalled on the joint between the conflicting sections.

[ilium007]

Ok but I’d still require a DPDT relay wouldn’t I ?

[Ian.M]

Yes, if you are dumb enough to go for this over-complex relay switched short length of track between sections. 

Consider the cost of the relays, controllers, fitting extra power feeds and insulating fishplates (and the irreplaceable time to mod the layout - nobody's getting any younger here) and the potential for it to go badly wrong, v.s, the cost of doing it right with absolutely no relays, instead using parallelable H-bridges with good enough over-current protection to make them 'bomb proof', even if you torture them by directly shorting the track or shorting diagonally across two different track sections

Ultimate torture test - If you can clip one lead to the tang of a new coarse steel file and run a nail down it attached to the other lead without doing any damage, no matter what the H-bridge control inputs are doing, its sufficiently bomb-proof.

You deal with the possibility of a H-bridge or over-current protection circuit failure by fusing the supply to them.   Worst case - if one fails it may take out an adjacent section before the fuse blows.  Swap out the affected section drive boards and you are back in business.  Replace the damaged H-bridges and test (and maybe fix) the over-current protection, and you've got your spare drive boards back.

[ilium007]

Umm ok. I wasn’t trying for a ‘dumb’ solution. I just went back through the thread and started looking at your first solution.

I’ll go to the next option now of paralleled H-bridges. Pololu told me today that what I was trying to do wasn’t considered ‘paralleling’ and that what I was trying to do would never work but I’ll do some more research on running two L298 which should be less.... dumb

[ilium007]

I found Allegro do a series of current detection IC’s that might be suitable.

[Ian.M]

As I said, L298 or similar H-bridges with robust low side over-current detection and limiting added (they have provision for connecting the required sense resistors) can be bomb-proof even if their control is fully distributed.  Any conflicts can be handled by the fast over-current protection, even if they are on fully independent PWMs, though you'll get less jerking at handover points if you don't try to have local track power control  modules and instead you keep them all together and run them from one MCU, sync the PWMs, and distribute their track power outputs over heavy twisted pair.

As it will be the main power consumer, you can build it in the same box as the main PSU, with a big-ass heatsink on the back for all the H-Bridges,  each H-bridge chip and current sense circuit on its own little board for ease of maintenance.
Put the whole shebang under the layout somewhere in the middle to reduce the power wiring length, with remote CANbus control and diagnostics.  I'd advise using pluggable screw terminal strips for the track wiring - that way you can easily disconnect it and pull it out for maintenance.

IMHO you need to get a minimum radius loop of track on your bench with three sets of insulating fishplates, three power feeds and a loco and start experimenting.

[ilium007]

If you switch to another H-bridge controller chip that does permit paralleling, you can do away with the bridging relays.  Simply drive adjacent segments H-bridges with *EXACTLY* the same signal until you are certain the loco has fully crossed the gap.   If the MCU yu are using has sufficient PWMs that can run off exactly the same timebase, this can be done purely in software, otherwise you may need switching logic.  Probably the easiest option there would be an analog switch matrix to switch N PWMs to M track segments.  You can get the Microsemi MT8816 8:16 crosspoint switch array for as little as $10.  It isn't SPI compatible, unless you add an external shift register and a little glue logic, but that isn't a show-stopper.   That would let you switch eight control PWMs to 16 track segments.  Each switch in the matrix is individually addressable so to switch PWMs to a singe output without conflicts requires two operations - one to turn the previous PWM off, and one to turn the new one on.   Expanding to 8:32 would be as simple as adding another MT8816.  It will switch 5V logic signals while running from 5V so no exotic supply voltages are required.

So this is the non-dumb solution that I’m now looking in to. Trying to find a H-Bridge that can be paralelled.

[ilium007]

As I said, L298 or similar H-bridges with robust low side over-current detection and limiting added (they have provision for connecting the required sense resistors) can be bomb-proof even if their control is fully distributed.  Any conflicts can be handled by the fast over-current protection, even if they are on fully independent PWMs, though you'll get less jerking at handover points if you don't try to have local track power control  modules and instead you keep them all together and run them from one MCU, sync the PWMs, and distribute their track power outputs over heavy twisted pair.

I’ll go through the L298 datasheet tonight and try and work something out. I have 8 timer outputs on the Teensy on two of the hardware timers so I have plenty of outputs to keep the h-bridges in perfect sync.

[C]

To be safe last drawing needs a ONOFF relay to middle section.

Only safe thing is to sense voltage change to un-powered section to detect a engine entering that area.
When one wheel touches un-powered area you have a voltage change.
You do not have a large current until engine is drawing power from section.

Now convert to rugged solid state.

Keep in mind that a in relay logic an H-Bridge is a DPDT relay and most have off to this relay.
Some can turn off one side of H=bridge
Some sense only common low side current
Some sense common high side and low side current.

A mosfet is a one direction switch with a diode in other direction.

[C]

lan.M
is adding fast current sense
Safe current short
Fast control
prevention of fast current change
and others.

[Ian.M]

Yep.  Thanks for hiliting those key bullet points.

[ilium007]

So if I can tri-state the MC33926 outputs then why can’t I just put a break between the two track segments, have one side tri-stated and when the active side senses zero current tri-state it’s output and enable the other side ?

[C]

For MC33926

You are controlling inputs.
MC33926 is controlling the outputs.

To protect it's self the MC33926 does different then what you put on inputs.

[ilium007]

From the MC33926 datasheet:

Two independent disable inputs are provided to force the H-bridge outputs to tri-state (high-impedance off state).

[Ian.M]

For the MC33926, you've got to be certain the train has cleared the previous section (which means a delay), and tristate it before you can start the new section's PWM.  It will therefore jerk badly as if you'd slammed on the brakes when crossing a section gap.  Also consider the false zero current detection problems you will get if there is any dirt whatsoever on the track or wheels.

That's why all the mess with bridging relays was needed if you were going to use the MC33926 so you could pick the time to switch which section was active without needing to detect or know the exact loco wheel positions with respect to the insulating fishplate.

[ilium007]

So how does changing PWM driver fix this ? If they can be “paralleled” are you saying they can both be “active” at the same time as long as they are timed exactly the same ?

I’m not tied to the MC33926 - I had only bought one of them for testing.

[Ian.M]

Yes.  Same input signal means you can run the loco right across an insulating fishplate, and the brief short between the two dumb H-bridges doing exactly the same thing wont even be noticed except as some fluctuations in the current monitoring as the loco load transitions from one section to the next.

The problem with the MC33926 is its too smart - if you give two the same inputs you cant guarantee they are doing exactly the same thing at the same time.

[ilium007]

Ok

[TomS_]

Hi TomS, You wrere doing real good Until you went fubar with this.

Sorry, your posts are a bit difficult to understand. But if I do understand what you are saying then you are suggesting that message "types" could be soft mapped to some kind of action? Perhaps that map is stored in EEPROM, maybe loaded in to RAM on startup, and when a message is received the type is looked up and translated to an action?

And the maintenance messages you speak of could allow this soft map to be loaded or updated over the network itself?

Sounds quite reasonable. I was typing quickly because I was at work, so probably overlooked a couple of things.

[ilium007]

lan.M
is adding fast current sense
Safe current short
Fast control
prevention of fast current change
and others.

I am reading the data-sheet for the MC33926, https://www.nxp.com/docs/en/data-sheet/MC33926.pdf, and it says the following:

The 33926 has output current limiting (via constant off-time PWM current regulation),
output short-circuit detection with latch-off, and overtemperature detection with latch-off.

Does this mean "prevention of fast current change"

A disable
timer (time tB) is incorporated to distinguish between load currents higher than the ILIM
threshold and short-circuit currents. This timer is activated at each output transition.

I was searching for a H-bridge with Ian.M's specifications and the MC33926 came up in the results - thats why I'm asking.

The L298 doesn't handle short circuits evidently.

[C]

I sometimes need to say same thing different ways.

 The basic idea is to keep it simple, the same and very logical binary.

CAN bus arbitration works due to no two devices sending same ID.

To make two devices have unique ID just a few bits in ID need to change. One byte data difference would let you have up to 256 devices if all were used in ID.

Step two.
Seep is simple
A device scans it's input bits and outputs a CAN Message.
Here you want Input changed for input bit.
previous scan bit is different from current bit to get if changed.
Bit value goes in CAN Data with option of also in CAN ID.

When this is put together you get first bits of CAN ID being priority followed by ( device# & Bit#). With requirement to have Device # in CAN ID you can not have two devices sending the same ID.

With a standard for Can Bit message like this CAN ID is all the decode you need.

Device output is
CAN Message causes output bit on device change.
CAN message( a packet) goes to CAN INPUT Input buffer on device.
 
You could have many different CAN ID's with a need to change a output bit. You have a List of CAN ID's to change output bit.

SO for device a CAN message is always DATA that can change,
Not part of program just data the program uses.

Remember that All devices start out the same but for that one device ID byte.
You have the same program on all.

Now add in CAN messages to/from device.

One function you want to have is reprogramming firmware over CAN bus.  Lets you easily add improvements to firmware.
You can/could reprogram EEPROM data and use this for CAN message data for above.

With CAN messages to device you can configure each device and read back configuration.

These device  maintenance messages can be very powerful.
If you have many different types of devices it can ask device for a lot of details.
What version of firmware and u[date of needed/
Could configure PINS to different modes.

So if you had one device with attached sdcard this one device could update and configure all the other devices.

The control program for a model train becomes just list management.

You can have virtual things. You could have a virtual software output that processes it's input list and outputs a CAN message. Using this you just made the CAN message list for an output 2X-1 larger.

You can have virtual software output that remembers bit state.
This lets you build all kinds of logic.

This is all bits but you can have many types. Bits, Bytes Words for example

Now think about PWM
You have PWM setup and PWM value change. just a few more CAN message types.

Now the Input bit CAN message could change a bit or a PWM value.

Little simple program changes that add huge power to system.

A kid can build the data to control the system.

And the huge advantage system can grow get fancier with small changes.

Think of doing the system with very simple logic, what would you need?  (and gate, or gate, inverter)
Then CAN messages can be input to logic and output
 

[Ian.M]

I was searching for a H-bridge with Ian.M's specifications and the MC33926 came up in the results - thats why I'm asking.

The L298 doesn't handle short circuits evidently.

The problem is the MC33926's method of handling over-current (i.e. shorts) - you cant guarantee that two of them will current limit synchronously, and its almost certain they wont, and will conflict.

The L298 is designed to support external current measurement - that's why the low sides of its two H-bridges are bought out to separate sense pins (1,15) from the logic ground ( 8 ).   A low-ohm external current sense resistor goes between the sense pin and ground,  you amplify the voltage drop across it using a single supply OPAMP with common mode input range that includes ground, and use a comparator to gate off the enable input of that half of the L298.  At its simplest the comparator could be the other half of a dual OPAMP and the gating a simple AND gate.  However for your application, gate logic that latches off for the period of the motor PWM  would be preferable.  The motor PWM drives the gate logic which drives the EN pin of the L298.

A true comparator will be faster - you'll need to do the OPAMP slew rate calcs and add the logic and L298 propagation delays to see if you can get away with a quad OPAMP (as the L298 has two halves) doing both the sense amp and comparator functions.   For the logic, you'll need half a 74x74 for the flipflop and 1/4 of a quad AND gate.   The PWM signal goes to one input of the AND gate and the CLK of the flipflop to clock in a 1.  The Q output of the flipflop goes to the other AND gate input so that 1 lets the PWM through to the L"98 EN pin.   The comparator current limit output goes to the /CLR pin of the flipflop to trip it to 0 and shut off the PWM cycle early if the current limit is reached.

Assuming a quad OPAMP is good enough, that's 2 1/2 support chips per L298.  As each H-bridge has two inputs for direction and braking control, if you put two L298s per board for four track segment outputs, they'll take five support chips (2 quad OPAMPs, 2 dual flipflops & 1 quad AND gate) and you'll need 8 bits of control signals + 4 PWMs from the MCU board.  The current amp outputs can be RC low pass filtered and fed back to ADC inputs of the MCU for train presence detection.  l would also advise feeding back the /Q outputs of the flipflops to the MCU for easy over-current detection, as the average voltage from the current amp output will be low once the over-current circuit has tripped.

[ilium007]

I was searching for a H-bridge with Ian.M's specifications and the MC33926 came up in the results - thats why I'm asking.

The L298 doesn't handle short circuits evidently.

The problem is the MC33926's method of handling over-current (i.e. shorts) - you cant guarantee that two of them will current limit synchronously, and its almost certain they wont, and will conflict.

The L298 is designed to support external current measurement - that's why the low sides of its two H-bridges are bought out to separate sense pins (1,15) from the logic ground ( 8 ).   A low-ohm external current sense resistor goes between the sense pin and ground,  you amplify the voltage drop across it using a single supply OPAMP with common mode input range that includes ground, and use a comparator to gate off the enable input of that half of the L298.  At its simplest the comparator could be the other half of a dual OPAMP and the gating a simple AND gate.  However for your application, gate logic that latches off for the period of the motor PWM  would be preferable.  The motor PWM drives the gate logic which drives the EN pin of the L298.

Ok - I'm sort of following ! I have never done anything with opamp's so now is a good time to start reading.

[ilium007]

Although I had just found the TI DRV4484 whose data sheet I was reading - it looks pretty nice. MOSFET driven outputs instead of the BJT's and I think it can be paralleled.

http://www.ti.com/lit/ds/symlink/drv8848.pdf

[TomS_]

I’m looking at this layout trying to work out how a DPST relay would work...

Ive been biting my tongue a bit on this, but ... Are you really reeeeaaaally sure that there is zero room for DCC controllers in the locos? There are some really small ones around if you dont care about fancy lighting effects/sound etc.

e.g. this one is small enough to fit in an N scale loco: http://www.digitrains.co.uk/ecommerce/locomotive-decoders/small/mx622-mini-dcc-decoder.aspx

The other thing to consider in respect to those isolated blocks of track is what if you want to run a multiple engine consist, and youve got physical sections of isolated track that are only big enough for one loco?

Not cheap, but it really does seem like DCC would remove a lot of the seemingly complicated trickery you are trying to achieve with H bridges and isolating relays/circuits etc.

[ilium007]

I’m looking at this layout trying to work out how a DPST relay would work...

Ive been biting my tongue a bit on this, but ... Are you really reeeeaaaally sure that there is zero room for DCC controllers in the locos? There are some really small ones around if you dont care about fancy lighting effects/sound etc.

e.g. this one is small enough to fit in an N scale loco: http://www.digitrains.co.uk/ecommerce/locomotive-decoders/small/mx622-mini-dcc-decoder.aspx

The other thing to consider in respect to those isolated blocks of track is what if you want to run a multiple engine consist, and youve got physical sections of isolated track that are only big enough for one loco?

Not cheap, but it really does seem like DCC would remove a lot of the seemingly complicated trickery you are trying to achieve with H bridges and isolating relays/circuits etc.

Dad does NOT want to modify any of the locos. I was over their today and mentioned DCC again and he wants no part of it. It's not going to happen.

[Ian.M]

Although I had just found the TI DRV4484 whose data sheet I was reading - it looks pretty nice. MOSFET driven outputs instead of the BJT's and I think it can be paralleled.

http://www.ti.com/lit/ds/symlink/drv8848.pdf

Sorry, its too smart. See the requirements for enterin and leaving paralleled mode:

7.3.3 Parallel Operation
The two drivers can be used in parallel to deliver twice the current to a single motor. To enter parallel mode, AIN1 and AIN2 must be left Hi-Z during power-up or when exiting sleep mode (nSLEEP toggling from 0 to 1).
BIN1 and BIN2 are used to control the drivers. Tie AISEN and BISEN to a single sense resistor if current control is desired. To exit parallel mode, AIN1 and AIN2 must be driven high or low and the device must be powered-up or exit sleep mode. Figure 7 shows a block diagram of the device using parallel mode.

As you need to enter/leave parallel mode dynamically as the loco crosses each isolation gap, that's far from ideal.    Also its a SMD device with a thermal pad so is a PITA to assemble unless you've got reflow capability or rework for future repair unless you've got a hot air rework station and a board preheater.  You dont want to be forced into using off-the-shelf preassembled breakout boards for it as they'll push the cost up significantly and are likely to go obsolete (or change their pinout or pin spacing) just when you need a replacement.  Its also a PITA to heatsink properly unless you invest in an aluminum substrate PCB for it, or put a lot of filled vias in the thermal pad to get the heat to a heatsink on the back f the PCB.

[ilium007]

Ok gotcha

[ilium007]

A true comparator will be faster - you'll need to do the OPAMP slew rate calcs and add the logic and L298 propagation delays to see if you can get away with a quad OPAMP (as the L298 has two halves) doing both the sense amp and comparator functions.   For the logic, you'll need half a 74x74 for the flipflop and 1/4 of a quad AND gate.   The PWM signal goes to one input of the AND gate and the CLK of the flipflop to clock in a 1.   The comparator current limit output goes to the /CLR pin of the flipflop to shut off the PWM cycle early if the current limit is reached.

umm yeah... I have no chance !

[ilium007]

Could I cheat and take the current sense output back to the analogue input of the MCU and then control the EN pins of the L298.

V = I x R = 2A x 0.5 ohms = 1VDC @ 2A per motor.

Could I not write code to chop the EN pins at, say, 2A / 1VDC ?

[Ian.M]

No. code just cant do it fast enough unless your MCU runs at hundreds of MHz.
Consider a 1mH choke.   With 12V across it the current will rise from 0 to 2A in 167us.  You've then got another 41us before it exceeds the L298 repetitive peak current limit of 2.5A

Your code has to react in that 41us and shut off the PWM as soon as possible, and it has to do it for twelve channels - eight for the outer layout and four for the inner.  IMHO that just ain't going to happen in pure software.  However if the MCU has hardware auto-shutdown logic for the PWM, the PWM gating can be moved into the MCU, and if it has enough adjustable threshold analog comparators that can control the PWM gating everything except the first current sense OPAMP can be moved into the MCU.

A bigger choke would make it easier as the current would rise more slowly, but high inductance chokes that can handle >2.5A without saturating are $expen$sive$ and bulky + you need two per H-bridge for the load filter.   If the choke saturates, its game over - the current will rise rapidly before the protection can trip and blow out the H-bridge, so you cant skimp on the chokes by using ones only rated for the average DC current.

[ilium007]

**sigh**

[Ian.M]

QUAD OPAMPs and 74HCxx logic are jellybean parts.,  The BOM cost for eight L298 based controllers should come in far under the cost of eight dual MC33926 breakout boards.

Also you get the satisfaction of saying "I designed and built that", not "I hacked that together with maker modules".

[ilium007]

QUAD OPAMPs and 74HCxx logic are jellybean parts.,  The BOM cost for eight L298 based controllers should come in far under the cost of eight dual MC33926 breakout boards.

Also you get the satisfaction of saying "I designed and built that", not "I hacked that together with maker modules".

I agree 100% my **sigh** is because I am sitting here realising how knowledge deficient I am in this field. It is so frustrating !

[TomS_]

Dad does NOT want to modify any of the locos. I was over their today and mentioned DCC again and he wants no part of it. It's not going to happen.

Ah, fair enough.

Another thought comes to mind, and this may be so basic that I may have missed it: what about combining route control with power distribution?

As you setup a route, a bunch of switches and/or relays can be used to not only switch the points to create that route, but switch power from a variable power supply to the appropriate sections of track? Only one train can in theory operate in one section of track at a time, so your interlocking logic ensures not only that two trains cannot collide with each other, but that two routes cannot be joined together such that power from one supply gets mixed with power from another supply.

This means you probably only need to break your track up before and after each set of points, and you join the sections of track with DPDT switches or relays? Some other basic logic would be required to determine which power supply feeds a given route.

You should still be able to break it up in to even smaller sections of occupancy detection for triggering signals etc, and no need to worry about shorting H bridges, or doing fancy handover from one section to the next?

Have I missed something really obvious ....?

[ilium007]

Yeah !! We've been there a few pages back !

[Ian.M]

@ ilium007,
So do what I said - get a loop of track on your bench and a loco and start breadboarding this stuff.   There's no substitute for hands-on experiance.

The L298 has a staggered pinout but with care the legs can be bent slightly to fit it to matrix board.  Do the high current stuff (L298, 4 external catch diodes per channel, current sense resistor, filter chokes and capacitor), soldered on matrix board, then you can do the current sense amp and  control logic on solderless breadboard.  Stick an Arduino Nano^* on the breadboard to provide PWMs and drive the direction inputs.  You've got it right when you can set two different speeds via the PWMs for the two H-bridges in the L298, powering the two halves of the loop, and the loco goes round it with the speed changing at the isolation gaps without any drama like hot chips or magic smoke release., and shorting the track with a screwdriver  stops it and lights an error light, with no damage, so one button press later it starts again.

* The Nano's not essential, but its easier than breadboarding a bunch of switches and 2 555 timers to provide the PWMs.  Use a Nano clone because its dirt cheap, breadboardable and 5V.  OtOH you could use a Uno with a socketed ATmega328P and jumper across to the breadboard, but that's likely to be more expensive if you do something daft compared to a disposable Nano clone.

@ TomS_
The idea was to get away from the large relay tree or relay matrix for cost and reliability reasons.   Also, IMHO, having a layout that sounds like a 1950's telephone exchange is not so cool!

[ilium007]

@ ilium007,
So do what I said - get a loop of track on your bench and a loco and start breadboarding this stuff.   There's no substitute for hands-on experiance.

The L298 has a staggered pinout but with care the legs can be bent slightly to fit it to matrix board.  Do the high current stuff (L298, 4 external catch diodes per channel, current sense resistor, filter chokes and capacitor), soldered on matrix board, then you can do the current sense amp and  control logic on solderless breadboard.  Stick an Arduino Nano^* on the breadboard to provide PWMs and drive the direction inputs.  You've got it right when you can set two different speeds via the PWMs for the two H-bridges in the L298, powering the two halves of the loop, and the loco goes round it with the speed changing at the isolation gaps without any drama like hot chips or magi8c smoke release., and shorting the track with a screwdriver  stops it and lights an error light, with no damge, so one button press later it starts again.

* The Nano's not essential, but its easier than breadboarding a bunch of switches and 2 555 timers to provide the PWMs.  Use a Nano clone because its dirt cheap, breadboardable and 5V

@ TomS_
The idea was to get away from the large relay tree or relay matrix for cost and reliability reasons.   Also, IMHO, having a layout that sounds like a 1950's telephone exchange is not so cool!

I'll see if the local electronics shops have the parts - here in Australia they are all useless and I will probably have to order it online.

[Ian.M]

Don't forget a heatsink for the L298.  It does have over-temperature protection, but its better not to rely on that as if the chip's already boiling hot, it has less safety margin for peak current etc.   An old CPU heatsink should do nicely as it only has to dump 20W worst case for both channels hard on @2A load current.

You'll need about 14V to the L298 as it will drop around 2V.  Trim the PWM duty cycle to limit the max average voltage at the track to 12V running one loco.

For the final build, try to scrounge up a real brute of a used heatsink for free or dirt cheap.  You ideally want one big enough to mount eight L298 chips to, to give you some spare capacity for future expansion.

[TomS_]

@ TomS_
The idea was to get away from the large relay tree or relay matrix for cost and reliability reasons.   Also, IMHO, having a layout that sounds like a 1950's telephone exchange is not so cool!

Thats a fair point. 

[ilium007]

For the logic, you'll need half a 74x74 for the flipflop and 1/4 of a quad AND gate.

I'm assuming I should be sticking with the 74HCxxx IC's ?

[Ian.M]

Should be, but for breadboarding one, it doesn't really matter if you use 74LS with its higher power consumption or 74HCT with its poorer noise immunity.   Just avoid original 7400 and high speed parts like 74AS or 74AC.

For the AND, there's no problem (except slightly worse propagation delay) with using half a quad NAND with the second gate to de-invert the first gate's output.

You may need a tiny bit of low pass filtering on the current sense OPAMP so turn-on transients cant immediately trip the current limit.  Don't over-do it or it will overshoot the set current limit.

[ilium007]

One more question tonight, what’s the fastest I can PWM the L298’s ? I’ve been running the MC33926 at 20kHz and don’t get any motor noise.

[Ian.M]

The datasheet says the L298 can commutate at up to 40KHz although 25KHz is typical.  If it can commutate that fast it can PWM via enable at the same frequency. However for high PWM frequencies you'll need Schottky catch diodes (at least 1A) to shunt the motor current when the bridge is Hi-Z.  Low frequency PWM can get away with Silicon catch diodes, though Schottkys are preferable.

N.B. the turn-off and turn-on delays are asymmetric so don't slam from forward to reverse without going through a stop mode in between or shoot-through may damage it.

[ilium007]

The datasheet says the L298 can commutate at up to 40KHz although 25KHz is typical.  If it can commutate that fast it can PWM via enable at the same frequency. However for high PWM frequencies you'll need Schottky catch diodes (at least 1A) to shunt the motor current when the bridge is Hi-Z.

N.B. the turn-off and turn-on delays are asymmetric so don't slam from forward to reverse without going through a stop mode in between or shoot-through may damage it.

Ok. Thanks again.

[rrinker]

 Buncha observations, from the point of view of a fellow model railroader. I'm building my own signal/detection/control system, though my layout is DCC. I looked into various bus systems and decided I did not want to deal with the complexity of things like CAN - so I am using RS485 with the CMRI protocol. Yes it is single master - inputs are read by polling the controller to see the current state, not by the input pushing data to the master. This works just fine, and is plenty fast enough - even on some REALLY huge model railroads. The protocol is dead simple - and I'm taking a few shortcuts so that some of the ID and config packets are not needed, by making each of my nodes identical (in software anyway - I am not populating a PCB with 4x 16 bit output latches for a node that only needs 16 bits of output. However, the PCB and the software will accept 64 bits of data, just only the first 16 will actually appear on physical outputs for the smaller node.
 There is in this design something more complex than a micro as the master - it's a full blown PC. That software will be written in VB.
 In the original CMRI articles in Model Railroader magazine back in the mid 80's, there were two versions of loco control for standard DC locos (there was no DCC at the time, but there were some command control systems available). In one, the computer drove a set number of throttles, say 4, which had their outputs switched to various blocks as the trains moved about. You could also use user controlled throttles, with the computer and the CMRI nodes applying a given throttle's power to the appropriate blocks. Option 2 had a computer controlled throttle for each block, similar to the one design posted above. This allowed for both full computer automation or the user could run a simple 'throttle' device that fed in to the computer which then applied power to the blocks as needed.
 Note that the power is not applied to the next block at the moment the train crosses the block boundary - this happens well before the train gets there. You do not operate trains without at least a one block separation. If a train is in block 1, the system should already determine that block 2 ahead of it is clear and assigned power to that train's throttle. If the block ahead is occupied, then the train is stopped - well before the electrical boundary. There should be no issues with one truck (bogie) being across the gap and the other behind it, passing power via the loco's internal wiring.
 The data protocol is open - you would have to make your nodes correspond to known designs if you want to use commercial (well, written by others) control software, or you can do what you like and write your own (as I am doing). There is an Arduino-based node available commercially, the code is open and the schematics are published - I am altering that design to use the SPI version of the IO Expander (MCP23S17 vs the commercial product's MCP23017 I2C version) and also fixing which chips are inputs and which are outputs (eliminates the config packets in CMRI). For actual point movement, I have a separate design that I posted here previously that has both control input from the node as well as local pushbuttons, the button lockouts being active low so that if I don't turn on the master computer and the control nodes, I can run trains by myself and just use the local buttons to line the points. Mine drive a servo, but it could be adapted to a stall motor or solenoid. It also drives a relay to switch power to each frog for maximum reliability.

[ilium007]

Buncha observations, from the point of view of a fellow model railroader. I'm building my own signal/detection/control system, though my layout is DCC. I looked into various bus systems and decided I did not want to deal with the complexity of things like CAN - so I am using RS485 with the CMRI protocol. Yes it is single master - inputs are read by polling the controller to see the current state, not by the input pushing data to the master. This works just fine, and is plenty fast enough - even on some REALLY huge model railroads. The protocol is dead simple - and I'm taking a few shortcuts so that some of the ID and config packets are not needed, by making each of my nodes identical (in software anyway - I am not populating a PCB with 4x 16 bit output latches for a node that only needs 16 bits of output. However, the PCB and the software will accept 64 bits of data, just only the first 16 will actually appear on physical outputs for the smaller node.
 There is in this design something more complex than a micro as the master - it's a full blown PC. That software will be written in VB.
 In the original CMRI articles in Model Railroader magazine back in the mid 80's, there were two versions of loco control for standard DC locos (there was no DCC at the time, but there were some command control systems available). In one, the computer drove a set number of throttles, say 4, which had their outputs switched to various blocks as the trains moved about. You could also use user controlled throttles, with the computer and the CMRI nodes applying a given throttle's power to the appropriate blocks. Option 2 had a computer controlled throttle for each block, similar to the one design posted above. This allowed for both full computer automation or the user could run a simple 'throttle' device that fed in to the computer which then applied power to the blocks as needed.
 Note that the power is not applied to the next block at the moment the train crosses the block boundary - this happens well before the train gets there. You do not operate trains without at least a one block separation. If a train is in block 1, the system should already determine that block 2 ahead of it is clear and assigned power to that train's throttle. If the block ahead is occupied, then the train is stopped - well before the electrical boundary. There should be no issues with one truck (bogie) being across the gap and the other behind it, passing power via the loco's internal wiring.
 The data protocol is open - you would have to make your nodes correspond to known designs if you want to use commercial (well, written by others) control software, or you can do what you like and write your own (as I am doing). There is an Arduino-based node available commercially, the code is open and the schematics are published - I am altering that design to use the SPI version of the IO Expander (MCP23S17 vs the commercial product's MCP23017 I2C version) and also fixing which chips are inputs and which are outputs (eliminates the config packets in CMRI). For actual point movement, I have a separate design that I posted here previously that has both control input from the node as well as local pushbuttons, the button lockouts being active low so that if I don't turn on the master computer and the control nodes, I can run trains by myself and just use the local buttons to line the points. Mine drive a servo, but it could be adapted to a stall motor or solenoid. It also drives a relay to switch power to each frog for maximum reliability.

Thanks for the detailed reply ! I’ll take a look at CMRI although I’m pretty certain I’ll go down the CANbus path as I can use the same protocol and design in later projects I have planned.

There is an Arduino-based node available commercially, the code is open and the schematics are published

Do you have the name of this ?

[rrinker]

 Yes, the commercial Arduino-based CMRI node is called cpNode from Model Railroad Control Systems

http://www.modelrailroadcontrolsystems.com/cpnode/

 They have a bunch of other interesting things as well, including equipment to do RFID.

[ilium007]

Thanks. They are the same ones I found when I went searching.

[C]

Think you might want to look at some LED drivers/
WWS2801
https://cdn-shop.adafruit.com/datasheets/WS2801.pdf
On amazon you can get these in strips or and single connected by wires
There are others
SK6822 WS2813 APA102 SK9822

Track blocks
With no motor controller on engine you could use a lot of blocks.
lan.M
has suggested motor controllers with current sense.

Three or more blocks in series lets you tell what block and what direction train is moving on block crossing.
A test loop could have large number of blocks
ABCABCABC

You could know that a engine is in B but not which B.

If you add a block D the computer could then tell you what block of the B blocks the engine is in after passing through D.

Think of the rules
  More then one engine in same block get same power & motor controller has to supply all.

  Move from block to UN-powered block.
  Move from block to like powered block.

Do not move from one block to different powered block.

With more blocks letters and a good time schedule you could have many engines on a loop.

You could have a dumb control system that learns from just driving a engine around track.
  At this PWM this block it X long. You have now measured length of most blocks.
 You have tested track sensors and found order.

Using CAN bus you can time sink all attached devices.
Simple sink gets you to one packet time difference.

For some things you can treat what is happening on track as an AC signal that is floating.

[ilium007]

I was looking through H-Bridge data sheets (thats my pastime at the moment !) and came across a different H-Bridge that seems rather simple compared to the others I had been looking at. While I'm happy to build the L298 based design and now basically understand the OPAMP / comparator / logic circuit required I found the TI DRV8870 seems to have the OPAMP / comparator built in - http://www.ti.com/lit/ds/symlink/drv8870.pdf.

The DRV8870 device is a brushed-DC motor driver
for printers, appliances, industrial equipment, and
other small machines. Two logic inputs control the Hbridge
driver, which consists of four N-channel
MOSFETs that can control motors bidirectionally with
up to 3.6-A peak current. The inputs can be pulsewidth
modulated (PWM) to control motor speed, using
a choice of current-decay modes. Setting both inputs
low enters a low-power sleep mode.

Plenty of current for my needs.

The DRV8870 device features integrated current
regulation, based on the analog input VREF and the
voltage on the ISEN pin, which is proportional to
motor current through an external sense resistor. The
ability to limit current to a known level can
significantly reduce the system power requirements
and bulk capacitance needed to maintain stable
voltage, especially for motor startup and stall
conditions.
The device is fully protected from faults and short
circuits, including undervoltage (UVLO), overcurrent
(OCP), and overtemperature (TSD). When the fault
condition is removed, the device automatically
resumes normal operation.

From reading the data sheet I can design a current trip point based simply on the sizing of the sense resistor.

Is there any advantage / disadvantage to using something like this vs. the L298 ? I know its in a HSOP package which I can get around with a reflow heat plate which I was going to experiment with anyway.

[Ian.M]

Its nice but its not safe to parallel them as will happen when the loco crosses an isolation break, again because its too smart.

See section 7.3.3 - if its in current regulation mode at the moment the wheel reaches the break, there's a risk of the next segment's driver having an upper MOSFET on while the current segment has both lower ones on, resulting in severe over-current and oit tripping its internal protection circuit.

You could get away with using it as a dumb H-bridge with short-circuit protection by grounding its Isense pin (avoiding the above issue), but it still has the disadvantage that you need to apply the speed control PWM to different pins for forward and reverse.

Its advantage is that the MOSFET output transistors it uses will have much lower voltage drip than the bipolars in the L298, so it needs less heatsinking, and the DC bus can be closer to 12v (lower) and still get 12V out, so it *may* be worth the pain of adding external high side current sensing or even true floating load current sensing + external logic for early PWM pulse termination for current control.

[ilium007]

You could get away with using it as a dumb H-bridge with short-circuit protection by grounding its Isense pin (avoiding the above issue), but it still has the disadvantage that you need to apply the speed control PWM to different pins for forward and reverse.

I did think about that, it would be a matter of reconfiguring the PWM pin on motor reversal and setting the other pin as digital LOW - I don't think its a big deal.

Are you saying by taking I_sense to GND it will do its own short circuit protection (is that what they are calling OCP) ?

Still happy to go with the L298 design but I thought this new IC looked pretty good !

[Ian.M]

It does have protection against a hard short - its datasheet claims a 3.6A limit, followed by tripping and auto-restarting 3ms later to see if the short's still present,

However its going to be a PITA to work with - either it needs a lot of PCB area to get rid of heat, or you need to either use an aluminum substrate PCB, or you need lots of thermal vias and the back of the PCB clamped to a heatsink with a silpad in between.   I hope you've got a hot-air rework station with a board preheater - you'll need it.

Its the usual issue - modern H-bridges don't come in hobbyist friendly packages, (which is why Polulu et al can make good money selling them on breakout boards) and doing maintenance on a board with an array of them clamped to a heatsink will be a real PITA - you have to first remove umpteen clamping screws, pry the board off the silpads hopefully without flexing it enough to crack any parts, pre-heat the whole board to replace one, and don't dare run it till its fully cooled off and any compressed or torn silpads have been replaced, and *ALL* the clamping screws are back in and tightened.  If you want to avoid that aggro you'll basically end up creating your own breakout board for it so you can undo a couple of screws and desolder the pins individually like you would to to replace a L298

[C]

There are some aliexpress.com modules based on

bts7960
http://www.robotpower.com/downloads/BTS7960_v1.1_2004-12-07.pdf

might work

[ilium007]

I'll have a look at designs but I'm not using breakout boards. I am going to build something to suit the purposes I require (even if I have to 'lean' on some other designs I find !)

[Ian.M]

I'm just saying that a monolithic board with  16x DRV8870 or similar SMD motor drivers on it will be an assembly and  maintenance nightmare.    Some stuff is best made modular, for ease of both construction and maintenance.  The pricing structure for nearly all PCB manufacturers that support small volume prototyping also favours a modular design, keeping individual board size down and board reuse up.

[C]

BTS 7960B
P-TO-263-7
BTS 7960P
P-TO-220-7

A TO-22o with 7 leads
A half-bridge so you need two

[Ian.M]

Nice chip, but its gone obsolete.  Fortunately there is a replacement with only a slight change in specs - BTN7960P, however even that is apparently NRND.

Its got the same sort of current limiting as the other modern H-bridges or half bridges we've looked at but as its nominally good for 47A, in this specific application paralleling them briefly via LC low pass filters for the loco to cross an isolation gap should be OK.  The track wiring will probably melt first, and its short-circit protection should handle the conflict if the over-current protection did get tripped.  However it certainly isn't suitable for hard paralleling in other applications,

It is going to need an external current limit comparator and gating circuit to avoid welding the train wheel to the isolation gap if a software fault lets a train attempt to proceed onto a section currently being driven with opposite polarity.

Its also not particularly cheap, (especially as this application will need 2x per segment vs half a L293) though you get a *LOT* of drive for your money, and the fact its an individual  half bridge makes a lot of sense for PWMed single ended drive applications or for three phase brushless motors etc.

[C]

Some one must have a few or there are clones.

Amazon has boards also.

Search for modules had h-bridge module under $10 on aliexpress and 11-22 on amazon and this is with heat sink.

Searching Aliexpress, some other chips are also used.
 
just thinking out loud so to speak.

Engine should move into an UN-powered block or a block with matching power inputs.  With engine using all wheels on a side you have a transfer of load for that length of time.
With a large number of blocks, control system should be able to prevent worse case which would look like a power rail to power rail short, but to chips an output to power rail that is said to be protected or output to output short.

Just wondering if three phase chips should be looked at. Two three phase chips could give 6 blocks for a section/. Could know position and direction of engine movement.
Would have to allow each half-bridge to be controlled and three current sense would be nice.

I would just get a few per-built modules. Test one then get more.

[ilium007]

I learning a lot out of the content of this thread - don't stop !

I can't believe that this "train goes from one track to another under two seperate PWM drivers" has never been done before but I simply cannot find anything on the internet about others running in to the same problem.

Likewise I can't find any OPAMP/comparator/logic circuits based around the L298. I understand the circuit from Ian.M's description, its just the supporting circuit such as the low pass filtering - I have no idea why I need low pass filters.

[Ian.M]

A large leading edge current spike is very common when PWMing a load.
See fig 2. at https://www.powersystemsdesign.com/articles/flyback-power-supply-development-part-iv/38/6602
Although it is NOT an H-bridge circuit, you will get similar issues with the L298 H-bridge low side current sensing.

The waveform is composed of a massive leading edge spike due to the discharge of the junction capacitance of the reverse biassed diode in parallel with the switching transistor (body diode for MOSFETs, or external catch diode for BJTs) superimposed on the typical inductive current ramp-up.   The raw signal (a) is unusable for current limiting as the spike will immediately trip the limiter.   After proper filtering, you get waveform (c) which is satisfactory for current limiting.  Waveform (b) is the bogus results you get if you use a scope probe with a normal length ground clip lead - the nearby current spike through the sense resistor inductively couples to the clip lead well enough to still swamp the signal.  See photo to the right of waveform (c) with the scope probe grounded by a loop of wire directly soldered to the ground plane, adjacent to the point being probed.

The magnitude and duration of the spike depends on the actual circuit and the slew rate of the H-bridge output.  You need to do some tests to determine an appropriate time constant for the sense waveform RC filter.   

Fancier chips have leading edge blanking on their current sense output - the internal current sense circuit is momentarily disconnected from the sense resistor when the control signal turns the transistor on.  You could add that externally with a fast CMOS analog switch and a circuit to generate a brief pulse to switch it at the PWM leading edge, but that's a lot of extra complexity for each driver board, and a RC low pass filter with an appropriate time constant is good enough.

[ilium007]

I don't have a scope so it is going to be next to impossible for me to progress on this design.

[Ian.M]

It will be difficult without a 10MHz or better bandwidth scope, but not impossible.
A lot of calculation and simulation will be involved, to get the design right the first time instead of 'suck it and see' experimentation.

Also a lot more detailed testing will need to be done e.g. test a L298 with a resistive load at DC to set up the current sense circuit, and the over-current comparator, then PWM it look at the delay between the PWM rising edge and the comparator tripping by converting the PWM signal and current limit flip-flop outputs to DC voltages by low pass filtering.   If the resistive load is under the limit, the flipflop output should stay high. If it trips due to the leading edge spike its output will be low nearly all the time.   Fiddle with the filtering till it doesn't trip on the leading edge.   Then add an inductor in series with the load resistor.  You know the current must ramp up, so you can now see if the current limit setpoint can shorten the PWM pulse from the gating circuit the way it is supposed to.   If that's all behaving as expected, set a safe current limit (go back to DC to do so) then try just the inductor as a load.   

It will probably take something like ten times longer without a scope and if something unexpected happens, it will be much harder to debug.   Perhaps you should consider getting a scope - I certainly wouldn't want to start a big project involving sensors, motor drives and serial comms without one.   If you cant afford a scope, you must be so close to living hand-to-mouth, that you really shouldn't be wasting money on electronics projects.

[rrinker]

 A train moving from one block to another under different PWM sources happens all the time when you cross booster block boundaries with DCC. Granted, it's not the motor drive power, at least not directly, but the two booster outputs are each a variable width squarer wave signal which is the propulsion voltage plus digital data stream for DCC. It's key that there is a common between the boosters, and both rails are gapped. This then becomes seamless, even when using the type of loco that picks up from one rail by the drivers and the other rail by the tender, in case of a steam loco, or in the older style diesels where the front truck picks up from one rail and the other picks up from the rear truck only. When such locos cross the gaps, you end up with one rail signal coming from booster A and the other half of the signal coming from Booster B. With a common between them, there is no voltage double effect and the loco just glides through. I don;t see why this would be any different if the signal were actually a PWM output connected directly to the loco motor.
 I'd have to go back and look at it, I'm not sure what Bruce Chubb's computer throttle design did for the actual throttles, it wasn't a PWM design but I'm not so sure it was a filtered DC either.
 I'll point you to something else as well, that pre-dated DCC. Ed Ravenscroft's MZL control. This was a non command control (thus no modifications or boards in the locos) system where the 'engineer' only had to wacth signals and control his train speed and direction. None fo that silly toggle switch flipping to assign blocks, power was automatically assigned to a clear block ahead based on the route selected at each turnout. Plenty of contacts and relays, but no active electronics. It didn't automate the movement of trains, it merely automated the "assign power to the correct block" task which was the most non-prototypical aspect of previous cab control systems. By computerizing the relay logic aspect, it could be made into a more automated running system. That's more or less what the Chubb Computer Cab Control (CCC) did - the computer automatically assigns power to the block, the person running the train just has to run the train and obey signals. It's almost all the capabilities of DCC without the decoder in each loco. One possible advantage over DCC - you can;t play Gomez Addams and have to trains hit head on. IN an eastbound train gets into the block of a westbound coming right at it, one of the two will reverse direction.

[Old Don]

I've been following this thread for some time and I've got to say you're putting a great deal of time into it and I hope you solve the problems.

An observation, once you are done you'll have a system that nobody else will be compatible with unless they modify there equipment to run on your track. So over here in the USA a lot of NMRA members visit with each other and bring their own equipment to run on the visiting rail line. That's why DCC has become the norm for our equipment. Warts and all. Locomotive DCC boards are all compatible, but controllers coming along from visitors have to match the DCC system used or they can't be used.

[ilium007]

I've been following this thread for some time and I've got to say you're putting a great deal of time into it and I hope you solve the problems.

An observation, once you are done you'll have a system that nobody else will be compatible with unless they modify there equipment to run on your track. So over here in the USA a lot of NMRA members visit with each other and bring their own equipment to run on the visiting rail line. That's why DCC has become the norm for our equipment. Warts and all. Locomotive DCC boards are all compatible, but controllers coming along from visitors have to match the DCC system used or they can't be used.

I have read about this being a 'thing to do' in the USA, probably here in Australia as well but Dad's train layout will stay firmly planted in his 'train room' !

[Old Don]

    I've been converting my 40+ year old stuff to DCC and finding ways to keep magic smoke stay in the boards has been a challenge at times. Darn shorts to chassis seem to find ways of sneaking up on me. 

[Ian.M]

Actually, *most* of the hardware discussed in this thread would be compatible with running locos equipped with DCC decoders, and even mixing them with multiple 'dumb' locos.

Simply up the track voltage to 15V, disconnect the -L+C+L- filtering between the H-Bridge outputs and the track, and instead of a PWM signal, supply a logic level DCC signal to the H-bridge driving any track segment currently occupied by a DCC loco.   The H-bridges' over-current protection will also need to be fast enough to cope without the fllters.

There will need to be some tweaks to the normal PWM to keep the average voltage down to 12V for 'dumb' locos, and as DCC is fairly fast (116us for a complete '1' bit and 200us for a complete unstretched '0' bit), either the MCU will need to be fast enough to update the PWM period and duty cycle on a cycle by cycle basis to modulate it with the DCC bitstream, or it will need some hardware assistance generating the DCC signal.

Also the 'dumb' locos will run  little hotter due to the unfiltered PWM (or DC imbalanced DCC signal if they are on the same segment as a DCC equipped loco), and there will be more EMI.