开云体育

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)


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

Bob,
You could copy your multi-page fine printed list* here and let us chose,
say, five items.

Well, since you asked...

Jon is referring to a "to do" list that I keep for JMRI/DecoderPro.
It's in a little database, so not easy to really show well in an
email, but I've dumped it below. In cases where there's some context
needed, e.g. I've assigned guilt to some element, there's a comment
to that effect in (). This is a little terse, as it's made from a
working document where I just jot down things I don't want to forget.

It's got about 200 items on it. Most are quite small, like a fix to a
small bug I don't want to forget, adding a missing test, etc. But
some are really, really large.

Bob


(Windows .bat files) Line-end problems when directly copying, reading from CD

Write README parts of LocoNet server, update web pages

Ant target for making update distributions

(PaneProgFrame) lifting read/write All doesn't stop until pane is
done (never, if pane is in error loop)

Pane Prog memory usage high again. Missing dispose? Scrolling?

Can't set baud rate on too many machines; try another javax.comm e.g. rxtx

(AllTest) TurnoutIcon test fails when running from Ant; resources missing?

Should default logging level be ERROR? MarkG things it should never
really issue messages?

LocoIO config frame and XML files

(LocoIO) Add support for B2 output (send OPC_INPUT_REP)

Build infrastructure for EasyDcc web access

LocoNet health counters for display (suggested by Alex Shepherd
2002-04-14 email)

(Lenz) register mode in programmer

Ant target for making distribution CD

Understand Jon's suggestion about using the User ID CVs for decoder
identification

(Decoder definitions) Provide version-number-controlled options, e.g.
"present for version > N", etc.

(Layout) Connect layout to Turnout manager via messages from TurnoutManager

(LocoNet) Move initial Manager config out of
LnTrafficManager/PortAdapter for simplicity

Merge Alex's autostart rmiregistry into startup scripts

Create a utility strings package to handle parsing, hex output formatting, etc.

(jmri.jar) Is this getting large due to the resources/ files? Are they in CVS?

(rmi) Apps need to be rebuilt with JVM options?

Roster management code

If you save a Loco as a new ID, you should get a _new_ entry (old
still exists)? Or provide another way to copy, and warn user

Need a way to import new roster files. Part of Update? How tell
backup files? Also, clean up backups

Does readonly work for enums?

MacOS X comboboxes aren't recolored when not selected.

resize leaves CV table all messed up

ReadSheet on CvTable pane doesn't do anything

Speed table not updating when CV changes? Editting on CV pane
doesn't generally work

(Speed Table) force left / force right to be monotonic happens even
when reading CVs, so the plot doesn't go white, show what's there

(CvTable, dirty bit, readonly) A write-all still prompts for "some
not written", perhaps because CV7,8 still show yellow?

(Readonly) You can write a read-only CV from the CvTable, and it then
shows OK with the value you set

(Readonly, decoder .xml) Readonly CVs 7,8 show as zero & yellow in
the CV table when it starts up, not a reasonable value

(symbolic programmer) Text suite needs to be reliable

(Cv Read, DecoderPro) only retry a CV read once, rather than getting
stuck in a loop

Ops mode programming

TL1 function control needs to map to function selection pane.

Config/monitor window for the NCE packet monitor board

(PaneProgPane) XML option "don't display if empty" default to display

(SpeedTableVar) put text fields in addition to sliders? Alt rep?

(LocoIO) decimal address column, kept in synch with hex, op code

(PaneProgFrame) Put info in frame title: File, decoder name, versions?

(C/MRI) Doc architecture: Polling, multiple items in one command,
need config to tell input from output

(sf feature request) Reset to linear button on speed table

(sf feature request) Tick marks and/or scale on sliders

(sf feature request) Numeric echo of slider values in speed table

(communications) Add a verification at startup that asks for some
kind of version info and retains it, plus accessor

(TurnoutTable) Neeed for configuring names, showing lots of info in a
small place.

(LocoNet programmer) Apparently Ops mode _can_ read if transponding is in use

