开云体育

At 8:52 AM -0700 8/8/02, Robin Becker wrote:

Bob or other control panel guru,

Once icons are placed on the control panel, the tooltip says "Alt-click to
see menu, drag with meta key..." Ok, I can move the icons around with the
right mouse button, but I tried all the combinations I could think of and
haven't been able to produce a menu. Is there a way to delete icons, etc?

Can you view the sensor or turnout number once you place them on the panel?

Uh, I don't know?

On a Mac, with only one button, "alt" is the control or option keys. So to see the popup menu I hold control and click-down on something. "Meta" is the command (a.k.a. Apple) key, so I hold that down to move things around.

Maybe control works the same on a Windows box?

PS. Bob - hardly worth noting at this point but the readme files show up in
the resource lists. So does logo.gif and decoderpro.gif, but hey somebody
might want them on their panel!

Worth noting, as I hadn't noticed. Will fix that, at least for the README file.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
At CERN until August 10, replies may be slow.

Bob,

If you need one, I got one to loan you.

Bob Jacobsen wrote:

I'd like to progran my CVP EasyDCC AD4 Accessory Decoder's via
DecoderPro but there no configuratrion file for them. Has anyone
produced an AD4 config file? If so, would you sharing it with the
group.

The AD4 splits its address across two CVs, which is a bit of a pain
to do manually. I wrote a little bit of code so that we can specify
that in a decoder file, and created an AD4 definition file to test
it. It will be in the next test installer, probably available
Thursday.

I don't have an AD4, though, so will be relying on you guys to test
it and comment on whether it's OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
At CERN until August 10, replies may be slow.


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



Your use of Yahoo! Groups is subject to

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)


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

I just attempted to download 1.0.3 and it wouldn't do it. Something
about can't read file????????????

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

Bob,

Apologize for the initial sketchy data on #3 in my previous post. When the
turnouts were drawn, all would display thrown and closed states by clicking
on them. Examination of the panel file shows the problem: the closed and
thrown icons for all turnouts except the first one are set to
os-upper-right-closed.gif.

Here is the data from a test panel file. Turnout #1 was drawn as an
upper-right turnout and #10 was an upper-left turnout. They both toggled
fine when first drawn.

<turnouticon class="jmri.jmrit.display.configurexml.TurnoutIconXml" x="184"
y="213" height="32" width="39"
closed="resources/icons/smallschematics/tracksegments/os-upper-right-closed.
gif"
thrown="resources/icons/smallschematics/tracksegments/os-upper-right-thrown.
gif"
unknown="resources/icons/smallschematics/tracksegments/os-upper-right-unknow
n.gif"
inconsistent="resources/icons/smallschematics/tracksegments/os-upper-right-e
rror.gif" turnout="LT1" />
<turnouticon class="jmri.jmrit.display.configurexml.TurnoutIconXml" x="91"
y="209" height="32" width="39"
closed="resources/icons/smallschematics/tracksegments/os-upper-right-closed.
gif"
thrown="resources/icons/smallschematics/tracksegments/os-upper-right-closed.
gif"
unknown="resources/icons/smallschematics/tracksegments/os-upper-right-unknow
n.gif"
inconsistent="resources/icons/smallschematics/tracksegments/os-upper-right-e
rror.gif" turnout="LT10" />



I think there is a naming issue here with turnouts that might cause
confusion (it confused me anyway). Normally a lefthand turnout means the
diverging route goes to the left of the main route, so the "upper right"
turnout in the control panel is a "lefthand" turnout.

Robin



3. When I add a _left_ turnout to the drawing, the initial icon displayed
is
a _right_ turnout in unknown state. Once I click on the turnout it
becomes
a closed _left_ turnout.
3a. When I save and then load the panel, all the turnouts are right
turnouts
in unknown state. I can click on each one and change it to closed,
however
only one will allow me to toggle it between closed and thrown.

Bob,

1. When I create a new control panel and add icons, nothing is visible on
the panel until I resize it. After I resize the panel everything is there.
I tried different X and Y values and it didn't matter.

