marklin-users.net community | Forum
»
General topics
»
Digital
»
MFX signal chose an already in use address upon install.
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
I thought the CS3 knows if an address is already used. My 37373 br 101 "Starlight Express" (which is not an MFX Loco.) was already in the CS3 loco. roster with address "03". I installed the dual aspect signal automatically. The CS3 chose "01" and "03" rrespectivley for the dual aspect home/distant signal. I heard the signal click change when I had the Loco running slow and touched the "rail" icon for the acc./dec/ delay off function. I'll just change the Loco. address to "04". When two Loco's. are selected with a duplicate addres, the CS3 prompts it.
|
 1 user liked this useful post by marklinist5999
|
|
|
Joined: 16/02/2004(UTC) Posts: 15,443 Location: DE-NW
|
Theoretically accessories should not respond to loco addresses and vice versa.
If the signal responds to the loco address then this appears to be a fault of the signal or the CS3. |
Regards Tom --- "In all of the gauges, we particularly emphasize a high level of quality, the best possible fidelity to the prototype, and absolute precision. You will see that in all of our products." (from Märklin New Items Brochure 2015, page 1) ROFLBTCUTS  |
 2 users liked this useful post by H0
|
|
|
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
Thank you Tom! Hmm, I wonder what sort of fault? Not always, but sometimes, when I shut down the CS3, the green check mark isn't always showing in the system status menu. Same thing after boot-up. All esle is fine with it. I only noticed it did this after I first changed the signal aspect with the mouse while this loco. was on the layout. There was one decoder update pending. I just now intitiated it.
|
 1 user liked this useful post by marklinist5999
|
|
|
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand
|
Originally Posted by: marklinist5999  ... I heard the signal click change when I had the Loco running slow and touched the "rail" icon for the acc./dec/ delay off function. I acknowledge the issue (bug? / feature?) Scope = - 76496 (and maybe its family) - not a m83 (neither mfx or non-mfx) - - Test candidate 76496 = firmware 1.18.0.4 date 20141118 - MM address #1 - CS accessory/signal type irrelevant - Any manual accessory added with MM#1 - Controller - - CS3 2.3.1(8) - - or CS2 4.2.13(14) - - or MS2 3.121 - - or 6021 As observed, on first glance, - setting F4 "ON" for the loco with MM address #1 will result in signal with address #1 .... ... to red if it was not red already ... prevent the signal from changing to a non red aspect (actually , when attempted, TWO changes happen in quick succession, the signal does go NOT RED but then immediately goes RED again) - setting F4 "OFF" - does not turn the signal to NOT red, but does (free up) allow for it to be set as per normal operation need to research a bit more....... On the basis that ... - multiple controller environments - the screen icon for the signal does NOT graphically reflect the change I would say we are talking a bug with the 7649* signals P.S. The thread title should be updated as this is neither a CS3(only) nor a mfx issue Edited by user 13 October 2021 10:54:55(UTC)
| Reason: add 6021 |
Peter
|
 5 users liked this useful post by clapcott
|
|
|
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
Ah, ok! So the signal decoder chose an already used address? My only other accessories are two m83 decoders. I installed them for maximum number of addresses. Is that the MM setting? I thought dcc. 400 beginning address. One other note I left out earlier was that I had the locomotive entered for use on both speed control knobs on the CS3. The signal has never acted that way before.
|
|
|
|
Joined: 16/02/2004(UTC) Posts: 15,443 Location: DE-NW
|
Originally Posted by: clapcott  P.S. The thread title should be updated as this is neither a CS3 nor a mfx issue Looks like a signal issue. The bug could be in the MM protocol implementation of the new mfx/DCC/MM signals. It surely is not an issue with the mfx address. AIUI the signal uses mfx to negotiate the MM address to be used. How about: "New mfx/dcc/MM signal responds to MM loco address"? |
Regards Tom --- "In all of the gauges, we particularly emphasize a high level of quality, the best possible fidelity to the prototype, and absolute precision. You will see that in all of our products." (from Märklin New Items Brochure 2015, page 1) ROFLBTCUTS  |
|
|
|
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand
|
Originally Posted by: marklinist5999  Ah, ok! So the signal decoder chose an already used address? No, on a couple of points. 1) If you use the CS2/CS3 "mfx discovery" then it is the CS that "chooses" an address to configure and only if you accept the option for "Get a new address" If you do not use the "mfx discovery" or select "keep its address" then the address will be what you "choose" to set up in the DIP switches. 2) Accessory addresses are different to locomotive decoder addresses, in a manner not too dissimilar to the way a DCC locomotive decoder and a MM/FX locomotive decoder are different. It is quite acceptable to have, on the same controller at the same time, ... - an accessory with MM address #1 - an accessory with DCC address #1 - a locomotive with MM address #1 - a locomotive with DCC address #1 - a locomotive with mfx address #1 (a bit unlikely as the mfx address is a serial number identifier - but theoretically possible, and there is also the implementation of the negotiated SID (short address) ) Currently I am not aware of any accessory device that OPERATES with mfx. The so called mfx accessory devices use the mfx protocol for configuration purposes ONLY and this does not preclude their configuration by the MM or DCC protocols if desired. |
Peter
|
|
|
|
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand
|
Originally Posted by: H0  Originally Posted by: clapcott  P.S. The thread title should be updated as this is neither a CS3 nor a mfx issue Looks like a signal issue. The bug could be in the MM protocol implementation of the new mfx/DCC/MM signals. It surely is not an issue with the mfx address. AIUI the signal uses mfx to negotiate the MM address to be used. How about: "New mfx/dcc/MM signal responds to MM loco address"? I would go further with .. "7649* signal with MM addr.#1 adversely affected by F4 of a loco also set to MM addr.#1""7649* and 7039* signal range incorrectly responding to Loco FUNCTION decoder addresses" no need for irrelevant references to mfx/dcc Edited by user 14 October 2021 07:46:41(UTC)
| Reason: Not specified |
Peter
|
 1 user liked this useful post by clapcott
