开云体育

-----Oorspronkelijk bericht-----
Van: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Verzonden: vrijdag 13 september 2002 15:49
Aan: jmriusers@...
Onderwerp: [jmriusers] User interface for "ops mode programming"


I'd like to ask about how the user should see "ops mode programming"
in DecoderPro.

Does this sound OK to people?

OK with 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.

At 3:45 PM +0200 9/8/02, Sip Bosch wrote:

1. If the number of entries in the speedtable is less then 28
(i.e. - entries="15") it is not shown accordingly on the speedtable pane.

I think I've fixed this. I didn't see a decoder file that defines a speed-table smaller than 28, so I hacked one together for a test.

Do any decoder files need updating before I put this change out?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob-
This sounds excellent to me. How close are you to having the code done? I
would like to try to get a Racetrack like program added to the system, and
the Ops mode would be essential. Unfortunately, I won't have any time for
that until into October.
David

Bob Jacobsen wrote:

I'd like to ask about how the user should see "ops mode programming"
in DecoderPro.

For technical reasons, it would be significantly simpler to code it
(at least for today) if the program could assume that a Roster entry
already existed for a decoder accessed in Ops Mode.

To do that I suggest:

a) The DecoderPro main page now contains a "Program Locomotive..."
button and a "Quit" button. The "Program Locomotive..." button would
be renamed to "Program Decoder on Programming Track..." and continue
to function the exact same way. "Quit" would remain unchanged. A
new "Program on Main Track..." (PMT) button would be added, see
below. (These names are wordy and obscure. Can somebody suggest a
better way to capture this difference that's not system-specific?)

b) Pressing the PMT button pops a new screen similar to the top-half
of the existing ident screen. There's a selection box to pick a
roster entry, and an open-programmer button. But there's no ident
button(s), and no decoder-selection tree.

So you click "Program on Main Track ...", select the loco from your
existing ones, and go.

If you don't have a roster entry for a loco, you should probably put
it on the programming track and "Read All" to create one. But you
could just create a dummy entry with the right address, but without
ever hitting a read or write button, and then use that for ops mode.

Does this sound OK to people?

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:

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

I'd like to ask about how the user should see "ops mode programming"
in DecoderPro.

<<rubbing my hands in gleeful anticipation... >>

For technical reasons, it would be significantly simpler to code it
(at least for today) if the program could assume that a Roster entry
already existed for a decoder accessed in Ops Mode.

Hmmm... A good idea, certainly makes sense. Only _potential_ reason not
to would be so that "visiting locomotives" could be programmed quickly,
but I don't see that as being a frequent need.

To do that I suggest:

a) The DecoderPro main page now contains a "Program Locomotive..."
button and a "Quit" button. The "Program Locomotive..." button would
be renamed to "Program Decoder on Programming Track..." and continue
to function the exact same way. "Quit" would remain unchanged. A
new "Program on Main Track..." (PMT) button would be added, see
below. (These names are wordy and obscure. Can somebody suggest a
better way to capture this difference that's not system-specific?)

Hmmm... how about radio buttons? Text saying "Program locomotive on:"
then radio buttons labeled "Programming Track" and "Layout", then use a
"Select Locomotive/Decoder" button to open the appropriate window.

b) Pressing the PMT button pops a new screen similar to the top-half
of the existing ident screen. There's a selection box to pick a
roster entry, and an open-programmer button. But there's no ident
button(s), and no decoder-selection tree.

So you click "Program on Main Track ...", select the loco from your
existing ones, and go.

If you don't have a roster entry for a loco, you should probably put
it on the programming track and "Read All" to create one. But you
could just create a dummy entry with the right address, but without
ever hitting a read or write button, and then use that for ops mode.

Does this sound OK to people?

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.

I'd like to ask about how the user should see "ops mode programming" in DecoderPro.

For technical reasons, it would be significantly simpler to code it (at least for today) if the program could assume that a Roster entry already existed for a decoder accessed in Ops Mode.

