Locked
Re: timeout on command station
Thanks for the troubleshooting advice. I got cute and installed the locobuffer in a Radio Shack plastic project box. And the set up is at the club layout. Tomorrow I will remove the box cover so I can see the LEDs and I'll post the results. Cheers At 07:53 PM 9/16/2002 -0700, you wrote: A timeout error generally means that the computer (DecoderPro) is not
talking to the unit on the test track.
1) Is LED D1 on ON the LocoBuffer?
2) Is the DCS100 ON?
3) When you open the programmer and try a read does D2 on the LocoBuffer
flash as data is being sent to the programming track?
Sometimes I like to open the LocoNet Monitor under DeBug and watch the
traffic on the LocoNet.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS jerry snyder Orlando, FL
|
Locked
Re: timeout on command station
A timeout error generally means that the computer (DecoderPro) is not
talking to the unit on the test track.
1) Is LED D1 on ON the LocoBuffer?
2) Is the DCS100 ON?
3) When you open the programmer and try a read does D2 on the LocoBuffer
flash as data is being sent to the programming track?
Sometimes I like to open the LocoNet Monitor under DeBug and watch the
traffic on the LocoNet.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: timeout on command station
Jerry:
I'm having the exact same problem, please let me know what you did. I just built my locobufer from a kit and have not gotten it to read a decoder on the test track.
Bill
toggle quoted message
Show quoted text
----- Original Message -----
From: jerrys1933
To: jmriusers@...
Sent: Monday, September 16, 2002 3:32 PM
Subject: [jmriusers] timeout on command station
Well, I downloaded the latest JMRI installation files and
successfully got Decoder Pro to execute.
But I got an error message when attempting to read the decoder CV's.
Decoder Pro kept giving an error of timeout while trying to contact
command station. (from memory, wording may not be exact)
The computer is at the club layout and my internet access is here at
home. So I plan to dig out my locobuffer documentation and check
that the jumpers are set for 57 kbaud. That is the extent of what I
can think of to troubleshoot this problem.
The system is a radio Chief and Jabour's locobuffer. I have
installed and successfully run John's RRCntl program to control a
loco on the running track. But this is the first time I have
attempted to talk to the programming track.
Think I have a chance of fixing this probelm with a jumper change?
Cheers
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
timeout on command station
Well, I downloaded the latest JMRI installation files and
successfully got Decoder Pro to execute.
But I got an error message when attempting to read the decoder CV's.
Decoder Pro kept giving an error of timeout while trying to contact
command station. (from memory, wording may not be exact)
The computer is at the club layout and my internet access is here at
home. So I plan to dig out my locobuffer documentation and check
that the jumpers are set for 57 kbaud. That is the extent of what I
can think of to troubleshoot this problem.
The system is a radio Chief and Jabour's locobuffer. I have
installed and successfully run John's RRCntl program to control a
loco on the running track. But this is the first time I have
attempted to talk to the programming track.
Think I have a chance of fixing this probelm with a jumper change?
Cheers
|
Locked
Re: Moderation as a virtue
Dave Nelson wrote:
toggle quoted message
Show quoted text
-----Original Message----- You can also send me a mail that's got enough info in it that I can
tell you're a real person, and I'll take you off moderation before
you're first post.
Thanks for your patience. I joined on the recommendation of Jon Miller, a fellow freight car buff, who
told me about it at the recent PCR meet. I have not yet acquired DCC (I'm
leaning to NCE) and was hoping to learn a few things from this group. So
far I can see the content is way over my head; I doubt I'll be posting --
looks like lurker status for me and to that end I may switch delivery from
e-mail to web page reading.
Dave Nelson
Oh boy. Hang on Dave... The simple answer is your right, this is not the list for new DCC user. That NOT your fault for what has happened is that you have joined an advanced DCC topic list which by it very nature assumes members of the list have some basic understanding of what some of the limitations of the systems are. Of the limitations, this list promotes some very specific solutions to very specific issues to make the advanced user experience even more enjoyable. But let me backup a bit and explain. You do not need to know ANY of this information on this list to enjoy the use of DCC. DCC does nor require any more from you than plain a old DC powered layout would have. You learn what you need to as you need it. DCC in it simplest form is very easy to use and a lot of fun. Many of us have come to understand the depth of it power and control and want to build on that knowledge and abilities to make the operations experience even more enjoyable. I can understand that one who is not familiar with DCC can quickly get confused, intimidate or even scared away from DCC because of all the techno babble that is discussed. However, once you get a hang of all the terminology and familiar with what it means in everyday usage as you operate your new DCC system, then all the pieces to what we are talking about will come together. As stated before, this list is definitely not for the beginner simply because the topic is about advanced DCC applications or more specifically what this group is doing is working with a set of software programs along with a PC that can be used with high end DCC system. The programs range from making programing advanced DCC decoders very easy to do to control you layout signaling system or implement a CTC type Dispatching system. The programs on this list are free and participation by users of the programs are encourage to provide feedback to the writer Bob Jacobson. Hence we often talk about problem with the software to make it better. As for a list that talks about DCC basics, there is the NMRA DCC list since that list is vendor neutral by it very definition. You can join it through the NMRA website. There are many DCC manufacture specific list on this Yahoo groups site that you can join to ask questions about how things work or get a sense of what going on with the particular system. You can find them by going to the yahoo groups home and do a search. Try "DCC" first for that will find most of them. You can also look under the DCC manufacture name too. I hope this clears things up. Hang on Dave. DCC is worth it.... Best Regards, Mark Gurries Linear Technology Power Supply & Battery charger Applications Engineer/Manager --------------------------------------------------------- Model Railroad Club and NMRA DCC presentations are at: -------------------------------------------------------- Audio Enthusiast (Love SAE equipment) ----------------------------------------------------------
|
Locked
Re: Moderation as a virtue
toggle quoted message
Show quoted text
-----Original Message----- You can also send me a mail that's got enough info in it that I can
tell you're a real person, and I'll take you off moderation before
you're first post.
Thanks for your patience. I joined on the recommendation of Jon Miller, a fellow freight car buff, who told me about it at the recent PCR meet. I have not yet acquired DCC (I'm leaning to NCE) and was hoping to learn a few things from this group. So far I can see the content is way over my head; I doubt I'll be posting -- looks like lurker status for me and to that end I may switch delivery from e-mail to web page reading. Dave Nelson -- modeling the Western Pacific in Sept 1950.
|
Locked
Re: Help with ops mode programming?
Bob, MY EBII doesn't offer feedback thus I'm not sure how valuable the following will be; packet: ef e 7c 67 0 40 22 0 0 0 3a 33 33 5d Write Programming Track: Write Byte in OP's Mode (NO feedback) Setting CV1 of Loco 8226 to 58 (0x3a) packet: b4 6f 40 64 LONG_ACK: The Slot Write command was accepted blind (no response will be sent) packet: bb 7b 0 3f Request data/status for slot 123 packet: e7 e 7b 4 40 7e 44 4 68 8 7f 33 33 8 Read Fast Clock: (Data is Valid) Running, rate is 4:1. Day 8, 0:0. Last set by ID 0x3333 Master controller implements LocoNet 1.1, Track Status is Off, Programming Track is Available packet: b4 6f 1 25 LONG_ACK: The Slot Write command was accepted Bob --- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote: I'm away from my layout, and just discovered that I'm not sure how to do Digitrax ops-mode writes to a _short_ address. I've just been
working with long addresses so far, but need to write the handlers
for decoders addressed via the short address.
I'd appreciate it if somebody could send me a trace of a an ops- mode write from a throttle to a decoder with a short address. It doesn't matter what type of Digitrax throttle, what CV, what value, or what
address so long as the decoder address is 99 or less and it's an
ops-mode operation.
Thanks in advance.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)
Am away from Berkeley, responses will be delayed.
|
This Yahoo group is set to "new members posts are moderated". This is because Yahoo groups are increasingly getting spammed, usually by people who sign up a spurious account, send obnoxious email, and then depart.
If you join, and then don't send a post for a long while, you might be surprised when that first post doesn't show up. After all, you've waited a long time to have something important to say, and it just disappeared. That's because its waiting for a moderator to look at it, make sure it's not spam, and forward it. This can take a while if you happen to hit an interval being email checks.
Once you've said something reasonable, we take you off moderation status. Your posts will no longer be delayed beyond the usual Yahoo randomness.
You can also send me a mail that's got enough info in it that I can tell you're a real person, and I'll take you off moderation before you're first post.
Thanks for your patience.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am away from Berkeley, responses will be delayed.
|
Locked
Help with ops mode programming?
I'm away from my layout, and just discovered that I'm not sure how to do Digitrax ops-mode writes to a _short_ address. I've just been working with long addresses so far, but need to write the handlers for decoders addressed via the short address.
I'd appreciate it if somebody could send me a trace of a an ops-mode write from a throttle to a decoder with a short address. It doesn't matter what type of Digitrax throttle, what CV, what value, or what address so long as the decoder address is 99 or less and it's an ops-mode operation.
Thanks in advance.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am away from Berkeley, responses will be delayed.
|
Locked
Re: User interface for "ops mode programming"
Hi-
This is very similar to what I had proposed about a month ago! See: [Image]
at the bottom of the page.
David
Joe Ellis wrote:
toggle quoted message
Show quoted text
--- In jmriusers@y..., "Joe Ellis" <filker@m...> wrote:
<<snip>>
How about _this_ approach?
Allow 2 decoders to be open at once, in "layered" windows. This would
let you twiddle both speed curves.
Maybe this ought to be a "special case" programmer, and use only the
MinV, MidV, MaxV, forward and reverse trim, and speed curve pane (split
horizontally for two locomotives) and allow manual entry of the
address. Here's a _very_ rough graphic of the kind of approach I'm talking
about:
I just pasted this together out of some of the screen shots I did for
the manual.
How about having basic throttle functions available _on_screen_ ? Just
Forward, Reverse, and _28_ speed steps. (the only ones you can adjust
on the speed tables). It would make programming easier by not having to
go back and forth between keyboard and throttle all the time.
While we're shooting the moon, would it be possible to have a "link
throttles" option, so that both locomotives got the same speed
commands? I'm not sure that OPS mode programming of MU'd units might
not defeat the purpose...
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: User interface for "ops mode programming"
--- In jmriusers@y..., "Joe Ellis" <filker@m...> wrote: <<snip>> How about _this_ approach?
Allow 2 decoders to be open at once, in "layered" windows. This would
let you twiddle both speed curves.
Maybe this ought to be a "special case" programmer, and use only the
MinV, MidV, MaxV, forward and reverse trim, and speed curve pane (split
horizontally for two locomotives) and allow manual entry of the
address. Here's a _very_ rough graphic of the kind of approach I'm talking about: I just pasted this together out of some of the screen shots I did for the manual. How about having basic throttle functions available _on_screen_ ? Just Forward, Reverse, and _28_ speed steps. (the only ones you can adjust on the speed tables). It would make programming easier by not having to go back and forth between keyboard and throttle all the time. While we're shooting the moon, would it be possible to have a "link throttles" option, so that both locomotives got the same speed commands? I'm not sure that OPS mode programming of MU'd units might not defeat the purpose...
|
Which version of the program are you using, and which DCC system? I'm using v1.0.6 (I check frequently for updates) and a Digitrax system. Aloha, Jim
|
(About hslider/vslider in a pane in a the decoder file itself)
Bob,
I just found out why hslider/vslider did not work. I assigned a min= value
to the CV. Stupid me.
Sibbo
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
>
>
>
>To unsubscribe from this group, send an email to:
>jmriusers-unsubscribe@...
>
>
>
>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>
>
>
>
>
>To unsubscribe from this group, send an email to:
>jmriusers-unsubscribe@...
>
>
>
>Your use of Yahoo! Groups is subject to
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Re: User interface for "ops mode programming"
No! I like having more than one programmer window open at a time. Then I just pop up the one I need at the moment -- much faster and convenient than reopening them, especially in a club situation, where you may be programming several decoders recurrently. For a 'racetrack' mode, you need to be able to step through the speed tables of both locos concurrently and adjust each speed table entry for one (or even both) loco. I think the stepping through the speed tables doesn't require linking the two op-mode programming pages, but would be convenient. I had envisioned a single page with the spped table of the second loco, and some buttons for stepping up and down the speed tables. David Bob Jacobsen wrote: At 2:42 PM +0000 9/13/02, Joe Ellis wrote:
Well, It's seems to me that one of the biggest reasons for OPS mode
programming is to play with speed matching... sooo...
How about _this_ approach?
Allow 2 decoders to be open at once, in "layered" windows. This would
let you twiddle both speed curves.
Maybe this ought to be a "special case" programmer, and use only the
MinV, MidV, MaxV, forward and reverse trim, and speed curve pane (split
horizontally for two locomotives) and allow manual entry of the
address.
More than one ops-mode programmer can be open at a time, so that's no
problem except for perhaps screen space. It might be useful to
create a programmer format that's really svelte so you can fit 2 or 3
or 4 on the screen at once.
Right now, you can actually open more than one programmer screen at
the same time. They work independently of each other, which is
confusing, but they do work. Once I make these changes to include
ops-mode, I was going to limit it to only one service-mode (e.g.
programming track) programmer window at a time.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to -- David Harris OmniPort Home Page: Discussion egroup: Swiki:
|
Locked
Re: Small speed tables (was re: various)
Do any decoder files need updating before I put this change out? As for as I know the answer is no. Lenz delivered some decoders for Roco products with 27 speed steps. Type and model unknown. sibbo Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: jmriusers-unsubscribe@... Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Re: User interface for "ops mode programming"
At 2:42 PM +0000 9/13/02, Joe Ellis wrote:
Well, It's seems to me that one of the biggest reasons for OPS mode
programming is to play with speed matching... sooo...
How about _this_ approach?
Allow 2 decoders to be open at once, in "layered" windows. This would
let you twiddle both speed curves.
Maybe this ought to be a "special case" programmer, and use only the
MinV, MidV, MaxV, forward and reverse trim, and speed curve pane (split
horizontally for two locomotives) and allow manual entry of the
address.
More than one ops-mode programmer can be open at a time, so that's no problem except for perhaps screen space. It might be useful to create a programmer format that's really svelte so you can fit 2 or 3 or 4 on the screen at once. Right now, you can actually open more than one programmer screen at the same time. They work independently of each other, which is confusing, but they do work. Once I make these changes to include ops-mode, I was going to limit it to only one service-mode (e.g. programming track) programmer window at a time. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Coping with CV1/CV29/etc interactions
Here's my current plan for coping with the various weird and wonderful things that decoders do when you write to CV1. Comments would be very welcome. Would this really solve the problems that people have seen?
I'm going to provide a new variable type "shortaddr" like the existing "shortAddressVal" like the existing "longAddressVal". It will have one new attribute:
"reset29" with values "no", "std" or a bit-mask e.g. "XXXXXVXX". If "no"
nothing happens when CV1 is written. If "std" or reset29 is not
defined, writing this variable will reset the programs value
for the short/long address bit. If a mask, the bits marked "V"
will be cleared when this variable is written.
It will also be possible to provide sub-elements defining a list of CVs that should be cleared when this variable is written.
So when this variable writes CV1, DecoderPro will change the "known" value of CV29 and perhaps others. That will make those variables as "editted", so if you're doing a write all or write sheet, they'll get written with this new value, etc. As far as I can tell, this will also work when you write through the CV pane (is that working these days) because a write to CV1 from the CV pane will make the short address variable as written, causing it to make the above changes.
There are two possible problems:
a) It's still confusing magic as far as the user is concerned. Even though this is doing something that's "NMRA-correct", it's still pretty fiendish.
b) Some PB has to go through all the files and edit-in the new variable type. I could avoid this by having the code treat CV1 as a very special case, but that would involve changes in a lot of places, so I'd rather fix this right.
Does this sound like an OK solution?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
(About hslider/vslider in a pane in a the decoder file itself)
I've tried a couple examples of this in 1.0.6 and didn't see it fail. If you have an example file around, would you mind sending me a copy? Thanks, that'll help me track it down.
Also, is this the reason that you needed to define new programmer files for the Zimo and ESU decoders?
One of the hard things about the XML definitions for decoders is to find a way to make as much of the different definitions "common" as possible. In the long run, I'd like to evolve to a common form for decoder definitions so that we can perhaps even get manufacturers to provide them. Hence the "names" business. If that's not really working for the ESU and Zimo decoders, I'd like to understand why & try to fix it.
I agree it's a hassle. There's probably some kind of tool support that would make it easier, but I haven't had time to really sit and think about that. Perhaps you've got some ideas?
Bob
toggle quoted message
Show quoted text
Re 4
This was a bug that's fixed in (I think) the 1.0.4 version; it's
certainly fixed in 1.0.6. Could you try that and let me know?
I tried them all with version 1.0.6, but no results. "Check XML file" OK'd
the file but trying
to open it will fail.
Re 5
Great! I'd like a copy. Can we include them in the distributions?
I will send them right away. Although more then 10 MX-61's and LokSound2's
were programmed
succesfully please check them carefully and let me know were I can improve.
If they are OK
with you they can be included by all means.
Kind regards
Sibbo
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Adding conditionals to decoder files (was re: various)
At 11:51 PM +0200 9/8/02, Sip Bosch wrote about the possibility of making parts of the decoder definition condition on the version number. Re 2
No, not yet. We've talked about that, but haven't come up with the
right way to do it usefully. Do you have a specific case where it
would help?
The differences between the early and late model MX-61 are substantial so
separate xml-files
were legitimate. But what in the case of few but substantial differences
like some Lenz
decoders have.
We could add a "minversion" to the individual variables. The default behaviour if the attribute isn't present would be the same as now. If that attribute was present and contained a number, the CV7 version number read from the decoder would determine whether the variable was defined or not. If the value was lower than the attribute, the variable definition would be ignored. If the value was equal to or greater, the variable would be defined and would appear on panes, etc. This is a lot like the way we handle variable number of functions & outputs now. It would be easy to add something along these lines because it could just piggyback on the minOutput/minFunction code. But it feels like a real stop-gap to me. It doesn't handle non-contiguous values very well, nor features that change or disappear in a higher version. And it's not clear how to handle the case of a user selecting that particular definition from the tree of possible decoders. Does such a definition appear or not in that case? So in the end I decided I didn't really understand what this should do, and didn't want to dig into a hole that would require supporting more and more complicated files. Perhaps somebody could write a specific proposal? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
At 12:30 PM -1000 9/8/02, Jim Buckley wrote: A possible bug in the Sountraxx DSD150 Diesel programmer's Function Mapping
screen. I wasn't able to confirm this on any other programmers -- I was
especially hoping someone could check a DSD150 Steam Function Mapping screen
since it's guts are probably similar. Here's what happens:
When using the Function Mapping screen for the first time, all check boxes
show up and can be manipulated. However, after performing the Read Sheet
operation, the boxes reflect decoder programming as they should, but any
time you return to that screen, there are no check boxes in any of the
columns to the right of and including F1 and the column headers "bell",
"horn", etc. are replaced by numbers. The boxes are lost forever for this
particular roster entry. Any new virgin screen contains all the boxes like
it should. Seems to happen only after a Read Sheet operation.
Also, is this the proper place to report bugs or is there a special address
to use? Sorry for the slow response. I was hoping that somebody else with a DSD150 could try that and see if they get the same thing. This is a fine place to ask about problems, etc. Which version of the program are you using, and which DCC system? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Bob Jacobsen