Designing model train layout I/O and PWM speed control

[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.