开云体育

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

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 -

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@...

JMRI does _not_ go to the web automatically to pick these. If you want to manually install files, you need to go get the ones you need: The top one, and all the other ones it includes, and perhaps ones that they include, etc.

This certainly could be made smarter. If the machine is attached to the network, somebody could write some code to figure out which how to get files that are web-accessible like these.

But there are interesting Catch-22s:

- People who don’t want to update JMRI to get new decoder definitions will hesitate to update JMRI to get a new way of getting decoder definitions either. So it’ll take a long time for this to be useful

- JMRI code and schema files, etc also advance, so some new files won’t work with old versions, particularly really old versions.

- The people with the oldest versions are most likely to need the most significant updates

- JMRI doesn’t (currently) have a mechanism to clearly say “This file is too new for this version of the program”. Having the _data_ to make that reliable is actually a lot of work, and volunteer decoder-definition developers are more likely to tell people “just update, you’ll have to eventually” rather than put in that time.

The “install new decoder file” was built for people sharing their own definitions, not as a way of updating JMRI.

There’s been some recent discussions of how to make a total JMRI update easier, particularly on light systems like Raspberry Pis.

Bob

On Jan 1, 2020, at 1:32 PM, forfoum@... wrote:

I have a question. Looking at the DEFINTION file, I see this (example)

<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">
<xi:include href=">

Does JMRI go on web and capture these files if they are not present or not current on the system.. ( I know they reside in C:\Program Files\JMRI\XML\DECODER\digitrax folder )

--
Bob Jacobsen
rgj1927@...

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

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 have a question.?? Looking at the DEFINTION file, I see this? (example)

<xi:include href="http://jmri.org/xml/decoders/nmra/decoderLockId16.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/nmra/consistAddrDirection.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/cv21.22.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/cv29NDOT.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/nmra/cv29speedSteps.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/cv29analog.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/nmra/cv29table3-28.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/functionmap.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/fxCVs.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/cv54.xml"/>
????? <xi:include href="http://jmri.org/xml/decoders/digitrax/bemf.xml"/>

Does JMRI go on web and capture these files if they are not present or not current on the system..? ( I know they reside in C:\Program Files\JMRI\XML\DECODER\digitrax?? folder )

Marc

On Wed, Jan 1, 2020 at 12:36 PM, Brian Jackson wrote:

On the subject of the slipturnouticon? not being supported is this with WiThrottle?

No, the issue is not with WiThrottle. It is with the client-side panel feature of the JMRI web server. The WiThrottle app simply provides a convenient way to reach it.

On Wed, Jan 1, 2020 at 12:36 PM, Brian Jackson wrote:

My last panel for the old layout used this also but with slightly different icons and worked ok when I last used it.

My guess is that you were using an older version of JMRI that defaulted to the older frameserver, not the newer panelserver. The default was changed a couple of versions ago. You can reenable the frameserver in Preferences. This may be a useful workaround for you.

--SteveT

Bob,

I treid this using? :

I go to the JMRI.org repository and do a right click on the file in question and? " COPY link location "
Go to DecoderPro, Import Decoder URL and can not PASTE via the MOUSE right-hand- mouse-button...? If I use CTRL+ V,? the string is pasted to the URL field

IF I go to any other APP and " PASTE "? the same string? via right-hand-button-of-mouse,? it is functional.? Within WIn10 the paste via mouse is operational.?

When I try and paste via mouse JMRI uses JAVA as I see a small JAVA icon in the task.? Example is ? Import Roster Entry. It opens but does not accept the mouse paste but does accept CTRL+V..
There is a small JAVA icon at top right corner of window by the way.

But I wonder if this " import Decoder URL " is even relevant any more since it does not take into account the constructs or fragment files at all.?
Why would people use it ?

Marc

Hi Steve

I've added a zip file for the icons.

I never thought about that as i always kept a backup of the icon folder.

I will look to move it in the future.

On the subject of the slipturnouticon? not being supported is this with WiThrottle?

