Changing decoder in DecoderPro

[WIMorrison]

Am I correct in thinking that if I change a decoder in a loco then the only way to reflect this in DecoderPro is to delete the old loco and create a new one? I can seem to find a way to keep the loco details and just change the decoder,

 

Clearly I need to set the decoder values up from scratch but it would nice to keep the meta data on the loco.

 

Ta

[Butler Henderson]

That's what I've always done. Can't see how else it could be changed as the loco data is linked to the decoder.

[Paul80]

That's the way I do it as well, it is probably possible so await a more knowlegable reply.

 

Paul

[Nigelcliffe]

Can be done by careful editing of XML files, most of the meta-data describing the loco is at the top of the file.   

Needs a text editor, Notepad at a push, or something better for code/text editing.

Create a new loco (so it's got the correct decoder data ), then copy over the data manually outside of JMRI.    But take care, its very easy to make a mess of XML files.

 

They're stored in "[username]/jmri/[optionally system connection name]/roster"  

 

( Don't be tempted to try to keep the decoder data if the loco has changed its decoder: that's a route to a mess or insanity )

 

- Nigel

Edited December 29, 2019 by Nigelcliffe

[peterfgf]

Not very helpful, but I've also not found a way to change the decoder in a loco that is already in Decoder Pro, I've always had to start again with "new loco / detect decoder".  

I keep a folder of photographs of the model and sometimes keep a text file of shed allocations to make re-entering data a little easier.  Hard-won experience suggests it is also a good thing to keep a spreadsheet of various tweaks or CV changes used with various decoders on some locomotives.  

Notepad is a basic text file editor but I've found TextPad to be a good alternative,

Peterfgf

[Steven B]

Notepad++ is a great, free, text editor which is much better than the standard Windows Notepad.

 

Being able to swap decoders without deleting or manually editing files is one of the biggest missing features in JMRI. 

 

Steven B

[Pete the Elaner]

3 hours ago, peterfgf said:

it is also a good thing to keep a spreadsheet of various tweaks or CV changes used with various decoders on some locomotives.  

Keeping a record of CVs is one of the things I use JMRI for: so I don't have to fiddle with spreadsheets.

Most CVs are held in the XML files. (I can't find the the pantograph tweaks for the class 90)..so I have moved these on to my NAS, which gets backed up.

 

JMRI talks to the decoder, not the loco. The decoder therefore holds its identity.

If you think of it that way, it follows that you must delete & re-create the entry if you swap out the decoder.

[peterfgf]

On 30/12/2019 at 08:57, Pete the Elaner said:

Keeping a record of CVs is one of the things I use JMRI for: so I don't have to fiddle with spreadsheets.

Most CVs are held in the XML files. (I can't find the the pantograph tweaks for the class 90)..so I have moved these on to my NAS, which gets backed up.

 

JMRI talks to the decoder, not the loco. The decoder therefore holds its identity.

If you think of it that way, it follows that you must delete & re-create the entry if you swap out the decoder.

Totally agree.  It's in the name: Decoder-Pro.

Peterfgf.

[melmerby]

On 30/12/2019 at 08:25, Steven B said:

Notepad++ is a great, free, text editor which is much better than the standard Windows Notepad.

 

Being able to swap decoders without deleting or manually editing files is one of the biggest missing features in JMRI. 

 

Steven B

If you are editing XML files how about XML Notepad?

e.g.

[WIMorrison]

 

On 30/12/2019 at 08:57, Pete the Elaner said:

Keeping a record of CVs is one of the things I use JMRI for: so I don't have to fiddle with spreadsheets.

Most CVs are held in the XML files. (I can't find the the pantograph tweaks for the class 90)..so I have moved these on to my NAS, which gets backed up.

 

JMRI talks to the decoder, not the loco. The decoder therefore holds its identity.

If you think of it that way, it follows that you must delete & re-create the entry if you swap out the decoder.

 

1 hour ago, peterfgf said:

Totally agree.  It's in the name: Decoder-Pro.

Peterfgf.

 

The decoder is only part of the locomotive definition, a major part of it but not the full definition. Indeed only 3 of the fields displayed on the DEcoderPro opening screen are related to the decoder, the other 10 provide information about the locomotive and are completely independent of the decoder. There are other fields within the definition filethat are not decoder related, rather locomotive related.

 

The identifier used by DecoderPro is the locomotive name which is linked to the address within the decoder. If the definition ONLY held detail on the decoder then your statements might be valid however the definition file held by DecoderPro is not limited as you suggest. You may only use the decoder information, but other uses the other data fields that are available and these will not change when a decoder is swapped. Even the xml file is named after the locomotive showing that the loco is the key, not the decoder.

 

There are also occasions when someone  would want to change a decoder and retain  all the settings that are recorded. An example of this is when a loco has been setup with an incorrect decoder because Decoder Pro did not have a definition file available that is provided by a later upgrade to the software - as happened in December last  year and the reason for my question., 

 

In essence the omission of the ability to change or swap a decoder would seem to be an omission from an otherwise very useful utility.

[Pete the Elaner]

1 hour ago, WIMorrison said:

The decoder is only part of the locomotive definition, a major part of it but not the full definition. Indeed only 3 of the fields displayed on the DEcoderPro opening screen are related to the decoder, the other 10 provide information about the locomotive and are completely independent of the decoder. There are other fields within the definition file that are not decoder related, rather locomotive related.

 

We are talking about freeware.

The people who wrote & update it could easily keep it within their own community.

They have no obligation to share or support it for others, but they choose to make it available to everybody.

 

I understand there is an online user group where you can get involved. I thought it was a yahoo group, but I can't find it.

Suggesting to somebody that they should change something tends to be upsetting. Asking to get involved so you can help to change something is a very different situation.

 

[melmerby]

32 minutes ago, Pete the Elaner said:

 

We are talking about freeware.

The people who wrote & update it could easily keep it within their own community.

They have no obligation to share or support it for others, but they choose to make it available to everybody.

 

I understand there is an online user group where you can get involved. I thought it was a yahoo group, but I can't find it.

Suggesting to somebody that they should change something tends to be upsetting. Asking to get involved so you can help to change something is a very different situation.

 

Here:

https://groups.io/g/jmriusers

[Nigelcliffe]

 

If swapping decoders is a feature wanted, then take the discussion to a place where someone who might consider implementing it will look at it - as Keith indicates, the JMRIUsers forum on Groups.IO, or if one of you is trying to implement it and getting stuck the jmri-developers list also on Groups.IO.

 

I think the non decoder data could be preserved in an "exchange decoder" operation, if what's wanted is an empty "default" set of CV values for the replacement decoder.  Which means the user still has the job of reading in and changing CVs in the new decoder.   
But if expecting to copy over any CV values (might just get away with address and CV29 settings), then the chances of a failure start to rise rather rapidly, making any utility unlikely to pass testing.  

 

 

- Nigel  

 

[WIMorrison]

53 minutes ago, Pete the Elaner said:

 

We are talking about freeware.

The people who wrote & update it could easily keep it within their own community.

They have no obligation to share or support it for others, but they choose to make it available to everybody.

 

I understand there is an online user group where you can get involved. I thought it was a yahoo group, but I can't find it.

Suggesting to somebody that they should change something tends to be upsetting. Asking to get involved so you can help to change something is a very different situation.

 

 

The JMRI suite, including DecoderPro, is Open Source, not Freeware (there are significant differences), and the ability to identify a shortcoming in a program isn't solely restricted to the development community.  Nor does it mean the shortcoming is only acceptable if you rectify the said shortcoming yourself.

 

Experience of open source software is, in fact, rather the opposite, as the development community has always been very appreciative of suggestions that have been made to improve the usability because they realise that they do not have all the use cases and that they are dependent upon the user community to provide these additional use cases.