The 1XD board provides step, direction and enable outputs to interface a Duet 3 system with a motor controller that takes those inputs. In addition it has a number of peripheral inputs and outputs for functions such as sensing driver alarms, temperature and controlling a brake and axis endstop. It connects to the Duet 3 CAN-FD bus using RJ11 connectors (same as the Duet 3 Mainboard 6HC, Expansion 3HC, and the tool distribution board). Multiple drivers can be daisy chained on the bus, with power (up to 48V) provided locally to the 1XD board. This allows for very large machines to be constructed without a significant wiring burden and signal integrity issues.

• ARM Cortex M0+ processor running at 48MHz.
• 5V differential Step, Dir and Enable outputs for a single external stepper driver, plus two common +5V pin. Each pin can source/sink a max of 10mA.
• Two low-current (2A max recommended) outputs at VIN voltage with PWM capability and built-in flyback diodes: out0, out1
  • Example use - Motor brake control, Motor Cooling control
• Two 5V-level PWM capable output (3mA max), through 470R series resistor: io0.out, io2.out.
  • Example use - the Alarm Reset signal on some Step/Servo drivers
  • Example use - Start built in function (e.g. homing) on some step/servo drivers
• Three digital inputs with permanent 27K pullup resistors, protected against over-voltage: io0.in, io1.in, io2.in
  • Example use - Alarm input, Brake Release input, Endstop
• One thermistor input (reduced accuracy compared to other Duet 3 boards, so PT1000 sensors not recommended): temp0
  • This is intended to allow for driver, motor or other similar temperature monitoring (potentially couple with a cooling system controlled by one of the outputs)
• RJ11 CAN In and CAN Out connectors to connect to the Duet 3 CAN-FD bus.
• Optional on-board CAN bus termination
• VIN: 12V-48V nominal (the absolute maximum VIN rating is somewhat higher to allow for the overshoot that occurs when the stepper motor is turned off)
• Jumper to force bootloader to request firmware update from Duet 3 main board - marked CAN_RST

Click on the image for a larger version

A STEP 3D model of the board is available on github.

Click on the image for a larger version

The .svg version of this diagram is available on github.

The 1XD v1.0 offers two methods of connecting to external stepper and servo drivers that accept a 5V step/dir/enable signal. Many drivers will work fine in single ended mode, which requires less wiring. Differential mode should be more resistant to electrical noise. Some drivers will only work with differential mode.

In this mode both the Step/Dir/En (-) and Step/Dir/En (+) signals are connected to the external driver.

*Note on some drivers the Step pin is called the Pulse or PUL pin.

In this mode the +5V wire from the 5-pin connector on the EXP1XD is daisy chained to Step+, Dir+ and Enable+ on the external driver.

*Note on some drivers the Step pin is called the Pulse or PUL pin.

Notes

a The requested pulse timing using M569 Tn:n:n:n . For these tests all the timings were set to the same (e.g. T5:5:5:5). Note in RRF 3.2 the exact pulse produced will be no shorter than this time but may be (slightly) longer due to clock rates and move processing times

b This is setting T0:0:0:0 this allows the firmware to generate short pulses. in measurement these where no shorter than 0.7ns.

The default step pulse timing on the 1XD is ~2.6µs (equivalent to the T2.5 in the table above). This is because many external stepper and servos drivers require about 2.5µs or longer pulses.

See CAN connection

