I asked for a refund. They paid in funny money.

Marc

I am having difficulties with turnouts occasionally switching back and forth after being closed or thrown through JMRI. I am using a Digitrax DCS240 and DS64’s to control the Tortoises. It can happen on any turnout on any DS64. Usually occurs if I select the turnout after starting JMRI to see which way it is thrown and then hit it again to change it if it’s not aligned properly. Sometimes it will correct itself after several seconds but usually requires me to shut down JMRI. I then have full control through Digitrax throttles for the turnouts and the switching back and forth instantly stops. Is there a way to fix this? ?Also is there a way to read the turnout position and signal aspects when JMRI is started?
Bob

开云体育

I got the same AVG message. I sent an exception request and later got back a message saying all was o.k. I do not know if they propagated that into their data set updates, or not.

Peace,

Mike G.

?

Bob,

While you were able to get the legacy format working, I highly recommend you try using the new format as it provides an easier (modifiable) view of your roster and a way to make direct changes to the entries that don't change the decoder values (name, owner, manufacturer etc).

It wont take long to get use to the newer format if you give it a try.

--
Peter Ulvestad

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

开云体育

开云体育

Charles,

I've created an issue ( ), where you can track this.

Klaus


Am 25.09.2019 um 13:58 schrieb Charles Meo:

Bottom line, with the hardware (command station, decoders) that you have, you have to set the command station to default to 28 steps. See page 85 in the (current version) EasyDCC command station manual.

Bob

On Sep 24, 2019, at 10:40 AM, Don Weigt <dweigt47@...> wrote:

I have taken this problem as far as I can. I have duplicated Gerry's results.

I can control all my locos with the JMRI monitor "vthrottle" if I change it to 28 speed step mode from 128. But, I can't save that. Each time the loco is released and then selected again, it's back to 128 speed steps and can't control my loco until changed again to 28 speed steps.

Like Marc, I could find no way to change the WiThrottles to 28 speed steps, and they can't control my locos.

I would like JMRI throttles, including WiThrottles, to have the option to set and save each loco as 28 speed steps (and probably even 14 steps) instead of 128. I'm very reluctant to change out about 10 good decoders, and throw away about that many perfectly good, unused ones. I can't believe I'm the only JMRI user or would be user with this problem

If JMRI's throttles don't get 28 speed steps added as an option, then I'm going to make an inline filter to convert RS-232 128 step speed commands to 28.

My thanks to everyone who helped find what's happening. It sure had me confused! It's a relief to understand what's wrong.

Don Weigt
Connecticut

--
Bob Jacobsen
rgj1927@...

Hi Charles,

I just tried a 3-cylinder BR 44 and it worked. It looks like I didn't do enough checks. So, thanks for reporting this.

In my VSD file I provided 6 WAV files for 6 chuffs per revolution. Could you please check if it works for you with 8 WAV files?

Thanks, and sorry for the trouble.

Klaus


Am 25.09.2019 um 13:58 schrieb Charles Meo:

开云体育

Hi Klaus,

I tried changing 'cylinders' to 4 and then three, since I run BR96 0880 Malletts and I wanted to see if this would produce more appropriate noises.

Got java exceptions for both values.

java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
??? at java.util.ArrayList.rangeCheck(ArrayList.java:657)
??? at java.util.ArrayList.get(ArrayList.java:433)
??? at jmri.jmrit.vsdecoder.Steam1Sound$S1LoopThread.selectData(Steam1Sound.java:965)
??? at jmri.jmrit.vsdecoder.Steam1Sound$S1LoopThread.run(Steam1Sound.java:928)

Looks like the code isn't expecting a value larger than 2. Not sure about hacking this myself since I don't know what side-effects might be produced by messing with the array size.

In all other respects, Class64 and Class94 are absolute winners and I'm having no trouble tweaking them to sync up with my test loco (BR05, Zimo? MX635) quite nicely.

Might not be 100% prototypical but I'm happy as a clam.

Charles

Charles,

Getting into "Virtual Sound Decoder" (VSDecoder or VSD) is not easy. So it's good to ask questions here.

The mentioned documentation VSD_File_and_Config.shtml is intended as a supplement. A good entry page is this one here: - the author is the main developer of VSD.

For steam sound there are two programs: steam and steam1. They are selected via
* <sound name="ENGINE" type="steam">
?or
* <sound name="ENGINE" type="steam1">
in your config.xml file.

