开云体育

The 0.9.3 update is out, so after I catch my breath, it's time to think about what to do next.

I'd like to get a "complete" DecoderPro version out by early July, but I'm not certain what should be considered the most important things to put in it. I've got a long list of little updates, fixes and cleanups to include, and I'll probably get to most of them. Big features are a little more problematic, as I don't often have the large chunks of time they require.

I've already promised to add Lenz XpressNet support to JMRI and DecoderPro, and C/MRI support to JMRI itself. So those will be happening. I've got some other stuff I'm playing with on the layout-control side of the house, and I'll probably keep doing that too.

But beyond those, I'd like to see what people think are most important. What would you most like to see?

Some of the items that have been suggested include:

a) Ops mode programming

b) Better programming GUI, for example making it possible to have some variables control whether others display, etc. Break some parts (roster pane, function mapping) into smaller parts so you could create a programmer that walks you through one item at a time (e.g. a "step 1" pane that handles the address, then a "step 2" pane that saves the file, then a "step 3" pane that sets momentum, etc)

c) Much smarter speed-table support, with various tools for smoothing curves, resetting the curve to a standard one, adjusting it to the contents of Vstart/VMid/VEnd, etc

d) Improvements to the roster - being able to copy & delete locomotives, better editing, import/export to various common formats, etc.

e) Fix the long-standing problem with many PCs not being able to connect at the MS100 baud rate. (This is a LocoNet-only problem, and I'll need help from somebody who speaks windows)

f) Integrated installers, esp. for Windows. The current multi-step install process is getting in the way. It would be pretty simple to create a two-step install process of the form "Run this Java installer, then run this DecoderPro installer", perhaps with an updater that makes future updates quicker downloads.

g) Lots more decoders

h) Add a progress bar when programming. This is not trivial, unfortunately, because the program doesn't really have any idea how long the programming will take, or even how many CVs are left to do. It would take a little effort to get that right-enough to be useful (nobody likes a progress bar that gets shorter, then longer, then shorter)

i) Get the "confirm" button working. This is really only faster on LocoNet command stations right now, as all others need to do a complete read to implement it. But it's still a useful thing to have when working with problematic decoders, e.g. you wonder whether the decoder's been changed, etc.

j) Make the programmer GUI more bullet-proof. Now, if you type letters in a decimal field, enter a too-large or negative number, etc, Bad Stuff happens. It would be good if that were more robust.

What do people think?

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

Bob,
You could copy your multi-page fine printed list* here and let us chose,
say, five items. Then do the higher percentages! Short of that my choices,
of those listed, are;
a. (I don't use this but a lot of people do.
f. (It might get us more Windows users)
d. (At least just the delete key, for mistakes)
g. (Users always want "their" decoder)

thoughts, and I have no idea how easy this would be.
j. -enter a too-large or negative number- Just add text "8 digit number
only" This would tend to indicate if you did something different bad things
would happen.
e. I would have put this above as I think it's one of the upper priority
items but without a Windows person it's hard to do. It would pick up more
Digitrax people though!
xx items. Sometimes just text on the panes would help but the real problem
is exactly what text and where.

* this is real, I've seen it <G>.



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

On Tuesday 14 May 2002 09:12 am, Bob Jacobsen wrote:

a) Ops mode programming

Good.

d) Improvements to the roster - being able to copy & delete
locomotives, better editing, import/export to various common formats,
etc.

It would be nice to have a simple way to copy the programming of one decoder
into anther. I have 2 GP9s and would like them to both have the same
characteristics.

It would be nice to be able to 'inherit' a roster entry when a new
decoder/loco is added to the roster. For example, loco #123 exists and loco
456 has the same decoder. It would be nice if the configuration from loco 123
could be copied to loco 456 as a starting point.

f) Integrated installers, esp. for Windows. The current multi-step
install process is getting in the way. It would be pretty simple to
create a two-step install process of the form "Run this Java
installer, then run this DecoderPro installer", perhaps with an
updater that makes future updates quicker downloads.

And perhaps: add a bin directory where all the scripts live and place
jmri.jar in the lib directory. For a Linux install, one could then simply
place DecoderPro in /usr/local/DecoderPro and create a symlink from
/usr/local/bin/dp -> /usr/local/DecoderPro/bin/DecoderPro.csh (or something
like that). Other platforms may have similar conventions to follow.

g) Lots more decoders

An Internet decoder registration tool built into DecoderPro. This would be
similar to the various CD players where if the CD player does not recognize
the CD (based on number of songs and length of each song) it queries the DB
on some Web server. If the unknown CD (decoder) is in the DB then DecoderPro
can update itself and the user can then use that definition. (you no longer
have to spin a new version of DecoderPro when new decoder files become
available). If the CD is not in the DB, the DB server also provides a way for
a user to enter the CD information and upload it to that central DB
(presumably someone checks the upload).

cheers,
Mike

It would be nice to have a simple way to copy the programming of one

decoder into anther. I have 2 GP9s and would like them to both have the same
characteristics.<

We played around with this some at the clinic and not sure what
happened. I think this.
1) You can open a file for the existing loco, say #1234.
2) You can then change the loco number, to #5678 and program all. Then
save. I think this works but we didn't spend much time with it and without
the ability to delete files (it's hard by hand) we (I) didn't experiment
much!

Lots more decoders<

Of course the really best would be convince manufactures that DecoderPro
is the (only) way to go and they would create the files.


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

On Tuesday 14 May 2002 10:22 am, Jon Miller wrote:

It would be nice to have a simple way to copy the programming of one

decoder into anther. I have 2 GP9s and would like them to both have the same
characteristics.<

We played around with this some at the clinic and not sure what
happened. I think this.
1) You can open a file for the existing loco, say #1234.
2) You can then change the loco number, to #5678 and program all. Then
save. I think this works but we didn't spend much time with it and without
the ability to delete files (it's hard by hand) we (I) didn't experiment
much!

Did this replace the file for 1234?

Lots more decoders<

Of course the really best would be convince manufactures that DecoderPro
is the (only) way to go and they would create the files.

Perhaps if 'we' created a standard XML format (schema?) to describe decoders
and created a central Internet-accessible DB of those XML definitions we
could get more buy in. A common format would allow the central DB to be used
by all decoder programming tools and would allow decoder manufacturers to
produce a single description file.

Mike

That's a good idea. Any one an XML 'expert'?
David

Mike Davison wrote:

Actually, the decoder format is XML, perhaps DecoderPro could ping the jmri.sourgeforge.net page to look for new files occaisionally?

-Dave

Bob:

In answer to your question,"What do people think?", I think this looks like a very ambitious undertaking and I don't know how you find the time to do it but we sure are glad that you do!! As a new user to the program(Robin Becker introduced me to it) I don't yet know all the in and outs but I did take your advice and have my computer guy getting a used PC ready for me to use in the train room with my NCE. After it is installed and I get some hands on work programming my locos, maybe I will be able to contribute more to the group. I have been helping Robin with the Soundtraxx CV7 problems so hope that gets straightened out soon.

Thanks again for the neat program,

Jim Hanna
El Cajon, CA

That would work and be easier to implement that my suggestion. When
DecoderPro runs it could determine if it's updated decoder files recently. If
not, it could check sourceforge for updates. It would probably be a good idea
if this behavior was configurable as some folks may not want DecoderPro
hitting the Internet at all while others would like it to do the update check
frequently.

Mike

Did this replace the file for 1234?<

I seem to remember "no". But as deleting files is difficult I didn't
feel like loading up my system with non-existent locos. Also we had a group
(well four<G>) and I wanted all to get "time on" DecoderPro!
I will do some playing later but have to take a week away.

Also just a mention on a decoder manufactures website would be grand.
Of course
'their decoders" would all have to be there<VBG>. I'm thinking to get the
jump on a new Broadway Limited engine would be neat. Who has ordered one
that could create a file for it.

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

Bob,

We need a "Test for Decoder" window/Step/Button.

Here's the problem

When someone brings up Decoder Pro, one of the most common problems is
making sure the decoder is working on the programming track. People
start with simply putting the engine on the engine and start with the
ASSUMPTION everything is working. Many times during startup there are
problems especially with new decoder installations. The other is that
sometimes during programming,, the locomotive physically moves only to
die on me because of dirty track. But the user may not know that and
naturally move on. The other is the programming current may be to high
and programmer station reports a Fault. Anyway, after they place the
loco on the programming track, they start to figure out which button "ID
for loco" or "ID for Decoder" to use. Because the "ID for Loco" is the
TOP button, most people not knowing what to do try that button first.
Nothing wrong with that. But in this case the program does not find the
locomotive because the decoder is not working, but they do not know that
it is NOT working. Not getting results they thought they would get, they
next try "ID for Decoder" to see if that will work instead. Again no
results but the system says it cannot identify the decoder brand when in
fact it got no response. So the explanation is incorrect and starts
people down a confusing path. Some go ahead anyway since most people
have no idea what they should see and proceed not understanding the
values they are getting reported are completely bogus. Reading a value
of 255 is usually a good sign that a decoder is NOT there. The point is
that they get lost and the decoder does not get programmed leading to
frustration.

In other words, because the decoder is not working, people start going
off in other directions only to get lost. Most experience users figure
out very early on that there is something wrong with the engine and are
able to correct the problem since we have an idea of what we should see.

So here is what I propose. When the user "clicks on" open programmer
button from the splash screen, a new top floating screen is shown above
the normal ID screen that is shown. At the top of this floating screen
is the title "Looking for a working Decoder". At the bottom are three
buttons.

1) Quit. Exits and goes back to splash screen.
2) Retry. Redo the test assuming the locomotive has been fixed by the
user.
3) Proceed Anyway. This tell the programmer to ignore all errors. We
need this for those decoders that draw to much power but can be
programmed anyway. Choosing this option essentially defeats all this
decoder reading checking process until the current session is closed. In
fact I would think that the READ button would ALSO be disabled with this
option since reading will only generate more errors. Of course a note
will pop up telling the user the consequences of choosing this option.