(decoderdefn) better handling of large families of decoders

(Installer) Windows installer

(Macintosh) Updater vise updater - make it easy to create, start creating

(Windows) Updater Vise updater - make it easy to create, start creating

(Throttle) LocoNet reference implementation

(Interfaces) Write-up description of two-layer architecture, system
names, Manager approach to access

display background picture

display general config load & store

(config) Document the config package

(jmri) Multi-bit inputs, outputs

(jmri) general-purpose output interface above Turnout

(app) LocoTools app

(javaDocs) Add package.html to packages - start with README contents

(JavaDocs) get overview.html to work

(jmri) Occupancy interface, connect to Sensor implementation

(Xml) XML defines class, element passed to ctor. That then handles
subelements. Do always, even when structure simple, to provide
encapsulation. May need to add grouping-elements to map to classes
whell.

NCE has "programming mode". Should entry/exit be explicitly
supported? What does EB do?

dispose() for local class in DecVar, Long Var, hexVar, Speed var

List.clear() in dispose() methods

pane prog config doc 3 examples of address: All 3 vars;
combined var; two addresses with radio boxes next to them

Directional Headlights variable is like a function mapping. Make sure
it can be mapped. Also, see TL1 mapping as enum

DH083 config file?

Read-only variables start off with what value? Do they update in
read? Need to get right before putting on pane

Need to say that certain variables are readOnly in ops mode?

Read sheet/all should read readOnly vars, set state. State should
also color, esp. initially

Ops mode, EvtBlder can't read. Should be a question you can ask the
programmer object. What does EB2 say on LocoNet?

Can we add a faint grid to the fnMapping widget?

Programming really needs a progress bar with a stop button.

Provide a sample decoder file that's got all the "names" variables,
since its easier to delete than add

Sample programmer file, to show what you can do, keyed to the
ConfigFile.html file

show version, other id of programmer and decoder files in use

Better documentation of how fnMap looks at the decoder file

(Common Sel Pane) After you've done identDecoder, how can you get
back to the full set of decoders in the ComboBox?

Mark wants to see programmer, decoder versions on screen somewhere

All Frames should have removeAll in their dispose() methods

All Frames should have a dispose() method

All Frames need to dispose when they close, so they need registered
close handlers

Gray out 'read' buttons when working with EB

Document to web the "label" attribute of output element, esp for wire labeling.

Mark G things programming mode selection is too obvious

EasyDCC should default to paged ID, while others default to register

jmrix.loconet Programming collisions need to be sorted out, e.g. two
requests for ops programming at same time, hitting a read button
while another window is reading.

jmrit.*.CvTableModel Problem in PaneProg. Display/edit is all messed
up. Should cells _inherit_ from Swing Components?

jmrit.*.PaneProgPane CV pane changes don't update variable display.
Thought to be due to same old text edit blindness, as some changes do
propagate.


No separators on MacOS X, Classic L&F

Is there a problem when you lift the "readScreen" button while
reading the speed table sliders? Doesn't stop

Changing Roster Entry pane fields doesn't set file-dirty

Instructions/support for building a program based on JMRI. First
example: simple signalling?

Ask NCE groups for Open Source ops prog pkt code, as somebody
probably has written it

Some variables control whether others appear grayed out or not.
Enums, also small digital values. How to represent?

Allow variable to "control" a row/column; display as BorderedPane

Get permission for locomon to show PM4 messages; Leonard Kerns requested

Add a preference for "fixed screen size", so they're always full screen

Need a clean shutdown mechanism, closing all windows, so all dirty
checks are made

PaneProgFrame "tooltip" item is in docs, but not yet presenting -
provide a connection to comments?

Split roster pane into individual, specifiable variables would allow
you to have a "walk through for beginners" programmer

rethink panes in decoder files. Instead, have them elsewhere, but
allow references to the files in decoder file?

LocoNetAdapter Has error handling and reporting that's not in NCE,
MS100; move to a common base class.

