Keyboard Shortcuts
Likes
Search
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. |
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:-- Bob Jacobsen rgj1927@... |
On Wed, Jan 1, 2020 at 02:45 PM, Iain Morrison wrote:
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 - |
No, Iain is asking for something different to "new decoder, read all sheets".
toggle quoted message
Show quoted text
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: 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". |