Topics

What does JMRI actually do with Sensor PullUp/PullDown setting?


JerryG
 

I'm working on an update to the Sensor Table help documents (https://www.jmri.org/help/en/package/jmri/jmrit/beantable/SensorTable.shtml and related) to add missing column and action info.  Can someone please tell me what JMRI uses the Pull-up/Pull-down setting for?  I'd like to be able to tell the users if and when they need to set this.  Current Help is somewhat non-explanatory:

"This tab lets you set whether your hardware has a puul-up [SIC] or pull-down resistor installed over the Sensor input." (from https://www.jmri.org/help/en/package/jmri/jmrit/beantable/SensorAddEdit.shtml#pullup)

Does it matter to JMRI whether your sensor input has a pull-up or pull-down resistor installed over it?  Does this change any JMRI actions?  I connect my sensors via an arduino which has pullup resistors installed, but that doesn't impact what I tell JMRI about the state of the sensor.  I don't know about how others set up their sensors.

Thanks, Jerry


Bob M.
 

Jerry,

Here are my opinions, and some technical considerations with respect to "pullup" and "pulldown" features:

- Such a setting can _only_ be effective if the associated hardware has software-controlled pullup/pulldown. It _does not apply_ for any hardware which does not have this capability. Arduino devices using Arduino pins to implement "sensors" may have this capability, while Arduino devices using some other data source (such as an I/O expander chip via I2C) may or may not have the capability.

- Some devices which may support "software-controlled pullup" may not support "software-controlled pulldown", and/or vice-versa.

- The typical _intention_ behind "pullup" or "pulldown" features is to provide a "default" state ("1" or "0", respectively) of a pin when it is not actively driven by some external source.

- The typical integrated circuit implementation of a "pullup" and/or "pulldown" may be "too weak" to effectively provide a default state for an input if there is "too much" wiring connected to that input, and/or if there is any source of "noise injection" into such wiring.

Trying to document these wildly-variable and "squishy" so-called details is an awkward task, at best, filled with general rules and significant exceptions. Documenting them for non-electrical-engineering-types is a daunting task!


It might be best to try to keep things simple (and fail miserably):

- A Pull-Up is intended to help an input achieve the "Active" level when the input is undriven by external hardware (assuming a non-inverting input).

- A Pull-Down is intended to help an input achieve the "Inactive" level when the input is undriven by external hardware (assuming a non-inverting input).

- Whether the input hardware implements an inversion is a separate question. If the hardware implementation of the input is "inverting", then the immediately-above two statements need their activity states inverted.

- Some hardware input implementations natively have a pull-up or pull-down feature which cannot be disabled.

- Software-controllable Pull-Up/Pull-Down only applies to certain hardware implementations. In the case of an implementation which does not support software-controlled Pull-up and/or Pull-down, the selection in JMRI of any such feature will have _no_ effect on the hardware and/or the sensor state.

- Pull-up/Pull-Down may not apply consistently across all of a given hardware implementation. Some inputs may not have any Pull-Up or Pull-Down capabilities, while some inputs may have "fixed" Pull-Up or Pull-Down features, while other inputs may have fully-programmable Pull-Up and/or Pull-Down behavior.

- An un-driven, long, wire connected to a typical integrated circuit input can introduce so much noise to the input pin that a Pull-Up or Pull-Down cannot actually guarantee a given state.

- An un-driven, long, wire connected to a typical integrated circuit input, with or without a Pull-Up or Pull-Down, can introduce so much noise to the input pin that it can cause malfunction of the integrated circuit or attached circuitry.

Perhaps it might be worthwhile to include a specific list of hardware _known_ to have Pull-Up/Pull-Down which may be controlled via this JMRI feature. Exactly which hardware that includes, I am unsure, but I believe that the feature was first added when Arduino "connections" were added.

Exactly how to describe the Pull-Up and Pull-Down features of any such device, on a pin-by-pin basis, is also unclear. It may need to be left to description by the hardware vendor or someone who gives technical support of those products. I would guess that such a list would be _outrageously_ complex for Arduino boards with their huge variety of "shields".

Regards,
Bob M.


dick bronson
 

Bob,

This sounds to me like a misguided attempt to do something in the JMRI tables that belongs in the hardware itself, or else in a configuration file. From your description below it has three known features:

a) It usually can not work.
b) It introduces confusion by adding a new option that seems like something important where none existed before. (proof of this is that the OP started this thread in the first place)
c) It clutters up the sensor table options for everyone when it actually belongs someplace else. IMHO Each added check box means that some percentage of potential users will say "Its too complicated and I can't learn complicated things anymore." This option is especially egregious because it doesn't give you the ability to do anything, but it gives you false information. For example all of our LCC nodes have built in pull up resistors, but if I check the 'Show' box then it states that they have 'No Pull-up/Pull-down' which is clearly incorrect and misleading information. Foul ball!