2. I can change a turnout by clicking on it but I can't change the displayed
state of a sensor by clicking on it. I think the help page says that this
should be possible?

3. When I add a _left_ turnout to the drawing, the initial icon displayed is
a _right_ turnout in unknown state. Once I click on the turnout it becomes
a closed _left_ turnout.
3a. When I save and then load the panel, all the turnouts are right turnouts
in unknown state. I can click on each one and change it to closed, however
only one will allow me to toggle it between closed and thrown.


LocoTools shows this message: Pick an input source from the input menu
first. Not sure what this refers to.

FYI I installed Java 1.4 and the combo box redraw problem when scrolling a
long list is gone.

Robin

Bob or other control panel guru,

Once icons are placed on the control panel, the tooltip says "Alt-click to
see menu, drag with meta key..." Ok, I can move the icons around with the
right mouse button, but I tried all the combinations I could think of and
haven't been able to produce a menu. Is there a way to delete icons, etc?

Can you view the sensor or turnout number once you place them on the panel?

Thanks.

Robin


PS. Bob - hardly worth noting at this point but the readme files show up in
the resource lists. So does logo.gif and decoderpro.gif, but hey somebody
might want them on their panel!

Wow, what a quick response! The miracle of time zones...

New organization for Digitrax decoders. This should work for
existing rosters, please check and let me know the specifics if
it doesn't.

It found my previously configured decoders ok but when I did an ident it
failed to find my DN149K2s.

I guess there must be more than one DN149K2 version, so here is the trace.

Thanks for the trace. I can read the reply from that. The ID of that came back as 129 (digitrax), version 241, which is a new code I'd not seen before. I'll add it to the list so the program will get it right next time.


Can I ask other people to spend a few minutes gathering that info? Specifically, I think we can make the automatic ID work much better if people will send me the CV7 value(s) that they see for each decoder type they have. This is easy to do with the "simple programmer" from the tools menu; just put in 7 as the CV address and click "read" for each decoder you've got.

Even better would be if somebody would volunteer for the task of accumulating that info. I'd be happy to edit the files, but if somebody else could prompt people to generate it and enter the info, that would let me work on some other stuff. (I do have a day job, unfortunately)

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
At CERN until August 10, replies may be slow.

Added new "log curve" button to speed table.

Looks good

New organization for Digitrax decoders. This should work for
existing rosters, please check and let me know the specifics if
it doesn't.

It found my previously configured decoders ok but when I did an ident it
failed to find my DN149K2s.

I guess there must be more than one DN149K2 version, so here is the trace.

time: 21:44:41
packet: ef e 7c 20 0 0 0 0 2 7 7f 0 0 38
Write Programming Track: Read Byte in Paged Mode on Service Track
Setting CV8 to 255 (0xff)

time: 21:44:41
packet: b4 6f 1 25
LONG_ACK: The Slot Write command was accepted

time: 21:44:47
packet: e7 e 7c 20 0 0 0 4 2 7 1 0 0 4a
Read Programming Track: Read Byte in Paged Mode on Service Track
Setting CV8 to 129 (0x81)
Status = Success

time: 21:44:48
packet: ef e 7c 20 0 0 0 0 2 6 7f 0 0 39
Write Programming Track: Read Byte in Paged Mode on Service Track
Setting CV7 to 255 (0xff)

time: 21:44:48
packet: b4 6f 1 25
LONG_ACK: The Slot Write command was accepted

time: 21:44:57
packet: a0 1 61 3f
Set speed of loco in slot 1 to 97

time: 21:44:59
packet: e7 e 7c 20 0 0 0 4 2 6 71 0 0 3b
Read Programming Track: Read Byte in Paged Mode on Service Track
Setting CV7 to 241 (0xf1)
Status = Success

Panel icons greatly improved.

Looks good, now if I just had a layout...

Cheers

Alex

I've just uploaded the 1.0.3 test installer.

This is a _test_ installer. I'm away from home this week, and haven't been able to really wring it out on my layout. As always, I strongly recommend backups.

Please give it a try and let me know what you find.

Changes:

Added new "log curve" button to speed table.

Lots of work on control panel files.

New organization for Digitrax decoders. This should work for
existing rosters, please check and let me know the specifics if
it doesn't. There is now a DZ121, although we don't yet handle
the various odd things it does when CV1 is written. Several other
new Digitrax decoders. Fixed a bug in FX definition for CV50.

New AD4 stationary decoder, along with some code to make it work.
You should select the new "Custom" programmer format along with
the decoder type. I'd be interested to know if it auto-idents OK.

Lenz now works at 19.2kb

Two appearance bugs fixed on Java 1.4, one on MacOS X.

Problem with displayed sensor addresses in LocoNet monitor fixed.
This should make debugging the speedometer easier.

Panel icons greatly improved.


The installer is available as a Windows executable at:



Please let me know if you want an archive for Macintosh, Linux or OS/2. I'll be happy to create one if anybody actually will promise to use it.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
At CERN until August 10, replies may be slow.

Mike:
How did you connect Decoder Pro to your system? Are you using MS100 (from PR1)? Is it a RJ11 plug to a 25 pin adapter? Can't get mine to see the loco on programming track.

Bill

I'd like to progran my CVP EasyDCC AD4 Accessory Decoder's via
DecoderPro but there no configuratrion file for them. Has anyone
produced an AD4 config file? If so, would you sharing it with the
group.

The AD4 splits its address across two CVs, which is a bit of a pain to do manually. I wrote a little bit of code so that we can specify that in a decoder file, and created an AD4 definition file to test it. It will be in the next test installer, probably available Thursday.

I don't have an AD4, though, so will be relying on you guys to test it and comment on whether it's OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
At CERN until August 10, replies may be slow.

Bob,

we have build for clients many panels, we have pictures for
Swiss, Autriche and Germany called INTEGRA, VGS, and SpDr60
construct by SIEMENS and for the United States CTC type
GE-Harris. We will give you a documentation in paper but we
do not have a post adress in an E-Mail to send it. We have
also a docu called Cab Control for analog and SELECTRIX 2000 (DCC)
there we drive with hardware a bloc systm and control it with
a panel. The greatest project was for Swiss SBB going the way to
LUCERN (G?TSCH). The documents is also for all peoples witch
sent an adress.

fax to germany:International Number and 0621 3393704
E-mail: berg.broman@...

Dieter

I haven't tried it but: The DCS100 can make the program track outputs into
a broadcast brake generator (still low current). This should provide power
to the decoder when not programming, then switch to program insturction
packets during programming then back to boradcast stop packets to keep power
to the decoder. DecoderPro could then set and clear OpSw47 as needed for
power / no power to the program track for the needed power cycle.

From the Super Chief manual page 119 (pdf page 61)

"OpSw47: Program track is brake generator when not programming. Braking is
DCC set to speed 0 (not Emergency stop) for address 0, light ON, broadcast
to all addresses"

More info at:


Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
Golden Empire Historical & Modeling Society www.trainweb.org/gehams
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal
Member
Kern County Live Steamers www.trainweb.org/kernctyls

I tried a test with my Digitrax DCS100 - the programming track is
unpowered until a read or write operation is done. Then the power
comes on, the action is performed and the power goes off. So I would
assume the DZ121 power up reset would take place on the next
read/write. (unless there is a difference in powering on the
programming track compared to the running track).

This would mean that if DecoderPro followed the write with a read or
a second write action, it would force the reset.

A few caveats:
I was using the throttle, not DecoderPro. (I havne't got my
Locobuffer built yet).
This wouldn't work with Ops mode programming as the power is not
cycled.
I haven't yet tried one of my DZ121's to see if I can force the reset
on the programming track using a read command. Maybe I'll have time
tomorrow.

Dennis

--- In jmriusers@y..., Mark Gurries <gurriesm@m...> wrote:

