Locked
Re: Change the way we present decoder names?
CV8 seems to be the most reliable data but I'm not sure what they do
when a decoder is subcontracted like say Digitrax makes a decoder for Atlas
or similar.
One of the very large problems I see with anything that is done is the
availability of programmers. We have very few and need to recruit
more<VBG>.
I see we have another Jon (I like that name<G>). Jon, as you work in
the software development industry do you fit in the above needed category?
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: Change the way we present decoder names?
Bob,
What about by Manufacturer, Scale, Model
Example:
Digitrax, N, DN142
or
North Coast Engineering, HO, D13SR
Al Silverstein
toggle quoted message
Show quoted text
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: Friday, May 31, 2002 1:52 PM
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
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 the Yahoo! Terms of Service.
|
Locked
Re: Change the way we present decoder names?
'Family' seems like a rather confusing category. Dividing the list by
manufacturer is a good idea. In other words, I agree with Robin.
Mike
toggle quoted message
Show quoted text
On Friday 31 May 2002 11:06 am, Robin Becker wrote: Bob,
I think I suggested a similar approach that was simpler. The dropdown
decoder list just shows manufacturers, but then there are flyout menus for
each manufacturer that list the models. If you like the family apprach,
you could flyout the family menu from the manufacturer instead, then have
the models flyout from the family. This advantage of this approach over
Mark's is that there is no need to enter data manually ahead of time for the
mfr or the family.
Robin
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Friday, May 31, 2002 10:52 AM
To: jmriusers@...
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
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 the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: Change the way we present decoder names?
I'm still getting my DCC system up and running; so, I'm not (yet) a
JMRI user; but, I work in the software development industry, so I'll
jump in and offer up my $0.02.
Perhaps what is needed is a simple search facility; so, if a specific
decoder is not listed, you could search for decoders that have similar
attributes (as listed on the mfg web site and/or the product
information supplied with the decoder). These attributes could
include (but not limited to)
* Manufacturer
* Power rating (1A, 1.5A, 2A, etc.)
* # functions
* FX
* Back EMF
* speed steps
* supported CV's
* etc.
Jon
|
Locked
Re: Change the way we present decoder names?
Bob,
I think I suggested a similar approach that was simpler. The dropdown
decoder list just shows manufacturers, but then there are flyout menus for
each manufacturer that list the models. If you like the family apprach,
you could flyout the family menu from the manufacturer instead, then have
the models flyout from the family. This advantage of this approach over
Mark's is that there is no need to enter data manually ahead of time for the
mfr or the family.
Robin
toggle quoted message
Show quoted text
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Friday, May 31, 2002 10:52 AM
To: jmriusers@...
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
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 the Yahoo! Terms of Service.
|
Locked
Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I agree it's a mess, and will be happy to implement whatever you guys think is best.
Mark Gurries made a suggestion a while back that I think would help with the user interface. He suggested that, instead of a single long list of decoders that's ordered by manufacturer, that we split it into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the left, that will restrict the other two to just that manufacturers families and models. If we auto-identify the manufacturer, that also does the restriction, so people just see the ones from that manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx, or "FX Decoders" for Digitrax. The idea is to have them be "so close together that they basically all program the same". Even if you're not sure of the particular model, and the program can't figure it out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for that in the "Model" column. If they don't see it, perhaps because nobodies ever made a file for it, but know that it's from "Wizzo Co", they could select that under manufacturer (or maybe decoder ID would do that), and look at the families. They they might realize that it's a "CoolChip" decoder, select that family, and be close enough to function.
Does this sound like it could help?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: decoder id and naming confusions
Because with some manufactures CV7 isn't going to always tell much maybe the DN14(x) concept would be good. The tabs (panes) for that group could then be asterisked with the comment, "not all of this family has this function". That way the user could at least get this information from the data sheet. We must assume at least a little reading is required! This would also work with the newer decoders, of the same family, that are going to 5 or 6 functions. CV07 value should be omitted from the decoder file so that IDENT can report the manufacturer name along with a message that the model cannot be determined?< This seems to be a reasonable idea, at least something to think about.
|
Locked
Re: decoder id and naming confusions
Ok, so how should the decoder name appear in the list when multiple decoders
have the same CV07 value?
My suggestion is that if the models have the same features, i.e. DN140,
DN144, DN145, DN146, DN147, DN148, then they should show up as _one_ entry
in the decoder list with some kind of generic name. Something like DN14X,
or DN140/144/145/146/147/148 or DN140/4/5/6/7/8 or ? This way when you use
IDENT the reported decoder type will at least include the number you expect.
If the models have different features but the same CV07 value, like all the
NCE decoders that report CV07-32, maybe their should be a flag in the
decoder file or the CV07 value should be omitted from the decoder file so
that IDENT can report the manufacturer name along with a message that the
model cannot be determined?
Robin Becker
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
Thanks Jon!
toggle quoted message
Show quoted text
-----Original Message-----
From: Jon Miller [mailto:atsf@...]
Sent: Friday, May 31, 2002 9:16 AM
To: jmriusers@...
Subject: Re: [jmriusers] 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
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
decoder sort order (was decoder id and naming confusions)
Jon,
You are correct, I missed the DN140 in the decoder list. This was certainly
operator error on my part, but that aside the sort order of the decoder list
is another thing I've been meaning to bring up. I think it should be
alphabetical within each mfr's block.
Robin
|
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
|
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
|
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
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
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
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: 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
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: 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: 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
|
Bob Jacobsen