Posts made by MaxGyver

I second this! The simplest way to determine when the nozzle is touching the bed, is to measure when the nozzle touches the bed.
I recon this feature could be used for Delta calibration since it requires a nozzle contact probe.

@dc42 I just had the same error as reported by @balajiramani . In my case, the error occurred during the first layer of a print job.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5+1 (2024-08-31 17:51:17) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 135136
Dynamic ram: 96472 of which 0 recycled
Never used RAM 68768, free system stack 198 words
Tasks: SBC(2,ready,0.8%,796) HEAT(3,nWait 6,0.0%,369) Move(4,nWait 6,0.0%,333) TMC(4,nWait 6,2.8%,353) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,353) MAIN(2,running,93.9%,440) IDLE(0,ready,2.4%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:37 ago, cause: software
Last software reset at 2024-09-18 18:45, reason: User, Expansion spinning, available RAM 65064, slot 0
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 33.9, current 34.3, max 34.5
Supply voltage: min 22.7, current 23.5, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/88/40, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-09-18 18:46:21
Slowest loop: 25.07ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
next step interrupt due in 297 ticks, disabled
Driver 0: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Phase step loop runtime (us): min=0, max=2, frequency (Hz): min=1913, max=2089
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 252, received 2403, lost 0, ignored 0, errs 315, boc 0
Longest wait 55ms for reply type 6041, peak Tx sync delay 50472, free buffers 50 (min 49), ts 187/186/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 1854/1854
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2858c
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:09:26, 32-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 60.06, max time between full transfers: 125.2ms, max pin wait times: 33.5ms/14.1ms
Codes per second: 2.94
Maximum length of RX/TX data transfers: 4476/1040

@dc42

I just tested 3.6.0-alpha.5+1 on our 5meter printer. The "homing jolt" on our CAN-connected Servo Drives is strong enough to make the servo drives go into fault mode Reducing the homing speed by 50% did help, but it still produces a loud "clonk"

Everything else is working as expected
Setup: Duet MB6HC+ 3xEXP1XD+ EXP3HC

My small printer is flawlessly printing since an on our under 3.6.0-alpha.5+1
Setup: Duet MB6HC+ 3xEXP1HCL+TOOL1RR

four screw bed tramming and mesh probing with the SZP seems to be working as expected, I only had to reduce the pressure advance value by 50%.
I have noticed some short movement pauses during printing, these were also present in RRF 3.5.2, maybe increasing the movement queue length can help here?

Since setting up a "Continuous rotational axis" is not yet supported by RRF, I thought about a workaround to get a continuous rotational axis that won't interfere with the rest of the movement system...

To recap:
I use a stepper motor peristaltic pump on my CNC-Router to control the coolant flow while milling aluminum parts. My original Idea was to set up an extra Axis on the duet to control the stepper motor of the peristaltic pump. Right now this doesn't work since there is no option to run an axis continuously and progressing the axis in a loop would block other movements.

Here is my Idea:
So I need a stepper motor that can basically be controlled like a Fan in DWC. So why not use one of the duet's PWM outputs to generate the step pulses for an external Stepper motor Driver?

@phildoyle

Please check the following on the software side:

• The correct steps/mm are set for your ballscrews pitch in config.g
• If you had backlash compensation enabled for your old leadscrews, disable it for now. Ballscrews should have relatively low backlash.
• You have set the correct tool diameter in your program
• Confirm the diameter of the physical tool

Since the holes are spaced correctly, it is unlikely that you are loosing steps. But you can check the following to make sure it is not a mechanical issue:

• See if the ballscrews are securely coupled to the motors

• See if the ballscrew bearings have any play or are loose

• Reduce your cutting feed and reduce your depth of cut to see if high feed speeds are bending your machine

• Check if your motors are loosing steps: Position the spindle at a point outside your working area. Get something to mark this position. A dial indicator would be optimal. Mount the dial indicator so that it is stationary on your machine. Set the spindle against the dial indicator in die direction of the X or Y-Axis. Zero the dial indicator and note down the machine position. Then run your Program. When the Program is finished, move the spindle to the previously noted position. If the dial indicator is still close to zero, there should be no lost steps.

@droftarts said in [3.5.0-rc3+] M108 (cancel heating) is not working.:

If you run M109 et al in a macro, cancel it by sending M108 from the console in DWC; I think that shouldn’t be blocked.

Yes, that works. Thank you very much for clearing that up!

@droftarts

Okay now I am confused...
From the M108 description I understood that the purpose of this command is to break out of an M109, M116, M190 or M191 wait-for-temperature loop.

When I send an M190 S60 over the console followed by an M108, the input channel is blocked until the bed reaches its set temperature of 60°.

The same goes for macros:

;M108 test
echo "setting bed temp!"
M140 S60 ; set bed temp
G4 S1
echo "sending M108"
M108

Max

I just noticed that the M108 command is not working... at least it does not work in RRF 3.5.0-rc3+. Unfortunately, I have no system running a stable version for testing if the problem is limited to the beta.

@dc42

Thank you very much for your feedback! Just to be on the side of caution. The Roto Toolboard should be ok with the 115W nominal power of the pheatus rapido?

According to the docs the current limit on the high current output of the Revo toolboard is 3.4A (80W @ 24V).
While this is totally fine for the intended use of the Roto tool board with the E3D Revo system (max 60W), most high flow hotends are well above 80W or even around 115W.
Since the full output current is only drawn during the first few seconds during heatup, I was wondering if the revo toolboard might be capable of handling currents higher than 80W for a short amount of time without damaging the high current mosfet?

I found this table for the phaetus rapido @24V. It illustrates the drop in current at different temperatures quite well:

Thank you all for your feedback! In conclusion, we all agree that for heavier machines, hardware limit switches are a must-have or are even mandatory for machines that are used in professional/business environment.

@dc42
@T3P3Tony
Are the X and Y moves considered probing or travel moves in G30 Pnnn?
I assumed that moves in X and Y are travel moves that position the head above the next probing point, and only the following move in Z is the actual probing move. Therefore, the limits in X and Y should be respected like for any other travel move. This would avoid raising faults or adjusting the bed.g macro.

@infiniteloop said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

During the setup process, this safety cannot exist - else, you would not be able to probe the limits. The same applies to tool changes: you will have to recalibrate your Z-height (which is inherently unsafe). [...]

In therms of referencing the machine at startup, I absolutely agree with you. But everything after that should happen within these machine (soft) limits or not? I can't think of a reason to command the machine outside these limits, since it can't physically move there. Maybe we need something like machine-limits and work-limits? Just like we have machine and work coordinates in CNC. The machine limits are set after referencing (aka. homing) and are not exceeded. By defining work-limits the head movement can be limited to a specified boundary like for example the printing area.

@dc42 said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

is that with G29 or G30?

G30 during four screw bed leveling: Please note that I have added the above-mentioned offset of 25mm to the PrintY_min point in order to counteract the probe Y-offset to keep it from crashing.

G30 K0 P0 X{global.PrintX_min} Y{global.PrintY_max} Z-99999 ; probe rear left
G30 K0 P1 X{global.PrintX_max} Y{global.PrintY_max} Z-99999 ; probe rear right
G30 K0 P2 X{global.PrintX_max} Y{global.PrintY_min+25} Z-99999 ; probe front right
G30 K0 P3 X{global.PrintX_min} Y{global.PrintY_min+25} Z-99999 S4 ; probe front left and calibrate 4 motor

@gloomyandy said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

If you are really concerned I'd suggest that you wire limit switches (in addition to any homing switches) that kill the power if they are triggered. Simple and they do not rely on any code to execute. Anything that relies on "soft limits" can go wrong.

On my CNC-Machines I have this security switches installed as a last resort security measure. They will stop the machine before it hits the bearing support of the spindle axis. But when these switches are triggered, the machine is already far outside its boundaries, meaning that before the security switches are hit something else might get hit first. Just like my Z-probe that got caught on aluminum profile just before the Y-axis touched its physical endtsop.

@infiniteloop said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

Where’s the problem? If you use G30 within your calibration process, they are embedded in scripts - when writing those scripts, you might possibly remember the permitted coordinate range.

Having to know and remember all the cases where the axis can move out of bounds is kind of my problem. I am not trying to be lazy here, I just want to improve the user experience and make the duet system safer and more intuitive to use.

For example, I have just installed the Duet scanning Z-probe. The probe is mounted with an offset of 25mm in Y-direction.
Setting the probe offset to 25mm made the head move out of bounds and damaging the probe coil. →Very frustrating and on larger machines dangerous.
Granted, It says so in the documentation. I have read the section on G30 more than once and still did not remember in this case.
For the probe points at the Y-min, I added an offset to counter the probe offset: → not very intuitive.

@gloomyandy said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

[...] but there are plenty of other places (like homing operations etc.) when it is also possible to exceed limits. In such situations I would suggest lowering motor power and taking other precautions if possible.

Exactly, but what are all those cases? I certainly don't know.

I understand that the axis can not adhere to limits if they have not been homed or during homing. But when an axis has been homed and the machine boundaries are known, I would expect the machine to adhere to these boundaries, like with every CNC-Machine controller that I have worked with so far. I understand that with 3D-Printers and nema17 motors it is not a big deal, but the Duet is becoming a good alternative for established CNC-Controllers. Especially with the Duet 6XD that I am using with AC-Servo drives ( I don't know if I can lower the current on those)

@gloomyandy

Thank you for pointing that out! I am surprised that this is indeed the intended behavior. I understand that in some cases it can be beneficial to probe outside the printbed area. So why not adjust (M208) or deactivate (M564 S0) the limits only in that case?

I am asking because I am working on a very heavy and very powerful 3D-Printer/CNC Hybrid machine. I have to make sure that the axis stay within their boundaries at all times. Failing to do so will inevitably lead to damaged machine parts or worse, damaged body parts sooner or later.

When probing a specific point using G30 Pnnn, the Axis limits in X and Y are not respected.
For example my Y-axis limit is set as follows:

M208  Y0:315 ; set axis limit

Running a G30 P0 Y-20 will result in the Y-axis moving past Y0 and crashing the head.
I would expect the axis to go as far as possible while respecting the axis limits.

@T3P3Tony

Excellent, thank you!