Topics

Configuration of CV using decimals and units

Alain LM
 

Hi All,

I'm trying to fix the decoder definition for Kuehn decoders that has been broken by a previous user when it comes to CV55.
Actually this CV definition is very special in the sense that it works with decimal values instead of bit values; there are two separate information on this CV, but instead of being split between low bits (0-3) and high bits (4-7), the interpretation of the CV relies on its decimal value, i.e. unit values xN (with N=0-7)) and decimal values Nx (with N=0-9).
Of course for the first one, easy to do with bits 0-2, but for the second one I have no clue how to do.

Any suggestion?
--
Alain LM

Alain LM
 

Hum not even simple for the first part (unit). My bad.
For the time being I'm going to allow all decimal values withing the possible range, with a tooltip explaining how to do. So it will remain confusing for the users not to have two separate fields for two different information.
--
Alain LM

Nigel Cliffe
 

That is the solution used elsewhere on other decoders. 

 

Most Zimo decoders have similar CV’s.   And I don’t think they are the only manufacturer with this issue. 

The “units” in a decimal number do one thing, and the “tens” and “hundreds” do other things.    The solution is either a tooltip or some text on the pane to explain it.

 

This isn’t that bad for user experience.  If the input box and supporting text uses the same terms as the manufacturer’s documentation, this is a help for the end user.  

 

 

Nigel

 

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Alain LM
Sent: 23 December 2018 11:50
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Configuration of CV using decimals and units

 

Hum not even simple for the first part (unit). My bad.
For the time being I'm going to allow all decimal values withing the possible range, with a tooltip explaining how to do. So it will remain confusing for the users not to have two separate fields for two different information.
--
Alain LM

Bob Jacobsen
 

Is this common enough that it’s worth creating a special variable type?

To put it another way, if I write one, will people use it?

Bob

On Dec 23, 2018, at 7:30 AM, Nigel Cliffe <nigel.cliffe@...> wrote:

That is the solution used elsewhere on other decoders.

Most Zimo decoders have similar CV’s. And I don’t think they are the only manufacturer with this issue.

The “units” in a decimal number do one thing, and the “tens” and “hundreds” do other things. The solution is either a tooltip or some text on the pane to explain it.

This isn’t that bad for user experience. If the input box and supporting text uses the same terms as the manufacturer’s documentation, this is a help for the

Nigel
--
Bob Jacobsen
@BobJacobsen

Nigel Cliffe
 

Worthwhile if it's not a massive amount of coding effort. And an explanation of how to use the new variable in a decoder file.

To adopt it on existing decoders would require editing a large number of decoder files, many of them with variables scattered on (now) strange choices of panes, custom display panes, and the like. Those would have been pragmatic solutions when written and are then reused on newer decoders from the same makers. The ones I'm familiar with would benefit from a significant re-write to reduce the number of files, and improve the appearance to users. But there is then an issue of how to ensure it doesn't break things for existing roster entries.


- Nigel

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: 23 December 2018 13:58
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Configuration of CV using decimals and units

Is this common enough that it’s worth creating a special variable type?

To put it another way, if I write one, will people use it?

Bob

On Dec 23, 2018, at 7:30 AM, Nigel Cliffe <nigel.cliffe@...> wrote:

That is the solution used elsewhere on other decoders.

Most Zimo decoders have similar CV’s. And I don’t think they are the only manufacturer with this issue.

The “units” in a decimal number do one thing, and the “tens” and “hundreds” do other things. The solution is either a tooltip or some text on the pane to explain it.

This isn’t that bad for user experience. If the input box and supporting text uses the same terms as the manufacturer’s documentation, this is a help for the

Nigel
--
Bob Jacobsen
@BobJacobsen

Alain LM
 

First time I see this, but I've never worked on Zimo files. I did not pay attention when I reworked the Kuehn files some years ago, but after a careful re-reading of the documentation, this is the way it is.
Actually I have just committed a change where I explain how it works it in the tooltip; the variable is however used for two purposes, which is not the way JMRI usually displays information (should be a 'no-brainer'). I guess the previous developer was confused as well, as neither his implementation not my previous one were actually OK. It is obviously more natural for users to understand than doing binary calculations on groups of bits...

But well if this is not an isolated case, well yes it is worth creating a special variable for it. I'm probably unable to code it, but I can contribute in testing it and implementing it where it should in the definition files.

Also similarly to what exists for splitval, a multiplier value (factor) on such variables could be of help : I had the case on a Märklin decoder which I could not resolve on a single variable (factor only works for splitval). But this is a disjoint requirement from the preceding.
--
Alain LM

Bob Jacobsen
 

Oops.

I just realized that I may be working on the wrong thing, sorry.

Do you need this to handle multi-digit BCD values, i.e. “23" stored as 2*16+3 = 0x23?

Or do you just need single-digit decimal values that are laid out in the CV as powers of 10?

What I’m working on is a generic masking that allows you to say e.g. for two decimal digit fields: “The first variable can be 0-9 and starts with value 0 in the CV; the second variable can be 0-9 and starts at value 10 in the CV; the third can be 0-1 and starts with value 100 in the CV”

That isn’t enough for true BCD. But is it that enough for those decoders (i.e. for now)?

Bob

On Dec 23, 2018, at 8:15 AM, Nigel Cliffe <nigel.cliffe@...> wrote:

Worthwhile if it's not a massive amount of coding effort. And an explanation of how to use the new variable in a decoder file.

To adopt it on existing decoders would require editing a large number of decoder files, many of them with variables scattered on (now) strange choices of panes, custom display panes, and the like. Those would have been pragmatic solutions when written and are then reused on newer decoders from the same makers. The ones I'm familiar with would benefit from a significant re-write to reduce the number of files, and improve the appearance to users. But there is then an issue of how to ensure it doesn't break things for existing roster entries.


- Nigel


-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: 23 December 2018 13:58
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Configuration of CV using decimals and units

Is this common enough that it’s worth creating a special variable type?

To put it another way, if I write one, will people use it?

Bob

On Dec 23, 2018, at 7:30 AM, Nigel Cliffe <nigel.cliffe@...> wrote:

That is the solution used elsewhere on other decoders.

Most Zimo decoders have similar CV’s. And I don’t think they are the only manufacturer with this issue.

The “units” in a decimal number do one thing, and the “tens” and “hundreds” do other things. The solution is either a tooltip or some text on the pane to explain it.

This isn’t that bad for user experience. If the input box and supporting text uses the same terms as the manufacturer’s documentation, this is a help for the

Nigel
--
Bob Jacobsen
@BobJacobsen








--
Bob Jacobsen
@BobJacobsen