#278 NCE PowerCAB fails to read BLI Paragon2 Motor tab

open
nobody
None
5
2013-01-21
2010-02-25
No

Here's a very repeatable bug in JMRI 2.9.4:

1. Start DecoderPro
2. Open the "NCE Command Monitor"
3. Open the Service Mode Programmer
4. Select the "BLI Paragon2 Diesel" from the pick list (you don't need a locomotive on the track)
5. Open the "Comprehensive" programmer
6. Select the "Motor" tab
7. Click the "Read Full Sheet" button

There will be a flurry of activity in the NCE Command Monitor window as DecoderPro tries to read the following CVs: 65 (Kick Start), 3 (Acceleration), 4 (Deceleration), 112:113 (Kp), 114:115 (Ki), 116:117 (Kd), and then 10 (BEMF cutout), 118 (KpSlow), 119 (KlSlow), 120 (Speed step smoothing).

With no loco on the track, all reads will fail, but notice the following:

1. The single-byte CVs will turn red as they fail

2. The two-byte CVs 112:113 and 114:115 will turn white as they fail to read (they should be red, shouldn't they)?

3. The reading stops after CV116 (first byte of CV116:117), leaving that CV red

4. There are five errors in the console window corresponding to each of the remaining CVs in the list (117, 10, 118, 119, 120)

[java] 231868 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
[java] 231868 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
[java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
[java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
[java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use

The same thing happens with an engine on the track (even an old Digitrax DN145 decoder). It seems that there is a threading issue in the JMRI NCE protocol layer with reading the double-byte CVs in this decoder definition. Doing a "Read Full Sheet" from the "CVs" tab does not have this problem -- it only occurs where JMRI switches from reading two-byte CVs to reading one-byte CVs.

Steve Williams

Here is the log I got from the NCE Command Monitor:

09:57:10.991: binary cmd: 9E
09:57:12.793: rep: "21"
09:57:13.793: binary cmd: A9 00 41
09:57:14.769: rep: "FF 33"
09:57:14.970: binary cmd: 9F
09:57:16.809: rep: "21"
09:57:16.819: binary cmd: 9E
09:57:18.652: rep: "21"
09:57:19.652: binary cmd: A9 00 41
09:57:20.629: rep: "FF 33"
09:57:20.829: binary cmd: 9F
09:57:22.672: rep: "21"
09:57:22.680: binary cmd: 9E
09:57:24.517: rep: "21"
09:57:25.521: binary cmd: A9 00 03
09:57:26.499: rep: "FF 33"
09:57:26.700: binary cmd: 9F
09:57:28.535: rep: "21"
09:57:28.536: binary cmd: 9E
09:57:30.379: rep: "21"
09:57:31.380: binary cmd: A9 00 03
09:57:32.365: rep: "FF 33"
09:57:32.565: binary cmd: 9F
09:57:34.401: rep: "21"
09:57:34.401: binary cmd: 9E
09:57:36.245: rep: "21"
09:57:37.245: binary cmd: A9 00 04
09:57:38.213: rep: "FF 33"
09:57:38.413: binary cmd: 9F
09:57:40.253: rep: "21"
09:57:40.264: binary cmd: 9E
09:57:42.088: rep: "21"
09:57:43.091: binary cmd: A9 00 04
09:57:44.057: rep: "FF 33"
09:57:44.257: binary cmd: 9F
09:57:46.095: rep: "21"
09:57:46.098: binary cmd: 9E
09:57:47.929: rep: "21"
09:57:48.929: binary cmd: A9 00 70
09:57:49.868: rep: "FF 33"
09:57:50.069: binary cmd: 9F
09:57:51.905: rep: "21"
09:57:51.905: binary cmd: 9E
09:57:53.741: rep: "21"
09:57:54.741: binary cmd: A9 00 71
09:57:55.696: rep: "FF 33"
09:57:55.896: binary cmd: 9F
09:57:57.735: rep: "21"
09:57:57.736: binary cmd: 9E
09:57:59.573: rep: "21"
09:58:00.573: binary cmd: A9 00 72
09:58:01.532: rep: "FF 33"
09:58:01.734: binary cmd: 9F
09:58:03.573: rep: "21"
09:58:03.573: binary cmd: 9E
09:58:05.421: rep: "21"
09:58:06.421: binary cmd: A9 00 73
09:58:07.385: rep: "FF 33"
09:58:07.585: binary cmd: 9F
09:58:09.423: rep: "21"
09:58:09.424: binary cmd: 9E
09:58:11.265: rep: "21"
09:58:12.265: binary cmd: A9 00 74
09:58:13.220: rep: "FF 33"
09:58:13.421: binary cmd: 9F
09:58:15.261: rep: "21"

Related

Bugs: #278

Discussion

  • Stephen P Williams

    Should have mentioned:

    OS is Linux (Debian testing) with Linux kernel 2.6.26-2, sun-java6-jre-6-12-1, JMRI 2.9.4.

    Connection is NCE USB to an NCE PowerCAB with firmware 1.28c (also fails with version 1.28.d2) on /dev/ttyUSB0

    Steve

     
  • Stephen P Williams

    Further debugging:

    1. There is an error in the BLI_Blueline_Paragon2_Diesel.xml with respect to the definition of CV116:117, it references CV115. My guess is that this causes listeners on the service mode programmer to be "interested" in CV115, and makes them misbehave. But the NCE code that tries to ensure that only one thread can "get" the program track is not working right here.

    2. Even after fixing the XML file to reflect the correct high byte of the variable, the PowerCab cannot read CV117 in direct-byte mode. It can read it in paged mode.

    3. There are other CVs missing from the decoder definition file when compared against the Paragon2 Technical Manual. I will post a patched file later.

     
  • Bob Jacobsen

    Bob Jacobsen - 2013-01-19

    Is this still doing it? There's been several changes in the area. Unfortunately, I don't have a NCE setup to test with.

     
  • Bob Jacobsen

    Bob Jacobsen - 2013-01-21

    Steve did some further testing, reported via email:

    The behavior with JMRI 3.2 is different now, and possibly more close to correct, but maybe worth thinking about.

    This time:

    1) the PowerCAB is sent into and out of programming track mode before every single CV is read. Or maybe I should say that the PowerCAB is taken out of programming mode and put back into programming mode after every read failure.

    2) each CV that is attempted is attempted twice

    3) only the lower-numbered CV of each 2-byte CV is read, since that fails, presumably the higher-numbered CV is skipped.

    4) all of the values on the "Motor" tab go red as they fail to red.

    5) the reading continues all of the way across the sheet and no longer hangs when reading 116.

    Steve

    Here is the trace from the NCE command monitor:

    22:20:30.899: [9E] Enter Programming track mode
    22:20:32.725: [21] command completed successfully
    22:20:33.728: [A9 00 41] Read CV 65 in direct mode
    22:20:34.705: [FF 33] Reply: FF 33
    22:20:34.908: [9F] Exit Programming track mode
    22:20:36.764: [21] command completed successfully
    22:20:36.771: [9E] Enter Programming track mode
    22:20:38.617: [21] command completed successfully
    22:20:39.621: [A9 00 41] Read CV 65 in direct mode
    22:20:40.607: [FF 33] Reply: FF 33
    22:20:40.810: [9F] Exit Programming track mode
    22:20:42.667: [21] command completed successfully
    22:20:42.680: [9E] Enter Programming track mode
    22:20:44.525: [21] command completed successfully
    22:20:45.529: [A9 00 03] Read CV 3 in direct mode
    22:20:46.520: [FF 33] Reply: FF 33
    22:20:46.723: [9F] Exit Programming track mode
    22:20:48.582: [21] command completed successfully
    22:20:48.589: [9E] Enter Programming track mode
    22:20:50.431: [21] command completed successfully
    22:20:51.437: [A9 00 03] Read CV 3 in direct mode
    22:20:52.417: [FF 33] Reply: FF 33
    22:20:52.622: [9F] Exit Programming track mode
    22:20:54.477: [21] command completed successfully
    22:20:54.487: [9E] Enter Programming track mode
    22:20:56.329: [21] command completed successfully
    22:20:57.333: [A9 00 04] Read CV 4 in direct mode
    22:20:58.308: [FF 33] Reply: FF 33
    22:20:58.514: [9F] Exit Programming track mode
    22:21:00.369: [21] command completed successfully
    22:21:00.375: [9E] Enter Programming track mode
    22:21:02.221: [21] command completed successfully
    22:21:03.228: [A9 00 04] Read CV 4 in direct mode
    22:21:04.210: [FF 33] Reply: FF 33
    22:21:04.414: [9F] Exit Programming track mode
    22:21:06.269: [21] command completed successfully
    22:21:06.276: [9E] Enter Programming track mode
    22:21:08.107: [21] command completed successfully
    22:21:09.111: [A9 00 70] Read CV 112 in direct mode
    22:21:10.059: [FF 33] Reply: FF 33
    22:21:10.264: [9F] Exit Programming track mode
    22:21:12.095: [21] command completed successfully
    22:21:12.105: [9E] Enter Programming track mode
    22:21:13.947: [21] command completed successfully
    22:21:14.959: [A9 00 70] Read CV 112 in direct mode
    22:21:15.917: [FF 33] Reply: FF 33
    22:21:16.122: [9F] Exit Programming track mode
    22:21:17.974: [21] command completed successfully
    22:21:17.980: [9E] Enter Programming track mode
    22:21:19.825: [21] command completed successfully
    22:21:20.829: [A9 00 72] Read CV 114 in direct mode
    22:21:21.825: [FF 33] Reply: FF 33
    22:21:22.028: [9F] Exit Programming track mode
    22:21:23.884: [21] command completed successfully
    22:21:23.895: [9E] Enter Programming track mode
    22:21:25.735: [21] command completed successfully
    22:21:26.741: [A9 00 72] Read CV 114 in direct mode
    22:21:27.717: [FF 33] Reply: FF 33
    22:21:27.922: [9F] Exit Programming track mode
    22:21:29.779: [21] command completed successfully
    22:21:29.790: [9E] Enter Programming track mode
    22:21:31.634: [21] command completed successfully
    22:21:32.638: [A9 00 74] Read CV 116 in direct mode
    22:21:33.602: [FF 33] Reply: FF 33
    22:21:33.810: [9F] Exit Programming track mode
    22:21:35.662: [21] command completed successfully
    22:21:35.671: [9E] Enter Programming track mode
    22:21:37.516: [21] command completed successfully
    22:21:38.519: [A9 00 74] Read CV 116 in direct mode
    22:21:39.499: [FF 33] Reply: FF 33
    22:21:39.702: [9F] Exit Programming track mode
    22:21:41.532: [21] command completed successfully
    22:21:41.538: [9E] Enter Programming track mode
    22:21:43.385: [21] command completed successfully
    22:21:44.388: [A9 00 0A] Read CV 10 in direct mode
    22:21:45.383: [FF 33] Reply: FF 33
    22:21:45.586: [9F] Exit Programming track mode
    22:21:47.417: [21] command completed successfully
    22:21:47.425: [9E] Enter Programming track mode
    22:21:49.269: [21] command completed successfully
    22:21:50.276: [A9 00 0A] Read CV 10 in direct mode
    22:21:51.251: [FF 33] Reply: FF 33
    22:21:51.455: [9F] Exit Programming track mode
    22:21:53.312: [21] command completed successfully
    22:21:53.320: [9E] Enter Programming track mode
    22:21:55.148: [21] command completed successfully
    22:21:56.152: [A9 00 76] Read CV 118 in direct mode
    22:21:57.118: [FF 33] Reply: FF 33
    22:21:57.322: [9F] Exit Programming track mode
    22:21:59.152: [21] command completed successfully
    22:21:59.158: [9E] Enter Programming track mode
    22:22:01.004: [21] command completed successfully
    22:22:02.009: [A9 00 76] Read CV 118 in direct mode
    22:22:02.991: [FF 33] Reply: FF 33
    22:22:03.195: [9F] Exit Programming track mode
    22:22:05.047: [21] command completed successfully
    22:22:05.057: [9E] Enter Programming track mode
    22:22:06.899: [21] command completed successfully
    22:22:07.904: [A9 00 77] Read CV 119 in direct mode
    22:22:08.869: [FF 33] Reply: FF 33
    22:22:09.073: [9F] Exit Programming track mode
    22:22:10.916: [21] command completed successfully
    22:22:10.921: [9E] Enter Programming track mode
    22:22:12.766: [21] command completed successfully
    22:22:13.769: [A9 00 77] Read CV 119 in direct mode
    22:22:14.743: [FF 33] Reply: FF 33
    22:22:14.946: [9F] Exit Programming track mode
    22:22:16.777: [21] command completed successfully
    22:22:16.783: [9E] Enter Programming track mode
    22:22:18.633: [21] command completed successfully
    22:22:19.636: [A9 00 78] Read CV 120 in direct mode
    22:22:20.595: [FF 33] Reply: FF 33
    22:22:20.800: [9F] Exit Programming track mode
    22:22:22.654: [21] command completed successfully
    22:22:22.660: [9E] Enter Programming track mode
    22:22:24.505: [21] command completed successfully
    22:22:25.510: [A9 00 78] Read CV 120 in direct mode
    22:22:26.453: [FF 33] Reply: FF 33
    22:22:26.665: [9F] Exit Programming track mode
    22:22:28.514: [21] command completed successfully

     
  • Dave Heap

    Dave Heap - 2013-01-21

    1) the PowerCAB is sent into and out of programming track mode before every single CV is read. Or maybe I should say that the PowerCAB is taken out of programming mode and put back into programming mode after every read failure.

    This behaviour also happens with NCE Power Pro systems, and is rather annoying as it briefly reconnects power to the layout (with sound locos attempting to restart). Whether it is necessary to do this on every read failure is a moot point. I havn't put much thought into it or looked at the code. Maybe just a "[9E] Enter Programming track mode" command is sufficient.
    2) each CV that is attempted is attempted twice

    3) only the lower-numbered CV of each 2-byte CV is read, since that fails, presumably the higher-numbered CV is skipped.

    4) all of the values on the "Motor" tab go red as they fail to red.

    5) the reading continues all of the way across the sheet and no longer hangs when reading 116.

    From an earlier comment:
    2. Even after fixing the XML file to reflect the correct high byte of the variable, the PowerCab cannot read CV117 in direct-byte mode. It can read it in paged mode.

    My JMRI/NCE combination always used to be very reliable reading CVs in direct mode. Somewhere in the last 12 months (or maybe less) I have started having issues reading reliably in direct mode. It has been on my 'to look into when I get time list'. It is particularly noticeable if you attempt the "Identify Loco" command in Direct Mode. My hunch is that it is at the CV17/18 read pair, which could tally with Steve's comments re 2-byte read combinations.

    I should look into it further... I think Steve may be onto something. Why only 24 hours in a day?

    Dave

     
  • Jim Betz

    Jim Betz - 2013-01-21

    Hi,

    As long as we are talking about things that don't seem to work
    very well ...

    1) The Paragon2 decoders(?) don't really read all that well in
    any environment.

    2) I, for one, think we are long overdue at revisiting the code
    for reading the 28-step speed table. The existing stuff was
    done in order to support the early decoders that could not
    deal with speed tables that had both ups and downs - each
    speed step was "required" to be either the same value as the
    one before it - or higher. That hasn't been true for a very
    long time.
    It is my belief that reading the 28-speed step table would
    be a lot faster/simpler/more effective is they were not
    treated as "a group that must complete as a unit". For
    instance, in the case of a read error for one of those CVs
    DP should just reread that CV immediately and after one
    retry move on to the next one "without prejudice". And in
    addition it should be possible to interrupt the process in
    the middle of reading the 28-step table.

    Sorry for some of this being "off topic" and a "WIBNI" ... Jim

     
  • Dave Heap

    Dave Heap - 2013-01-21

    On 22/01/2013, at 5:40 AM, "Jim Betz" oldrockygn@users.sf.net wrote:

    1) The Paragon2 decoders(?) don't really read all that well in any environment.

    The NCE Direct Mode read issues I have been seeing lately have been with QSI, LokSound, TCS and possibly Tsumani decoders.

    2) I, for one, think we are long overdue at revisiting the code
    for reading the 28-step speed table. The existing stuff was
    done in order to support the early decoders that could not
    deal with speed tables that had both ups and downs - each
    speed step was "required" to be either the same value as the
    one before it - or higher. That hasn't been true for a very
    long time.

    If this code is in, or affects 'SpeedTableVarValue.java' (I think it quite likely is), am in the middle of cleaning up some stuff to fix an issue Walter found with the new mfx style speed table I introduced in 3.3.1. If I can get those changes committed before tackling this one it would be appreciated. I also earlier discovered another bug with 3.2 where the dirty flag was not being set if only sliders were being changed and not text fields, but put that in the 'later' box.

    I need to get the mfx fix done ASAP. Will hopefully do so over the next couple of days.

    Dave

     
    Last edit: Dave Heap 2013-01-21
  • Stephen Williams

    I've been getting bounces when I reply to these messages to 278@bugs.jmri.p.re.sf.net, but will try once more.

    I should mention that at the time of the original bug report, I was using PowerCAB firmware 1.28c or 1.28d. I am now using firmware version 1.65. However, the commands sent to the PowerCAB do appear to be different now than they were with 2.9.4.

    I agree with Dave Heap that the recovery action of switching the PowerCAB out of service track mode and back to service track mode whenever a CV fails to read is not good. I can understand why the code might be trying to do that as a way to "recover". However, it makes the service mode programming track behavior of the PowerCAB dangerous since full track power can come back on whenever a CV read fails.

    I have learned from this experiment that I do not want to use JMRI for initial testing of a decoder after an installation in a new locomotive since I cannot control when JMRI switches to/from programming track mode.

    Steve

    On Jan 21, 2013, at 10:05 AM, Dave Heap wrote:

    1) the PowerCAB is sent into and out of programming track mode before every single CV is read. Or maybe I should say that the PowerCAB is taken out of programming mode and put back into programming mode after every read failure.

    This behaviour also happens with NCE Power Pro systems, and is rather annoying as it briefly reconnects power to the layout (with sound locos attempting to restart). Whether it is necessary to do this on every read failure is a moot point. I havn't put much thought into it or looked at the code. Maybe just a "[9E] Enter Programming track mode" command is sufficient.
    2) each CV that is attempted is attempted twice

    3) only the lower-numbered CV of each 2-byte CV is read, since that fails, presumably the higher-numbered CV is skipped.

    4) all of the values on the "Motor" tab go red as they fail to red.

    5) the reading continues all of the way across the sheet and no longer hangs when reading 116.

    From an earlier comment:
    2. Even after fixing the XML file to reflect the correct high byte of the variable, the PowerCab cannot read CV117 in direct-byte mode. It can read it in paged mode.

    My JMRI/NCE combination always used to be very reliable reading CVs in direct mode. Somewhere in the last 12 months (or maybe less) I have started having issues reading reliably in direct mode. It has been on my 'to look into when I get time list'. It is particularly noticeable if you attempt the "Identify Loco" command in Direct Mode. My hunch is that it is at the CV17/18 read pair, which could tally with Steve's comments re 2-byte read combinations.

    I should look into it further... I think Steve may be onto something. Why only 24 hours in a day?

    Dave

    [bugs:#278] NCE PowerCAB fails to read BLI Paragon2 Motor tab

    Status: open
    Created: Thu Feb 25, 2010 06:14 PM UTC by Stephen P Williams
    Last Updated: Mon Jan 21, 2013 07:17 AM UTC
    Owner: nobody

    Here's a very repeatable bug in JMRI 2.9.4:

    1. Start DecoderPro
    2. Open the "NCE Command Monitor"
    3. Open the Service Mode Programmer
    4. Select the "BLI Paragon2 Diesel" from the pick list (you don't need a locomotive on the track)
    5. Open the "Comprehensive" programmer
    6. Select the "Motor" tab
    7. Click the "Read Full Sheet" button

    There will be a flurry of activity in the NCE Command Monitor window as DecoderPro tries to read the following CVs: 65 (Kick Start), 3 (Acceleration), 4 (Deceleration), 112:113 (Kp), 114:115 (Ki), 116:117 (Kd), and then 10 (BEMF cutout), 118 (KpSlow), 119 (KlSlow), 120 (Speed step smoothing).

    With no loco on the track, all reads will fail, but notice the following:

    1. The single-byte CVs will turn red as they fail

    2. The two-byte CVs 112:113 and 114:115 will turn white as they fail to read (they should be red, shouldn't they)?

    3. The reading stops after CV116 (first byte of CV116:117), leaving that CV red

    4. There are five errors in the console window corresponding to each of the remaining CVs in the list (117, 10, 118, 119, 120)

    [java] 231868 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
    [java] 231868 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
    [java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
    [java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use
    [java] 231869 [AWT-EventQueue-0] WARN jmri.jmrit.symbolicprog.CvValue - Exception during CV read: jmri.ProgrammerException: programmer in use

    The same thing happens with an engine on the track (even an old Digitrax DN145 decoder). It seems that there is a threading issue in the JMRI NCE protocol layer with reading the double-byte CVs in this decoder definition. Doing a "Read Full Sheet" from the "CVs" tab does not have this problem -- it only occurs where JMRI switches from reading two-byte CVs to reading one-byte CVs.

    Steve Williams

    Here is the log I got from the NCE Command Monitor:

    09:57:10.991: binary cmd: 9E
    09:57:12.793: rep: "21"
    09:57:13.793: binary cmd: A9 00 41
    09:57:14.769: rep: "FF 33"
    09:57:14.970: binary cmd: 9F
    09:57:16.809: rep: "21"
    09:57:16.819: binary cmd: 9E
    09:57:18.652: rep: "21"
    09:57:19.652: binary cmd: A9 00 41
    09:57:20.629: rep: "FF 33"
    09:57:20.829: binary cmd: 9F
    09:57:22.672: rep: "21"
    09:57:22.680: binary cmd: 9E
    09:57:24.517: rep: "21"
    09:57:25.521: binary cmd: A9 00 03
    09:57:26.499: rep: "FF 33"
    09:57:26.700: binary cmd: 9F
    09:57:28.535: rep: "21"
    09:57:28.536: binary cmd: 9E
    09:57:30.379: rep: "21"
    09:57:31.380: binary cmd: A9 00 03
    09:57:32.365: rep: "FF 33"
    09:57:32.565: binary cmd: 9F
    09:57:34.401: rep: "21"
    09:57:34.401: binary cmd: 9E
    09:57:36.245: rep: "21"
    09:57:37.245: binary cmd: A9 00 04
    09:57:38.213: rep: "FF 33"
    09:57:38.413: binary cmd: 9F
    09:57:40.253: rep: "21"
    09:57:40.264: binary cmd: 9E
    09:57:42.088: rep: "21"
    09:57:43.091: binary cmd: A9 00 04
    09:57:44.057: rep: "FF 33"
    09:57:44.257: binary cmd: 9F
    09:57:46.095: rep: "21"
    09:57:46.098: binary cmd: 9E
    09:57:47.929: rep: "21"
    09:57:48.929: binary cmd: A9 00 70
    09:57:49.868: rep: "FF 33"
    09:57:50.069: binary cmd: 9F
    09:57:51.905: rep: "21"
    09:57:51.905: binary cmd: 9E
    09:57:53.741: rep: "21"
    09:57:54.741: binary cmd: A9 00 71
    09:57:55.696: rep: "FF 33"
    09:57:55.896: binary cmd: 9F
    09:57:57.735: rep: "21"
    09:57:57.736: binary cmd: 9E
    09:57:59.573: rep: "21"
    09:58:00.573: binary cmd: A9 00 72
    09:58:01.532: rep: "FF 33"
    09:58:01.734: binary cmd: 9F
    09:58:03.573: rep: "21"
    09:58:03.573: binary cmd: 9E
    09:58:05.421: rep: "21"
    09:58:06.421: binary cmd: A9 00 73
    09:58:07.385: rep: "FF 33"
    09:58:07.585: binary cmd: 9F
    09:58:09.423: rep: "21"
    09:58:09.424: binary cmd: 9E
    09:58:11.265: rep: "21"
    09:58:12.265: binary cmd: A9 00 74
    09:58:13.220: rep: "FF 33"
    09:58:13.421: binary cmd: 9F
    09:58:15.261: rep: "21"

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jmri/bugs/278/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

     

    Related

    Bugs: #278

  • Dave Heap

    Dave Heap - 2013-01-24

    On 24/01/2013, at 11:56 AM, "Stephen Williams" stevew123@users.sf.net wrote:

    I agree with Dave Heap that the recovery action of switching the PowerCAB out of service track mode and back to service track mode whenever a CV fails to read is not good. I can understand why the code might be trying to do that as a way to "recover". However, it makes the service mode programming track behavior of the PowerCAB dangerous since full track power can come back on whenever a CV read fails.

    I have learned from this experiment that I do not want to use JMRI for initial testing of a decoder after an installation in a new locomotive since I cannot control when JMRI switches to/from programming track mode.

    A somewhat surprising comment. I always use JMRI of initial testing of a decoder. In fact, I never use the Pro Cab/Power Cab handpiece for programming unless I do not have a computer with me. But on the other hand both my home (Power Pro) and clubhouse (Power Cab) layouts are fitted with a 4PDT programming track toggle switch (as well as an Auto-Switch), so full power cannot be accidentally applied until I am ready for it.

    I find the switching behaviour annoying annoying and often throw the isolating switches to the rest of the layout while reading all sheets. But not everyone has them (actually centre-off DPDT for DC-DCC changeover, but also useful for diagnostic isolation).

    Dave

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks