Keyboard Shortcuts
Likes
Search
Locked
Possible roster problem
#zimo
|
You may recall I have been unable to control old Lenz LE103 decoders with JMRI throttles, although I can control newer basic NCE decoders and SoundTraxx Econami steam decoders, at least the one of each I've tried so far. |
|
Read CV19.
If not 0, the command system has it in consist, and you need to use that number as address. Some systems set this in background, do on their throttle is looks like cab number, but translated internally to CV19 number. And make sure you are using short or long address as set be CV29 in decoder. Open JMRI as decoder pro, and read Basic sheet. (This is all NMRA, so any decoder type will have these) Check? for which address is active. (Includes read of CV19) Thomas DeSoto, TX |
|
Thanks, Marc. I already did one of those tests, as I first just entered the DCC address of the loco with the Zimo decoder. When that controlled function F1, which turns a home brew sound generator on and off, but couldn't make the loco run or stop, I then tried adding it to the roster, with the same result. The Lenz LE103s don't have any functions except the front and back lights. But, I can't control them, or make the locos run or stop. I'm not aware of anything else I can change, or would need to reset. But, I will try that, and then monitoring the JMRI message to the EasyDCC again. I was hoping there was some subtle DecoderPro "thing" going on that might explain lack of motor control when there is control of functions. I haven't heard yet that there is one. Bummer! Don Weigt Connecticut, USA |
开云体育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 On 20/09/2019 10:40 am,
forfoum@... wrote:
Thomas, that is a good point. -- Gerry Hopkins MMR #177 FNMRA Great Northern Downunder NMRA Australasian Region Contest & AP Chairman Web Administrator |
|
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, |
|
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:
|
|
Marc,
On 20 Sep 2019, at 1:44 PM, forfoum@... wrote: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 |
|
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, |
开云体育? 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 – 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 ? ? ? ? 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, |
|
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.? |
|
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:-- Bob Jacobsen rgj1927@... |
|
Marc,
On 21 Sep 2019, at 1:37 AM, forfoum@... wrote:Sorry, what I should have said is that "the numbers stored in CV1 and CV19 are both short addresses". Dave in Australia |
|
I now have a printout of the JMRI to EasyDCC commands for two locos. One with a year old basic NCE decoder using long address 349 works. One with a Lenz LE103 using long address 1477 does not. I will try decoding them on paper to look for errors. What I did was try to run forward, stop, run backward, stop, turn the light (CV0) on and off. Those should be easy to decode manually on paper. Sorry to add confusion, but after reprogramming the LE103 in 1477, it now was sometimes able to switch the headlight on using CV0. It only seemed possible while the EasyDCC Command Station was still circulating the packet from the EasyDCC throttle that turned it off. This was right after unplugging the EasyDCC throttle. I'd use JMRI to turn on the light, a couple seconds later it would turn off. I'd be able to turn the light back on, I think by pressing the light command twice on the JMRI throttle to get another "off to on" packet generated. After a second or two, it would turn off again. Once about two minutes had passed, and the other packet was cancelled, I couldn't control the light with JMRI. At no time could I make the loco move, forward or backward with JMRI. I may have to build one of those Arduino based packet sniffers. Data would reduce the number of possible explanations. I appreciate all the analysis, but it's getting confusing. With data to compare to that analysis, some understanding might follow quickly. If it were only the LE103s that didn't work, I might just replace them with the Zimos MX60 somethings I bought years ago. But, the one Zimo equipped loco I have tried has also not worked right. I could control functions, but not speed and direction. That may be something more easily solved. I keep hoping I'm one "Ah hah!" moment from a solution. It's beginning to seem I'm just wasting more and more time. But, those decoders were Standard compliant when new, and they SHOULD work! I didn't imagine I might have to replace all my decoders with newer ones to use JMRI.... Don Weigt Connecticut |
|
The code in JMRI that creates the Throttle messages to the EasyDCC command station knows _nothing_ of the decoder type. No matter what decoder type is out there, in JMRI’s roster or not, JMRI will send the same message to the command station given the same address and same speed/function/whatever content.
The problem is somewhere in the EasyDCC command station, EasyDCC throttles, and/or decoders themselves. The ones where it seem to work and then stop or are changed are almost certainly due to another throttle sending conflicting commands. Physically disconnect _all_ the EasyDCC throttles, remove the batteries from any that have them, reset (power off/on) the command station, and see if that class of problems remains. Bob On Sep 21, 2019, at 8:47 AM, Don Weigt <dweigt47@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Bob, Thank you for the very helpful?information that the JMRI throttle message code doesn't know or care what decoder type is out there. I thought the EasyDCC Command Station just added those JMRI throttle messages as packets to its queue. But, if what you wrote is true, then the Command Station must convert speed commands into the right packets for the various decoder speed step settings, such as 14 or 28, or 128, and format them for long or short addresses.
Bob Jacobsen:
"The code in JMRI that creates the Throttle messages to the EasyDCC
command station knows _nothing_ of the decoder type. No matter what
decoder type is out there, in JMRI’s roster or not, JMRI will send the
same message to the command station given the same address and same
speed/function/whatever content. The problem is somewhere in the EasyDCC command station, EasyDCC throttles, and/or decoders themselves." And then: "The
ones where it seem to work and then stop or are changed are almost
certainly due to another throttle sending conflicting commands.
Physically disconnect _all_ the EasyDCC throttles, remove the batteries
from any that have them, reset (power off/on) the command station, and
see if that class of problems remains." I do understand that, and said so in different wording. I found it most significant simply because it was the first time I'd been able to make any JMRI throttle cause any action by an LE103 decoder. I do think a packet sniffer is the next step. I need to compare packets to the LE103 decoders from EasyDCC throttles and JMRI throttles. Any differences in packets from my EasyDCC in response to JMRI messages would contain the problem. Once I know what's wrong, I should be able to zero in on the cause and fix. Yet, if packet formatting for both is done by my EasyDCC Command Station, it seems odd those from its throttles get formatted properly, and those from JMRI don't. I do hope to get this to work. I want to keep my plug in EasyDCC throttles for most walkaround control of the trains. I don't want to replace the Command Station, walkaround throttles, and layout wiring to keep that function, simply to add guest train control via smart phones and JMRI. I'd probably give up JMRI train control first, using it only to replace hardware panels for route control and signalling. Don Weigt. Connecticut |
开云体育Don Please refresh my memory - what version firmware do you have in the command station? Gerry On 22/09/2019 5:19 am, Don Weigt wrote:
-- Gerry Hopkins MMR #177 FNMRA Great Northern Downunder NMRA Australasian Region Contest & AP Chairman Web Administrator |
|
Gerry, The EasyDCC Command Station has V629 firmware. According to EasyDCC Tech Support, that should work fine. The latest is V631. The only change, I was told, is that now the Command Station remembers what DCC addresses (Locos) its front panel throttles were controlling when power is removed. Thus, they don't need to be reentered when the Command Station is powered?up. No change to handling of commands from the serial port. Don |
开云体育Don OK good to know. Today (Sunday) my layout was on a Layout Tour with 11 other layouts. 10.00 am to 4.00 pm - now it is over. I had a problem with my phone - unable to drive a train, it showed on the computer screen as being under the control if the phone, the command monitor showed that the commands were? being sent no response from the loco with a WOW v3 decoder. Tried to drive from the screen - nothing. Under edit, in defaults, the throttles and power had reverted to Sprog. Changed them back to Easydcc and every thing worked. Tomorrow I will set up the LE103 - (I threw 5 of these in the trash about 3 months ago) and the similar NCE 102 and the Wangrove 102 - all three are 1998 vintage - I will run your tests with the three of them. Doing the tests before? I get back installs for others. Gerry On 22/09/2019 8:42 am, Don Weigt wrote:
-- Gerry Hopkins MMR #177 FNMRA Great Northern Downunder NMRA Australasian Region Contest & AP Chairman Web Administrator |
Bob Jacobsen