Posts made by dc42

@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
}

@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.

For those testing beta 3 there are now beta3+1 builds of the main board firmwares at https://www.dropbox.com/scl/fo/bx70c7u0bshq79ez83mnn/AKMj4UCEimtQuGYxRj_d0ew?rlkey=7yiq3x5fcae3v2ogslfocx1op&dl=0. The most important bugs fixed in this version are:

Duet 2 Ethernet only: network connection was unreliable
Duet 3 6XD only: at high step rates the minimum interval between steps was not honoured, leading to steps merging

See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-rc1-in-preparation-changes-since-360-beta3 for other fixes and changes.

@mikeabuilder said in WHILE loop acts like an IF statement:

if there is some lag in getting the object model updated, it could give the result you are seeing.

There is no lag in reading OM values within macros when running in standalone mode. Even in SBC mode there is usually no lag because the SBC asks RRF to evaluate expressions.

@Guus the index pulse is generated once every pole pair (see page 10 of the datasheet), so it's not much use as an endstop. I guess you could use it to detect the passing of a magnet, but a Hall effect device would do that more simply.

@Paski there is no facility to read from a general text file, however you can read from a single-line CSV file. See function fileread at https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#functions.

@machinemark what firmware version? Standalone mode or SBC mode?

@Guus I've taken a look at the AS5311 sensor data sheet. It appears to me that, the quadrature outputs it provides could be used. They would need to be buffered from 3.3V to 5V because the 1HCL board includes pullup resistors to 5V on the A and B inputs. A bi-colour LED should be driven from the MagINCn and MagDECn outputs to indicate whether the magnet strength is in range.

Alternatively, the serial output could be used, provided that it can be guaranteed that this output is read at least three times per pole pair. Unfortunately the maximum clock rate of the serial output is only 1MHz, which is rather low (much lower than for the AS5047).

@machinemark said in Duet 6XD RRF3 Create a Input and Check its Status:

s it a case of only being able to use one or the other??

Yes. They are the same input, which is why they are both called io8. You have set up GpIn port 2 to use io8.in in your M950- command, so the status can be read from sensors.gpIn[2].value in the object model. The state of the output can be read from state.gpOut.

@MurphDurtay we'll need to see your config.g file and the GCode file too.

@feliz_k I am not a CNC user but I think you should check out the following GCode commands:

G10 with no L parameter, or L1 parameter: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g10-set-workplace-coordinate-offset-or-tool-offset. This command sets the offset of a tool. The offset (in particular, the Z offset) is what you need to change when changing to a different length tool.

You can calculate the new tool offset to use in the G10 command by measuring the height at which your sensor is triggered by the new tool. However, you may not need to do that because there is also this command:

G30 with S-2 parameter: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g30-single-z-probe. This uses a Z probe (which could be your sensor) to set the tool offset automatically. Don't forget to use G31 to set the Z probe trigger height to the tool height at which the probe triggers.

HTH David

@dwuk it's odd that it's producing such a low output voltage. What supply voltage are you giving it?

Another option may be to connect a small signal silicon diode (e.g. 1N4148) between the output and the pullup resistor (diode cathode to the sensor output0 and connect the junction of the diose and resistor to the Duet input. That will shift the voltage level up by about 0.6V.

Using IO3.in instead of IO1.in may also help, because IO3.in accepts lower logic levels than IO1.in.

@dwuk instead of a level shifter try adding a pullup resistor between the sensor output and +5V on the IO connector. I suggest a value of between 1K and 10K.

@dwuk if it's definitely NPN then connect the output of the sensor directly to the IO_IN pin. See https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_connecting#npn-output-normally-open-inductive-or-capacitive-sensor.

@bugpwr said in resume redundant extrusion:

by the way, I am having some (unrelated) motion troubles with the beta3+1. On a couple of incidents homing commands got stuck (e.g. G1 H1 Y480 F5000) I did not investigate further.

That is the second line of a 2-line error message. The first line includes a single-digit error code, which I need to know to investigate this further.

@bugpwr said in resume redundant extrusion:

@dc42 many thanks, the beta3+1 update works like a charm!!
(completely unrelated: speaking of 2.85mm systems, I don't want to bother you with a minor thing, but it would be awesome if M404 would upate move.extruders[].filamentDiameter. As of now, DWC always shows incorrect volumetric rate for 2.85 machines)

You can use M200 S0 D### to set the filament diameter to ###. Unlike M404, M200 allows you to set per-extruder filament diameters.

@c4tn1p I use two lengths of this https://uk.rs-online.com/web/p/twisted-pair-multicore-data-cable/6604052. One is for the 8-pin connector, the other for the 6-pin connector with two conductors in parallel used for each of the heater wires.

It is essential to provide strain relief for these cables. I printed this SmartEffectorStrainRelief2.3mf and used zip ties to secure the cables to the top.

@dwuk is that probe a standard NPN or PNP output sensor; if so, which?

@dwuk please read https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection. The TMC2209 drivers on the Mini5+ are quite finicky as regards getting stall detection to work. You need to at least reduce the M569 V parameter to a lower value (at least during stall homing) to avoid the "too slow" error message,