¿ªÔÆÌåÓý

Locked Decoder template replacement #definitions


 

There are occasions when I want to change he decoder template within DecoderPro, e.g. a new decoder definition template has been created that is the correct template for a decoder already fitted using another template, a decoder has been replaced and it is wished to retain the loco meta data.

?

Presently this requires a new loco to be created in DecoderPro using the correct, updated or new decoder template and re-entering the meta data which isn¡¯t onerous however a potentially nugatory step ¨C especially if the new decoder template is being applied to many locos.

?

The situation doesn¡¯t arise often, but it does happen where a incorrect template is used as DecoderPro hasn¡¯t had a template created and a few releases later the correct template is available. It happens regularly that a decoder is replaced and cutting and pasting all the non-decoder data can lead to errors.

?

Is it possible to create a way to replace the decoder template without having to create a new loco? It may be that the decoder template is replaced by a blank template of the new decoder that requires the values to be read from the existing decoder, and that would be an acceptable solution.

Iain? Morrison


 

Interesting question.

If one updates the DEFINITION file? and then opens the ROSTER entry? and requests a READ ALL (CV TAB)? does DecoderPro use the NEW definition file as the template
or does he simply go by what is currently in the? ROSTER entry.

Marc


 

I would expect it to read all the CVs from the decoder into the new template.

An example would be that I have some locos that shows as having MX618 decoders fitted as that is what was available when the were created but they actually have MX617N and I would like to use the correct decoder. My idea would be that the old data recorded from the MX618 would be lost and a new template for the MX617N added and that this would be populated by undertaking a Read All Sheets command.

This would then mean I have the correct chipset identified and I would retain the loco metadata that has been used previously.

Makes sense?

Iain


 

If you update a decoder definition and then ¡°Read All¡±, it¡¯ll read the new variable definitions, i.e. CVs, and save those values.

There is no way to convert a roster entry saved with one decoder definition into using a different decoder definition. The roster entries (you can look at one) save both variable _and_ CV values. There¡¯s no way to reasonably disentangle those and map them onto a different decoder definition.

Just make a new roster entry and then read-all. The ¡°read all¡± part of creating a new definition takes no longer than any possible ¡°read all¡± of with an updated definition, so there¡¯s not even really anything to gain.

Bob



On Jan 1, 2020, at 1:45 PM, Iain Morrison <w.iain.morrison@...> wrote:

I would expect it to read all the CVs from the decoder into the new template.

An example would be that I have some locos that shows as having MX618 decoders fitted as that is what was available when the were created but they actually have MX617N and I would like to use the correct decoder. My idea would be that the old data recorded from the MX618 would be lost and a new template for the MX617N added and that this would be populated by undertaking a Read All Sheets command.

This would then mean I have the correct chipset identified and I would retain the loco metadata that has been used previously.

Makes sense?
--
Bob Jacobsen
rgj1927@...


 

On Wed, Jan 1, 2020 at 02:45 PM, Iain Morrison wrote:


I would expect it to read all the CVs from the decoder into the new template.

An example would be that I have some locos that shows as having MX618 decoders
fitted as that is what was available when the were created but they actually
have MX617N and I would like to use the correct decoder. My idea would be that
the old data recorded from the MX618 would be lost and a new template for the
MX617N added and that this would be populated by undertaking a Read All Sheets
command.

This would then mean I have the correct chipset identified and I would retain
the loco metadata that has been used previously.

Makes sense?

Iain
What you are suggesting isn't really any different than the existing creating a new loco file and reading all sheets.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -


 

Apart from retaining all the fields that are not part of the decoder definition. e.g. images, loco details, etc ...


 

No, Iain is asking for something different to "new decoder, read all sheets".

In the XML file for a roster entry, there are user-editable fields, such as "loco name" "description" "road number", etc.. which are not copied, except by hand.
And elements like "throttle images", and throttle settings (such as function key latching/non-latching).


I think it should be do-able.

- Nigel

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Ulvestad
Sent: 01 January 2020 22:32
To: [email protected]
Subject: Re: [jmriusers] Decoder template replacement #decoderpro

On Wed, Jan 1, 2020 at 02:45 PM, Iain Morrison wrote:


I would expect it to read all the CVs from the decoder into the new template.

An example would be that I have some locos that shows as having MX618 decoders
fitted as that is what was available when the were created but they actually
have MX617N and I would like to use the correct decoder. My idea would be that
the old data recorded from the MX618 would be lost and a new template for the
MX617N added and that this would be populated by undertaking a Read All Sheets
command.

This would then mean I have the correct chipset identified and I would retain
the loco metadata that has been used previously.

Makes sense?

Iain
What you are suggesting isn't really any different than the existing creating a new loco file and reading all sheets.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -


 

An outside script could read from old file, and 'update' a new file with data from the original (name, number,? known CVs). This wouldn't catch CVS that where not in the original. The worst-case scenario would be something like a basic decoder definition with just names, and? CVs 1-20? while the new definition includes indexed CVs.

A JMRI option to swap between definitions, which then read the unknown CVS could be nice, though how valuable it is, when you can read all sheets on a new definition, only having to re-enter the? hunman-entered data again...


.


On Wed, Jan 1, 2020 at 10:40 PM Nigel Cliffe <nigel.cliffe@...> wrote:
No, Iain is asking for something different to "new decoder, read all sheets".

In the XML file for a roster entry, there are user-editable fields, such as "loco name" "description" "road number",? etc..? which are not copied, except by hand.
And elements like "throttle images", and throttle settings (such as function key? latching/non-latching).?


I think it should be do-able.? ?

- Nigel



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Ulvestad
Sent: 01 January 2020 22:32
To: [email protected]
Subject: Re: [jmriusers] Decoder template replacement #decoderpro

On Wed, Jan? 1, 2020 at 02:45 PM, Iain Morrison wrote:

>
> I would expect it to read all the CVs from the decoder into the new template.
>
> An example would be that I have some locos that shows as having MX618 decoders
> fitted as that is what was available when the were created but they actually
> have MX617N and I would like to use the correct decoder. My idea would be that
> the old data recorded from the MX618 would be lost and a new template for the
> MX617N added and that this would be populated by undertaking a Read All Sheets
> command.
>
> This would then mean I have the correct chipset identified and I would retain
> the loco metadata that has been used previously.
>
> Makes sense?
>
> Iain
>

What you are suggesting isn't really any different than the existing creating a new loco file and reading all sheets.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -