Keyboard Shortcuts
Likes
Search
Locked
Decoder Pro Errors out when Programming Functions on TSU-21PNEM
#soundtraxx
#tsunami
I'm using windows 10, Decoder pro works fine with NCE and LOCONet via PR3.? I can control locomotives, program them and do just about everything. Here is the log from the system console: 2019-08-30 15:32:25,838 util.Log4JUtil? ? ? ? ? ? ? ? ? ? ? ? INFO? - * JMRI log ** [main] 2019-08-30 15:32:25,848 util.Log4JUtil? ? ? ? ? ? ? ? ? ? ? ? INFO? - This log is appended to file: C:\Users\pcgum\JMRI\log\messages.log [main] 2019-08-30 15:32:25,849 util.Log4JUtil? ? ? ? ? ? ? ? ? ? ? ? INFO? - This log is stored in file: C:\Users\pcgum\JMRI\log\session.log [main] 2019-08-30 15:32:25,854 apps.AppsBase? ? ? ? ? ? ? ? ? ? ? ? ?INFO? - DecoderPro version 4.17.3+R12d2ded starts under Java 1.8.0_221 on Windows 10 x86 v10.0 at Fri Aug 30 15:32:25 PDT 2019 [main] 2019-08-30 15:32:26,044 gui3.Apps3? ? ? ? ? ? ? ? ? ? ? ? ? ? INFO? - Starting with profile My_JMRI_Railroad.3f60eef2 [main] 2019-08-30 15:32:26,585 node.NodeIdentity? ? ? ? ? ? ? ? ? ? ?INFO? - Using 7b5a555b-e311-40a3-8586-36ee772ee891 as the JMRI storage identity for profile id 3f60eef2 [AWT-EventQueue-0] 2019-08-30 15:32:26,676 xml.AbstractSerialConnectionConfigXml INFO? - Starting to connect for "NCE" [main] 2019-08-30 15:32:27,722 serialdriver.SerialDriverAdapter? ? ? INFO? - NCE COM4 port opened at 9600 baud [main] 2019-08-30 15:32:27,760 xml.AbstractSerialConnectionConfigXml INFO? - Starting to connect for "LocoNet" [main] 2019-08-30 15:32:27,879 nce.NceConnectionStatus? ? ? ? ? ? ? ?INFO? - NCE EPROM revision = 6.2.1 [AWT-EventQueue-0] 2019-08-30 15:32:27,881 locobufferusb.LocoBufferUsbAdapter? ? INFO? - LocoBuffer-USB adapter set hardware flow control, mode=2 RTSCTS_OUT=2 RTSCTS_IN=1 [main] 2019-08-30 15:32:27,882 locobuffer.LocoBufferAdapter? ? ? ? ? INFO? - COM5 port opened at 57600 baud with DTR: true RTS: true DSR: true CTS: true? CD: false [main] 2019-08-30 15:32:27,897 loconet.LnPacketizer? ? ? ? ? ? ? ? ? INFO? - lnPacketizer Started [main] 2019-08-30 15:32:28,076 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path program: is C:\Program Files (x86)\JMRI\ [main] 2019-08-30 15:32:28,076 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path preference: is C:\Users\pcgum\JMRI\My_JMRI_Railroad.jmri\ [main] 2019-08-30 15:32:28,076 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path profile: is C:\Users\pcgum\JMRI\My_JMRI_Railroad.jmri\ [main] 2019-08-30 15:32:28,076 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path settings: is C:\Users\pcgum\JMRI\ [main] 2019-08-30 15:32:28,076 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path home: is C:\Users\pcgum\ [main] 2019-08-30 15:32:28,077 util.FileUtilSupport? ? ? ? ? ? ? ? ? INFO? - File path scripts: is C:\Program Files (x86)\JMRI\jython\ [main] 2019-08-30 15:32:41,010 decoderdefn.IdentifyDecoder? ? ? ? ? ?INFO? - Decoder returns mfgID:141;modelID:71;productID:285 [AWT-EventQueue-0] 2019-08-30 15:33:14,926 ementation.MultiIndexProgrammerFacade ERROR - Exception doing final write [AWT-EventQueue-0] jmri.ProgrammerException: CV number not supported at jmri.jmrix.nce.NceProgrammer.writeCV(NceProgrammer.java:130) at jmri.implementation.MultiIndexProgrammerFacade.programmingOpReply(MultiIndexProgrammerFacade.java:397) at jmri.Programmer.notifyProgListenerEnd(Programmer.java:216) at jmri.jmrix.nce.NceProgrammer.notifyProgListenerEnd(NceProgrammer.java:317) at jmri.jmrix.nce.NceProgrammer.reply(NceProgrammer.java:268) at jmri.jmrix.nce.NceTrafficController.forwardReply(NceTrafficController.java:110) at jmri.jmrix.AbstractMRTrafficController.notifyReply(AbstractMRTrafficController.java:298) at jmri.jmrix.AbstractMRTrafficController$RcvNotifier.run(AbstractMRTrafficController.java:1229) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$500(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) ?
|
开云体育pcgumshoe, I'm using windows 10, Decoder pro works fine with NCE and LOCONet via PR3.? I can control locomotives, program them and do just about everything. The problem is caused by a Power Pro firmware issue that affects program track operations with both JMRI and the NCE throttle. If you, by any means, attempt to write a value to any CV>256 in Program Track mode using an NCE Power Pro, the firmware will instead write to a CV<257, possibly corrupting ?your decoder. For, example, if you use the NCE throttle to write a value to CV275, that value will be written to CV19 (the consist address) instead, making your decoder appear non-responsive to its normal address! If you attempt use JMRI to write a value to CV275, JMRI intercepts that request (to protect your decoder) and instead throws an error (unfortunately not gracefully, but the error can be seen in the JMRI system console). The DDE ?and other advanced panes in the TSU2 use CVs>256 so are affected. The only workaround for these decoders is to read the decoder on the Program Track, then save and reopen in Program on Main mode. Attempting to use the NCE throttle as a workaround will simply corrupt other CVs in your decoder. ( The ESU decoders are not affected because ESU provides an in-decoder workaround that doesn't involve writing to CVs>256 so JMRI intercepts the write command and uses that workaround.) If you have TSU2 decoders, your only choices are to use Program on Main or to get another programmer (such as a SPROG or an NCE Power Cab/NCE USB combination). JMRI can easily be configured to use two connections in the same session, with Program on Main, throttles, turnouts etc. being directed to the Power Pro and Program Track commands being directed to the SPROG/Power Cab. Don't try other means to cheat around the firmware limitation in the Power Pro, it will inevitably lead to tears. Dave in Australia |
Thanks Dave for that explanation.
I placed my loco on my portable programming track that has an NCE USB connection and a PowerCab.? I was able to program the function correctly, so I thought, I still can't get the F3 to turn on when the loco is moving forward or stopped.? In the "Function Map" tab, I selected "FX3 Effect" and changed it to "F0" and then I put check marks in the "Forward Driving" and "Forward Standing," spots, still no luck. Thinking out of the box earlier, I did think to do a program on the main, but I wasn't getting any feedback or notification that my programming was having any effect.? It may have been after the decoder was corrupted with bad CV data, I reset the decoder before placing it on my PowerCab track. |
On Fri, Aug 30, 2019 at 04:29 PM, Dave Heap wrote:
The Digitrax PR4 also works well with these (and most/all other) decoders and is a more economical alternative. Steve "Breezlys" |
开云体育pcgumshoe, I placed my loco on my portable programming track that has an NCE USB connection and a PowerCab.? I was able to program the function correctly, so I thought, I still can't get the F3 to turn on when the loco is moving forward or stopped.? In the "Function Map" tab, I selected "FX3 Effect" and changed it to "F0" and then I put check marks in the "Forward Driving" and "Forward Standing," spots, still no luck.
NCE command stations always report success for any CV write operation (main or program track), even if there is no loco on the track. These are called "blind writes" and are common for most systems when programming on main. Dave in Australia |
开云体育Steve, On 31 Aug 2019, at 10:03 AM, Breezlys via Groups.Io <livinthelife@...> wrote: The Digitrax PR4 also works well with these (and most/all other) decoders and is a more economical alternative. There is a also CV128 'gotcha' when using the PR3/4 with non-Digtrax decoders: Dave in Australia |
Thanks everyone, you've solved my problem with programming and I solved my problem with the ditch lights, the diagram said function 2 (assuming F0, F1, F2, etc)? it was actually FX4 in decoder pro, I was thinking it was FX 3.? It's a fault with the TCS Keep alive circuits diagram and not conforming to everyone else.
|
开云体育Marc, On 1 Sep 2019, at 1:31 AM, forfoum@... wrote: The default values ?of CV57 and CV58 depend on what firmware version is on the decoder. FW version 1.0 will have 253/254, and FWv 1.1/1.2 will have 61/62. ?Recent 21PNEM releases should have FWv 1.1 or 1.2. JMRI only handles early firmware versions (CV57/CV58) The Soundtraxx related definition file (ecocv.xml) ?has not been reviewed/corrected for the new FWv details as it pertains to CV57/CV58 and will write 253/254 as the defaults. Since he has a PR3 in his hands and in his JMRI ?setup, he could use it to program the Soundtraxx TSU2 decoders as the PowerPro has issues with Index CV's as Dave points out. That or use the NCE PowerCab as his programming device of choice. This will not correct the fact that not all parts of the Soundtraxx definition files has been corrected for the FWv changes and he will still encounter the same issue. The default values in JMRI are always subject to the caveat that they may not apply to all versions of the decoder and that a Factory Reset followed by Read All CVs is best. For the TSU2, there are several significant problems: - The definitions currently identify (and name models) based on CVs 8,7,253,256. <> - To make firmware-specific defaults or definitions requires splitting 100 existing models into numerous firmware-based models (300 at last count).?<> - The model identification would have to be updated to include CVs 105 & 106. - However CVs 105 & 106 are the user-writeable User ID #1 and User ID #2. - The Firmware version is given by the default values of CVs 105 & 106 after a factory reset, not the current values. So identification would have to do a Factory Reset followed by a read of CVs 105 & 106. I don't think anyone would find that acceptable. - If, in spite of the above, it was decided to press ahead, it would require checking the defaults of over 300 CVs for all 300 model/firmware combinations (documented where?). That's around 90,000 CV default values to check against where? and much XML coding. Some things just aren't feasible or practical. Reading CVs (with or without a Factory Reset) is the only way for many of the complex modern decoders. Dave in Australia |