To do that I suggest:

a) The DecoderPro main page now contains a "Program Locomotive..." button and a "Quit" button. The "Program Locomotive..." button would be renamed to "Program Decoder on Programming Track..." and continue to function the exact same way. "Quit" would remain unchanged. A new "Program on Main Track..." (PMT) button would be added, see below. (These names are wordy and obscure. Can somebody suggest a better way to capture this difference that's not system-specific?)

b) Pressing the PMT button pops a new screen similar to the top-half of the existing ident screen. There's a selection box to pick a roster entry, and an open-programmer button. But there's no ident button(s), and no decoder-selection tree.

So you click "Program on Main Track ...", select the loco from your existing ones, and go.

If you don't have a roster entry for a loco, you should probably put it on the programming track and "Read All" to create one. But you could just create a dummy entry with the right address, but without ever hitting a read or write button, and then use that for ops mode.

Does this sound OK to people?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

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?

Aloha,
Jim

Bob,

It is a pleasure working with DecoderPro. Not only are new loco's easily
programmed but the
possibility of saving what one has done makes it a tremendous tool.

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.


Re 3
I think that should work, but I don't recall using it in a decoder
file. Is it not working for you? It's a tricky bit of code, so there
might well be bugs there.

Actually I could not get it to work. This is the code I used on the
LokSound2 on CV 9 (PWM period);
<enumVal>
<enumChoice value="0" choice="22 KHz"/>
<enumChoice value="204" choice="87 Hz"/>
</enumVal>

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.

At 3:45 PM +0200 9/8/02, Sip Bosch wrote:

Allow me the following remarks and implicit questions;

Thanks for going through it so carefully, and for taking the time to write.

1. If the number of entries in the speedtable is less then 28
(i.e. - entries="15") it is not shown accordingly on the speedtable pane.

This is a bug, thanks for catching it.

2. Can I use options/inOptions like a "if"-statement (i.e. if decoderversion
is "x" then ...)

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?

3. In case of two different values to be assigned to a CV (i.e. either "128"
or "12") can I use enumChoice combined with the value="xxx" statement

I think that should work, but I don't recall using it in a decoder file. Is it not working for you? It's a tricky bit of code, so there might well be bugs there.

4. Reading the decoder-config.dtd I got the impression that vslider, hslider
etc. were allowed on the specific mfg pane. Either I'm doing something wrong
or....

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?

For those interested I completed the Zimo MX-61/62 and ESU Loksound2 xml
files. Let me know and I send them directly.

Great! I'd like a copy. Can we include them in the distributions?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob,

Allow me the following remarks and implicit questions;

1. If the number of entries in the speedtable is less then 28
(i.e. - entries="15") it is not shown accordingly on the speedtable pane.

2. Can I use options/inOptions like a "if"-statement (i.e. if decoderversion
is "x" then ...)

3. In case of two different values to be assigned to a CV (i.e. either "128"
or "12") can I use enumChoice combined with the value="xxx" statement

4. Reading the decoder-config.dtd I got the impression that vslider, hslider
etc. were allowed on the specific mfg pane. Either I'm doing something wrong
or....

For those interested I completed the Zimo MX-61/62 and ESU Loksound2 xml
files. Let me know and I send them directly.

Sibbo

Had a quick look through the revised document and must say you've
made some excellent changes. Great Work!

Bob

--- In jmriusers@y..., "barr_ceo" <filker@m...> wrote:

OK... Spelling corrected, incorporated Programming Mode

explanations,

and reformatted things so that all the graphics are in a separate
folder so I don't get confused so easily...

"Nuff. I'm going to bed. <<grin>>

Gotta re-build a Saxophone this weekend, so that will keep me

pretty

busy. Probably won't do any more updates of the Manual until

V1.0.7...

I'm expecting to have to redo a bunch of screen shots for that one

if

Bob incorporates the Programming Mode changes he was talking about.

