FrightRisk
commented
3 years ago The output code interestingly has more options already. Those could be implemented into sensors. Since we are already using iFlags for outputs, why not use them for sensors? It is more complicated to explain I understand, but it is consistent:
IFLAG, bit 0: 0 = forward operation (ACTIVE=HIGH / INACTIVE=LOW) 1 = inverted operation (ACTIVE=LOW / INACTIVE=HIGH)
IFLAG, bit 1: 0 = state of pin restored on power-up to either ACTIVE or INACTIVE depending on state before power-down. 1 = state of pin set on power-up, or when first created, to either ACTIVE of INACTIVE depending on IFLAG, bit 2
IFLAG, bit 2: 0 = state of pin set to INACTIVE upon power-up or when first created 1 = state of pin set to ACTIVE upon power-up or when first created
This accounts for restoring the state of an output on power up. That is not necessary for sensors AFAIK. Technically the polling checks for a state change high to low or low to high (and a transistor feeding off the emitter or collector can invert that anyway) But it is true that the software would have to know which tranistion is the one you want. I love all the expanded capabilities!
Asbelos
We already have the facility to define a sensor essentially as a single pin test. This has a few limitations, for example:
By extending the < S > command we could improve the range of sensor connection possibilities :
< S id PIN pinno [PULLUP] [INVERT] > < S id I2CPIN pinno [PULLUP] [INVERT] > < S id ANALOG pinno triggerval [INVERT]> < S id LCN >
Original command retained for compatibility so < S 5 20 1> is equivalent to < S 5 PIN 20 PULLUP >
Automatic polling of sensors should only be enabled when it is certain that JMRI (or similar) is operating the automation externally... RMFT will effectively switch this off.