¿ªÔÆÌåÓýMick, On 27 Nov 2019, at 8:20 AM, Mick Moignard <mick@...> wrote: So I reset it again, checked that the loco would run, went back to my intended function map, erased actions on the F28 row and rewrote the entire decoder in POM mode. Bricked again. ?Reset on program track, erased the entire row with F28, and it still bricks - indeed, it actually bricked while writing the function map pane. ?? Could the issue be row 40? No, my intended function map setup goes to row 38 only. ?? The LokSound 5 Function Map has 72 rows. So the question is whether this is a Loksound 5 feature/bug, a Decoderpro function map issue, ?a sound project issue, or possibly even a Mick issue. If you haven't done the full correct read procedure described below with a LokSound decoder, writing anything on the Function Map pane can apparently "brick" the decoder and require a full reset. You must use New Loco->Read Type from Decoder to uniquely identify the decoder. If it doesn't do so, let me know what the system log says about the ID process. Drive Hold has changed from being a special template in Sound Slot 2 (with a V4) to a logical output. Independent brake has also changed somewhat. I can't see any problem with the CVs and bits in Row 40. You can check these yourself with the tooltips when you hover over the various checkboxes and also conform in the CVs pane. Have you tried to use a different row? Blank rows in the Function Map are ignored. If you can do one CSV Export from Read All immediately after a factory reset and another after you've made changes, I may be able to spot the problem. But on the other hand, Sound Slots have odd logical functions contained in them. Read All Sheets Reading the full decoder is essential, particularly with ESU decoders where there are no "standard defaults". Each sound project has its own "factory defaults". All ESU sound decoders are manufactured effectively blank. When a Sound project is loaded to the decoder (using LokProgrammer software) part of the procedure is to write a new set of "factory defaults". Because of a known (but as yet unresolved) race condition with certain decoder settings variables in JMRI code: 1) Use "Read Full Sheet" on the CVs pane instead of "Read All Sheets". It is less likely to cause errors when reading a decoder with lots of CVs. Once finished, some may be missed (displayed in red). Use "Read Changes on Sheet" as many times as needed until no red items remain. (Hint: Click on the Status column in the CVs pane until you see a down arrow. All the Red items will then be at the top.) 2) After you make changes on a programming sheet, don't use Write/Read changes on that programming sheet. Instead, switch to the CVs pane and use Write/Read changes on (the CVs) sheet. The result is the same but it will never trigger the race condition. You'll also see a number of messages in the JMRI System Log like this: "ERROR - Variable=xxxxxx; Busy goes false with state IDLE" Ignore these as they don't indicate a real error, we'll fix the problem in a later JMRI release. Dave in Australia |