OK... Spelling corrected, incorporated Programming Mode explanations,
and reformatted things so that all the graphics are in a separate
folder so I don't get confused so easily...

"Nuff. I'm going to bed. <<grin>>

Gotta re-build a Saxophone this weekend, so that will keep me pretty
busy. Probably won't do any more updates of the Manual until V1.0.7...
I'm expecting to have to redo a bunch of screen shots for that one if
Bob incorporates the Programming Mode changes he was talking about.

At 9:17 AM -0700 9/5/02, Bob Jacobsen wrote:

[ ... ]
Register mode is an extension of address mode. You literally cannot
have register mode without address mode, as a write to the short
address in register mode is an identical sequence to an address mode
write. But register mode only allows you to change a few things, not
all the various CVs. There are some older register-mode-required
decoders still being sold, mostly from MRC and Wangrow. And a _lot_
of people have them!

[ ... ]

It's been so long since I thought about this stuff I've probably got
it wrong. The two really old (pre-DCC standard!) Lenz decoders I have
installed in the boxcab (#36) and the MDC Consolidation (#32) probably
do not have more than one programming mode. IIRC you poked at them one
evening to add to the list. FWIW.




--+---+ &#92;/ -bill
++---+ |[]]|_^_[] steamloco2001@...
_|____+-+___|____|_ Concord, CA
| o+o +-+ <>--<>-= &#92;

You're doing a great job Joe, maybe a double barrel 10 gauge :).

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

--- In jmriusers@y..., "Jon Miller" <atsf@i...> wrote:

Joe,
Do you think Bob's discussion on decoder modes would be good to add to
the manual or just confusing? If added it probably would go with "How to
select the right decoder programmer" Your thoughts?

Jon Miller

Only in a very simplified form. Most users don't need to know _why_ something is, just how to use it and when. For me, having enough information to write clear instructions is important. I _think_ I've got that now. I'll write something up and get it into the next update (probably late tonight or tomorrow...)

I'm glad I'm doing this in HTML, and broken into pages. It's becoming more obvious that I'm aiming at a quickly moving target, and I'm better off with a shotgun than a rifle! <<grin>>

PULL!! <<blam blam blam....>>

At 6:11 PM +0000 9/5/02, barr_ceo wrote:

The most extreme example of overly wide graphics is the Speed Control page. I _did_ scale the shots of the effects of the "curve" buttons down because no essential information was lost - the shape of the curve was still evident. If I scale the others, though, it makes it impossible to read the text.

On MacOS X, Windows and Linux, the size of some of the fonts is shrunk to make that page fit better. Unfortunately, the method used to shrink fonts isn't available on original Macintosh and OS/2. (That's the bug that was causing your crash in 1.0.5). I've gotten some advice on a different shrinking method that should work for those, and hope to try it in 1.0.7 by early next week.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

At 11:02 AM -0700 9/5/02, Mark Gurries wrote:

Accidentally clicking on a programming mode button could lead to problems
as well as showing to much information is potentially confusing. I
would suggest that the program only show the current mode in real time. However, clicking on the MODE display window would take you to a dialog
box that shows you all the options and Defaults. A note would tell
people what this is about and suggest leaving it alone unless they know
what they are doing. Naturally there would be a cancel button to clear
the window without changing anything.

So in place of the existing line of radio buttons, the identification panel and the main (tabbed) programming panel would have a bottom line that looked like

Paged programming mode (Set...)

where the (Set...) is a button, and the rest is text which could say "Register programming mode", "Direct byte programming mode", etc. Clicking the button pops a dialog box with some explanatory text and the option radio boxes, plus "OK" and "Cancel" buttons which do the obvious thing.

That's a straight-forward change in the code, and I'm happy to make it if people think it an improvement.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

--- In jmriusers@y..., jerry snyder <jerrys@c...> wrote:

Really a nice work! I have just printed it and am sure it will be helpful
in mastering Decoder Pro.