On you will find an example for "steam" (Generic_Steam.vsd) and two examples for "steam1" (Class64.vsd and Class94.vsd).

"steam1" is the newer program. It is more flexible and complex. It allows parameters like <accel-rate> and <decel-rate>. "steam" ignores these parameters.

Also can we have an explanation of what these things do:

<top-speed>75</top-speed>
<driver-diameter>60</driver-diameter>
<cylinders>2</cylinders>

<top-speed> defines the maximum speed in miles per hour.
<driver-diameter> defines the diameter of the driver wheel in inches.
<cylinders> defines the number of the steam engines. Mostley there are 2 cylinders. Because cylinders are double-acting there are 4 chuffs per driver wheel revolution.

and a guide to how to change them to get various results. If they plug into a formula, what's the formula, and what does it do?
Also how is the 'rpm' which it all uses derived? How do you set it for various prototypes? Can you use throttle values instead, and if so, how? Is rpm identical to throttle value?

VSD gets the speed from JMRI as a value of 0 - 1. Then VSD calculates the speed as revolutions per minute (RPM). Here is the formula:

speed = % of topspeed (mph)
RPM = speed * ((inches/mile) / (minutes/hour)) / (pi * driverdiameter)

With the calculated RPM VSD can choose the suitable sound files.

I haven't thought about how RPM should be set for various prototypes. Of course the value RPM must match the maximum speed of the loco type. More important is the typical sound of a loco type.

Throttle values are used for diesel sounds. See the <accel-limit> and <decel-limit> parameters in a diesel VSD file. I think RPM can be "identical" to the throttle value, if the speed curve of VSD and the DCC decoder matches.

Sorry if this has been dealt with elsewhere, but I couldn't find it so far and if anyone has a pointer to another thread or document, that will do nicely.
Cheers,
Charles

It's fine. The documentation is not perfect.

Regards,
Klaus

开云体育

Excellent, thank you Klaus. That certainly explains why accel and decel weren't working. I'm using the generic steam project with 'steam' not 'steam1'

I'll mull over the other stuff and do more tinkering.

Cheers,

Charles

Charles,

Getting into "Virtual Sound Decoder" (VSDecoder or VSD) is not easy. So it's good to ask questions here.

The mentioned documentation VSD_File_and_Config.shtml is intended as a supplement. A good entry page is this one here: - the author is the main developer of VSD.

For steam sound there are two programs: steam and steam1. They are selected via
* <sound name="ENGINE" type="steam">
?or
* <sound name="ENGINE" type="steam1">
in your config.xml file.

On you will find an example for "steam" (Generic_Steam.vsd) and two examples for "steam1" (Class64.vsd and Class94.vsd).

"steam1" is the newer program. It is more flexible and complex. It allows parameters like <accel-rate> and <decel-rate>. "steam" ignores these parameters.

Also can we have an explanation of what these things do:

<top-speed>75</top-speed>
<driver-diameter>60</driver-diameter>
<cylinders>2</cylinders>

<top-speed> defines the maximum speed in miles per hour.
<driver-diameter> defines the diameter of the driver wheel in inches.
<cylinders> defines the number of the steam engines. Mostley there are 2 cylinders. Because cylinders are double-acting there are 4 chuffs per driver wheel revolution.

and a guide to how to change them to get various results. If they plug into a formula, what's the formula, and what does it do?
Also how is the 'rpm' which it all uses derived? How do you set it for various prototypes? Can you use throttle values instead, and if so, how? Is rpm identical to throttle value?

VSD gets the speed from JMRI as a value of 0 - 1. Then VSD calculates the speed as revolutions per minute (RPM). Here is the formula:

speed = % of topspeed (mph)
RPM = speed * ((inches/mile) / (minutes/hour)) / (pi * driverdiameter)

With the calculated RPM VSD can choose the suitable sound files.

I haven't thought about how RPM should be set for various prototypes. Of course the value RPM must match the maximum speed of the loco type. More important is the typical sound of a loco type.

Throttle values are used for diesel sounds. See the <accel-limit> and <decel-limit> parameters in a diesel VSD file. I think RPM can be "identical" to the throttle value, if the speed curve of VSD and the DCC decoder matches.

Sorry if this has been dealt with elsewhere, but I couldn't find it so far and if anyone has a pointer to another thread or document, that will do nicely.
Cheers,
Charles

It's fine. The documentation is not perfect.

Regards,
Klaus

