Locked
Re: Handling changes to the short-address CV
Bob Jacobsen wrote:
Currently, a yellow color for a value indicates both "read from file,
not known to be the same as in the decoder" and "edited, not yet
written". (Red means "error writing or reading, value in decoder
unknown"; white means "value known to be the same as the decoder due
to having done a read or write") Perhaps it would be clearer to
people if those two states were different colors. Then you could
recognize the "edited" state, which generally means "you have to
write this before the change takes effect". Would orange be a good
color for that?
How about flashing yellow? Catches the eye easily and works for color blind people. The other part is to let the user know they need to make the save. Perhaps flash or highlight the write buttons under these conditions so one does not have to hunt down the pane involved. 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) ----------------------------------------------------------
|
Locked
Re: EasyDCC serial cable?
I use a DB-9 to RJ-45 connector for hooking my laptop up to the console
ports of Cisco Routers, so I know those are readily available. The newer
Cisco's serial ports are RJ-45 connectors. Is the EasyDCC serial port a
RJ-11/12 or RJ45? I also have some _really old_ DB-25 to RJ-12 from a
company called "Custom Cable Industries".
Mike M.
toggle quoted message
Show quoted text
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Wednesday, October 16, 2002 8:38 AM
To: jmriusers@...
Subject: [jmriusers] EasyDCC serial cable?
Is there a good source for an EasyDCC-compatible serial cable?
Somebody asked me where to get a cable to hook a DB9 serial port from
a computer to the telephone-style connector on the EasyDCC command
station. I don't know of a source, other than soldering one up.
Is there a place to get them premade?
Thanks
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Handling changes to the short-address CV
I'd like to describe a way for DecoderPro to handle the side-effects of changing CV1, the short address CV. I'd really appreciate hearing whether people think this will do what they want. I'd also like to hear whether we should change an aspect of the color coding.
In many decoders, when you change CV1 other CV values change. The NMRA specs state that CV29 and CV19 should be changed so that command stations that can't change these directly can count on particular values. (None of the ones that DecoderPro works with have this limitation, but we still have to deal with the side-effects of the weird parts of the NMRA spec). Some decoders reset additional CVs, e.g. the DZ121 resets it's BEMF settings.
To fix this, I've introduced a "short address variable" type that will handle it as a special case. This will allow us to specify the correct CVs to change, etc, in the decoder definition file.
When the program writes the short address to the decoder, it will also mark the other values as "edited" so the program thinks they need to be written. This will write the _desired_ values, not the default values, so the decoder will be restored to the "intended" contents even though the short-address write has changed them.
For this to work, the panes containing modified values have to have "write sheet" pressed, or "write all" has to be pressed. If you try to close the window before doing that, you'll be reminded that some values haven't been written to the decoder. (Until recently there was a bug in this logic; I think that is now fixed)
Currently, a yellow color for a value indicates both "read from file, not known to be the same as in the decoder" and "edited, not yet written". (Red means "error writing or reading, value in decoder unknown"; white means "value known to be the same as the decoder due to having done a read or write") Perhaps it would be clearer to people if those two states were different colors. Then you could recognize the "edited" state, which generally means "you have to write this before the change takes effect". Would orange be a good color for that?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Is there a good source for an EasyDCC-compatible serial cable?
Somebody asked me where to get a cable to hook a DB9 serial port from a computer to the telephone-style connector on the EasyDCC command station. I don't know of a source, other than soldering one up.
Is there a place to get them premade?
Thanks
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
I think I've finally tracked down the cause of this. Under obscure circumstances, default values in the decoder definition file would result in some CV variables being marked as "editted" when the programming frame was first opened. The program them thought that a person had changed them, even though they were just the default values. And much confusion would ensue. I'm testing a fix. Bob At 10:40 AM -0700 9/30/02, Jon Miller wrote: Test done with fresh T1 decoder.
Use programming track.
Paged Mode
Decoder installed, Ident.
Found mfg 153 (TCS) version 22 not defined
Changed to T1 and opened Programmer
In roster Entry changed ID to 1234 and did a save.
Went to Basic pane and changed long address to 1234, checked Extended
Addressing and did write sheet.
Colors changed from yellow to red to white as normal.
Went to roster entry and did a save.
When I tried to exit program got the ¡°some changes have not been written"
window.
Closed window anyway!
--closed the program.
Reopened the program.
Went through the above steps except didn¡¯t do roster entry.
1234 showed in Long address but not in DCC Address and Extending addressing
box was not checked, tried to exit but program hung.
Reopened the program and went through above step except for two differences;
used 1235 number and did a read of all panes. This time program closed as
it should.
When I reopened program old message was at the bottom found mdg 153 etc.
I 'quit' the program and reopened. Now it came up in idle. Went through
the same above and went to basic pane, the address had not changed.
At this point I decided to reload the program.
Went through above steps but this time used engine number id, it was there
and showed engine 1235.
?? It's not working like it did but I can't exactly define what's wrong
other than above comments.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Well we need to break the problem down
First check that the LocoBuffer works with John's RRCTRL program. Download
it from:
Connect it up with the same cable and make sure it works. Do things like:
- Open the Debug windows and make sure messages are recived when you do
things with the throttle.
- Make sure you can turn the Layout power on with it or open a throttle
windows and control a loco.
This should verify your hardware and note the baud rate used and use this
with DecoderPro later.
If you cannot get this to go then you need to double check the LB jumpers. I
recently helped someone else who had the LB in MS100 mode. Half way down the
page there are some notes about LB jumpers here:
Once you can verify the LB and the PC connection then try again with
DecoderPro and use the same baud rate that your LB jumpers are configured
for and enable hardware handshake.
Hope this helps
Alex
toggle quoted message
Show quoted text
----- Original Message ----- From: "Wendell Camp" <wendellcamp@...> To: <jmriusers@...> Sent: Tuesday, October 15, 2002 12:17 PM Subject: Re: [jmriusers] decoder pro Alex I reinstalled decoder pro and now can pick my ports . I get a message that loco buffer is not receiving data to check connection and cycle loco buffer power
----- Original Message -----
From: Alex Shepherd
Sent: Monday, October 14, 2002 6:36 PM
To: jmriusers@...
Subject: Re: [jmriusers] decoder pro
This is a bit strange as the DecoderPro installer pretty much gets it
right now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value
should be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Alex I reinstalled decoder pro and now can pick my ports . I get a message that loco buffer is not receiving data to check connection and cycle loco buffer power
toggle quoted message
Show quoted text
----- Original Message -----
From: Alex Shepherd
Sent: Monday, October 14, 2002 6:36 PM
To: jmriusers@...
Subject: Re: [jmriusers] decoder pro
This is a bit strange as the DecoderPro installer pretty much gets it right
now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since
you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value should
be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
This is a bit strange as the DecoderPro installer pretty much gets it right
now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since
you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value should
be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
|
Hi I am having trouble getting decoder pro to come upIhave been in
touch with John Jabourand bob Jacobsen we think the loco buffer is
working . I doenload up dated versions of Java and Decoder Pro When I
open Decoder Pro it said that com1 didnot exist when I go to pick a
seiral port the box is blank HELP Wendell
|
I'm working through the decoder details & emails before the next DecoderPro version. Did you ever hear from anybody about F5 and BEMF?
Bob
toggle quoted message
Show quoted text
On the Digitrax FX3 series the Digitrax pane has a control for F5 to
turn BEMF on or off. As far as I can tell F5 doesn't do this anymore for
this series. Is this correct?
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: interrupt sharing conflict
Robin, As luck would have it I believe I was having a similar problem. Tried a number of options and found that turning off the flow control and leaving everything else set up as normal i;e baud rate at 57,000 etc DecoderPro (version 1.0.5) it ran sweet as. Hope this helps. David Hodgson Palmerston North New Zealand --- In jmriusers@y..., "Robin Becker" <rbgroups@e...> wrote: Has anyone successfully run under Win9X with a serial mouse and DecoderPro sharing an interrupt (i.e. mouse on com1 and DecoderPro on com3, or com2 / com4)? One user I'm trying to assist has 3 active serial devices and ran into a problem in this configuration. Thanks.
Robin Becker
Tucson, AZ
D&RGW Model Railroad Layout
|
Locked
Re: Function Map for Soundtraxx DSX Diesel decoder
Michael,
The default settings in DecoderPro for the DSX function map correspond to
the Soundtraxx published default settings for the decoder, not the settings
for any particular throttle. The NCE ProCab throttle default settings are
F3 for Bell and F2 for Whistle, which are different from the Digitrax DT400R
settings you listed. So it is to be expected that the decoder function map
defaults might not match the throttle function assignments, and fortunately
DecoderPro makes it easy to change the decoder settings as required.
(FYI, those who have used DSD Diesel with NCE will have run into another
problem: the DSD only allows the Bell to be mapped to F1 or F2! Thankfully
the NCE throttle sound functions are programmable. The trick is to change
the throttle behavior to accomodate the DSD diesel, and then change the
function map on non-DSD units to match.)
Robin Becker
Tucson, AZ
toggle quoted message
Show quoted text
-----Original Message-----
From: Michael McCaffery [mailto:mdmccaf@...]
Sent: Monday, October 07, 2002 10:47 AM
To: jmriusers@...
Subject: [jmriusers] Function Map for Soundtraxx DSX Diesel decoder
The problem Jon Miller alluded to earlier was apparently mostly operator
error, except for the following:
In Decoder Pro 1.0.7, for a DSX Diesel decoder, the Function Map has
Functions 1 and 2 reversed. That is, Function 1 should be for the Bell,
and
Function 2 for the Horn (if using a DT400R). At least, that's my take
on
it.
Just passing it along, FWIW.
And I LOVE that software!
########################
Michael McCaffery
Davis, CA
Email: mdmccaf@...
|
Locked
Function Map for Soundtraxx DSX Diesel decoder
The problem Jon Miller alluded to earlier was apparently mostly operator
error, except for the following:
In Decoder Pro 1.0.7, for a DSX Diesel decoder, the Function Map has
Functions 1 and 2 reversed. That is, Function 1 should be for the Bell, and
Function 2 for the Horn (if using a DT400R). At least, that's my take on
it.
Just passing it along, FWIW.
And I LOVE that software!
########################
Michael McCaffery
Davis, CA
Email: mdmccaf@...
Creating a kinetic and artistic representation of a mid-twentieth century
Kentucky railroad transportation system, based on extensive research and
personal experience.
########################
toggle quoted message
Show quoted text
Date: Sun, 6 Oct 2002 14:20:16 -0700
From: "Jon Miller" <atsf@...>
Subject: Re: Saving with 1.0.7
Bob,
Had a phone conversation with Michael and Soundtraxx is pulling up some
interesting panes. I will let him describe what going on.
We did check that save or inability to save one pane and exit. Did you
find that problem? Understand 1.0.8 might be coming soon.
Jon Miller
|
Locked
interrupt sharing conflict
Has anyone successfully run under Win9X with a serial mouse and DecoderPro
sharing an interrupt (i.e. mouse on com1 and DecoderPro on com3, or com2 /
com4)? One user I'm trying to assist has 3 active serial devices and ran
into a problem in this configuration. Thanks.
Robin Becker
Tucson, AZ
D&RGW Model Railroad Layout
|
Bob,
Had a phone conversation with Michael and Soundtraxx is pulling up some
interesting panes. I will let him describe what going on.
We did check that save or inability to save one pane and exit. Did you
find that problem? Understand 1.0.8 might be coming soon.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
|
Locked
LocoBuffer difficulty (continued)
It's now working (at least I was able to program and modify a Soundtraxx
decoder), and it seems the problem was with com ports, baud rates, and their
interaction with the LocoBuffer itself (and perhaps just a bit of operator
error).
So thanks to all those who responded, both on and off line, for the support.
This is truly a wonderful system, a great time saver, and lots of fun
besides.
Happy railroading!
########################
Michael McCaffery
Davis, CA
Email: mdmccaf@...
Creating a kinetic and artistic representation of a mid-twentieth century
Kentucky railroad transportation system, based on extensive research and
personal experience.
########################
I'm now at
toggle quoted message
Show quoted text
the point where I'm getting an error message (once connected - I
think - to the specific decoder installed in a locomotive) that
says: "Programmer error: timeout talking to command station."
Any suggestions or pointers as to my next step?
|
Locked
Re: Physical Data Decoders
-----Oorspronkelijk bericht-----
Van: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Verzonden: zaterdag 5 oktober 2002 17:30
Aan: jmriusers@...
Onderwerp: Re: [jmriusers] Physical Data Decoders
>Can physical decoder data be included.
>It does not seem to work.
>
> Could you tell me what goes wrong?
It took me a while to find a funny consistency;
It seems that if a decoderfile is both in the user directionary
and JMRI system directory and bearing the same name
the physical data is accepted.
That is; only if the file in the user directory does not contain
physical data.
I use the latest version 1.08. Either the falling rain drives me
mad or ....
Sibbo
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Re: Physical Data Decoders
Bob,
Can physical decoder data be included.
It does not seem to work.
Could you tell me what goes wrong? I only did a little testing, so could have overlooked something. Only the most recent version of the code & DTD (data definition file) have max current, etc defined. If you try to read a file with those attributes in an earlier version, it will fail. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Bob,
Can physical decoder data be included.
It does not seem to work.
Sibbo
|
Locked
Re: No such decoder defined...
On Friday 04 October 2002 04:46 pm, Bob Jacobsen wrote: At 3:55 PM -0700 10/4/02, Mike Davison wrote:
In each decoder file mfg is "Throttle-Up (SoundTraxx)" while in
decodersIndex.xml it is "Throttle-Up".
That's probably the problem.
In an effort to fix the problem I changed the string in decodersIndex.xml to match the decoder files. Then I restarted DecoderPro. Now I see this error:
Found mfg 141 (Throttle-Up) version 14; no such decoder defined
So now DecoderPro has the string 'Throttle-Up' in spite of the fact that
the index and the decoder files have 'Throttle-Up (SoundTraxx)'. Weird. Ideas? It probably uses the one in your preferences (which I think is in
~/.jmri on Linux). Which one did you edit?
~/.jmri/... did the trick. Without reading the code, I'm note sure which one is used when making
a new decoder index. It could be the original (distributed) file, or
it could be the local copy.
Once you get this fixed, could you commit your changes? If I can recall the CVS magic. I'll bug you if I can't figure it out. Thanks, Mike
|
Bob Jacobsen