Umm... I didn't really think anyone would want to actually print this whole thing out - rather, just use it online. When we get the initial kinks worked out I'll try to do an archive file that has the whole thing in it so it can be downloaded and accessed off your own computer instead of over the net. That will speed things up considerably!

I noticed in printing that:

The link to using Decoder Pro also includes the Using the Basic Programmer
section. I almost printed this section twice.

Probably because they're on the same "page"... I used "Targets" to go to the appropriate key points. Should I break this out onto its own page? I thought it made more sense this way...

The last screen shot, Setup and Roster Panes, is too wide for the
document. The right portion is clipped.

The screen shots for the Comprehensive Programmer are big and wide. (around 830x598, give or take a pixel or two) There's a lot of "white space" (actually, gray space) in the screens, but I didn't want to potentially confuse folks by changing the way the screen looked. If a screen is clipped, there's a scroll bar in it to get to the hidden part. (probably ought to add that to the manual, too...)
Can your browser print at, say, 85-90% size? That should solve the problem.

The most extreme example of overly wide graphics is the Speed Control page. I _did_ scale the shots of the effects of the "curve" buttons down because no essential information was lost - the shape of the curve was still evident. If I scale the others, though, it makes it impossible to read the text.

Now to get to what was asked about typo's etc.

BTW is filker@m... the Joe Ellis recently of Orlando N'Trak fame?

That's me! What, you didn't recognise the BARR roadname in the roster screen? <<grin>> Hi, Jerry!

Cheers


jerry snyder
Orlando, FL

At 10:56 AM -0700 9/5/02, Jon Miller wrote:

>we typically use Paged Mode programming most of the time<
Very true and I do also. Except for one item I always make a mistake on
and that's the AD4 which is direct only. Also I believe the RP's went to
suggesting all future decoders be direct (or something like that)!

The AD4 is a good example of how it currently works.

When I opened an ID panel just now, it picked paged mode. That would have had trouble identifying an AD4 (though I don't have one to try it with). If I manually select AD4, though, and open the programming, it will open in direct byte mode, and should work.

There are two steps there, which makes it confusing. Good thing we've got a manual to explain all this....

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob Jacobsen wrote:

The program will gray-out modes that the attached DCC system can't
use. But it _won't_ gray out modes that the current decoder can't
use. It won't select those automatically, but it does allow you to
select them manually. This may be a mistake, but my logic was "We
don't have files for every decoder ever made, and not all files are
perfect. People might have a decoder that's a 'XXX except it also
allows this other mode', etc, so let's let them override the
program's choices". If the concensus is that this is just too
error prone, we can change it.

The original plan was to have the options grayed out when the decoder was
identified and such the identification allowed sufficient revision
information to know what the decoder supported. But alas as many of you
know, the revision info does not always work given the inconsistency of
the how the revision codes are use and what they indicate.

However, I would at least try to go with family definitions to limit the
options to a common subset that you know will work. That way the system
always takes advantage of the best mode for that family.

Accidentally clicking on a programming mode button could lead to problems
as well as showing to much information is potentially confusing. I
would suggest that the program only show the current mode in real time.
However, clicking on the MODE display window would take you to a dialog
box that shows you all the options and Defaults. A note would tell
people what this is about and suggest leaving it alone unless they know
what they are doing. Naturally there would be a cancel button to clear
the window without changing anything.



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)


----------------------------------------------------------

At 10:13 AM -0700 9/5/02, Jon Miller wrote:

Do you think Bob's discussion on decoder modes would be good to add to
the manual or just confusing? If added it probably would go with "How to
select the right decoder programmer" Your thoughts?

A lot of what I do is just confusing...

Seriously, perhaps this could appear at several levels. In the main flow of the text you have something like "used paged unless its not working right, in which case try register or direct", perhaps with a sentence or two about the types of problems you'll encounter if you've got an incompatibilty. There could also be a link to more info, that goes into a little more depth for those who really want to learn more.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)