Maybe the best option is to figure out who added it and why, and if there is not any good reason for it to be in the sensor table, then remove it and/or put it where it belongs ASAP before it causes more issues.

Dick :)

On 9/7/2020 4:11 PM, Bob M. wrote:
Jerry,

Here are my opinions, and some technical considerations with respect to "pullup" and "pulldown" features:

- Such a setting can _only_ be effective if the associated hardware has software-controlled pullup/pulldown. It _does not apply_ for any hardware which does not have this capability. Arduino devices using Arduino pins to implement "sensors" may have this capability, while Arduino devices using some other data source (such as an I/O expander chip via I2C) may or may not have the capability.

- Some devices which may support "software-controlled pullup" may not support "software-controlled pulldown", and/or vice-versa.

- The typical _intention_ behind "pullup" or "pulldown" features is to provide a "default" state ("1" or "0", respectively) of a pin when it is not actively driven by some external source.

- The typical integrated circuit implementation of a "pullup" and/or "pulldown" may be "too weak" to effectively provide a default state for an input if there is "too much" wiring connected to that input, and/or if there is any source of "noise injection" into such wiring.

Trying to document these wildly-variable and "squishy" so-called details is an awkward task, at best, filled with general rules and significant exceptions. Documenting them for non-electrical-engineering-types is a daunting task!


It might be best to try to keep things simple (and fail miserably):

- A Pull-Up is intended to help an input achieve the "Active" level when the input is undriven by external hardware (assuming a non-inverting input).

- A Pull-Down is intended to help an input achieve the "Inactive" level when the input is undriven by external hardware (assuming a non-inverting input).

- Whether the input hardware implements an inversion is a separate question. If the hardware implementation of the input is "inverting", then the immediately-above two statements need their activity states inverted.

- Some hardware input implementations natively have a pull-up or pull-down feature which cannot be disabled.

- Software-controllable Pull-Up/Pull-Down only applies to certain hardware implementations. In the case of an implementation which does not support software-controlled Pull-up and/or Pull-down, the selection in JMRI of any such feature will have _no_ effect on the hardware and/or the sensor state.

- Pull-up/Pull-Down may not apply consistently across all of a given hardware implementation. Some inputs may not have any Pull-Up or Pull-Down capabilities, while some inputs may have "fixed" Pull-Up or Pull-Down features, while other inputs may have fully-programmable Pull-Up and/or Pull-Down behavior.

- An un-driven, long, wire connected to a typical integrated circuit input can introduce so much noise to the input pin that a Pull-Up or Pull-Down cannot actually guarantee a given state.

- An un-driven, long, wire connected to a typical integrated circuit input, with or without a Pull-Up or Pull-Down, can introduce so much noise to the input pin that it can cause malfunction of the integrated circuit or attached circuitry.

Perhaps it might be worthwhile to include a specific list of hardware _known_ to have Pull-Up/Pull-Down which may be controlled via this JMRI feature. Exactly which hardware that includes, I am unsure, but I believe that the feature was first added when Arduino "connections" were added.

Exactly how to describe the Pull-Up and Pull-Down features of any such device, on a pin-by-pin basis, is also unclear. It may need to be left to description by the hardware vendor or someone who gives technical support of those products. I would guess that such a list would be _outrageously_ complex for Arduino boards with their huge variety of "shields".

Regards,
Bob M.




Bob M.
 

Dick (and Jerry),