All boards in the system must have different CAN addresses. 1XD boards are shipped set to a default CAN address of 122. They will also revert to 122 if you use the jumper to force the bootloader to request new firmware. Therefore, if you have more than one new 1XD board, only one of them must be powered up and connected to the CAN bus. So disconnect power to all but one of them (you can leave the CAN bus connected if it's easier). When you have changed the CAN address of that board, you can connect the next one; and so on.

Check that you can communicate with the 1XD board, by sending:

M115 B122

If that fails try placing a jumper on the CAN_RST pins and powering up, then power down and remove the jumper before powering up again, this will reset the CAN-FD bus settings to the default (address 122, bus speed 1Mbps)

The 1XD board will be shipped with firmware loaded during production. You can check the version loaded by sending

M115 B122

(or B## where ## is the new CAN address of the board if you have changed it already)

To update the firmware get the latest version from the RepRapFirmware github. It is recommended to upgrade all the firmware in your Duet 3 system together so that the versions do not get out of sync.

Send M997 B## to carry out a firmware update, the bootloader will request the Duet3Firmware_EXP1XD.bin from the Duet 3 main board, it needs to be in the /sys folder.

• Send command M115 B## to verify that the main board can communicate with the 1XD board, where ## is the default address of 122 if it has not been changed already.
• Send command M952 B# A## where ## is the new address you want to use. Allowed CAN addresses for normal use are 1 to 119. We suggest you use addresses starting at 40 for 1XDs. So for the first 1XD board, if your new CAN board was at address 122, send M952 B122 A40.
• Power the system down and up again, or send M999 B122. This will cause the 1XD board to restart with the new address.
• Send command M122 B40 (or whatever address you chose) to verify that you can communicate with the 1XD board at its new address
• You can now power up the next 1XD board and commission it in the same way, choosing a different CAN address for it.

The default CAN address is 122. It can be changed as described above.

Please see the current RepRapFirmware limitations, especially Z probing with drivers drivers on external boards:

Duet 3 with CAN expansion firmware configuration limitations

It is recommended to add the following to config.g, before any commands that reference any CAN bus connected expansion boards

G4 S1   ;wait for expansion boards to start

CAUTION before using these examples check the datasheet and user manual of the external driver you are using. Especially: check compatibility of signal voltages and the implication's of triggering actions on the external driver or motors.

The board defaults to the following external driver parameters (note, these may change in future firmware versions):

• ENA output: active to enable drive (M569Pxx R0). If driving the ENA pins of your external driver disables the drive, use R1 in the M569 command for this driver.
• 2.7us minimum step pulse width, step pulse interval, direction-to-step setup time, and direction-to-step hold time (M569 Pxx T2.7:2.7:2.7:2.7). These are satisfactory for some external stepper drivers.

Here's an sample excerpt from a config.g file to drive the X and Y motors from 1XD boards configured at CAN addresses 40 and 41, driving DM556 or similar drivers:

M569 P40.0 S0 R1 ; change enable polarity, active = disable drive
M569 P41.0 S0 R1 ; change enable polarity, active = disable drive
M584 X40.0 Y41.0 ; set X and Y drivers

Some closed loop drivers provide an alarm signal when they are unable to maintain the required torque/velocity or some other parameter is out of range. To use one of the io inputs to monitor this signal first configure it as a GPIO (io0.in in this example)

M950 J4 C"!^40.io0.in" ; create input pin number 4 on 1XD board at CAN address 40 for servo alarm. The alarm is active low so invert the input and enable the pullup to prevent spurious alarms caused by noise

M950 P5 C"40.io0.out" ; create a GPIO pin number 5 on 1XD board at CAN address 40 for alarm reset

M581 P4 S0 T3 R1 ; invoke trigger 3 when an active-to-inactive edge is detected on input 4 and a file is being printed from SD card

The sys/trigger3.g macro file would then contain suitable actions to undertake when the alarm signal was detected.

At the end of that trigger macro (if some method of auto-recovery was available) or driven by a user macro a sequence such as:

M42 P5 S1 ; set the alarm reset pin to logic 1
G4 P300 ; wait 0.3s
M42 P5 S0 ; set the alarm reset pin to logic 0

could be used to reset the alarm on the driver (refer to the motor driver documentation on how to reset an alarm)

The temperature sensor is less accurate than those on other Duet 3 boards designed for extruders or other heater circuits. It is most suited to using with Thermistors, not PT1000 sensors. The following code could be used in config.g to set the sensor as a thermistor:

M308 S3 P"40.temp0" Y"thermistor" T100000 B3950 A"X Motor Temp" ;Setup temp  0  on 1XD at CAN address 40 as sensor 3  - sensing X motor temperature
M308 S4 P"41.temp0" Y"thermistor" T100000 B3950 A"Y Motor Temp" ;Setup temp 0 on 1XD at CAN address 41 as sensor 4  - sensing Y motor temperature

These sensors would be displayed in the "extras" tab in DWC and available in the object model to query and potentially take action on for example the following could be inserted into daemon.g to

check the motor temperature every second and raise the alarm if they are higher than a set value of 70C

if sensors.analog[3].lastReading >70
    echo "X MOTOR Temp Alarm: ", sensors.analog[3].lastReading
    M98 P"motorovertemp.g"
if sensors.analog[4].lastReading >70
     echo "Y MOTOR Temp Alarm: ", sensors.analog[4].lastReading
     M98 P"motorovertemp.g"
G4 P1000

Where the "motorovertemp.g" macro can have whatever actions are appropriate. This logic can be extended to take different actions at different temperatures ( e.g. log at 70, sound alarm at 80, pause print at 100)

Some drivers have a motor brake control pin for an external holding brake solenoid. As long as the solenoid max current draw is <2A and it is rated for the VIN voltage used it can be directly controlled by out 0 or out 1. The signal to apply/remove the brake would be generated by the motor driver and connected to an IO input pin, in this example io1.in. Ensure you confirm the logic of the brake enable/disable pin, e.g. does 3.3V indicate apply or remove the brake!

The following lies would be added to config.g to setup the input and output:

M950 J6 C"40.io1.in" ; create input pin number 6 on 1XD board at CAN address 40 for brake enable.

M950 P7 C"40.out0" ; create a GPIO pin number 7 on 1XD board at CAN address 40 for the brake solenoid.

M581 P6 S1 T4 R0 ; invoke trigger 4 when an inactive to active edge is detected on input 6 (at any time).

M581 P6 S1 T5 R0 ; invoke trigger 5 when an active to inactive edge is detected on input 6 (at any time).

then /sys/trigger4.g could simply contain the code to turn on the solenoid:

M42 P7 S1 ; set board 40 out 0 to 1 (turn on brake)

with similar code in trigger5.g to turn it off.

NOTE proceed with caution, always test these examples with low motor current and slow speeds first

Significant changes from v0.4

• Driver 0 is now differential output rather than single ended.
• IO pins rearranged to have each IO on their own 3 or 4 pin header.
• io2.out2 is now named io2.out and is now PWM capable
• LED 0 and LED 1 are now named Status and Act respectively
• Silkscreen labels corrected

Here is a typical connection between the EXP1XD and an external stepper driver.

The +5V wire from the 5-pin connector on the EXP1XD is daisy chained to Step+, Dir+ and Enable+ on the external driver.

The prototype boards are labelled "Duet 3 1XD v0.4". These boards have the following errata:

• The pin labelling for connector IO_0 IO_1 on the underside of the board is incorrect. The GND and IO_1_IN labels should be swapped.
• Pin IO_2_OUT is not PWM capable
• Pin IO_2_OUT must be addressed in M950 commands as "io2.out2" instead of as "io2.out"