Okay, I have changes pending to add modParam descriptions to RTEC devices, as well as the EL3xxx temperature sensors and EL7041 driver. Most of the random EL* devices don't use modParams, and I don't want to go overboard, especially with devices that I don't have on hand. Here's a sample of what lcec_configgen now produces:
Code:
<slave idx="15" type="EL3204" name="D16">
<!-- Sensor type, Pt100|Ni100|Pt1000|Pt500|Pt200|Ni1000|Ni1000-TK5000|Ohm/16|Ohm/64 -->
<modParam name="ch0Sensor" value="Pt100"/>
<!-- Sensor resolution, Standard or High. High reduces the range in some cases. -->
<modParam name="ch0Resolution" value="Standard"/>
<!-- Number of wires used for sensor connection. 2, 3, or 4 -->
<modParam name="ch0Wires" value="2"/>
<!-- Sensor type, Pt100|Ni100|Pt1000|Pt500|Pt200|Ni1000|Ni1000-TK5000|Ohm/16|Ohm/64 -->
<modParam name="ch1Sensor" value="Pt100"/>
...
<!-- Number of wires used for sensor connection. 2, 3, or 4 -->
<modParam name="ch4Wires" value="2"/>
</slave>
....
<slave idx="19" type="EP7041" name="D20">
<!-- Maximum Amps for stepper -->
<modParam name="maxCurrent" value="5.0"/>
<!-- Stepper steps per revolution (usually 200) -->
<modParam name="motorFullsteps" value="200"/>
<!-- Encoder steps per revolution (usually 4000) -->
<modParam name="encoderIncrements" value="4000"/>
<!-- Maximum speed in steps/second. 1000|2000|4000|8000|16000|32000. -->
<modParam name="maxSpeed" value="2000"/>
<!-- Enable encoder. The EL7041 will fake an encoder if false. -->
<modParam name="encoder" value="true"/>
</slave>
<slave idx="27" type="ECT60" name="D28">
<!-- Enable support for Cyclic Synchronous Position mode. -->
<modParam name="enableCSP" value="true"/>
<!-- Enable support for Cyclic Synchronous Velocity mode. -->
<modParam name="enableCSV" value="false"/>
<!-- Maximum stepper Amps. -->
<modParam name="peakCurrent_amps" value="6.0"/>
<!-- Operation mode: openloop, closedloop, or foc. -->
<modParam name="controlMode" value="closedloop"/>
<!-- Number of encoder steps per revolution. -->
<modParam name="encoderResolution" value="4000"/>
<!-- Output 1 use: general, alarm, brake, in-place. -->
<modParam name="output1Func" value="alarm"/>
<!-- Output 2 use: general, alarm, brake, in-place. -->
<modParam name="output2Func" value="brake"/>
<!-- Input 3 use: general, cw-limit, ccw-limit, home, clear-fault, emergency-stop, motor-offline, probe1, probe2 -->
<modParam name="input3Func" value="cw-limit"/>
<!-- Input 4 use: general, cw-limit, ccw-limit, home, clear-fault, emergency-stop, motor-offline, probe1, probe2 -->
<modParam name="input4Func" value="ccw-limit"/>
<!-- Input 5 use: general, cw-limit, ccw-limit, home, clear-fault, emergency-stop, motor-offline, probe1, probe2 -->
<modParam name="input5Func" value="home"/>
<!-- Input 6 use: general, cw-limit, ccw-limit, home, clear-fault, emergency-stop, motor-offline, probe1, probe2 -->
<modParam name="input6Func" value="motor-offline"/>
</slave>
I'm trying to ride the line here between config spam and undiscoverability. In general, settings that will usually need to be changed, or settings that will give *really* unexpected results are getting documentation added that will flow directly through to generated configs.
The precise formatting is still bugging me; there's an extra newline before </slave>, and I should probably add a way to add a top-level comment for devices, like "see http://.../rtec.md for configuration details". But it's coming along nicely.