PaneProgAction move the preload of various things out of this, or at
least figure out a way to make sure they're not duplicated by other
actions

(jmrit.symbolicprog) Update to use New/Found Frame at startup

(jmri.symbolicprog) Symbolic (table) programmer use split pane
layout, perhaps side-by-side?

Confirm button should show value from memory, but set color on difference

Allow info pane to be put anywhere

CV table shows CVs in order from the file; numeric order would be better

loconet.SlotMon will need table updates

Empire Builder can't read - how handle that?

Digitrax TD1 decoder file

Digitrax TL1 decoder file

Digitrax DZ121 doesn't have direct mode

Some of the sound CVs need a capability of graying-out a variable if
another is on/off; tooltip?

XmlFile parse errors are exceptions, which propagate up to a higher
level. Can some of this be centralized?

(PaneProgFrame) needs some progress bars or similar so you know how
its doing during programming, startup

(jmrit.*.VariableTableModel) Display/edit is all messed up. Should
cells _inherit_ from Swing Components?

Remove Vector in favor of ArrayList, array where possible

Create a ABC for platform-specific behaviour, where you fill the
methods & ctor invokes

Mark Gurries suggests an "Add panes" item. In menu? Allow initial
ComboBox to have multiple selections? Maybe prog file is pointer to
pane files?

Sensors/Inputs Need an "override" capability to change the expressed state until the next real change

Get Jbuilder CVS working

LocoNet message parsing mess, redo along NCE model

(jmrit.*.AbstractValue) Lots of *Table tools are in PaneProgFrame,
PaneProgPane - should live in an AbsValueTable?

ABC for both symbolic programmer (renamed table programmer?) and Pane programmer?

Pull JDOM definition of test cases from test classes to single place

NceInterfaceScaffold is in NcePowerManager; move it to file of its own

PaneProg tests directly invoke setUpDecoder from DecoderFileTest

Check how DecoderFile interacts with other classes; hint that
VariableTable, CvTable are right tools for interchange?

Check how DecoderFile creates its full information; is it really
obeying open/closed?

Break monolithic DecoderPro config into parts

Ugly hack in LocoFile.loadCvModel so that LongAddr shows as FromFile
after read from file.

dccAddrPane has ugly hack to register variables in PaneProgPane
create row/column code. Also, reads longaddr when not needed (slow)

Set Mac filetypes to "TEXT" when writing file

symbolic (table) programmer uses same start-up code as pane programmer

(ConfigFile.html) Add more info to ConfigFile docs

(jmrix.loconet.?) Tool for convenient "status editting" of locos

Roster management tools: Delete an item, import a file.

Start a manual!

Check loco ID before writing

(PaneProgFrame) add a preference item (?) specifying a "read loco
address" confirmation before writing

(VarValue) Config entry for colors, for mapping to states

(LocoFile) Investigate .dec files, which seem to be Excel-compatible
output from PR1WIN? See JMRI mailbox

(jmrix.loconet) DT100 throttle sends SW_REQ_ACK, has separate ON &
OFF commands. Should we do this?

ABC for PaneProgrammer Panes

FnPane needs a Test routine

(SymbolicProgFrame) has a writeFile operation that should be deferred
to LocoFIle

(Variables, VarTableModel) This really has to be cleaned up; not
overlaps in setRow and setConstant, and code dup throughout

Roster update button on PaneProgrammer entry frame is disabled

Document .lcf file, how to control logging, categories

(loconet.SlotManager) needs tests, esp. of programming packets

(PaneProgFrame) When you lift readAll/writeAll, the current pane
completes its read/write. Should stop faster

NCE command station configurer like "commando"

Max/min handling in dec, hex variables (part of text edit update?)

(JDOM) Is JDOM not thread safe?

Restrict file choosers to possible files

Visual (video) block ID

Some kind of LocoPalm connection?

Monitor window scrollbars should stay at the bottom as new items
added (SourceForge item)

Can't copy from monitor window on Macintosh (SourceForge item)

