Locked
Re: System Intereface Requirements
Bob,
As you guessed, R/W is required at this time. That means the EB is not
supported.
Robin Becker
Tucson, AZ
toggle quoted message
Show quoted text
-----Original Message-----
From: original_black_bart [mailto:rc_blackwell@...]
Sent: Thursday, May 23, 2002 4:39 PM
To: jmriusers@...
Subject: [jmriusers] System Intereface Requirements
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
|
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
|
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
toggle quoted message
Show quoted text
-----Original Message-----
From: vanhovem02 [mailto:mvanhove@...]
Sent: Saturday, May 25, 2002 9:06 AM
To: jmriusers@...
Subject: [jmriusers] New Install
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
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: System Intereface Requirements
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
|
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
|
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!
|
Locked
Re: AD4 accessory decoders
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
|
Locked
Roster copy, delete, import and export
I've added a "Roster" menu to DecoderPro that let's you copy, delete, export and import locomotive configurations. The first draft of a web page describing this is at
If you'd like to try this out, I posted a test file at:
Just replace your previous jmri.jar file with this one. I haven't had time to give this file the usual set of tests, so you might want to keep your old jmri.jar file around until you're sure it's working OK.
Sorry this took so long; I had to clean the cobwebs off a few parts of the code that really needed cleaning.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: System Intereface Requirements
At 11:39 PM +0000 5/23/02, original_black_bart wrote: 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. Sorry for the slow reply. The Empire Builder doesn't have the ability to read from decoders. There's nothing a PC can do about that, unfortunately. DecoderPro should still be able to program them, and can keep records of the values you've stored in its roster. That'll help you keep track of what options you've set, and make it easier to make small changes. If you click any of the buttons that cause a read operation, such as either of the "Ident"s, "Read All", etc, you should get a message saying that the operation failed near the bottom of the window. But the "Write All" and "Write Sheet" buttons should still work OK. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: New install of DecoderPro
Sorry for the slow reply. Perhaps you've got it working, at least for write operations now?
If not, there are a couple things you can check to help track down the trouble. First, see if basic communications are working:
a) The LED on the LocoBuffer should be flashing with LocoNet traffic, for example if you turn a throttle. This means it's sending something to the iMac.
b) Next, pull down the "Debug" menu and select "LocoNet Monitor". This should open a window that let's you see LocoNet traffic. When the LocoBuffer's LED flashes, you should also see the messages in that window.
If you get this far, the connection LocoNet -> LocoBuffer -> Keyspan -> iMac -> program is working. That's pretty good... If not, let us know what's happening.
Now for the other direction. Try to write to the decoder again. You should see a programming message in the LocoNet monitor window almost immediately, followed by a short burst of replies and other stuff.
A few more small questions:
What version of MacOS are you running? I ask not because I know of any that are problematic, but I'm just curious, and perhaps it'll be a clue.
What version of the LocoBuffer PIC code are you using? Some of the older ones (pre-January) had problems with the long programming messages, but if you got your PIC from John in the last couple months it should be fine.
Let me know how it's going, please.
Bob
toggle quoted message
Show quoted text
At 4:05 AM +0000 5/25/02, vanhovem02 wrote: 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
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: System Intereface Requirements
The Empire Builder doesn't have the ability to read from decoders.
There's nothing a PC can do about that, unfortunately. DecoderPro
should still be able to program them, and can keep records of the
values you've stored in its roster. That'll help you keep track of
what options you've set, and make it easier to make small changes. Bob, When using an EB (I have a DCS100 not a BD150) you would have the problem of not knowing the initial decoder settings, so does DecoderPro set all the CV's to a particular value (0 ?) when you open the Programmer window? After the user has made all their changed from this default above, does clicking the "Write All" button write all CVs even if they were not changed? If it does then you could be _fairly_ sure that DecoderPro's and the decoder's state are in sync. I have noted a few times people having problems programming decoders and want to revert their decoder back to "factory defaults" to start again, but I think that only a few recent decoders have a CV for this. Maybe a "factory default" attribute could be added to DecoderPro's decoder config files, so that resetting to factory defaults could be possible and configurable. This might also be handy for people to create a baseline config that they use to start from, although I note that you can do this with the copy/rename functions talked about and maybe added recently. Alex
|
Locked
Re: System Intereface Requirements
When using an EB (I have a DCS100 not a BD150) you would have the problem of
not knowing the initial decoder settings, so does DecoderPro set all the
CV's to a particular value (0 ?) when you open the Programmer window? Each CV has a default value specified for it by the writer of the decoder specification. Some default to zero while other CVs have defaults configured to be the same as the defaults the factory sets in the decoder. If I recall correctly, the default values are displayed when you start the programmer. After the user has made all their changed from this default above, does
clicking the "Write All" button write all CVs even if they were not changed?
If it does then you could be _fairly_ sure that DecoderPro's and the
decoder's state are in sync. Yes. The fields that are yellow are ones that DecoderPro will write when you click 'write sheet' or 'write all'. I have noted a few times people having problems programming decoders and
want to revert their decoder back to "factory defaults" to start again, but
I think that only a few recent decoders have a CV for this. Maybe a "factory
default" attribute could be added to DecoderPro's decoder config files, so
that resetting to factory defaults could be possible and configurable. That would be a good idea. It would be difficult in some cases as not all manufacturers clearly state the default values for all CVs, but it is a good idea. I think DecoderPro could do this now. Simply open the programmer using the decoder type rather than roster entry. Then perform a 'write all'. This will set all CVs to the default value. A specific button to do this from a roster entry programmer window would be nice. This might also be handy for people to create a baseline config that they
use to start from, although I note that you can do this with the copy/rename
functions talked about and maybe added recently. It does look like Bob has a good handle on this one with the copy functions that he is planning. cheers, Mike
|
Locked
Re: index file woe after update
At 10:00 PM -0700 5/18/02, Robin Becker wrote: 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? That's a good idea. I played with it some last week, but wasn't able to make it really reliable. I'll keep working on it. (The problem is that the index can be in two places: The xml/ directory, where the distributed index lies, or the prefs/ directory, where you can make your own. But only one is used, so they can get out of sync with each other) 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? I added a Roster menu to help with some of this. It lets you delete an entry, including the associated file, export and import entries to separate files, and copy an entry into a new one. In each case, the old file is backed-up by renaming it, then leaving it in the directory. The new name has the "xml" on the end replaced with a bunch of digits (to make it unique). I guess those files will start to build up over time, so I should probably add a way to clean them up.... 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. I've tried to recreate this without success, sorry. Next time it happens, could you do a test for me? Open a new programmer (you don't have to restart the program first) and push the "ident decoder" button. If that fixes it (command station goes back to normal), I think it likely that a message got lost between the program and the command station. If that _doesn't_ fix it, there's probably something inconsistent in the program. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: index file woe after update
Bob,
Thanks for all your work. I'm sure you'll come up with something for the
index files.
I tried out the roster tools this morning and they looked good. Jim will
try to keep an eye out for a repeat of the NCE problem.
Hope you enjoyed the holiday weekend.
Robin
toggle quoted message
Show quoted text
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Monday, May 27, 2002 3:20 PM
To: jmriusers@...
Subject: Re: [jmriusers] index file woe after update
At 10:00 PM -0700 5/18/02, Robin Becker wrote:
>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?
That's a good idea. I played with it some last week, but wasn't able
to make it really reliable. I'll keep working on it. (The problem
is that the index can be in two places: The xml/ directory, where
the distributed index lies, or the prefs/ directory, where you can
make your own. But only one is used, so they can get out of sync
with each other)
>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?
I added a Roster menu to help with some of this. It lets you delete
an entry, including the associated file, export and import entries to
separate files, and copy an entry into a new one.
In each case, the old file is backed-up by renaming it, then leaving
it in the directory. The new name has the "xml" on the end replaced
with a bunch of digits (to make it unique). I guess those files will
start to build up over time, so I should probably add a way to clean
them up....
>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.
I've tried to recreate this without success, sorry. Next time it
happens, could you do a test for me? Open a new programmer (you
don't have to restart the program first) and push the "ident decoder"
button. If that fixes it (command station goes back to normal), I
think it likely that a message got lost between the program and the
command station. If that _doesn't_ fix it, there's probably
something inconsistent in the program.
Bob
|
Locked
decoder id and naming confusions
Did a DecoderPro install today for a friend, and he immediately ran into
confusion on Digitrax and Lenz decoder models. He had a factory installed
Digitrax DN146 decoder and a factory installed Lenz LE063. Neither of these
types is in the decoder list in the current version of DecoderPro. After
checking both mfrs websites tonight, I concluded that the DN146 has the
same functions as the DN142, and the LE063 has the same functions as the
LE062, both of which are included in DecoderPro.
You can see how confusing this would be to a new user though. I can't find
anything about the CV07 values on the mfrs websites, so I have no idea if
the ID for the DN146 is the same as the DN142. I was somewhat confused by
the explanation on the Digitrax site for the 5th character (3rd digit) in
the model number. They talked about series 1 and series 2, and then fx3
products, but then a DN141 seems to be the same as a DN142 so I don't know.
At least Lenz stated that decoder models that differ in number by 1 are the
same thing, just with different connectors.
I think at a minimum the decoder names in DecoderPro ought to be looked at.
Maybe LE062/3 or something? Not sure what would work for Digitrax -
DN142-DN146?
Robin Becker
Tucson, AZ
|
Locked
Re: decoder id and naming confusions
The DN-146A program wise is the same as a DN-140. The DN-142 has
transponding and back emf that the 146 and 140 do not have. Program wise
the DN-144K, 145K,146A,147A & 148K are like a DN-140. While the DN-149K2,
141K2 and 141E2 are like a DN-142. The -163 decoders are another set of CVs
to be programmed.
Programming wise the Lenz/Atlas LE-062 and LE-063 are the same.
Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal www.ncinternet.net/~mmosher
Member
Golden Empire Model Railroad Club www.gemerc.homestead.com
Kern County Live Steamers www.trainweb.org/kernctyls
toggle quoted message
Show quoted text
----- Original Message ----- From: "Robin Becker" <n3ix@...> To: <jmriusers@...> Sent: May 30, 2002 09:33 PM Subject: [jmriusers] decoder id and naming confusions Did a DecoderPro install today for a friend, and he immediately ran into
confusion on Digitrax and Lenz decoder models. He had a factory installed
Digitrax DN146 decoder and a factory installed Lenz LE063. Neither of these types is in the decoder list in the current version of DecoderPro. After
checking both mfrs websites tonight, I concluded that the DN146 has the
same functions as the DN142, and the LE063 has the same functions as the
LE062, both of which are included in DecoderPro.
You can see how confusing this would be to a new user though. I can't find anything about the CV07 values on the mfrs websites, so I have no idea if
the ID for the DN146 is the same as the DN142. I was somewhat confused by
the explanation on the Digitrax site for the 5th character (3rd digit) in
the model number. They talked about series 1 and series 2, and then fx3
products, but then a DN141 seems to be the same as a DN142 so I don't know. At least Lenz stated that decoder models that differ in number by 1 are the same thing, just with different connectors.
I think at a minimum the decoder names in DecoderPro ought to be looked at. Maybe LE062/3 or something? Not sure what would work for Digitrax -
DN142-DN146?
Robin Becker
Tucson, AZ
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: decoder id and naming confusions
Michael,
Thanks. I don't see a DN140 in the DecoderPro set at this point.
For reference, can you point me to where on the Digitrax site this is all
spelled out?
Robin
toggle quoted message
Show quoted text
-----Original Message-----
From: Michael Mosher [mailto:mmosher1@...]
Sent: Friday, May 31, 2002 7:41 AM
To: jmriusers@...
Subject: Re: [jmriusers] decoder id and naming confusions
The DN-146A program wise is the same as a DN-140. The DN-142 has
transponding and back emf that the 146 and 140 do not have. Program wise
the DN-144K, 145K,146A,147A & 148K are like a DN-140. While the DN-149K2,
141K2 and 141E2 are like a DN-142. The -163 decoders are another set of
CVs
to be programmed.
Programming wise the Lenz/Atlas LE-062 and LE-063 are the same.
Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal www.ncinternet.net/~mmosher
Member
Golden Empire Model Railroad Club www.gemerc.homestead.com
Kern County Live Steamers www.trainweb.org/kernctyls
----- Original Message -----
From: "Robin Becker" <n3ix@...>
To: <jmriusers@...>
Sent: May 30, 2002 09:33 PM
Subject: [jmriusers] decoder id and naming confusions
> Did a DecoderPro install today for a friend, and he immediately ran into
> confusion on Digitrax and Lenz decoder models. He had a factory
installed
> Digitrax DN146 decoder and a factory installed Lenz LE063. Neither of
these
> types is in the decoder list in the current version of DecoderPro.
After
> checking both mfrs websites tonight, I concluded that the DN146 has the
> same functions as the DN142, and the LE063 has the same functions as the
> LE062, both of which are included in DecoderPro.
>
> You can see how confusing this would be to a new user though. I can't
find
> anything about the CV07 values on the mfrs websites, so I have no idea
if
> the ID for the DN146 is the same as the DN142. I was somewhat confused
by
> the explanation on the Digitrax site for the 5th character (3rd digit)
in
> the model number. They talked about series 1 and series 2, and then fx3
> products, but then a DN141 seems to be the same as a DN142 so I don't
know.
> At least Lenz stated that decoder models that differ in number by 1 are
the
> same thing, just with different connectors.
>
> I think at a minimum the decoder names in DecoderPro ought to be looked
at.
> Maybe LE062/3 or something? Not sure what would work for Digitrax -
> DN142-DN146?
>
>
> Robin Becker
> Tucson, AZ
>
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> jmriusers-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
>
>
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: decoder id and naming confusions
Robin,
In my version I have a DN140 and a couple of DN142's. Looks like a
little housecleaning is in order<G>.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: decoder id and naming confusions
This just was posted on the Digitrax list, useful information!
Out of production Digitrax decoders are listed at
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Bob,
Jim Hanna found that IDENT didn't work for NCE decoder. Checking into this,
I found that the NCE name is used differently in the decoderIndex and the
decoder files. In decoderIndex.xml, it is shown as "NCE Corp" but in the
NCE_D13SR.xml file is is "North Coast Engineering". Once Jim changed the
decoder file to read NCE Corp and then reindexed, IDENT "worked" fine.
I put worked in quotes because every NCE decoder reports 32 for CV07! Jim
is going to call NCE and ask about this. Perhaps they use a different CV
for model info.
Robin
|
Bob Jacobsen