You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking into doing different types of signal aspects (eg, in DB - because I live in Germany, signals are RED (double-red), AMBER (amber-green), and GREEN (green)). I had hoped to look at UK too, but the extra double-amber aspect is a bit too big of a change to do - so let's ignore that one for now.
I don't yet have the trains or the signals to test this (I'm just getting into this, but I come more from the software and control systems side than the scenery-building), but I had a look at the RMFT2::doSignal() (EXRAIL2.cpp), and I think that the LED section ends up much cleaner with a sort of LED aspect "map". Given the int16_t for the signal flags, there was only space to add one more flag, so I settled on a main aspect map to 3 LEDs and an alternate, with new EXRAIL macros for SIGNALA and SIGNALAH to use the alternate map. This could also allow shunt signals, I guess.
Interestingly, using an aspect to pin map also makes the code easier to follow (at least from my point of view), because the red/green simulated amber can be handled there, as can the high-inversion of SIGNALH (and the new SIGNALAH).
As I say, this is not yet tested, as I don't yet have all the starter bits for my modelling (including the arduino), but I wanted to share and see if this was the kind of thing anyone else was interested in, if it's the right kind of style (I did clean up a few blank-space parts), and the contributing suggests to open an issue first.
The text was updated successfully, but these errors were encountered:
mb-m
added a commit
to mb-m/CommandStation-EX
that referenced
this issue
Oct 1, 2024
…#422)
Idea to use a map to control the pins set for the different signal aspects,
instead of just straight RED->redpin, AMBER->amberpin, GREEN->greenpin. There
is a main map which does this and then an alternate map which may do anything.
In the example, we use red -> amber/green -> green, which is the Deutsche Bahn
signalling resolution (where physical signals are used rather than in-cab).
This rewrites the LED section of the RMFT2::doSignal(), making it use the
aspect map for even the features of merging red and green together for amber
and the high-is-off setting. It adds 2 new automations: SIGNALA and SIGNALAH
to allow the use of the alternate maps.
I was looking into doing different types of signal aspects (eg, in DB - because I live in Germany, signals are RED (double-red), AMBER (amber-green), and GREEN (green)). I had hoped to look at UK too, but the extra double-amber aspect is a bit too big of a change to do - so let's ignore that one for now.
I don't yet have the trains or the signals to test this (I'm just getting into this, but I come more from the software and control systems side than the scenery-building), but I had a look at the RMFT2::doSignal() (EXRAIL2.cpp), and I think that the LED section ends up much cleaner with a sort of LED aspect "map". Given the int16_t for the signal flags, there was only space to add one more flag, so I settled on a main aspect map to 3 LEDs and an alternate, with new EXRAIL macros for SIGNALA and SIGNALAH to use the alternate map. This could also allow shunt signals, I guess.
Interestingly, using an aspect to pin map also makes the code easier to follow (at least from my point of view), because the red/green simulated amber can be handled there, as can the high-inversion of SIGNALH (and the new SIGNALAH).
As I say, this is not yet tested, as I don't yet have all the starter bits for my modelling (including the arduino), but I wanted to share and see if this was the kind of thing anyone else was interested in, if it's the right kind of style (I did clean up a few blank-space parts), and the contributing suggests to open an issue first.
The text was updated successfully, but these errors were encountered: