I have many locomotives with proper road numbers that overlap with others. For example, I have a Kato NYC PA unit with the number of 4301, but I also have a Kato SD70ACE in MRL with the same number.? I have many instances of this same situation.? There must be a better way to assign the identity of a locomotive so that these miss-identities do not happen. I have 62 of these occurrences. This is where better indexing could keep this from happening.

开云体育

??????

I do a lot of installs for others so it is not unusual to get locos with the same number. My method of assigning the file name would be in your case:-

NYC 4301

MRL 4301

I then have the owners initials after the number - so NYC 4301 xx and MRL 4301 yy

This might help.? You can also sort the roster either by File ID or Loco number.

Gerry

I have many locomotives with proper road numbers that overlap with others. For example, I have a Kato NYC PA unit with the number of 4301, but I also have a Kato SD70ACE in MRL with the same number.? I have many instances of this same situation.? There must be a better way to assign the identity of a locomotive so that these miss-identities do not happen. I have 62 of these occurrences. This is where better indexing could keep this from happening.

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

This isn't a JMRI issue but an ID naming issue on your part. Gerry has already suggest one way to do it.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

开云体育

I have been having similar issues. I agree that this is not a JMRI problem, but one which was caused by the short sighted people who set up the original specification for DCC

I name the locomotives by the manufacturer's part number, and they are unique.

I guess the right response is that the ID for every locomotive is the manufacturers part number. So the NYC 4301 PA unit is?106-0701-B, and the MRL SD70ACE is?176-4301-9999 where the 999 in my scheme means it is a custom painted and numbered locomotive. As I said all my ID's are unique.

The Identify button is a crude identification procedure because it relies on reading CV information from any arbitrary decoder and matching it to the roster entries.

What identification is in the roster entry is limited. No matter what manner the roster entry has been created (read type from decoder or simple manual selection), the only (hopefully reliable) information is the DCC address (in CVs 29,1,17&18) stored in the roster entry (provided the user either read or set and wrote that). There's no guarantee that CVs 7 and 8 have been read by the user either (however the identify procedure does attempt to match them as well - hopefully only if non-zero, I haven't checked the code).

Any attempt to read (and store) ProductID from a decoder during Identify is not only time consuming but not gaining anything because again there's no guarantee the user used the "Read type from Decoder" rather than manually picking (possibly incorrectly).

There's no way JMRI can tell the difference between liveries etc. from the decoder.

Furthermore many Sound decoders share ProductIDs between decoders with different sound projects, or have differing ProductIDs due solely to hardware batch numbers.
--
Dave in Australia

This is why the application needs a database engine under the hood. That would also allow picklists for road names and locomotive models. That would make it very easy for make an indexable ID system.?

开云体育

???????

Here is just a small section of my roster - all have the same Road identification, most have the same road number, but different decoders. This roster only has 1,405 entries - some N Scale, Some HO and Some O scale. These locos are all green.

NSW 3801	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 ar	3801	Econami Steam	ECO-200 Steam
NSW 3801 bd	3801	Tsunami Steam	TSU-1000 Light Steam
NSW 3801 dt	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 gh	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 gw	3813	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 jb	3830	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 jp	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 js	3801	Tsunami Steam	TSU-1000 DRGW K-Class Steam
NSW 3801 mp	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 mw	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 mw fl4	3801	TCS Function Decoders	FL4
NSW 3801 SM	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 tsu	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 wh	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 wh2	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3802	3802	QSI Steam Ver. 7	QSI Revolution Steam
NSW 3802 ls	3802	Tsunami Steam	TSU-1000 DRGW K-Class Steam
NSW 3802 rb	3802	Tsunami Steam	TSU-1000 DRGW K-Class Steam

This is why the application needs a database engine under the hood. That would also allow picklists for road names and locomotive models. That would make it very easy for make an indexable ID system.?

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

开云体育

...and is the discussion about the DCC ID or the JMRI ID? I am totally confused.
--
Stefan Bartelski

Home layout: The Blue Ridge Line, an HO representation of the L&N Etowah Old Line from Etowah to Elizabeth, set in 1986 9under construction)
Modular Layout: Shoofly module of the Country RRoads Modular group

That is the problem. There's no way of uniquely determining the JMRI ID (user-created and stored in the roster entry) from what is stored in (and we can read back from) the decoder (DCC ID, CV7, CV8). (That is what the original poster asked for.)

JMRI attempts to do just that. In some cases you may be lucky, in other cases (see Gerry's, mine is similar) you are going to get many matches to the only readable information.

The Identify button is a blunt instrument. If it works for you, count yourself lucky.
--
Dave in Australia

The identify-locomotive engine is here:



It’s just a simple state machine that reads CV29 to decide whether the short or long address is in use, then reads the appropriate CVs to get the address.

It’s used in several places, but a typical one is here:



where the address is used to do a selectLoco operation.



In turn, that selectLoco operation knows whether one or more matched. That would be a good place for the program to reason about whether any additional reads (CV7, CV8, etc) would be able to distinguish the different choices, and if need be, spend the time to do them.

If somebody wants to write that, the process is described here:



and related pages in the left index.

Bob


--
Bob Jacobsen
jacobsen@... +1-510-708-5988 AIM, Skype JacobsenRG

开云体育

It’s true that IdentifyLoco reads CV7 and CV8, but in at least some of the places in the code it does not use those values. Other places it does use them.

For example, java/src//jmrijmrit/roster/swing/RosterFrame.java has a selectLoco(int dccAddress, boolean isLong, int mfgId, int modelId) that uses the CV7/CV8 information when multiple values would otherwise match just the address. See the code right below the "//Still more than one possible loco, so check against the decoder family” comment.

Other places _don’t_ use the CV7/CV8 information. For example:

java/src//jmri/jmrit/symbolicprog/KnownLocoSelPane.java
java/src//jmri/jmrit/symbolicprog/CombinedLocoSelPane.java
java/src//jmri/jmrit/symbolicprog/CombinedLocoSelTreePane.java

which just use the address.

Depending on what code is selecting the locomotive, the selection might use CV7 and CV8 or it might not.

RosterFrame (which does use CV7 and CV8, at least as far as I can see) handles the “Identify” button on the upper left of the main DecoderPro roster pane. So that should be doing what’s requested already. It’s not clear to me what invokes the other code, but if somebody is seeing CV7/CV selection not working, that might be why.

If somebody wanted to read the ProductID from the decoder, that could be done only when needed by putting another check on the number left selected at the end fo the code in RosterFrame, and perhaps in the other places.

Bob

On Jan 2, 2019, at 10:28 PM, Dave Heap <dgheap@...> wrote:

The "Identify" button on the main DecoderPro window already reads the following CVs, in the order listed below:

CV29
CV17 & CV18 OR CV1 (depending on the result from CV29)
CV7
CV8

All the uses cases I checked (long and short addresses, no address match, unique address match, multiple address match) exhibited this behaviour.

So the "Identify" button is already reading CVs 7 and 8. We don't need to add them.

I don't have time to check the code at present to see if it actually uses the read values of CVs 7 and 8 nor in what way.

Tea time over here now and time to slow down for the day... Not to mention the thunderstorms starting...


--
Dave in Australia



On 3 Jan 2019, at 4:35 PM, Bob Jacobsen <rgj1927@...> wrote:

In turn, that selectLoco operation knows whether one or more matched. That would be a good place for the program to reason about whether any additional reads (CV7, CV8, etc) would be able to distinguish the different choices, and if need be, spend the time to do them.

--
Bob Jacobsen
rgj1927@...

开云体育

We also need to be careful to not lead a user into jumping to conclusions.

Just because a loco on the programming track returns an exact match to either:

A) DCC Address alone.
or
B) DCC Address plus CVs 7 & 8.
or
C) DCC Address plus CVs 7 & 8 plus ProductID.

Does not unequivocally mean that the loco under test is represented by that roster entry.

1) It's possible that the loco under test has had its DCC Address accidentally reset or changed and you have a false match.

2) It's possible that the loco under test doesn't have a roster entry but its DCC Address (and possibly also other items listed above) happen(s) to match an existing roster entry.

It is not uncommon to encounter user confusion between the roles of the "Identify" button versus the "Read Type from Decoder" button, since both of them involve the concept of identifying something. We tend to assume others have the background knowledge we do.

Another unrelated gotcha is that if you have a roster group selected and an "Identify" returns a match to a non-visible entry the "Identify" will succeed but no loco will be seen to be selected.

Dave

My experience is that the "Identify" button currently does a "first match" and doesn't flag multiple matches (unlike "Read Type from Decoder").

In my testing I often create multiple test entries (of the same or another decoder) without changing the address from the default of 3. I occasionally hit "Identify" without thinking and get a first-match.
--
Dave

开云体育