jmrix.loconet.? Not handling turnout feedback completely, only has the one form

(lots!) Protect text fields from invalid entries, e.g. non-numeric

(jmrix.loconet.hexfile) Hexfile should create a debug programmer
before you open the file to ease testing

(jmrix.loconet.SlotManager) Slot manager state model not good, LACK
not handled robustly

If you close MS100 et al before selecting something, show a warning dialog.

Update logo on web pages - see home.html, home2.html

Printing support

Roco Crane controller!

Use block detection to switch reversing-section PM4, removing
hesitation? Is there a hesitation?

has TrainProgrammer, which uses a Tree
interface, has nice speed graph

jmrix.loconet.? DS54 programmer (search mail in JMRI folder)

jmrix.loconet.? Chief configurer (See Digitoys-systems.com/Chf_Download_e.htm)

jmrix.loconet.? Digitrax consist manager (see Wielgus email 12/7/01,
loconet_hackers files)

Throttle implementations; a key part of getting the interface right!

"About" handler

Program icons for Classic, OS X (iconeer?), folder icons (Folder Icon X?)

JMRI, jmri creator codes to be used

Better menu control in demo, with only available system-specific tools active

(PowerManager) Subdistrict support, esp for PM4 subdistricts

(PowerManager) TRIPPED state, e.g. off-due-to-protection-circuitry,
not because it was commanded off

(PowerManager) Is there a state for "power is on, no packets being sent"?

(PowerManager) Feedback: Loconet knows real state from network; NCE
just knows if commanded; could actually measure! Like for turnout

(Digitrax) Route programmer - use a trace to figure out what the throttle does

periodically, check memory growth and update dispose() tree as needed

Layout monitor for decoding DCC packets?

Sensor/SensorManager semantics

Sensor/SensorManager tests are still (?) based on Turnout tests,
hence erroneously passing

DS54 pointed out that having non-contiguous enum values would be
nice; DS54 now to be handled differently

Support for 'options' in decoder definitions

Packet generator at

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

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.

Bob,

Provided some telephone help to a friend that was trying to update to the
latest version today. Had trouble getting the decoder list to come out
right. Eventually had him delete the decoder index in the Prefs folder,
then create a new index which solved the problem. Maybe including an empty
Prefs folder index file as part of the update package, along with some code
in the app that automatically creates a new index when the index is empty?

Another thing that came up had to do with the roster. Some of the entries
there were from earlier playing around. I talked him through a manual edit
of the roster file, which solved that problem also but a typo during the
edit caused some extra grief. Any plans to incorporate roster management?
Also there were many old versions of the index and roster files around so I
wondered if anything is planned in the way of file maintenance?

After getting everything ironed out, the app had no problem talking to the
NCE system. However after successfully reading the loco data and saving it
to disk, the NCE was still held in some kind of programming command mode.
Don't know if shutting down the app would have fixed this, but I heard that
turning off the PC did release the NCE.

Robin


Robin Becker
Tucson, AZ

Bob,

Looks like when you create a roster entry and save it the filename is not
display on the Roster Entry screen. Might lead a new user to conclude that
the file had not been created/saved. In fact I don't think there is ever
feedback that the file save has succeeded? Maybe a message on the status
bar would be worth considering.

BTW I think I saw a comment from someone suggesting you could clone a loco
by just changing the ID and doing a save. Didn't work when I tried it.

Robin

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)?

That's part of it. It turns out that's a little more complicated than throwing turnouts, as there are _lots_ of different ways that information comes into the system. So the basic code has to be pretty flexible.

>>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...)?

The XpressNet itself is not something that can be easily done with a PC serial port. It requires some timing & bit-banging that's beyond my capabilities. So the first thing I'm working on for Lenz command stations is communication through a LI100. The messages are pretty-much the same as XpressNet itself, but the serial port control is much simpler.

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

At 10:31 AM -0700 5/14/02, Mike Davison wrote:

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