If I recall correctly, this feature was added to the Sensors Table some time shortly after native Arduino connections were added. My vague recollection was that Paul Bender was directly involved, but I could be wrong. The feature was added at the specific request of a specific user, for configuring the Atmel-processor-internal pullup/pulldown on individual Arduino pins (or perhaps it was configuration of individual pulls on I/O expander devices on an I/O shield; I don't remember the details!).
bo
What does JMRI implement? It appears that the JMRI feature was made available to _all_ connection types, by default. It appears that it may be _disabled_ at the connection level, by the related sensor manager, via the isPullResistanceConfigurable method. The isPullResistanceConfigurable method is referenced in:
- managers/AbstractSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/ProxySensorManager.java: public boolean isPullResistanceConfigurable(){
- jmrix/pi/RaspberryPiSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/configurexml/AbstractSensorManagerConfigXML.java: if (sm.isPullResistanceConfigurable()) {
- jmrit/beantable/sensor/SensorTableDataModel.java: return (senManager.isPullResistanceConfigurable());
- jmrix/ieee802154/xbee/XBeeSensorManager.java: public boolean isPullResistanceConfigurable(){

Examination of the concrete implementations shows that the ieee802154/xbee implementation and the pi implementation both make use of the feature. I do not see any signs of other implementations which make use of the generic Sensor "pullup/pulldown" features.

How does JMRI behave for a Sensor on a connection which does NOT support the feature? The column can appear if the "Show Pull-Up/Down Information" checkbox is checked, but the settings show up as "No Pull-Up/Pull-Down" and cannot be changed. If you "Edit" a sensor, a tab shows up for "Pull-Up/Down", and a setting on that sheet _can_ be changed, although the changed value does _not_ appear to "stick". At least this is true with 4.21.1 and a simulated LocoNet connection.

In my opinion, JMRI's generic, connection-agnostic documentation should say "see your specific hardware information". And individual connection documentation should describe what, if anything, the connection implementation will do with those settings. Individual connection documentation should be responsible for describing any "gotchas" which could occur when using any such pullup or pulldown.

I will take an action to add some text to the LocoNet documentation:
- to specifically state that no JMRI Sensor implemented via LocoNet hardware will be affected in any way by a Sensor Table "pullup/pulldown" setting
- that any such LocoNet hardware feature must be configured, if possible, via a LocoNet-device-specific setting

Regards,
Billybob


JerryG
 

BiilyBob (Bob M), Dick, and others  - 

Thanks so much.  Interesting where my novice-level investigation of JMRI Help leads...

As such, I'm trying to write for the JMRI Help - somewhat for beginners - and am trying to be mindful of comments in the recent user survey (see the JMRI Users Group topic #178277) about pushing the complexity to the background.  Does what I have below sum it up from the point of view of what to put in the Sensor Table help?  If our use of PullUp/PullDown is changed in the future, we can change the documentation, but for now it should document how it currently works. 

This appears in the text of the actual Sensor Table Edit window:

"Some system types allow the user to choose whether sensor inputs are pulled down (low) or pulled up (high) or neither.
On these systems, set this drop down to match the attached hardware."

So I would basically clarify that and add a little more for the Help page:

"Some sensor hardware allows the user to choose whether sensor inputs are pulled down (low) or pulled up (high) or neither.
If you are using such a system, select Edit to set this field to match the attached hardware.  JMRI may take action based on particular hardware and that should be documented in help pages for that hardware.  The default selection is “No Pull-up/Pull-down."“

At least that should remove some of the mystery of this column.

Thanks again, Jerry



 


dick bronson
 

Bob,

If there is actually a legitimate reason to be in the Sensor Table, then it should have been added with the defaults as disabled, not enabled. Poor design choice. The proper place for the solution is in the code, not in you trying to document around it.

Back when the LocoNet OPs mode read was disabled (optionally) whoever did that was careful to go into the decoder files that do allow OPS mode read (like ours) and enable them. (by adding the enable option into our decoder files)

I would expect better of Paul, especially if this change was requested by one user, but winds up impacting everyone else negatively. More especially when it amounts to a hardware option selection which IMHO has no place in the sensor table in the first place. That is what configuration files are for. (CDI or CVs in decoder files)

Dick :)

On 9/7/2020 5:47 PM, Bob M. wrote:
Dick (and Jerry),

If I recall correctly, this feature was added to the Sensors Table some time shortly after native Arduino connections were added. My vague recollection was that Paul Bender was directly involved, but I could be wrong. The feature was added at the specific request of a specific user, for configuring the Atmel-processor-internal pullup/pulldown on individual Arduino pins (or perhaps it was configuration of individual pulls on I/O expander devices on an I/O shield; I don't remember the details!).
bo
What does JMRI implement? It appears that the JMRI feature was made available to _all_ connection types, by default. It appears that it may be _disabled_ at the connection level, by the related sensor manager, via the isPullResistanceConfigurable method. The isPullResistanceConfigurable method is referenced in:
- managers/AbstractSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/ProxySensorManager.java: public boolean isPullResistanceConfigurable(){
- jmrix/pi/RaspberryPiSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/configurexml/AbstractSensorManagerConfigXML.java: if (sm.isPullResistanceConfigurable()) {
- jmrit/beantable/sensor/SensorTableDataModel.java: return (senManager.isPullResistanceConfigurable());
- jmrix/ieee802154/xbee/XBeeSensorManager.java: public boolean isPullResistanceConfigurable(){

Examination of the concrete implementations shows that the ieee802154/xbee implementation and the pi implementation both make use of the feature. I do not see any signs of other implementations which make use of the generic Sensor "pullup/pulldown" features.

How does JMRI behave for a Sensor on a connection which does NOT support the feature? The column can appear if the "Show Pull-Up/Down Information" checkbox is checked, but the settings show up as "No Pull-Up/Pull-Down" and cannot be changed. If you "Edit" a sensor, a tab shows up for "Pull-Up/Down", and a setting on that sheet _can_ be changed, although the changed value does _not_ appear to "stick". At least this is true with 4.21.1 and a simulated LocoNet connection.

In my opinion, JMRI's generic, connection-agnostic documentation should say "see your specific hardware information". And individual connection documentation should describe what, if anything, the connection implementation will do with those settings. Individual connection documentation should be responsible for describing any "gotchas" which could occur when using any such pullup or pulldown.

I will take an action to add some text to the LocoNet documentation:
- to specifically state that no JMRI Sensor implemented via LocoNet hardware will be affected in any way by a Sensor Table "pullup/pulldown" setting
- that any such LocoNet hardware feature must be configured, if possible, via a LocoNet-device-specific setting

Regards,
Billybob




Bob M.
 

From the perspective of a novice, it would be possible to interpret "whether sensor inputs are pulled down (low) or pulled up (high) or neither" in many different ways:

- The setting could be seen as if an input "pulled down (low)" would mean that the input would NEVER be anything other than "low", and as if an input "pulled up (high)" would mean that the input would NEVER be anything other than "high", so the only acceptable way would be "NEVER" if the user wants to ever see changes on the Sensor;

- The setting could be seen as "if I am driving the input with a signal which goes low to indicate that it is active, then I want 'pulled down (low)'", and "if I am driving the input with a signal which goes high to indicate that it is active, then I want 'pulled up (high)', and I don't know what "neither" means.

From the perspective of an electrical engineer, pullups and pulldowns are primarily used to determine "the default state of an input when it is otherwise undriven". Such "pulls" are "weak" relative to the input signal, such that the input signal, when present, overpowers the "pull". Perhaps something along these lines could be included early in any discussion of pullups/pulldowns.

Regards,
Bob M.


Bob M.
 

Dick,

The "Pull-up/Down" feature _IS_ disabled by default, and only two connection types actually enable it.

The nature of JMRI is such that certain system-specific behaviors can become exposed to users of other systems in ways that are not easily handled. This is one of those cases.

I would have preferred that these features be handled in system-specific code, akin to how C/MRI tends to handle its output-specific features (i.e. "momentary" versus static, and number of outputs used by the JMRI Turnout object. And I would have preferred that the implementation not display those options for connection configurations where they don't apply. For whatever reason, that is not how it is realized in the current implementation.

Regards,
Bob M.

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of dick bronson via groups.io
Sent: Monday, September 07, 2020 8:07 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] What does JMRI actually do with Sensor PullUp/PullDown setting?

Bob,

If there is actually a legitimate reason to be in the Sensor Table, then
it should have been added with the defaults as disabled, not enabled.
Poor design choice. The proper place for the solution is in the code,
not in you trying to document around it.

Back when the LocoNet OPs mode read was disabled (optionally) whoever
did that was careful to go into the decoder files that do allow OPS mode
read (like ours) and enable them. (by adding the enable option into our
decoder files)

I would expect better of Paul, especially if this change was requested
by one user, but winds up impacting everyone else negatively. More
especially when it amounts to a hardware option selection which IMHO has
no place in the sensor table in the first place. That is what
configuration files are for. (CDI or CVs in decoder files)

Dick :)

On 9/7/2020 5:47 PM, Bob M. wrote:
Dick (and Jerry),

If I recall correctly, this feature was added to the Sensors Table some time shortly after native Arduino connections were added. My vague recollection was that Paul Bender was directly involved, but I could be wrong. The feature was added at the specific request of a specific user, for configuring the Atmel-processor-internal pullup/pulldown on individual Arduino pins (or perhaps it was configuration of individual pulls on I/O expander devices on an I/O shield; I don't remember the details!).
bo
What does JMRI implement? It appears that the JMRI feature was made available to _all_ connection types, by default. It appears that it may be _disabled_ at the connection level, by the related sensor manager, via the isPullResistanceConfigurable method. The isPullResistanceConfigurable method is referenced in:
- managers/AbstractSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/ProxySensorManager.java: public boolean isPullResistanceConfigurable(){
- jmrix/pi/RaspberryPiSensorManager.java: public boolean isPullResistanceConfigurable(){
- managers/configurexml/AbstractSensorManagerConfigXML.java: if (sm.isPullResistanceConfigurable()) {
- jmrit/beantable/sensor/SensorTableDataModel.java: return (senManager.isPullResistanceConfigurable());
- jmrix/ieee802154/xbee/XBeeSensorManager.java: public boolean isPullResistanceConfigurable(){

Examination of the concrete implementations shows that the ieee802154/xbee implementation and the pi implementation both make use of the feature. I do not see any signs of other implementations which make use of the generic Sensor "pullup/pulldown" features.

How does JMRI behave for a Sensor on a connection which does NOT support the feature? The column can appear if the "Show Pull-Up/Down Information" checkbox is checked, but the settings show up as "No Pull-Up/Pull-Down" and cannot be changed. If you "Edit" a sensor, a tab shows up for "Pull-Up/Down", and a setting on that sheet _can_ be changed, although the changed value does _not_ appear to "stick". At least this is true with 4.21.1 and a simulated LocoNet connection.

In my opinion, JMRI's generic, connection-agnostic documentation should say "see your specific hardware information". And individual connection documentation should describe what, if anything, the connection implementation will do with those settings. Individual connection documentation should be responsible for describing any "gotchas" which could occur when using any such pullup or pulldown.

I will take an action to add some text to the LocoNet documentation:
- to specifically state that no JMRI Sensor implemented via LocoNet hardware will be affected in any way by a Sensor Table "pullup/pulldown" setting
- that any such LocoNet hardware feature must be configured, if possible, via a LocoNet-device-specific setting

Regards,
Billybob





Ken Cameron
 

I see these along the same line as the CMRI node configuration options.
There you have things you can set within the node, but this is done as a
node configurator, not within the sensor or turnout table. Might some of
those options better fit being viewed from the sensors and turnouts, some
users may find that more focused.

Yes the Arduino and Xbee have the options to configure those aspects of the
hardware. I would say this should only show when you have those system
connections and only on the objects that are part of those systems and not
others.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Ken Cameron
 

Jerry,

I think you should review similar features of other systems and find that
there is a category of options in the tables that only exist for a few
specific systems. An example of these 'extra' features would be with LCC,
there are two options, one for 'authoritative' and 'always listen'. From my
view those and the pull up/down are both 'system specific columns' and
should be lumped together.

In the help, I'd put these together towards the end of the section as most
systems and users will never see them or use them. I mean they shouldn't be
part of the main path of educating users. Think of it more as an elective
course or maybe a summer workshop type content.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Paul Bender
 

On Sep 7, 2020, at 5:47 PM, Bob M. <jawhugrps@...> wrote:
If I recall correctly, this feature was added to the Sensors Table some time shortly after native Arduino connections were added. My vague recollection was that Paul Bender was directly involved, but I could be wrong.
It was added specifically for RaspberryPi GPIO and XBee IO pins when used for sensors. In both cases, the hardware connected to those pins is custom, and some people choose to use active high logic and others choose to use active low logic.

Paul


Paul Bender
 

Sent from my iPad
On Sep 7, 2020, at 8:26 PM, Bob M. <jawhugrps@...> wrote:
I would have preferred that these features be handled in system-specific code, akin to how C/MRI tends to handle its output-specific features (i.e. "momentary" versus static, and number of outputs used by the JMRI Turnout object.
The way the C/MRI Turnouts ask for System specific options is by display of JOptionPanes directly by the C/MRI turnout manager. I have two problems with that A) That process doesn’t work in a headless environment, and it should. B) to the best of my knowledge, there is no way to change those selections without deleting the turnout and recreating it.

The reality is that there is are GUI elements in code that shouldn’t have GUI elements in the C/MRI turnout manager code, but nobody has ever seen it as a big enough issue to fix it. This is not the example we should be using for how non-universal options should be configured.

Adding the pull up/down information to the sensor table allows initial setting of the values along with reconfiguration without the dialogs in the manager. We have other options that don’t always apply displayed this way as well ( turnout locks being one example ).

Paul


Paul Bender
 

On Sep 7, 2020, at 8:06 PM, dick bronson via groups.io <dick=rr-cirkits.com@groups.io> wrote:
If there is actually a legitimate reason to be in the Sensor Table, then it should have been added with the defaults as disabled, not enabled. Poor design choice. The proper place for the solution is in the code, not in you trying to document around it.
That actually was the way it was originally written. It may show up on the “ALL” tab, but for system specific tabs, it should only display if it is meaningful. Even on the “ALL” tab, it should be disabled unless there is a system configured where use is possible... but I would have to dig to find out if that is the case, and that is not high on my priority list.

I would expect better of Paul, especially if this change was requested by one user, but winds up impacting everyone else negatively. More especially when it amounts to a hardware option selection which IMHO has no place in the sensor table in the first place. That is what configuration files are for. (CDI or CVs in decoder files)
As for why this is in the sensor table and not elsewhere:
1) There isn’t always a place to store this information in the hardware itself. You certainly can’t store the pull-up/down settings on a RaspberryPi, or at least not in any way I have discovered.
2) It functions in many ways like invert, but it is inverting the sense of the hardware, rather than the logical output of the sensor. Specifically, If you have this set incorrectly for the connected hardware, the sensor values may never change.

Taking those two points together makes this layout specific configuration information.

In other words, I should be able to configure my hardware on one RaspberryPi and then reconnect the hardware to a different RaspberryPi and get the same result with the same panel file.

Paul


Steve_G
 

On Mon, Sep 7, 2020 at 11:07 PM, Paul Bender wrote:
The way the C/MRI Turnouts ask for System specific options is by display of JOptionPanes directly by the C/MRI turnout manager.
Olcb and loconet use getKnownBeanProperties if that's any help.
Steve G.


Balazs Racz
 

Maybe a relatively simple improvement would be to not even render the "show pullup/pulldown column" checkbox in the bottom when the current connection does not implement it. Then in the All tab figure out if any connection implements this feature and if none do then hide the checkbox altogether.

This will effectively make the complexity disappear until you go and use an arduino or raspberry pi connection, where you actually do need the feature and we can also assume that you are more of a tinkerer.

Balazs


Andrew Crosland
 

Does selecting a pull-up also enable inverting of the input that is, presumably, active-low (otherwise, why pull-up by default)?

Andrew

------ Original Message ------
From: "Balazs Racz" <balazs.racz@...>
Sent: 08/09/2020 09:38:01
Subject: Re: [jmri-developers] What does JMRI actually do with Sensor PullUp/PullDown setting?

Maybe a relatively simple improvement would be to not even render the "show pullup/pulldown column" checkbox in the bottom when the current connection does not implement it. Then in the All tab figure out if any connection implements this feature and if none do then hide the checkbox altogether.

This will effectively make the complexity disappear until you go and use an arduino or raspberry pi connection, where you actually do need the feature and we can also assume that you are more of a tinkerer.

Balazs

--
Andrew Crosland


Bob M.
 

Andrew,

Generally, inversion is a separate concept from pullup/pulldown:

- "Pull"s relate to how the input is driven by the driver, and are generally needed _only_ if the driver is not always driving to a valid level

- Inversion relates to the "sense" of the signal - does a "High" input mean "Active" or does a "Low" input mean "Active".

Tying the two concepts together in any way would prevent proper system action for certain possible applications.

Regards,
Bob M.


Bob M.
 

All

LocoNet's use of getKnownBeanProperties (for connection-specific Turnout properties) gives one trivial but _specific_ advantage when compared to the Sensor (system-non-specific) implementation of "Pull-Up/Down":

- The checkbox for "show system-specific columns" _does_ show up on the Turnouts table for the "All" and "LocoNet" tabs, but _not_ on the "Internal" tab, because of the system-specific implementation of the LocoNet Turnout features.

- The checkbox for "Show Pull-Up/Down Information" shows up on every Sensors table tab, because of its system-agnositc Sensor implementation.

Both implementations share the "problem" that the associated checkboxes _will_ show up on the "All" tab, and the columns will show up when the checkbox is checked. And both implementations share the "problem" where all entries in those columns _will_ be filled with control objects, but where a specific object type does not support the feature, the control object in the feature column will be _disabled_.

As such, there isn't much user-level difference between, or benefit from, a system-specific implementation over an object-generic implementation.

But it does emphasize the "flaw" of both implementations, in that the "Table" GUI representation displays information for an object which _cannot_ be configured and which is likely to confuse at least some users.

Getting back to the original issue of "help" documentation: If the beantable (or Data Model?) implementation could be changed to hide the non-applicable controls instead of disabling them, it would lead to a better user experience, and would be easier to document. In such a case, the system-agnostic documentation could be something as simple as "see system-specific documentation".

Regards,
Bob M.


Ken Cameron
 

I get a feeling that some properties in the CMRI node configurator might
serve the users better if they were part of the tables. There may be other
systems out there that may also utilize this concept.

I think the key right now is the table is showing the checkbox and columns
even when the option isn't available for the current system connections.
That is confusing to users. My thought is the checkbox selector and columns
should not show in the system specific tab if that system doesn't support
it. The checkbox and columns should not show on the All tab if none of the
current system connections support it.

That would make sense to the users. I suspect something changed in the main
tables and this checking got broke. It seems the checkbox shows all the time
and if checked, you get the columns and it seems they act like they can do
something. Worse it seems to remember if they had been displayed and return
when you restart JMRI, even though it shows the checkbox as not selected.

I just brought up a LocoNet profile and I see the checkbox and if I click
it, I get a column with a selector box, granted only selection is no-pull
up/no pull down. I think a blank would be less confusing for the users.
There is a pull-up/pull-down tab if you edit a sensor. Again, I think that
should only be there if the system supported the feature.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Bob Jacobsen
 

I wanted to see exactly how this works at HEAD of master.

If you start a LocoNet-type connection and look at the sensor table, you don’t see a pull-up column:


You do see a checkbox that will show it (see arrow).  When you check that box, a column appears:

The LocoNet sensors show “No Pull-up/Pull-down” and no other choice is available.  That seems completely reasonable to me.

Interestingly, the debounce information is showing in both cases for me, even though the box is not checked (red? arrow). If I check the box and then uncheck it, those columns disappear; they stay gone.

From this I conclude there’s a confusing bug:  If one of the boxes is checked at shutdown, that state is remembered (OK) and controls the display next time (OK), but the box is not checked next time (Not OK, as it’s confusing)

That same bug seems to be present for Show Pull-up/Down Information and Show State Query actions checkboxes.

Bob