Anyway...

The program automatically goes into what every programming mode is
necessary and reads the decoder Manufacture ID looking for any value
other than 0 or 255. This is done 3 times in a row. If you get a value
of 0 or 255 at any time, then the decoder is considered not working and
reports that to the uses then allowing him to go check the locomotive and
retest until a favorable report is received. Once a favorable report is
received, Decoder found statement is shown for a moment and the screen
automatically goes away and the normal ID screen is presented. If not,
then the user is asked to check that:

A) the locomotive is seated correctly on the track.
B) the locomotive wheels and Programming track are clean.
B) DCC mode is enabled (Some decoders have a DC or DCC mode jumper like
Atlas)
C) The decoder is actually connected properly. Check for lose open wires.

If the system reports a short, then the screen should say a short has
been detected.

A) Make sure all Function lights are off or disconnected if the run from
track power.
B) Any other electrical accessory (Smoke Generators) are disconnected if
the run from track power.
C) Check to see if the locomotive is seated correctly on the track.
D) There are no lose uninsulated or pinched wires inside the locomotive


You get the idea, but there is more

On every normal programming window pane, there is a new "DECODER STATUS:"
Status line. Possible sharing the same space as the Programming status
line. The status line has 4 values displayed

1) "OK" in green or white if no errors are recorded
2) "UNKNOWN" status in Yellow if any single CV values reports back as
255. If the next CV read is not 255, then it changes back to "OK"
3) "FAILURE" in Red if more than one CV reports 255 one after the other.
4) "IGNORE" in green or white. This appears ONLY if the "Proceed Anyway"
button is pressed on the "Looking for a working Decoder" window.

The CV checking process does not interfere with the current activities,
but does give the user confidence about what is going on. A watchful Eye
so to speak. With this report the user is now informed about the decoder
and has the option of going to the bottom of any window pane where they
can find a button called "Test Decoder". When a person suspects that
there is something wrong, clicking this button allows them to suspend the
current programming session and bring back up the "Looking for working
Decoder" test screen again. When operation is restored, the user goes
back to where they left off. In fact you may want to suggest that they
reread current window values to verify all is correct.

I really think this would be a big differentiating feature that make your
program even better. Be able to program in confidence addresses one of
the most intimidating things about DCC.

That the big Idea. I leave it up to you to figure out how to do it.

Different subject. We talked about a progress bar. I think a temporary
form of a progress bar would be in fact be a Elapse Timer instead. Every
time Decoder Pro is waiting for a response, the timer keeps counting up
the time in seconds starting from zero. When the response comes back, the
timer is reset. This also gives the user a sense of how well the
programming is going. Things that take longer then normal can sometimes
be a clue to something is wrong. An expansion on this timer function
would be a timer that keeps track of the elapsed time for the ALL READ
and ALL WRITE commands from start to finish. Sort of a bench-marking
capability indicating total system speed. It would also allow people to
see what effects a change, hardware or software, effected his system.




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)


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

Having a "Update Now" button would work, too.

For those who want to schedule updates it probably makes sense to use
something like Mac OS X uses:


----------



-Dave

Bob

How about stationary decoders? DS54 for instance. Nice little GUI to
handle it all. Any ideas?

cheers
bob

Hello Bob,
I am new one with only two question-suggestion for start:
-What about layout feedback,
-What practically mean your plan "Lenz XpressNet support to JMRI"?

Best regards,
Aleksandar

At 3:47 PM +0200 5/15/02, Aleksandar Vukalovic wrote:

Hello Bob,
I am new one with only two question-suggestion for start:
-What about layout feedback,

