开云体育

Group,
Another plus for our beloved DecoderPro. I bought a group of CVP AD4
accessory decoders for switch motors. Not wanting to do these by throttle I
first used PR1DOS connected through the MS100. I already knew the PR1
'standalone' wouldn't work from another report. I could not get the PR1DOS
through the MS100 to work at all. Many tries.
I connected up DecoderPro through LocoBuffer and used the single CV
programming tool. Worked each and everytime. While I did have to put in
numbers for the CV's it's quite easy as they are explained in the AD4
instructions.
So another que for DecoderPro. I think a pane for the AD4 would
probably be easy but that's another one for the tomorrow file!

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

I have a DB150 hooked up to my computer via a LocoBuffer. Before I
found out that the DB150 can't read CVs I thought it wasn't working,
however I am able to write CVs. Sure is much easier than putting
them in by hand with my UT2!

Group,
I think Bob did some experiments with a DB150 (EB) and found that he
could write but as we know the EB has no programming track so no read back
capability. This is a type of system problem and would effect any type of
computer programming.

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

Bob,
Digitrax is soon releasing the lower cost DCS050 and this unit has a
programming track. I am going to get one when they come out, probably June
or July. Depending on their specs. (it's not exactly known how they would
work with an EB) they might be a good combination with the EB which would
then give a programming track.

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

Mike,

The EB (DB150) does not provide readback of CVs and does not support a
separate programming track. I think that currently DecoderPro supports
Digitrax via the programming track of the Chief (DCS100). Don't think
there is anything you can do via LocoNet to get a DB150 to read CVs, but
maybe Bob will add a "write only" option to DecoderPro.

Robin

I didn't mention that I have an Empire Builder II. After reading
Robin Beckers reply to the last message, I wonder if I'm screwed
at this point? This simple project is getting out of hand. (G)
I originally started to build the LocoBuffer and get the other
pieces together, because I understood the DecoderPro would
give me the R/W capability. There's no fool like an old fool still
applies, I guess. If I understand correctly, this means that I have
to shelve the LocoBuffer, KeySpan etc. or buy a Chief Controller.
Is that correct?
Thanks for the help.
At least, if I have to shelve this stuff, maybe the iMac will start
accessing the Internet again. (VBG)
Mike

Bob,

As you guessed, R/W is required at this time. That means the EB is not
supported.

Robin Becker
Tucson, AZ

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

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

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)

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)

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)

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

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

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.

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

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)

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

Bob

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

cheers
bob

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