I'd like to see manufacturers providing comprehensive info on their decoders. Even if we still have to make up the files, having good info would really help.
For example, Debbie Ames of Lenz has been very helpful in getting me info on the current Lenz decoders, and Jim Scorse of NCE has promptly answered every time I needed clarification. With that kind of help, making the files is a reasonable task.

I've backed off a little in my hopes that people would make decoder files for all the decoder they're interested in. There are a few people who've done that, including some on this list, but it's harder than I originally imagined it would be. It's taken some really dedicated people to succeed with new files. In part this is because there are just _so_ _many_ options in modern decoders; some of them have over 100 settings to encode! In part it's because the XML format is so verbose & redundant; it's hard to work on the files with just an editor.

In the long term, we need a tool to make creating those files easier. I'm not sure how to do it, but something where you can just sit down and fill out some forms. The problem is providing enough flexibility to map all the possibilities we see in the marketplace. This might be a good project for somebody who'd like to play with some Java code...

In the shorter term, I'd like to find some time to lobby manufacturers for more information. I'm hoping to track down some of the people involved at the NMRA convention & train show this summer; maybe talking in person will help.

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

Thanks for all the good ideas. I suspect that getting the roster-management features working is going to take a couple of go-rounds, so I should probably get started on that first.

So the next question is: what needs to be there, and how should it look?

My original idea was that the "update roster" button would remake the index, so any files you've inserted or deleted in the prefs/roster directory would be known. That seems way too simple now.

It sounds like people want that, plus:

a) A way to delete an entry

b) A way to duplicate an entry (so they can make a new loco that's "the same except ...")

c) Import and export of roster files, so you can carry them around with the locomotive itself.

d) Starting values for specific decoders, so when a new file is created its default contents are what you'd like as a starting point for that model of decoder.

e) A way to copy an entry ("Make this one like the other one that I just updated ..."). I'm not sure how to actually use that, so I'd appreciate it if somebody could walk me through what you have in mind. The tricky bit seems to be updating just part of the contents; which part?

f) Clearer documentation, esp. the connections between files, filenames and the roster contents.

That seems like enough to start.

I'll probably create a "Roster" window that has buttons to do all these things, along with a (scrolling) list of defined locomotives. Or maybe a small table where you can edit things directly?

Suggestions are always welcome!

Bob

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

Read about, then D/Led the latest veriosn of DecoderPro. Got to
admit, I like the selection system and screen layouts. Problem is I
can't get it to communicate with either my Digitrax EBII or to a
dedicated programming track via a PR-1.

What are the system interface requiremnts of this application. It
looks to me that it requires a Digitrax Chief or a similar system
which supports read and write, not just write functionality as the
EBII has.

Bob

Hello: I have just completed the assembly of John Jabours
LocoBuffer Kit and it tested out okay. I built a 9 pin to 25 pin
cable. Intalled a Keyspan PDA Adaptor between a USB port and
the LocoBuffer. Hooked up a 12 volt, 200 mA WallWart. Turned
on the iMac and clicked on DecoderPro. Set preferences:
LocoBuffer; 19700 baud; Basic. So far, so good! Entered the
programmer mode, entered some data regarding the
SoundTraxx equiped engine that I have just completed. It
(DecoderPro) seems to work okay, until I attempt to "write". Then
I get a message:
"Programming error: timeout talking to command station" which
then alternates with the message: "Writing CV29"
That's all folks.
I haven't a clue what to do next. Any suggestions?
One other thing that is driving me nuts: since I hooked this up,
the iMac's internal modem won't dial up the Internet without my
going into the control panels and changing it back to "Internal
Modem, 56K". It will be changed to "Infrared Modem", which I
don't now and never have had. It must be related, it's never
happened before, and if I reset the Control Panel, I can dial up
the Internet just fine.
I do disconnect the LocoBuffer from the USB Port, however.
Thanks for the help. Maybe I should be asking John, but I have
bugged the poor guy to death while building the LocoBuffer, so
hate to bother him further. (VBG)
Mike Van Hove