Charles,

Getting into "Virtual Sound Decoder" (VSDecoder or VSD) is not easy. So it's good to ask questions here.

The mentioned documentation VSD_File_and_Config.shtml is intended as a supplement. A good entry page is this one here: - the author is the main developer of VSD.

For steam sound there are two programs: steam and steam1. They are selected via
* <sound name="ENGINE" type="steam">
or
* <sound name="ENGINE" type="steam1">
in your config.xml file.

On you will find an example for "steam" (Generic_Steam.vsd) and two examples for "steam1" (Class64.vsd and Class94.vsd).

"steam1" is the newer program. It is more flexible and complex. It allows parameters like <accel-rate> and <decel-rate>. "steam" ignores these parameters.

Also can we have an explanation of what these things do:
<top-speed>75</top-speed>
<driver-diameter>60</driver-diameter>
<cylinders>2</cylinders>

<top-speed> defines the maximum speed in miles per hour.
<driver-diameter> defines the diameter of the driver wheel in inches.
<cylinders> defines the number of the steam engines. Mostley there are 2 cylinders. Because cylinders are double-acting there are 4 chuffs per driver wheel revolution.

and a guide to how to change them to get various results. If they plug into a formula, what's the formula, and what does it do?
Also how is the 'rpm' which it all uses derived? How do you set it for various prototypes? Can you use throttle values instead, and if so, how? Is rpm identical to throttle value?

VSD gets the speed from JMRI as a value of 0 - 1. Then VSD calculates the speed as revolutions per minute (RPM). Here is the formula:

speed = % of topspeed (mph)
RPM = speed * ((inches/mile) / (minutes/hour)) / (pi * driverdiameter)

With the calculated RPM VSD can choose the suitable sound files.

I haven't thought about how RPM should be set for various prototypes. Of course the value RPM must match the maximum speed of the loco type. More important is the typical sound of a loco type.

Throttle values are used for diesel sounds. See the <accel-limit> and <decel-limit> parameters in a diesel VSD file. I think RPM can be "identical" to the throttle value, if the speed curve of VSD and the DCC decoder matches.

Sorry if this has been dealt with elsewhere, but I couldn't find it so far and if anyone has a pointer to another thread or document, that will do nicely.
Cheers,
Charles

It's fine. The documentation is not perfect.

Regards,
Klaus

Barry,

On 25 Sep 2019, at 9:11 AM, barrychinn <bechinn1@...> wrote:

In theory, updating roster files from either computer should be available to be read correctly from either location. In practice, updates from either location (sometimes?) necessitates rebuilding the roster at the other computer.

JMRI wasn't initially designed to be multiuser and have simultaneous file access. However, many users and developers now use Dropbox or similar to share user files, so we have made it easier:
<>

Dropbox (OneDrive, Google Drive) work fairly well because they are a file syncing service, not a file sharing service (each instance of JMRI is working on local copies), so file corruption does not occur (Dropbox keeps both versions if there is a sharing conflict). However Network File sharing is quite likely to corrupt files.

So a service like Dropbox is fine for files that are not being written while open on another computer. In the case of a panel or decoder file, that may mean the file has to be closed and reopened to see changes.

The one small problem area is that the Roster Index is always open in any instance of JMRI and is rewritten on close. This means that:
- Additions or deletions to the roster will not be visible on another computer unless you "Rebuild Roster" on all connected computers.
- Sometimes conflicted roster index files are created. No harm done, just make sure only one JMRI instance is running and Rebuild Roster.

I don't recommend having Rebuild Roster as a Startup item. It is quite resource intensive and time consuming for large rosters. You are more likely to have problems. Just Rebuild Roster when needed (you suspect something missing) or as an occasional cleanup tool.

Dave in Australia

Hi Steve,
Thanks for the reply.
But I think the fixes you suggest are beyond my limited novice capabilities.

Note that everything works exactly as it should, including click position on the lists, if I use

pnl.add(self.cb2)

without the scrollpane.

The problem then is , because I have to make the font large to make text selection practical on a touchscreen, I cannot display a long enough list. If I could scroll up and down within the frame that would give me what I want. Is that possible ?

Thank for your help again.

Dave

Bob,

The "new" DecoderPro3 is just a different "look" and accesses the same underlying code as the legacy DecoderPro interface.

Like you, I much prefer the legacy interface and have created an icon to launch it, using the directions located here:?

HTH,
Steve
"Breezlys"