Bob Jacobsen wrote:

At 3:15 PM -0700 7/31/02, Jon Miller described a nasty feature of

the DZ121:

It basically says that anytime you reprogram CV01 (the 2digit

address), the

DZ121 automatically resets several CVs. The key here is the

reset doesn't

happen during programming, it happens the first time the DZ121

powers up on

the layout in normal mode. So if you use the PR1 to program your

values and

change CV01, using the PR1 to read back the data shows everything

as you

would expect. In other words, it confirms everything was

programmed as you

requested. But when you carry the loco to the layout and place

it on the

track, the DZ121 powers up, detects the CV01 change and resets

the following

CVs ...

The nasty thing about this is that there's no way for DecoderPro

to

fix it while the decoder is on the programming track; the CVs are
changed when you _later_ power the decoder. At that point, it's

too

late for the program to fix the values.

Can anybody think of a good way to cope with this?

I guess the problem solution depends on the command station.

With NCE, you can cycle power on the programming track allowing you

to

work around this.

I cannot say absolutely about the others but it should be possible

too

since the service mode programming track is supposed to be

unpowered when

you put the locomotive on it and then enable the programing.

Clearly

this will not work with a system that do not support service mode

tracks.

This get things complicated since now we have a decoder pane

response

that depends on a command station.

Maybe what you do is define a command that called reset that can be

added

to the XML files as part of the script in some way. When the

command is

called, a dialog box pops up and says resetting the programming

track and

goes away when it is done. But if the command cannot be

implemented

because the command station does not support it, it tells the user

what

to do manually instead.




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)


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

Stony,

My 'vast' experience includes programming 2 SoundTraxx DSD-150 decoders so I
can't offer expert advice. You may want to contact CVP and run this problem
by them.

There is no risk of damage with a resistor that is too large or too small so I
would try a bit larger range. It may be the case, that some decoders need
resistors and some do not. You may also want to verify that the operations
work directly from the CS (wispering: since there could be a bug in
DecoderPro, but don't tell Bob I said this).

cheers,
Mike

Downloaded and installed Decoder Pro on a _really_ old laptop. All I can
say is WOW! All contributors did an awesome job on this. I look forward to
using and possibly developing applications using JMRI.

-Mike M.

Mike

I may have spoken too soon. The 82 ohm resistor cured my problem with
SoundTraxx decoders but I still can't read values from Digitrax decoders.
I've tried resistors from 68 to 150 ohms with no luck on DH121s and DN121s.
Any other ideas.

Thanks

Stony

Bob,

Let me first say that while the decoders under discussion belong to Digitrax there are other decoder manufacturers that are effected in the same way.

This is just a suggestion and works in concept on paper. Earlier this summer I started working on the idea of a DCC comparision web site. Depending on the type of DCC hardware under comparison I have grouped things differently.

In the area of Command stations I have two divisions:
a) entry level
b) full feature

In the area of decoders I have five divisions:
a) N/Z scale decoders
b) HO/O scale decoders
c) Large scale decoders
d) Function Only decoders
e) Stationary decoders

In my comment section of the decoder areas I have a statement that scale is not the only factor in choosing a decoder. I know many HO scale modelers that are using N/Z scale decoders. This usually happens when dealing with small locomotives. As an example several years ago I gave Don Crano a working HO scale Gandy Dancer. It is almost impossible to install a HO scale decoder in it but a Z scale might work just fine.

There is a problem in the standards when dealing with CV7. The Recommended Practices RP-9.2.2 only define CV7 as "This is reserved for the manufacturer to store information regarding the version of the decoder". It does not define how the manufacturer must use it. It RP allows the manufacturer use or not use this space as he sees fit. This allows the each manufacturer to make up their own rules for what is placed in CV7. It even allows for the manufacturer to change their mind. In my opinion at this time CV7 is worthless and should not be used in assisting to identify the decoder.