My last panel for the old layout used this also but with slightly different icons and worked ok when I last used it.? Must admit I haven't used WiThrottle for a few years so was suprised when they were missing from the new panel.

I have added a screen shot of the old panel

Regards

Brian

Thanks, Brian.
I will also need the contents of your "Brians trackwork" folder.
The issue is that the "slipturnouticon" you are using is not (yet) supported by the client-side panel code. I will create an issue to add that support and include your example.

Note: I see that you've placed that folder under your program folder. It should really be placed under your user files folder, or it could be removed when you upgrade JMRI.
--SteveT

Paul,
I put the script in the folder 'ahouse' in the 'Problemsbeingworkedon' folder. Script is SidingList.py.
Regards,
Allen

I seem to have it where the simple client is seeing the turnouts ok, but it
is replying with either the wrong sensor value or many times sensor unknown,
displaying a wrong name. Many times it looks like it was truncating the
sensor value but other times, I don't know what it was translating into a
value.

This is with 4.18, on Windows, with both JMRI running on the same box for
testing. The server side is using LocoNet simulator. Anyone have a clue on
this or willing to try reproducing?

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

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 – 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

Dave, both end up pointing at the same downloadable file. " WHQL Certified. Includes VCP and D2XX. "

D2XXX :


VCP :


Marc

I don't think that there's any code to connect layout objects by dragging endpoints (except for track segments).
You can only connect them by dragging the entire object (again, except for track segments).
If you make a turnout too small then trying to click an endpoint will click in its control circle instead. That may be what you're running into. Try turning on control circles (options menu -> turnouts) and maybe making them smaller.

BTW: I find resizing relative to center annoying… I'd much prefer the opposite anchor(s) stay stationary and only the point I'm dragging move. Thoughts?

I've also thought about add "real" units of measurement (inch, foot, yard, mile, mm, cm, km, etc.) such that maybe a pixel is 1/16 of an inch, minor grid marks are an inch and major grid marks are a foot (so 16 pixels to an inch (minor grid) and 12 minor grid to major grid). Or each pixel is a 1/10 of a meter, minor grid 1 meter, major grid 10 meters, etc.

I could add a (virtual) ruler to measure distances and coordinates could have real world units. Thoughts?

What URL are you trying?

Bob

On Jan 1, 2020, at 10:10 AM, Bob P <comm4rgp@...> wrote:

If you can’t copy and paste it (which would be a Windows issue, not a JMRI one), then try typing it in.<<<<
Tried typing out the entire URL, but then Decoder Pro indicated this was not a valid xml file.

--
Bob Jacobsen
rgj1927@...

Roger,

On 2 Jan 2020, at 3:29 AM, Ken Cameron <kcameron@...> wrote:

The point is many use a physical barrier, look up 'smash board', you'll get
an idea. The other is some use a 4PDT switch so there is a dead block
between the programming track and the rest of the layout. That way if a loco
was creeping, it would lose contact with the programming track before it
could bridge to the main track. Any connection between the main track power
and the programming track power will fail components. IE loss of magic
smoke.

<>
<>

Dave in Australia

Bob P,

On 2 Jan 2020, at 5:10 AM, Bob P <comm4rgp@...> wrote:

If you can’t copy and paste it (which would be a Windows issue, not a JMRI one), then try typing it in.<<<<
Tried typing out the entire URL, but then Decoder Pro indicated this was not a valid xml file.

I believe this is a repost of an earlier thread where you were attempting to get an old JMRI Version to accept a recent LokSound definition file.

Your answer is in the Decoder Pro message; this definition uses XML constructs or fragment file inclusions that are not available to your old JMRI version.

Dave in Australia

Marc,

On 2 Jan 2020, at 5:45 AM, forfoum@... wrote:

Since you have the cable use the D2XXX drivers (2.12.28) from this link :

The D2XX drivers are absolutely useless as far as JMRI is concerned - they communicate via a Windows DLL. JMRI needs a Virtual COM Port.

Bruce, you need the VCP drivers from:
<>

Dave in Australia