/
CreateDecoder.shtml
530 lines (446 loc) · 22.1 KB
/
CreateDecoder.shtml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.17), see www.w3.org">
<!-- Copyright Bob Jacobsen 2008 -->
<title>JMRI: DecoderPro User Guide - Creating A Custom Decoder
File</title>
<!-- Style -->
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<link rel="stylesheet" type="text/css" href="/css/default.css"
media="screen">
<link rel="stylesheet" type="text/css" href="/css/print.css"
media="print">
<link rel="icon" href="/images/jmri.ico" type="image/png">
<link rel="home" title="Home" href="/">
<!-- /Style -->
</head>
<body>
<!--#include virtual="/Header.shtml" -->
<div id="mBody">
<!--#include virtual="Sidebar.shtml" -->
<div id="mainContent">
<h1>JMRI: DecoderPro User Guide</h1>
<h2>Creating A Custom Decoder File</h2>
<p>This page provides information on how the decoder
definition files for the DecoderPro Symbolic Programmer work
and how to create a new one.</p>
<p>In this user guide, we walk you through the process of
creating a file to describe a new decoder. You might benefit
from reading the other sections of the DecoderPro user guide
to get background information, especially the <a href=
"IntroXML.shtml">XML introduction</a> and the section on
<a href="Files.shtml">Configuration Files contents</a>.</p>
<p>The easiest way to create a configuration file is to
modify an existing one. In this section, we walk you through
doing this.</p>
<dl>
<dt class="left">Make a copy of a similar file.</dt>
<dd class="first">
<p>Although you can call this new file anything you like,
it will work best if you use the same convention as the
provided files. That's <tt>"manufacturer name"_"decoder
family".xml</tt>, for example: <tt>Digitrax_1x2.xml</tt>
and <tt>Atlas_DualMode.xml</tt></p>
<p>For the provided files, we use the same
capitalization, etc, that the decoder manufacturer uses
in their documentation.</p>
<p>This new file should go in the <tt>decoders</tt>
subdirectory in the <tt>JMRI</tt> preferences directory
so that the program can find it. The
<tt>DecoderProConfig2.xml</tt> file lives in the
preferences directory, so you can search for that file to
locate it. (See the <a href=
"Files.shtml#location"><em>configuration files
page</em></a> for further details about how to find that
directory and its contents)</p>
<p>If you're modifying a decoder definition, it is best to
start with the most recent version, which can always be
found here on the JMRI web site at <a href=
"http://jmri.org/xml/decoders/">http://jmri.org/xml/decoders/</a>.
That way, it won't be hard to merge your changes with
ones that might have come before. Please don't do any
more reformatting than you have to. If you change the
tech stuff in the top 5 or 10 lines, or reformat the
contents, it gets very hard to tell what's changed and
what has not.</p>
</dd>
<dt class="left">Edit the new file</dt>
<dd>
<p>Open the new file with your favorite text editor.</p>
</dd>
<dt class="left">File contents: XML Header</dt>
<dd>
<p>You'll see something like this at the top of the file
(the examples are from the <a href=
"../../../../../xml/decoders/0NMRA.xml">0NMRA.xml</a>
file):</p>
<p class="example"><?xml version="1.0"
encoding="utf-8"?><br>
<?xml-stylesheet type="text/xsl"
href="../XSLT/decoder.xsl"?><br>
<!-- Copyright (C) JMRI 2001, 2005, 2007, 2-009, 2010
All rights reserved --><br>
...<br>
<decoder-config
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://jmri.org/xml/schema/decoder.xsd"><br>
</p>
<p>Don't mess with these lines; they describe the format
of the file.</p>
</dd>
<dt class="left">File contents: Author</dt>
<dd>
<p>The next element describes the author and version of
this decoder file:</p>
<p class="example"><version
author="jake@physics.berkeley.edu"<br>
version="1" lastUpdated="20011201"/></p>
<p>These attributes are only read by people, not the
program, so their exact format isn't critical. But we
encourage you to insert your email address in files you
create or change, so that if anybody has any questions
they can find you. The version and lastUpdated attributes
provide a way of telling different versions of a decoder
definition apart, so we'd also like you to update those.
For a new file, set the version back to "1", and if
you're modifying an existing file, increment the version
attribute to the next number.</p>
</dd>
<dt class="left">File contents: Decoder Family and
Model</dt>
<dd>
The next lines identify the "family" of decoders that
this file describes:
<p class="example"><decoder><br>
<family name="Digitrax 1x2" mfg="Digitrax"<br>
lowVersionID="240" highVersionID="242"<br>
comment="Digitrax DH142, etc" ><br>
<model model="DH142" numOuts="4"
numFns="2"/><br>
<model model="DN142" numOuts="4"
numFns="2"/><br>
<model model="DH083" numOuts="5"
numFns="2"/><br>
</family></p>
<p>The spacing is not important, but it is useful to indent
the file like this to make it more readable. XML uses
"elements" and "attributes" to carry information. The
<model> things are elements; attributes like
numOuts are set to specific values within elements. In
the 2nd through 4th lines above</p>
<p class="example"><family name="Digitrax 1x2"
mfg="Digitrax"<br>
lowVersionID="240" highVersionID="242"<br>
comment="Digitrax DH142, etc" ></p>
<p>the element is 'family', with attributes 'name',
'mfg', 'lowVersionID', 'highVersionID', and 'comment'. An
attribute is given a value with an equals sign and a
value in quotes (the quotes are required). The order of
the attributes is not important, and you can break them
across lines if that makes the file easier to read. Note
that all of the attributes must be inside the angle
brackets, and after the name of the element.</p>
<p>In this element, change the attributes to match your
new decoder:</p>
<ul>
<li><dfn>name</dfn> - the name of the decoder family.
It's best if you use the same name here as you used in
the filename.</li>
<li><dfn>mfg</dfn> - the manufacturer of the decoder.
It's best if you use the same manufacturer name here as
you used in the filename.</li>
<li>
<dfn>lowVersionID</dfn>, <dfn>highVersionID</dfn> -
The manufacturer can load a version number into CV 7
of a decoder. Not all manufacturers do this, but if
one is available the programmer can check if this
file is being used with the expected decoder type. If
only one specific value is valid, define the both
lowVersionID and highVersionID with the same value,
e.g.
<p class="example"> lowVersionID="123"
highVersionID="123"</p>If the decoder type can have
any one of a range of numbers, for example because
the manufacturer has made some updates, define both
attributes to cover the range:
<p class="example"> lowVersionID="21"
highVersionID="42"</p>If you don't know the version
number, don't define either of these attributes; just
leave them off. lowVersionID defaults to 0,
highVersionID defaults to 255, so together the
defaults mean "any value".
</li>
<li><dfn>comment</dfn> - this is optional. You might
want to include your name, or other info about the
changes in the file.</li>
</ul>
<p>The following lines:</p>
<p class="example"> <model model="DH142"
numOuts="4" numFns="2"/><br>
<model model="DN142" numOuts="4"
numFns="2"/><br>
<model model="DH083" numOuts="5"
numFns="2"/></p>allow you to list a number of
different decoder models that can use this file. For a
single decoder, remove all but one of the "model"
elements, and give it the model name of the decoder. The
numOuts and numFns are described later, but for now you
can just delete them, leaving something like:
<p class="example"> <model model="DH142"
/></p>The model element can also contain lowVersionID
and/or highVersionID attributes, which apply to just that
model. If one doesn't appear, the value from the family
element (or its default) will be used.
<p>It is important to note that
<em>the 'family'+'model' combination must be unique</em>.
This is the <em>only</em> information that can be used to match
a decoder definition to an existing roster entry.
</p>
<ul>
<li>There can be multiple instances of model 'x'
but they must reside in different families.</li>
<li>There can be multiple definitions of family 'y'
(in different decoder files) but model 'x'
can only appear within one of these.</li>
<li>The 'family'+'model' uniqueness restriction
applies irrespective of manufacturer.</li>
</ul>
</dd>
<dt class="left">File contents: Programming Modes</dt>
<dd>
<p>The next element defines what programming modes the
decoder can understand:</p>
<p class="example"><programming direct="byteOnly"
paged="yes"<br>
register="yes" ops="yes"></programming></p>
<p>Paged, register and ops can be set to either "yes" or
"no". Direct can be set to "no", "bitOnly", "byteOnly",
or "yes". The programmer uses this information to select
the programming mode to use when working with a
decoder.</p>
</dd>
<dd><a name="variable" id="variable"></a></dd>
<dt class="left">File contents: Variable names</dt>
<dd>
<p>The next part of the file consists of a set of
'variable' elements defining specific variables, nested
inside a 'variables' (note the extra "s") element. An
example:</p>
<p class="example"><variables><br>
<variable CV="1" item="Primary Address"
default="03"><br>
<decVal min="1" max="127"/><br>
<label>Short Address</label><br>
<comment>NMRA standard form</comment><br>
<tooltip>Digitrax systems only address
1-99</tooltip><br>
</variable><br>
<br>
(followed by more <variable> entries)<br>
<br>
(Insert new ones at the end)<br>
</variables></p>
<p>Each variable represents one thing to configure. They
can represent a single CV, e.g. address, or a few bits
that can be configured to control a particular function.
If some of these aren't appropriate to your decoder, you
can just remove them. Make sure you remove the entire
element from the <variable> to the matching
</variable>. You can also rearrange them if you'd
prefer a different order.</p>
<p>The attributes include:</p>
<ul>
<li><dfn>item</dfn> - The 'standard' name for this
variable. See the <a href=
"Programmer.shtml#id">discussion on the programmer
definition page</a> for more information on this.
Generally, look at the Comprehensive programmer to find
something similar, and use the "name" attribute of
that.</li>
<li><dfn>CV</dfn> - Which CV contains the configuration
information for this variable.</li>
<li><dfn>mask</dfn> - A pattern like "XXXVVVXX" which
controls which bits in the CV make up the variable.
Each "V" is a bit that's included, and "X" are bits
that are not to be included. It's best to have eight
characters, as that makes it clearer what's going on.
If the variable is a full byte, this attribute can be
omitted.
<p>
Generally, the V characters should be a contiguous block
of bits as specified in the manufacturer's documentation
for the decoder. In certain rare cases, the
layout of the decoder might
require a different pattern like XXVVXXVV, but
in those cases please check the operation of the
resulting decoder definition carefully to make sure it
does what you want.
<p>
As another special case, this can also be used (along with
some other attributes) to handle CVs that are coded in
bases other than binary: Ones that store their
parts as decimal digits, or even base 3 or 5.
That's a bit more technical, it's rarely needed, but
if you do need it see the
<a href="http://jmri.org/JavaDoc/doc/jmri/jmrit/symbolicprog/VariableValue.html">javadoc for more details</a>.
<li><dfn>default</dfn> - The default value for this
variable. This is used for a new decoder, or when you
want to set the decoder back to its defaults.</li>
</ul>
<p>(There are a few more, which we'll leave for the
advanced section below)</p>
<p>The "label" included element provides a
human-comfortable name for this variable. This is
generally what the decoder manufacturer calls this item,
even if other manufacturers or the NMRA use a different
name for similar things. It is optional, in which case the
"item" value will be used to label it when it's presented
to the user.</p>
<p>The "comment" element let you provide additional
information to future developers. This information is
visible when editing the definition, but isn't provided
to somebody who's just using DecoderPro.</p>
<p>The "tooltip" element let you provide additional
information to the user when the user hovers their cursor
over the variable on the screen.</p>
</dd>
<dt class="left">File contents: Creating new Variable
definitions</dt>
<dd>
<p>You can also define new variables. A good starting
point is to copy a similar definition, change its item
name to a new value, and then edit its contents.</p>
<p>To define how the new variable is displayed and
edited, you add elements within the 'variable' element.
There are several possible forms:</p>
<ul>
<li>For a decimal value, you include a decVal element
like the example above. The two optional attributes are
min and max, which define the range of acceptable
values. If you omit them, values from 0 to 255 are
allowed.</li>
<li>If you'd rather enter and display values in
hexadecimal, use a 'hexVal' element. It's otherwise the
same as the 'decVal' element we've already
discussed.</li>
<li>
<p>If your decoder supports a long address, you can
add a 'longAddress' element. It's perhaps easiest to
copy this from another file, or from this
example:</p>
<p class="example"><variable item="Long Address"
CV="17"><br>
<longAddressVal/><br>
</variable></p>
</li>
<li>
<p>If your decoder supports it, you can enter a
'speedTableVal' element for the speed table. Optional
attributes are: "entries", "min", "max" and "mfx"
(when true enables the Märklin mfx® style
speed table). Example:</p>
<p class="example"><variable item="Speed Table"
CV="67"><br>
<speedTableVal/><br>
</variable></p>
</li>
<li>Some decoder options are best represented by
"choose one choice". These are represented by a
enumVariable element. Example:
<p class="example"><variable item="F6 during DC
operation" CV="13" mask="XXVXXXXX"><br>
<enumVal><br>
<enumChoice choice="Off"/><br>
<enumChoice choice="On"/><br>
</enumVal><br>
</variable></p>
<p>Each enumChoice element describes one possibility.
There can be as many of these as desired. For a one
bit choice, you use two enumChoice elements as in the
example. For a 4 bit choice, like the FX codes in a
Digitrax decoder, you can use up to 16 choices. They
are displayed in the order they are entered in the
file, and are also numbered in that order. If the
first is chosen, a 0 is entered in the CV bits;
choosing the second stores 1; etc.</p>
<p>If you need to specific a specific number for an
enum option, add a "value" attribute:</p>
<p class="example"> <enumChoice choice="Blue"
value="32"/></p>
</li>
</ul>
</dd>
<dt class="left">Including fragment files</dt>
<dd>
<p>Decoder definitions can include "fragment files"
which provide common definitions of some CVs.
This has the advantage that they're already created and
tested, and often include tooltip text, translations
and other nice features. See the existing
decoder definitions for
<a href="http://jmri.org/xml/decoders/nmra">examples</a>.
Some key ones:</p>
<ul>
<li>CV1, the primary or short address,
CV17 and 18, the extended or long address,
and the corresponding CV29 bits can
be handled by one of these, depending
on what the decode supports:
<ul>
<li>xml/decoders/nmra/shortAddressOnly.xml
<li>xml/decoders/nmra/shortAndLongAddress.xml
</ul>
<li>CV19, the consist address and direction,
can be handled by one of these:
<ul>
<li>xml/decoders/nmra/consistAddr.xml
<li>xml/decoders/nmra/consistAddrDirection.xml
</ul>
<li>The CV16/CV15 decoder lock feature can be
handled by the xml/decoders/nmra/decoderLockId16.xml
fragment file. Note that only CV16 is included;
CV15 should not be included in the definition
to prevent it from being changed after decoder
installation.
</ul>
<p>You can also use fragment files to include (hence simplify)
<a href="http://jmri.org/xml/decoders/parts">common sets of enum choices</a>.</p>
</dd>
<dt class="left">Checking for syntax errors</dt>
<dd>
<p>At this point, you've created a new configuration
file!</p>
<p>You can check it for syntax by selecting the "Validate
XML file" item from the "Debug" menu. It opens a file
selection dialog; select your file and click "open". If
all is well, you'll get a dialog box that says "OK". If
not, you'll get a completely incomprehensible error
message. About the only useful part of that message is
the line number; open an editor to that line and try to
see what's wrong with the syntax.</p>
</dd>
<dt class="left">Add the file to the index</dt>
<dd>
<p>All that's left is to enter your new file in the
index. This index is used to speed the startup of the
program, when the list of available decoders is
constructed.</p>
<p>Select the "Recreate decoder index" item from the
DecoderPro "Actions" menu or the PanelPro "Debug" menu.</p>
</dd>
</dl>
<p>Congratulations! You're done. Next, open the programmer
application and try it.</p>
<p>For more advanced information on the content of the files,
please see the <a href="CreateDecoderAdvanced.shtml">Advanced
Decoder Definitions</a> page.</p>
<!--#include virtual="/Footer.shtml" -->
</div><!-- closes #mainContent-->
</div><!-- closes #mBody-->
</body>
</html>