i have currently 9 Digitrax DS64 per there recemidations I created ID# 101 - 109. I also named each switch address 1 thru 36. In Panel Pro where does it see the address for the DS64? It¡¯s seeing the switch address¡¯s. Am I missing something? In panel Pro I saw there is a programming button for the DS64¡¯s but I don¡¯t understand what that does.
Wayne Snyder
|
Locked
Re: VSD Sound from ZIMO's Sound Library
Klaus,
I'm back at it and making progress.? Tried system console and got a large error list.?Took a fresh approach.? My mistake was that I had too many NW2 config files and? was apparently copying them into the incorrect vsd folder.? A mess.? a side by side comparison in my xml editor show the difference.? With a fresh start - good news.
So far, ZIMO's wav files don't have clicks.? I have a NW2 vsd folder with ZIMO's bell, horn and compressor.? The engine part is very simple - just start, stop and 3 run wav files.? No clicks when notching.? As I remember the original vsd folder had this simple 3 step system also.? So now my task is to incorporate the transition steps that are provided by ZIMO's wave files, i.e. 0-1, 1-2, 2-1 and 1-0.? If that works I'll try adding the all 8 steps that ZIMO has.
Conrad
PS? With the click problem, the volume problem and ZIMO files I will, for now, stay far away from system console msgs:)??
|
Locked
Re: Steve Todd's image - Buster Update?
Thanks, G
There's a new version here:?
It includes the latest Buster updates and JMRI 4.17.3.
--SteveT
|
mcdougle1979,
A long shot:
Take a look at the Advanced pane (Read Full Sheet first) and make sure "Automatic Speed Step Detection" is enabled.
I don't think it will help greatly but worth a try.
Dave in Australia
|
mcdougle1979 (Name please ¨C we are ¡®friends¡¯ and generally converse on a first-name basis?
?)
?
The Sprog FAQ has a link to ¡°¡±?
-- unfortunately the link isn¡¯t working at the moment.
< >
?
The SPROG user guide addresses speed step selection on pages 46 (Control Panel) and page 47:
¡°Choose the speed step mode to be used by the SPROG throttle. The default is 128 step, which is recommended for all recent DCC decoders.¡±
?
You may want to check this setting ensuring it is set correctly.
< >
?
HTH
?
Ross
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of
mcdougle1979
Sent: Saturday, September 7, 2019 7:30 AM
To: [email protected]
Subject: Re: [jmriusers] LokSound v5 issues
?
Have you possibly set your DCC system to send 14 2peed-step commands to this locomotive address?
?
What DCC system (and what throttle) are you using?
I'm using JMRI with Sprog. Same effect if using Engine Driver or just on-screen throttle. I've not changed the speed steps, but I had this once before and had to program the decoder to 14 (as it was reading as 128) and then re-program it
to 128 and that worked fine. I've tried this using JMRI screens and using CVs directly and nothing improving.
|
Have you possibly set your DCC system to send 14 2peed-step commands to this locomotive address?
We are talking about the SPROG Console menu item and the SPROG throttle Speed Step Mode setting there. You need to check that and make sure it isn't at 14.
That governs both Engine Driver and JMRI screen throttles.
?
What DCC system (and what throttle) are you using?
I'm using JMRI with Sprog. Same effect if using Engine Driver or just on-screen throttle.
See above. I've not changed the speed steps, but I had this once before and had to program the decoder to 14 (as it was reading as 128) and then re-program it to 128 and that worked fine. I've tried this using JMRI screens and using CVs directly and nothing improving. Never set ESU decoder speed steps to anything other than 28/128 with your SPROG DCC system. In that mode it accepts either 28 or 128 speed step commands.
Never try to use it when set to 14.
<>?
Dave in Australia
|
Thanks for the advice on reading the full CVs. I tend not to bother. Not got my layout up and running yet and all running on rolling road seems to be OK.
Good way to mess up your decoders... But a decoder reset should fix that.
Also tried another loco which I've not recently changed and it also stops responding over speed step 14.
Looks like you're doing something wrong (unrelated to ESU).?
Dave in Australia
|
Have you possibly set your DCC system to send 14 2peed-step commands to this locomotive address?
?
What DCC system (and what throttle) are you using?
I'm using JMRI with Sprog. Same effect if using Engine Driver or just on-screen throttle. I've not changed the speed steps, but I had this once before and had to program the decoder to 14 (as it was reading as 128) and then re-program it to 128 and that worked fine. I've tried this using JMRI screens and using CVs directly and nothing improving.
|
Who loaded the Sound File into the decoders?
1) Did you do it yourself using LokProgrammer.
2) Did you buy it from a vendor who had preprogrammed it?
3) ESU does not load sound Files into decoder it sells. Loading is the responsibility of the vendor or end-user.
Bought from Legomanbiffo. Installed all 3 in locos, programmed just the address and they worked OK. Swapped the speaker over and now not working.
What version of JMRI are you using. I recommend V4.17.3 for ESU decoders.
I was using latest Production version. I've just tried upgrading to the latest beta, same issue.?
?
Did you "Read Type from Decoder" or did you manually pick a model - a very bad idea?
I used the "read type from decoder". Thanks for the advice on reading the full CVs. I tend not to bother. Not got my layout up and running yet and all running on rolling road seems to be OK. Also tried another loco which I've not recently changed and it also stops responding over speed step 14.
|
mcdougle1979,
?
Have you possibly set your DCC system to send 14 2peed-step commands to this locomotive address?
?
What DCC system (and what throttle) are you using?
?
Ross
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of
mcdougle1979
Sent: Saturday, September 7, 2019 3:29 AM
To: [email protected]
Subject: [jmriusers] LokSound v5 issues
?
Installed and tested v5 decoders. Seemed to be working ok. Changed the speakers over, now the deciders are misbehaving. They only respond in6 14 speed steps - anything above step 14 brings the loco to a halt. The sound function buttons
have gone haywire. Pressing on any function button makes a random selection of sounds lock on.
I've tried a decoder reset; tried reprogramming to 128 speed steps; tried restarting jmri; tried restarting the sprog controller and decoder pro. Nothing seems to help.?
Anyone got any advice I could try?
|
Installed and tested v5 decoders.
Who loaded the Sound File into the decoders? 1) Did you do it yourself using LokProgrammer. 2) Did you buy it from a vendor who had preprogrammed it? 3) ESU does not load sound Files into decoder it sells. Loading is the responsibility of the vendor or end-user.
If whoever loaded the project (using LokProgrammer) didn't make sure the "Write Decoder Data to Defaults" checkbox was ticked, a "Factory Reset" will render the decoder apparently corrupted.
What was the Loco (actually Sound Project) name on the Information Pane when you read the whole decoder? (I sincerely hope you did that before programming).
What version of JMRI are you using. I recommend V4.17.3 for ESU decoders.
Did you "Read Type from Decoder" or did you manually pick a model - a very bad idea?
Seemed to be working ok. Changed the speakers over, now the deciders are misbehaving. They only respond in6 14 speed steps - anything above step 14 brings the loco to a halt. The sound function buttons have gone haywire. Pressing on any function button makes a random selection of sounds lock on.
Sounds like the decoder was either contents-corrupted or damaged by your work.
I've tried a decoder reset;
How did you do that? The correct way to do that is to make sure the SPROG is set to programmer mode (not Command Station mode), open the roster entry in Program Track mode and use the Resets Menu (next to File menu). The loco should respond with a lurch when you do this.
ESU does not recommend resetting using Program on Main, the results are unpredictable.
tried reprogramming to 128 speed steps; tried restarting jmri; tried restarting the sprog controller and decoder pro. Nothing seems to help.? None of these are likely to help.
If the reset doesn't get your decoder going again as per received, your decoder is either: A) Damaged. B) Sound Project corrupted by some event while working on it (static discharge, short circuit ...) C) Incorrectly loaded Sound Project (defaults not written through).
There's nothing JMRI can do directly about these. You need help from someone with a LokProgrammer. - Someone with access to a LokProgrammer and your loco can determine (A) or fix (B). - If you definitely know the Sound Project name someone remote with access to a LokProgrammer can create and send you a CV list Export file you can Import into JMRI and write full sheet on the CVs pane. A Band-Aid fix for (C).
See footnote below.
Dave in Australia?
Reading Decoder CVs
Reading the full decoder is essential, particularly with ESU decoders where there are no "standard defaults". Each sound project has its own "factory defaults". All ESU sound decoders are manufactured effectively blank. When a Sound project is loaded to the decoder (using LokProgrammer software) part of the procedure is to write a new set of "factory defaults".
Because of a known (but as yet unresolved) race condition with certain decoder settings variables in JMRI code:
1) Use "Read Full Sheet" on the CVs pane instead of "Read All Sheets". It is less likely to cause errors when reading a decoder with lots of CVs. Once finished, some may be missed (displayed in red). Use "Read Changes on Sheet" as many times as needed until no red items remain. (Hint: Click on the Status column in the CVs pane until you see a down arrow. All the Red items will then be at the top.)
2) After you make changes on a programming sheet, don't use Write/Read changes on that programming sheet. Instead, switch to the CVs pane and use Write/Read changes on (the CVs) sheet. The result is the same but it will never trigger the race condition.
You'll also see a number of messages in the JMRI System Log like this: "ERROR - Variable=xxxxxx; Busy goes false with state IDLE"
Ignore these as they don't indicate a real error, we'll fix the problem in a later JMRI release.
|
Installed and tested v5 decoders. Seemed to be working ok. Changed the speakers over, now the deciders are misbehaving. They only respond in6 14 speed steps - anything above step 14 brings the loco to a halt. The sound function buttons have gone haywire. Pressing on any function button makes a random selection of sounds lock on.
I've tried a decoder reset; tried reprogramming to 128 speed steps; tried restarting jmri; tried restarting the sprog controller and decoder pro. Nothing seems to help.?
Anyone got any advice I could try?
|
On Sep 6, 2019, at 11:31 AM, Jon Miller <atsfus@...> wrote:
I have a very very early decoder I have lost the instructions
to. The only ID I have is the sticker on the chip. It reads;
MELEC TL2054
It may or may not be a sound decoder so maybe someone could tell me what they think it is. Also I tried to read the pertinent CVs using JMRI and couldn't. If it is old enough, it may not support anything but the standard NMRA registers. Try reading register 1 in register mode. I have a couple of old decoders I have to do this with. Paul
|
Locked
Re: SSL heads fail to set properly after start .... JMRI 4.17.3
Roger, friends,
This topic is GREAT. I have one small suggestion. I "occasionally" help others build and modify panels . One major problem is that when custom icons are used, and an xml file is sent to someone else, especially this list, all custom icons, and the location where they are saved, should be included with the file. I've literally spent weeks debugging a friend's panel after he (novice user) over-lapped several panels into one massive panel that killed his system's ability to load it. Not only did he load over 4 panels but he had created at least a dozen or more custom icons as well as a complete custom background that covered 4 monitors in width.
Whenever I tried to load his panel, it would have so many error messages about missing icons that getting the panel to initially load took almost 15-20 minutes and I am using a gaming machine that boots in 13 seconds using Windows 7 Pro.
With his inexperience with computers and Panelpro it took us several long phone calls to sort out what happened.
Just a heads-up to the artists and innovators in the group. Always supply everything you create when you ask for help.
Regards, Nick Kulp
"I'm not a failure. I started at the bottom and I found it easily attainable. Life is too short to set unattainable goals"- Nick Kulp
Roger,
Yes, same deal with custom icons etc..., keep them in the user directories.
The idea is you repeat the same tree as the production content and most of
the tools know to look for them there in addition to the production files.
And for some cases, like signal rules, if the same file name is in both
places, it should use the one from the user directory tree instead of the
production version. Handy for testing ideas and customizing stuff. But I'm
not sure exactly which cases it works automatically, and which need help.
Where it really helps is when you need help. You can zip up your custom
directories of stuff and then the panels find all their parts.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
|
|
Locked
Re: Determine Digitrax UR92 firmware with JMRI and Locobuffer USB
All,
Thank you for the replies. I have successfully update my UR-92 using the Digitrax S/W and Locobuffer. I believe the correct baud rate is 57600 (the only option some of the Digitrax programs allow).
Jack Varadi
|
Locked
Re: SSL heads fail to set properly after start .... JMRI 4.17.3
Roger,
Yes, same deal with custom icons etc..., keep them in the user directories.
The idea is you repeat the same tree as the production content and most of
the tools know to look for them there in addition to the production files.
And for some cases, like signal rules, if the same file name is in both
places, it should use the one from the user directory tree instead of the
production version. Handy for testing ideas and customizing stuff. But I'm
not sure exactly which cases it works automatically, and which need help.
Where it really helps is when you need help. You can zip up your custom
directories of stuff and then the panels find all their parts.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
Locked
Re: SSL heads fail to set properly after start .... JMRI 4.17.3
|
??? I have a very very early decoder I have lost the instructions
to.? ? The only ID I have is the sticker on the chip.? It reads;
MELEC TL2054
??? It may or may not be a sound decoder so maybe someone could tell me what they think it is.? Also I tried to read the pertinent CVs using JMRI and couldn't.
--
Jon Miller
For me time stopped in 1941
Digitrax Chief/Zephyr systems,
SPROG, JMRI User
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: SSL heads fail to set properly after start .... JMRI 4.17.3
Although it¡¯s perfectly fine for people to run their own modified scripts, it¡¯s also nice to have ones that do what people want. So I¡¯ve added a jython/SetUnknownTurnoutsClosed.py script that just sets the UNKNOWN-state turnouts. It¡¯ll be in the next test release. Bob On Sep 5, 2019, at 4:23 PM, Roger Merritt <merritt_roger@...> wrote:
Bob,
Found the problem.
Since I had moved from a bootleg script that clears all UNKNOWN states of sensors and turnouts to the official scripts that is when the problem came up. Seems the the script "SetAllTurnoutsToClosed.py" closes all the turnouts, even the signalheads for the SE8Cs. After changing the 'IF (turnout) is not closed' to 'IF (turnout) is UNKNOWN' To set the turnout to closed cured the problem.
Now I have to remember to keep this altered script in my USER file section each time I do a update to new version.
-- Bob Jacobsen rgj1927@...
|
conrad
Dave Barraza
Ken Cameron
Roger Merritt
Bob Jacobsen