|
|
|
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
Still, as HO Tom stated above earlier, A Loco. function should not activate an accessory, nor should an accessory activate a Loco. function. Thought's Clapcott?
|
|
|
|
Joined: 23/07/2014(UTC) Posts: 8,470 Location: ENGLAND, Didcot
|
Originally Posted by: clapcott  It is quite acceptable to have, on the same controller at the same time, ... - an accessory with MM address #1 - an accessory with DCC address #1 - a locomotive with MM address #1 - a locomotive with DCC address #1 - a locomotive with mfx address #1 (a bit unlikely as the mfx address is a serial number identifier - but theoretically possible, and there is also the implementation of the negotiated SID (short address) )
Currently I am not aware of any accessory device that OPERATES with mfx. The so called mfx accessory devices use the mfx protocol for configuration purposes ONLY and this does not preclude their configuration by the MM or DCC protocols if desired.
Peter missed out another alternative address possibility. What he describes as an accessory with MM address #1 only covers points and signals. The one missed out is a mobile accessory like the 4998 Panorama Car, 4999 Dance Car and 49960 Measurement Wagon which use another address space that can be #1. This address space is sometimes linked to a loco address (which happens with a 2680 King Wilhelm train) so that coach lighting operated by the mobile accessory address space is operated by function keys on the locomotive selection. In the case of the King Wilhelm train the coaches use the mobile accessory address space to activate coach lighting, while the loco uses the MM loco address space to control speed and its own functions (I think only lights). It sounds to me as though the cs3 software is mistakenly linking a loco address space address with an accessory space address because they have the same address number. It shouldn't do this, if it was going to make such a linkage it would be a loco address with a mobile accessory address instead of a fixed accessory address.
|
 1 user liked this useful post by kiwiAlan
|
|
|
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
Thank's Alan! That makes sense to me.
|
|
|
|
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand
|
Originally Posted by: kiwiAlan  It sounds to me as though the cs3 software is mistakenly linking a loco address space address with an accessory space address because they have the same address number. As above it is NOT just the CS3 and I am unsure if it is a mistake with the multiple controllers (6021, MS2, CS2, CS3) unless they are all failing to set the middle trit to 1-1 More likely the signal is failing to honour the middle trit and validate only 0-0 (i.e. it should ignoring 1-1) Quote:The one missed out is a mobile accessory like the 4998 Panorama Car, 4999 Dance Car and 49960 Measurement Wagon which use another address space that can be #1. Correct and it is this format that helps to explains the address alignment and Fx combinations (still requires a bug in the misinterpretation of the middle trit to have an effect) Address:While accessory address #1 just happens to map to Loco "mobile accessory" address #1, Loc(acc) #2 , is like a k83 box where the second k83 has its first port as #5. Loc(acc) #3 , is like a k83 box where the third k83 has its first port as #9. Function becomes Sub-address. with the misinterpretation going on, F4 on = pulse the addressed port F1-F3 become the port sub-address with an octal range of 0-7. Thus if your Loco has a base address of 3 and ... - the F1-F3 states are OFF-OFF-OFF when F4 is set on this translates to pulse Acc address 9 RED (i.e. Red or aspect Hp00) - the F1-F3 states are ON-OFF-OFF when F4 is set on this translates to pulse Acc address 9 GRN (i.e. Green or aspect Hp1) - the F1-F3 states are ON-ON-OFF when F4 is set on this translates to pulse Acc address 10 RED (i.e. Green/Amber or aspect Hp2) - the F1-F3 states are OFF-ON-OFF when F4 is set on this translates to pulse Acc address 10 GRN (i.e. Red/White or aspect Hp2) etc |
Peter
|
 2 users liked this useful post by clapcott
|
|
|
Joined: 10/02/2021(UTC) Posts: 3,888 Location: Michigan, Troy
|
The decoder in this Loco. is acting odd. It was hesitating to start. It was actually set at address #01, which is the home part of the signal. I thought perhaps it was the address confusion doing it. So I changed the Loco's. address to 04. It's still acting the same. I put my ICE 3 on the layout, which has address #03, the same as the distant part of the signal. No odd functioning. The 37780 ICE 3 however does not have a accelleration/decel. off function.
|
|
|
|
marklin-users.net community | Forum
»
General topics
»
Digital
»
MFX signal chose an already in use address upon install.
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.