Each device (no matter if actuator or input) would report its status continously (repeated in short but not too short intervals).
So one could attach or power on any device any time later and it'll sync automatically to the whole system status.
That makes sense... So if each device transmitted its status every, say, 1 second (speed isn't really critical when it's just continuous updating), or instantly if there's a change in status, then eventually everything would be updated. As for startup, if I simply programmed each module to send a status on startup, but with a delay unique to each module - for example module 1 transmitted after 1ms, module 2 after 2ms etc. - then I'd eventually have all the statuses after starting up.
You'll have to think about CAN bus addressing, since CAN addresses are limited and each packet has a maximum payload of 8 bytes, and what to do if there's more than 8 bytes to transmit. My approach is to split larger data into a series of packets with the first (or first two) byte as an index and the rest 6 or 7 bytes representing the data structure at the offset pointed to by the first (first two) bytes. Maybe you won't need that as I believe your payload data is mostly just a few bits for an actuator or input device.
Aye, 8 bytes is more than enough. Each command packet will be 2 bytes as far as I can work out - one address byte for each device (point, signal, track circuit) followed by a status - for track circuits that's obviously just a bitvalue, but signals could contain multiple states. In the future I could always expand on this by adding an additional address byte, and an additional data byte - but I doubt I'll ever reach 8 bytes, let alone exceed it.
Status packets will be a bit different... But again, 8 bytes will be more than enough.
Sent from my ONEPLUS A3003 using Tapatalk