That's what I originally set out to do last summer, before getting distracted by a bunch of other uses. The program now has some limited capabilities to do that; it can throw and track turnouts, animate a little track plan as things change, etc. But it will probably never be in the same "point&click" league as the commercial products such as WinLok and RR&Co; it's more aimed at being a library you can use to write your own programs more easily.

-What practically mean your plan "Lenz XpressNet support to JMRI"?

First, make it possible for DecoderPro to program decoders with an XpressNet command station (Lenz or Atlas Commander) via a LI100 interface. Then add turnout control, throttles, etc.

Bob

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

Hi Bob, thanks for answer.

That's what I originally set out to do last summer, before getting

distracted by a bunch of other uses. The program now has some
limited capabilities to do that; it can throw and track turnouts,
animate a little track plan as things change, etc. But it will
probably never be in the same "point&click" league as the commercial
products such as WinLok and RR&Co; it's more aimed at being a library
you can use to write your own programs more easily.<

OK, and what about monitoring of track/block occupation (from
detectors)?

What practically mean your plan "Lenz XpressNet support to JMRI"?<<

First, make it possible for DecoderPro to program decoders with an

XpressNet command station (Lenz or Atlas Commander) via a LI100
interface. Then add turnout control, throttles, etc.<

I am not sure, but XpressNet and Li(F)100 with PC communication is
separate and different things (programs, protocols...)?


Best regards,
Aleksandar

I'm a complete newbie at this, just having received my my DCC system,
programmed 4 decoders, and having not yet actually used DecoderPro (just
started it up to play with it). However, I consider that the basic
programming (address, basic configuration) is reasonably easy to do
through the throttle and in theory should only have to be done once.

What I'm hoping to use DecoderPro for is Speed Tables (and probably BEMF
once I get some of the BEMF decoders installed). Given that speed
tables require multiple CVs to be set, and maybe a few times until they
are operating as desired, I would put the higher priority on getting
these features working reliably.

Making the GUI more bullet-proof is also a good goal - if the program
crashes on simple entry errors, people will likely be put off quickly.

Dennis

Bob Jacobsen wrote:

The 0.9.3 update is out, so after I catch my breath, it's time to
think about what to do next.

I'd like to get a "complete" DecoderPro version out by early July,
but I'm not certain what should be considered the most important
things to put in it. I've got a long list of little updates, fixes
and cleanups to include, and I'll probably get to most of them. Big
features are a little more problematic, as I don't often have the
large chunks of time they require.

I've already promised to add Lenz XpressNet support to JMRI and
DecoderPro, and C/MRI support to JMRI itself. So those will be
happening. I've got some other stuff I'm playing with on the
layout-control side of the house, and I'll probably keep doing that
too.

But beyond those, I'd like to see what people think are most
important. What would you most like to see?

Some of the items that have been suggested include:

a) Ops mode programming

b) Better programming GUI, for example making it possible to have
some variables control whether others display, etc. Break some parts
(roster pane, function mapping) into smaller parts so you could
create a programmer that walks you through one item at a time (e.g. a
"step 1" pane that handles the address, then a "step 2" pane that
saves the file, then a "step 3" pane that sets momentum, etc)

c) Much smarter speed-table support, with various tools for smoothing
curves, resetting the curve to a standard one, adjusting it to the
contents of Vstart/VMid/VEnd, etc

d) Improvements to the roster - being able to copy & delete
locomotives, better editing, import/export to various common formats,
etc.

e) Fix the long-standing problem with many PCs not being able to
connect at the MS100 baud rate. (This is a LocoNet-only problem, and
I'll need help from somebody who speaks windows)

f) Integrated installers, esp. for Windows. The current multi-step
install process is getting in the way. It would be pretty simple to
create a two-step install process of the form "Run this Java
installer, then run this DecoderPro installer", perhaps with an
updater that makes future updates quicker downloads.

g) Lots more decoders

h) Add a progress bar when programming. This is not trivial,
unfortunately, because the program doesn't really have any idea how
long the programming will take, or even how many CVs are left to do.
It would take a little effort to get that right-enough to be useful
(nobody likes a progress bar that gets shorter, then longer, then
shorter)

i) Get the "confirm" button working. This is really only faster on
LocoNet command stations right now, as all others need to do a
complete read to implement it. But it's still a useful thing to have
when working with problematic decoders, e.g. you wonder whether the
decoder's been changed, etc.

j) Make the programmer GUI more bullet-proof. Now, if you type
letters in a decimal field, enter a too-large or negative number,
etc, Bad Stuff happens. It would be good if that were more robust.

What do people think?

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

Yahoo! Groups Sponsor

ADVERTISEMENT
[Image]

Height: ftin

Weight:

Sex:FM

To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.