Locked
Bucklew's tutorial part 3
Hello all. I'm trying to figure out how to use signal heads and SSL and am finding Robert Bucklew's tutorial 3 () very helpful. But I have two questions:
1. does anyone know where I can find a panel file (xml) for the finished product of this tutorial?
2. I'm confused about the naming of the signal heads. On page 3 are instructions for adding 4 heads:
4 East Upper, 4 East Lower, 4 West main, and 4 West Siding.
On subsequent pages these signals are all placed in the northWEST corner of the layout, if I'm not mistaken. I'm puzzled why the upper and lower are called East since they are placed in the west portion of the layout. What am I missing?
Thanks, Hal.
|
Locked
Re: Signal Mast Appearance definition file
On Thu, Sep 19, 2019 at 07:55 PM, billybob experimenter wrote:
Unfortunately, it appears that some recent web page re-organization work is incomplete. This means that the individual mast-specific pages are not rendering correctly. This leaves these pages partially "broken", with some missing text. I have filed an issue with the JMRI development team.
Regards,
Billybob
Billybob, This issue should now be fixed. Thanks for raising it. Best regards, Matt H
|
Locked
Re: Signaling - strange message in apperance table
Petr,
This issue should now be resolved - can you verify?
Thanks.
Best regards,
Matt H
|
14 -> 27 and 28 -> 55 were Ugly Hacks built into some early command stations. Basically, the command station would rapidly switch back and forth between step N and N+1 to _effectively_ have step N+0.5. Putting a 0.5 in between all 14 steps gives you 27 total steps. Once 128 existed, there was little need. Bob On Sep 20, 2019, at 8:17 PM, whmvd <vandoornw@...> wrote:
55?? That's a new one on me!
On Fri, 20 Sep 2019 at 18:14, <forfoum@...> wrote:
As per the LE103 doc I found on Yumpu, These did not support 128.
They supported 14/27 or 28/55 Speed Steps.
So if the Command Station default for Speed Steps is 28. No issue. But you would need to check how the decoder address is REGISTERED with
your EASYDCC for speed steps, might have been changed inadvertently.
Your CV7 = 0. If that is correct, that is some very old decoder. Values should be 41 thru 43 for the LE103.
Marc
-- Bob Jacobsen rgj1927@...
|
55?? That's a new one on me!
As per the LE103 doc I found on Yumpu, These did not support 128.?
They supported 14/27 or 28/55 Speed Steps.
So if the Command Station default for Speed Steps is? 28. No issue. But you would need to check how the decoder address is REGISTERED with
your EASYDCC for speed steps, might have been changed inadvertently.?
Your CV7 = 0. If that is correct,? that is some very old decoder. Values should be 41 thru 43 for the LE103.
Marc
|
?
My current theory revolves around 28/128 steps.
?
For the problematic LE103 decoders:
What happens if the EasyDCC throttle is changed to 128 steps ?? Can the EasyDCC throttle now control the LE103 ?? ??If the answer is ¡°no, it¡¯s now like JMRI
throttles¡±, then it may be a clue.
?
I¡¯ve known with other DCC systems problems with the JMRI throttles if they are set to anything other than 128 steps.?? It¡¯s never bothered me as I use 128 steps,
and I don¡¯t know if the issue I¡¯ve seen is related to certain DCC systems, or more widespread.?
?
?
A more complete answer would be found if there were a DCC packet analyser looking at the track signal, and comparing what is sent from a (working) EasyDCC throttle
with the (problematic) JMRI throttle.??? But, unless there is one to hand, that means a short diversion into either tracking down such a device, or building one ¨C there are several online instructions on how to do this with an Ardunio and a handful of components,
but it¡¯s a diversion into electronics.
?
?
?
-?????????
Nigel
?
?
?
?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]]
On Behalf Of Don Weigt
Sent: 20 September 2019 16:15
To: [email protected]
Subject: Re: [jmriusers] Possible roster problem #zimo #decoderpro
?
wouter,
No, I haven't checked the JMRI speed table for this decoder recently. With EasyDCC I do normally have a start voltage set, and mid and full speed, often evenly divided with full speed at 100%. On a few of my faster locos, full speed is reduced. Momentum is
set for 4 or 5 accelerating and braking. It seems the JMRI roster info needs to be checked for that.
In 28 speed step mode, wouldn't the JMRI be sending "speed step nn", and the decoder using its value for that speed step to control the motor? I don't think there is a way JMRI could tell these decoders the actual duty cycle the decoder should be setting.
If the number of speed steps is mismatched, or the JMRI speeds are 0 for start, mid, and full, wouldn't F0 still control the lights? I can't even do that on LE103s with JMRI, but can with EasyDCC plug in throttles. The speed table values seem more likely to
be the source of trouble with the Zimo decoder, where I could control F1, but not train speed.
The recent discussions of what may be wrong are interesting and educational. Thanks for helping me, guys! I have always set these decoders up in EasyDCC as Class 2, which supports 28 speed steps. Even in the late 1990s, the decoders I used supported that. There
was no reason to use the coarser 14 speed steps on any of my locos. Notice 1477 read back showed it is configured for 28/128 speed steps. I believe all my roster entries are set for 28 speed steps, so that should match, but I will confirm that.
Don Weigt
Connecticut
|
Hi Don,
Both things I mentioned (speed values 0 and momentum huge) are pretty long shots more in desperation than anything else. Somewhere along the line I have confused issues in my mind - I thought that for all problem cases the headlights worked but the motor wouldn't budge. If that's not so, then what I said becomes even more unlikely. Still worth a quick check, I suppose.
One thing: don't trust the roster. The roster may be out of sync with the decoder, especially where momentum is concerned as that's often modified while running - and the roster simply won't know until you read back the value. At this stage, I would suggest reading CVs directly from the decoder at all stages - unless you've done a full read very recently.
Wouter
On Fri, 20 Sep 2019 at 16:14, Don Weigt < dweigt47@...> wrote: wouter,
No, I haven't checked the JMRI speed table for this decoder recently. With EasyDCC I do normally have a start voltage set, and mid and full speed, often evenly divided with full speed at 100%. On a few of my faster locos, full speed is reduced. Momentum is set for 4 or 5 accelerating and braking. It seems the JMRI roster info needs to be checked for that.
In 28 speed step mode, wouldn't the JMRI be sending "speed step nn", and the decoder using its value for that speed step to control the motor? I don't think there is a way JMRI could tell these decoders the actual duty cycle the decoder should be setting.
If the number of speed steps is mismatched, or the JMRI speeds are 0 for start, mid, and full, wouldn't F0 still control the lights? I can't even do that on LE103s with JMRI, but can with EasyDCC plug in throttles. The speed table values seem more likely to be the source of trouble with the Zimo decoder, where I could control F1, but not train speed.
The recent discussions of what may be wrong are interesting and educational. Thanks for helping me, guys! I have always set these decoders up in EasyDCC as Class 2, which supports 28 speed steps. Even in the late 1990s, the decoders I used supported that. There was no reason to use the coarser 14 speed steps on any of my locos. Notice 1477 read back showed it is configured for 28/128 speed steps. I believe all my roster entries are set for 28 speed steps, so that should match, but I will confirm that.
Don Weigt
Connecticut
|
wouter,
No, I haven't checked the JMRI speed table for this decoder recently. With EasyDCC I do normally have a start voltage set, and mid and full speed, often evenly divided with full speed at 100%. On a few of my faster locos, full speed is reduced. Momentum is set for 4 or 5 accelerating and braking. It seems the JMRI roster info needs to be checked for that.
In 28 speed step mode, wouldn't the JMRI be sending "speed step nn", and the decoder using its value for that speed step to control the motor? I don't think there is a way JMRI could tell these decoders the actual duty cycle the decoder should be setting.
If the number of speed steps is mismatched, or the JMRI speeds are 0 for start, mid, and full, wouldn't F0 still control the lights? I can't even do that on LE103s with JMRI, but can with EasyDCC plug in throttles. The speed table values seem more likely to be the source of trouble with the Zimo decoder, where I could control F1, but not train speed.
The recent discussions of what may be wrong are interesting and educational. Thanks for helping me, guys! I have always set these decoders up in EasyDCC as Class 2, which supports 28 speed steps. Even in the late 1990s, the decoders I used supported that. There was no reason to use the coarser 14 speed steps on any of my locos. Notice 1477 read back showed it is configured for 28/128 speed steps. I believe all my roster entries are set for 28 speed steps, so that should match, but I will confirm that.
Don Weigt
Connecticut
|
Marc, On 20 Sep 2019, at 1:44 PM, forfoum@... wrote:
Not what I said. I asked what would occur if CV1 = 66 and CV19 = 66. And I tested it and the decoder accepts this. Now the Command Station sends out commands to Address 66... So which will it be ? the Standard address or the Consist address ? CV19 takes precedence over others and I do not see the Command Station changing this based on which throttle. CV1 and CV 66 are both short addresses. With that configuration, the only way to make the loco move is to send short address 66 speed packets. Having a non-zero CV19 overrides anything in CVs 1, 29, 17 or 18 as far as speed packet receptivity is concerned. <> Dave in Australia
|
Locked
Re: Signaling - strange message in apperance table
This is thought to be an unwanted side-effect of migrating the JMRI site to https: Bob On Sep 20, 2019, at 11:32 AM, Petr ?¨ªdlo via Groups.Io <sidlo64@...> wrote:
Lately there is a strange message in the Apperance table
for example
Error: This appearance does not appear in the aspect table. Check spelling and upper / lower case.
In the Aspect table, the respective aspects are
for example
I did not observe this error before. -- Bob Jacobsen rgj1927@...
|
Locked
Re: VSD CLASS 64 COASTING WEIRDNESS
Conrad, I think that the loco decoder and VSD are in sync when the HALF_SPEED key is switched and the loco is not running. Prerequisite: the basic acceleration and deceleration times of the loco decoder and VSD are in sync. If the HALF_SPEED key is changed while the loco is running, things are not fully synchronized. I admit I haven't read the NMRA recommendations on half-speed. Thus, am I correct in understanding that VSD's engine code is only responding to LocoNet "Set speed of loco in slot 2 to xx" packets?? I say this because watching my JMRI LocoNet Monitor I see that toggling HALF_SPEED (F8) does not result in speed packets being sent.? This makes sense as HALF_SPEED?just tells the decoder to cut or increase the speed, say by half, independent of throttle setting.? So the code for HALF_SPEED goes to say F8, but is not linked to the engine functions.
The answer to your question is yes. JMRI provides a speed value between 0 and 1. If HALF_SPEED is active, VSD divides the value by 2. That's it. There are no speed setting packages on the LocoNet. VSD then uses momentum to adjust the speed. And it looks like the loco decoder doesn't do this. Klaus
|
Locked
Signaling - strange message in apperance table
Lately there is a strange message in the Apperance table
for example
?
Error: This appearance does not appear in the aspect table. Check spelling and upper / lower case.
In the Aspect table, the respective aspects are
for example
I did not observe this error before.
--
Petr ?¨ªdlo
Czech Republic
|
PS: also a huge acceleration momentum value combined with a lack of patience can make it seem like a loco does nothing. Yes, the words 'clutching' and 'straws' may well spring to mind.
On Fri, 20 Sep 2019 at 07:41, Wouter van Doorn < vandoornw@...> wrote: Hi Don,
Have you checked the values of the speed table and of Vstart, Vmid and Vmax? If those were inadvertently all zero... Not likely, I'll readily admit, but as you're running out of likely things it may be worth a look.
Do look in the decoder itself, not in the roster (or at least, not before reading all values in the all CVs pane).
Wouter
On Fri, 20 Sep 2019 at 04:31, Don Weigt < dweigt47@...> wrote: Thomas,
I have done the tests you recommended. On the programming track,
ID reads 1477, CV19 reads 0, CV29 reads 34
Read Basic Sheet shows:
Long (two byte) address
Active Address = 1477
Primary Address = 3
Loco Direction = Normal
Speed steps = 28/128 speed step format (recommended)
Power source conversion = NMRA Digital only
User ID#1 = 0, User ID#2 = 0, Manufacturer ID = 99, Version = 0
Everything seemed correct, but I couldn't control the loco with JMRI throttles. Could with EasyDCC.
Changed the address to short, 03.
Did Write sheet changes
Read Basic Sheet showed the changes were made successfully, all the rest was unchanged.
Couldn't control the loco with JMRI throttles. Could with EasyDCC throttles as address 03.
Made a log file of some JMRI to EasyDCC commands, with a list of what I did on the throttle. I saved the file, but couldn't remember how to get it from my RPi VPN connection on my laptop to the laptop's hard drive, so I can print it, analyze it at my leisure, or post it to the group. Tomorrow, I hope to do those things.
Marc,
I didn't try resetting the decoder back to defaults. I wouldn't expect it to matter, but will try to do that tomorrow.
Thank you both for your suggestions!
Don Weigt
Connecticut
|
Hi Don,
Have you checked the values of the speed table and of Vstart, Vmid and Vmax? If those were inadvertently all zero... Not likely, I'll readily admit, but as you're running out of likely things it may be worth a look.
Do look in the decoder itself, not in the roster (or at least, not before reading all values in the all CVs pane).
Wouter
On Fri, 20 Sep 2019 at 04:31, Don Weigt < dweigt47@...> wrote: Thomas,
I have done the tests you recommended. On the programming track,
ID reads 1477, CV19 reads 0, CV29 reads 34
Read Basic Sheet shows:
Long (two byte) address
Active Address = 1477
Primary Address = 3
Loco Direction = Normal
Speed steps = 28/128 speed step format (recommended)
Power source conversion = NMRA Digital only
User ID#1 = 0, User ID#2 = 0, Manufacturer ID = 99, Version = 0
Everything seemed correct, but I couldn't control the loco with JMRI throttles. Could with EasyDCC.
Changed the address to short, 03.
Did Write sheet changes
Read Basic Sheet showed the changes were made successfully, all the rest was unchanged.
Couldn't control the loco with JMRI throttles. Could with EasyDCC throttles as address 03.
Made a log file of some JMRI to EasyDCC commands, with a list of what I did on the throttle. I saved the file, but couldn't remember how to get it from my RPi VPN connection on my laptop to the laptop's hard drive, so I can print it, analyze it at my leisure, or post it to the group. Tomorrow, I hope to do those things.
Marc,
I didn't try resetting the decoder back to defaults. I wouldn't expect it to matter, but will try to do that tomorrow.
Thank you both for your suggestions!
Don Weigt
Connecticut
|
Am 20.09.2019 um 01:35 schrieb conrad: Just found the updated VSD example file on github (3 days old).
All four locos run (3 diesel, 1 steam).? all sounds ?same? as previous release.? diesels good,
steam not so good (choppy chuff transitions).
not sure what changes were made. Conrad, I have only made small changes in example.vsd. The reason for this was an issue on Github, created by a VSD user, see for the background (Github issues are another way to report errors). Clicking on the first reference in this Github issue will take you to the actual starting point of the fault. Here are some details about my changes: * changed file name "Idle 1.wav" to "Idle 1a.wav" and "Idle 8.wav" to "Idle 8a.wav" * deleted sounds/engine/645turbo/D3- 4.wav * downsampled 16-bit sounds/engine/nw2/stop.wav to 8-bit stop2.wav, sounds/engine/ge7fdl/engine/Start_22050.wav and Shutdown_22050.wav are also downsampled * upsampled sounds in sounds/engine/nw2 to Start_22050.wav and stop_22050.wav * used the shorter D1k.wav instead of D1.wav in "EMD 645 Turbo" * inserted an exponent value in Generic_Steam * some minor formal changes Klaus
|
Thomas,
I have done the tests you recommended. On the programming track,
ID reads 1477, CV19 reads 0, CV29 reads 34
Read Basic Sheet shows:
Long (two byte) address
Active Address = 1477
Primary Address = 3
Loco Direction = Normal
Speed steps = 28/128 speed step format (recommended)
Power source conversion = NMRA Digital only
User ID#1 = 0, User ID#2 = 0, Manufacturer ID = 99, Version = 0
Everything seemed correct, but I couldn't control the loco with JMRI throttles. Could with EasyDCC.
Changed the address to short, 03.
Did Write sheet changes
Read Basic Sheet showed the changes were made successfully, all the rest was unchanged.
Couldn't control the loco with JMRI throttles. Could with EasyDCC throttles as address 03.
Made a log file of some JMRI to EasyDCC commands, with a list of what I did on the throttle. I saved the file, but couldn't remember how to get it from my RPi VPN connection on my laptop to the laptop's hard drive, so I can print it, analyze it at my leisure, or post it to the group. Tomorrow, I hope to do those things.
Marc,
I didn't try resetting the decoder back to defaults. I wouldn't expect it to matter, but will try to do that tomorrow.
Thank you both for your suggestions!
Don Weigt
Connecticut
|
Marc
Easydcc will not let you put "66" in the number AND in the
Advance consist.
He is using a Lenz LE 103 - they do not like 128 peed steps -
they are better with 28 or even 14.
Now, WiFi to JMRI to Easydcc - not sure what the commend station
send to the decoder. Does the speed steps in JMRI go to CVP or
does the setting in Easydcc override that and send its default?
The cvp panel can be set to default to 14 - 28 or 128.
I threw out about 6 of these decoders a couple of months ago -
still have one for testing.
I will not get time until Monday to "play" with it. My layout is
on a layout Tour all day Sunday and I am off to an operating
session today (Friday).
Gerry
Thomas, that is a good point.
Only problem is these LE103 of his work when he uses the EasyDCC
throttle. So that throws the CV19 theory for a loop.
CV19 takes precedence over both CV1 and CV17/18. If CV19? was the
root cause, then all throttles would have the same symptom.
Now what if he has CV1 = 66 and CV19 = 66.. Could it be JMRI and
WiThrottle? using address 66 ends up on CV19 as a "Consist"? but
his EasyDCC throttle
that might not support "Consist"? ends up on address 66? (CV1).?
Not probable as CV19 is a decoder thing.
Marc
--
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder
NMRA Australasian Region
Contest & AP Chairman
Web Administrator
|
Locked
Re: NCE PowerPro Connection Issues
Thanks for the responses, Dave and Dave! I'm tied up for the weekend, but will try your suggestions Monday.
-- Jeff
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave
Sand
Sent: Thursday, September 19, 2019 7:03 PM
To: [email protected]
Subject: Re: [jmriusers] NCE PowerPro Connection Issues
Jeff,
Since you are using Windows, a JMRI upgrade may leave some old stuff
behind depending on how old the previous version was.
I always do a clean install. This involves using the Control Panel to remove
the old JMRI version followed by manually deleting the residual JMRI
directory in C:\Program Files (x86).
Note: If you have placed custom components, such as icons, in the install
location instead of the user files location, be sure to back them up before
doing the cleanup steps.
The user data, such as rosters, panels, operations files, etc., are located at
C:\Users\<username>\JMRI.
Dave Sand
On Sep 19, 2019, at 5:30 PM, Jeff Mutter <jwmutter@...> wrote:
I¡¯m not sure if it was the same set of errors but yes, I got several errors
about three times before I saved the last one.
I did upgrade Java yesterday, too. Could that be related?
-- Jeff
From: [email protected] [mailto:[email protected]] On Behalf Of
Dave Heap
Sent: Thursday, September 19, 2019 6:16 PM
To: [email protected]
Subject: Re: [jmriusers] NCE PowerPro Connection Issues
Jeff,
On 20 Sep 2019, at 3:12 AM, Jeff Mutter <jwmutter@...> wrote:
Shorted the ¡°2¡± and ¡°3¡± pins on the serial adapter. Didn¡¯t see the
¡°timeout flushes receive buffer: AA¡± message, but got a bunch of ¡°ERROR¡±
messages (see log below). Does that mean the adapter is bad, or do the
error messages mean something else is wrong?
It looks more like a transient error in the JMRI or the Pure Java Comm library we use. Or possibly a poor contact between pins 2 & 3.
Is it reproducible every time you start JMRI?
Dave in Australia
|
Locked
Re: Turnouts work only in Edit mode
Thanks Dave. I will check when I get home. I forgot to mention all other turnouts work correctly. It is just the new ones added that do not.
|
Locked
JythonAutomation and JythonSiglet use?
Does anyone use Jython scripts with the JythonAutomation and JythonSiglet classes?
I am looking for sample scripts used with those classes as documented for automation (kind of) in??so I can write up sample uses for those classes.
Thank you, Randall Wood
|
Matthew Harris
Bob Jacobsen
Petr ?¨ªdlo
Richard_vanRaay