As I side note I have heard a rummor on several occasions that the NMRA DCC WG has discussed this problem but has not found a solution. I have heard that a solution discussed was the addtion of another recommended CV. In several of these rumors CV7 was to be the model of the decoder and the other CV would be related to the firmware issue and any subsequent changes to the hardware. Of course the manufacturers will have to change the rules they use to insure that the CV7 and this other CV are updated as a change in the decoder is implemented.

Just a few thoughts on my part.

Al

Bob Jacobsen wrote:

At 3:15 PM -0700 7/31/02, Jon Miller described a nasty feature of the DZ121:

It basically says that anytime you reprogram CV01 (the 2digit address), the
DZ121 automatically resets several CVs. The key here is the reset doesn't
happen during programming, it happens the first time the DZ121 powers up on
the layout in normal mode. So if you use the PR1 to program your values and
change CV01, using the PR1 to read back the data shows everything as you
would expect. In other words, it confirms everything was programmed as you
requested. But when you carry the loco to the layout and place it on the
track, the DZ121 powers up, detects the CV01 change and resets the following
CVs ...

The nasty thing about this is that there's no way for DecoderPro to
fix it while the decoder is on the programming track; the CVs are
changed when you _later_ power the decoder. At that point, it's too
late for the program to fix the values.

Can anybody think of a good way to cope with this?

I guess the problem solution depends on the command station.

With NCE, you can cycle power on the programming track allowing you to
work around this.

I cannot say absolutely about the others but it should be possible too
since the service mode programming track is supposed to be unpowered when
you put the locomotive on it and then enable the programing. Clearly
this will not work with a system that do not support service mode tracks.

This get things complicated since now we have a decoder pane response
that depends on a command station.

Maybe what you do is define a command that called reset that can be added
to the XML files as part of the script in some way. When the command is
called, a dialog box pops up and says resetting the programming track and
goes away when it is done. But if the command cannot be implemented
because the command station does not support it, it tells the user what
to do manually instead.




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)


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

Comments below

Bob Jacobsen wrote:

<snip>

The "families" originally grew out of noticing that a manufacturer
would have the same CVs in a lot of different models. Sometimes the
models were just different in wiring harness, e.g. DH142AT vs DH142,
but other times you couldn't really tell from the number that they
were related. To save costs, manufacturers often put the exact
same processor chip & code in different decoder models which vary
only in the shape of the PC board, size and number of output drivers,
etc.

So the idea of the family was that if you knew you had a "FX"
decoder, you wouldn't have to worry so much _which_ decoder it was,
you could just select the family as a whole. This also helped with
the problem of automatic identification, which can't tell all those
models apart based on the CV values they contain (because the
processor is saying the same thing).

We went through several different approaches to manually selecting
decoders before getting to the tree method you see now. The original
single list made each one quite visible, but was _really_ long (there
are over 80 individual names on the list now, and it has a ways to
go).

But you raise an important point: The tree makes it hard to find a
DH142 unless you know it's a Digitrax FX decoder. And we don't want
to make that hard/confusing for people.

Can anybody suggest a solution that allows us to keep the tree?

Bob

I would definitely keep the tree structure - it works great. What I would suggest
is to separate the two approaches to finding an appropriate decoder into two
branches: specifically-named decoders and family/generic decoders (and maybe a
third for other devices). That way the tree would become something like (use
fixed pitch font to keep readable):

Digitrax
|__ Decoders by Number
|__ DHxxx
|__ DH121
|__ etc.
|__ DNxxx
|__ DN121
|__ etc.
|__ Other
|__ DGxx
|__ etc.
|__ Decoders by Family (I just used these designations arbitrarily)
|__ Basic
|__ Basic-FX
|__ etc.
|__ Other Devices
|__ DS54
|__ etc.

I haven't delved into the details of the decoder configuration xml files, but I
would assume this structure would call for a generic sheet for a family type and
specific sheets for the individual decoders and may require some changes to the
current xml files. I'm also assuming that the tree structure is created
on-the-fly based on the decoder xml files that are present rather than being hard
coded in the program.

Dennis