Why 1x micro stepping?

Have you tried with pla instead of tpu?

@qlqlo, the 6HC will draw from the 48V supply only a small fraction of the current that they supply to the stepper motors. This is because the drivers reduce the voltage from 48V to the voltage actually needed by the motors (which at standstill is just a few volts) and the current drawn from 48V reduces in the same proportion. When the motors are moving fast they need more voltage, but the phase angle between voltage and current also has the effect of reducing the net current drawn from 48V. So your six stepper motors will likely draw only about 3A total from 48V when they are at standstill, and a bit more when they are accelerating.

If your SSRs will work with control voltages down to 3V then they will probably just about work with the IO_OUT outputs. Some alternatives include:

• Use the LASER/VFD output for one of them, which is 5V
• Use the PS_ON output for one of them, which is open drain and can conveniently be used with 5V
• Use high current OUT ports to drive them, with series resistors to reduce the output voltage from 48V to be within the working range of the SSR
• Use low current OUT ports to drive them with the voltage selection jumper on those ports set to 12V.

HTH David

@audryhome I believe this is already fixed in 3.6beta3. The object model returns 3 decimal places for both user and machine position of all axes (with trailing zeros in the decimal part suppressed); however DWC only displays 2 decimal places.

m409 k"move.axes[].machinePosition"
{
    "key": "move.axes[].machinePosition",
    "flags": "",
    "result": [
        0.045,
        -7.955,
        9.894,
        129
    ],
    "next": 0
}

@machinemark Great! I haven't used it myself, so didn't want to give you a command to follow, as it might have been wrong! You didn't have to send http://192.168.1.14/rr_connect?password= first?

Ian

@audryhome this is a bug in 3.6beta. Axis positions are supposed to be reported to 3 decimal places, although trailing zeros in the decimal part are always omitted in the JSON response. I will fix it in the next build.

@jasko said in SD CARD PROBLEM DUET 6HC V1.01:

SD card 0 detected, interface speed: 12.5MBytes/sec

It says the card is detected, but the interface speed is slow for a 6HC; it should be 25MB/sec. This may suggest an issue with the SD card or the socket. As you have tried other SD cards, can you post a picture of the SD card socket and the components around it?

If you remove the card, does M122 then report it starting in SBC mode? If the SD socket has failed, and the board is over 2 years old (ie out of warranty), you may be able to run it in SBC mode.

Ian

@qlqlo said in 6HC capabilities:

• Our original plan was to use the Duet 3 6HC mainboard powered by a 48V PSU. We selected six stepper motors (one each for X, Y, and Z axes, plus three more for other functions), each rated for 48V and 3.18A.

Those stepper motors should be fine, and are within the capability of the 6HC stepper drivers (6.3A peak current/4.45A RMS). Note that stepper drivers' current rating is usually quoted as either peak or RMS (you haven't specified which yours is). RepRapFirmware uses peak current. Divide peak current by 1.414 for RMS current. Stepper motor current is rarely set at the full current capability of the motor, as this tends to heat them up excessively, but at 80% of full current. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_choosing#detailed-considerations

• Since the total current output from the board would be approximately 30A, would the 6HC be suitable for this setup, or would we need to consider the Duet 3 6XD instead?

Stepper motors rarely work at peak current, though the peak they could theoretically reach is 18A (assuming your quoted 3.18A is peak current). Heaters, once they reach temperature, also do not pull full current all of the time (though using PWM control, they are turned on and off quickly). Will you have a number of heaters connected direct to the Duet 6HC? Note OUT 1/2/3 current limit is 6A.

48V at 30A is what we suggest as the maximum current, as that is the fused limit of V_Fused (15A) and Out0 (15A); see https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Mainboard_6HC_Hardware_Overview#operating-limits
Note that V_Fused supplies the stepper drivers and OUT 1/2/3, as well as all other components on the 6HC (though these are unlikely to draw very much current).

2. Can the 3.3V IO outputs on the 6HC board control solid-state relays (SSRs) for 230V heaters, or would we need to step up the control voltage to a higher level to ensure reliable operation?

That really depends on the SSR you choose, and if they support that voltage for switching. You can also use the heater outputs themselves (OUT 0/1/2/3) to switch an SSR, which would be at the VIN voltage (48V). See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Heaters_bed#bed-heater-driven-using-a-solid-state-relay for our recommendations for DC/DC and DC/AC SSRs.

Ian

@machinemark Ah, right, you can't click to get to the console. Yes, you can send Gcodes via html. See https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests#get-rr_gcode
Probably have a read of the whole page.

Ian

@aceranic said in MMU - Single nozzle, multi material (filament):

One thing regarding the GPIO and Arduino. I connected pin13 and one ground pin from duet to arduino. Is this ok?
Does it require any additional resistors or other components?

I think that should be okay. You're not pushing voltage from the Arduino into the Duet, so they are just sharing a GND. Should be fine, especially if they powered from the same PSU.

Ian

@timschneider I've logged this here: https://github.com/Duet3D/RepRapFirmware/issues/1074 But since you need to poll rr_reply for certain codes anyway, that solution probably isn't really applicable as a fix for your other problem.

chrishamm created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Add option to rr_connect request to prevent G-code replies from queuing up #1074