Best posts made by Leonard03

Good morning everyone!

First of all, I would like to apologize to you. This was not an issue with RRF but with my own code... Thank you all for your help and support!

Just in case, @gloomyandy and @AndyE3D you were right about M118 in every file in MMU Control. But I has no chance seeing something unusual until I used logging.
@dc42 I am sorry for tagging you here and wasting your time.. was my fault, not RRF's fault..

The problem was elsewhere, right at the beginning, in tpostn.g.
There, were three simple calls: load the filament in the MMU, then in the extruder and last in the nozzle. If during those macros any error raised, the tool change macro continued showing a dialog (M291). But, it can also call errorAction.g which by itself loads the filament all the way to the nozzle, but being called from a "while" loop in tpostn.g, after errorAction.g the while loop was trying to load it again to the MMU. The log confirmed that:

2023-08-02 12:02:28 [debug] Finish: loadToBondtech.g
2023-08-02 12:02:28 [debug] Begin: idlerMove.g
2023-08-02 12:02:28 [debug] Finish: idlerMove.g
2023-08-02 12:02:28 [debug] Begin: loadToNozzle.g
2023-08-02 12:02:28 [debug] Finish: loadToNozzle.g     < here the duex.e2stop is configured as a filament sensor
2023-08-02 12:02:28 [debug] Begin: loadToFinda.g     < here the duex.e2stop is used to load the filament in the MMU
2023-08-02 12:02:35 [warn] Error: Pin 'duex.e2stop' is not free
2023-08-02 12:02:35 [warn] Error: G1: Failed to enable endstops
2023-08-02 12:02:41 [info] Event logging stopped

In tpostn.g adding a break statement to exit the wile loop solved this problem

Thank you again to all of you for your support!

For me at least, a 3D printer is the perfect companion for those who like to do electronic projects.

Electronics are my toys from when I was born, so this hobby persists to this day. Every project needs some kind of enclosure.

I'm thinking about an Arduino/Raspberry Pi. As these boards can interact with many peripherals, 3D printing is indispensable for that "professional" touch.

There are generic "project boxes," generic ones, injection molded. But it is something generic. As an enthusiast, I think that every project, custom and unique.

If in some shop I see something that catches my attention, most of the time in my mind comes an "I can do it better", for me at least.

For an enclosure for that board, sensors, lights, and everything else, it is one thing to mount it with double-sided tape (maybe), and it is another thing that every LED, sensor, and internal layout has its own nut, bolt, and its own place to be mounted to.

Another benefit of 3D printing in this area is the freedom to choose your own color schemes and different materials you can print (e.g., matte vs. glossy vs. CF).

I've seen very good projects done using generic components and plastic components, but in my opinion, those can't beat your personal idea, and the fact that this technology can really bring a thought to reality just as you imagine it.

@fcwilt Since every G30 command alters the X coordinate without physically moving the stepper, after the initial homing, I don't know where the toolhead is.

By setting its physical position to X0 Y0, using G92, I can measure the distance between the reported and actual positions relative to endstop.
Let's say I move the nozzle to X80 and perform 10 probes at that point; the reported coordinate is no longer X80, regardless of the actual physical position. If I set that position as the zero position and perform a G1 H4 move toward the endstop, the reported X position afterward is the offset amount. I want to obtain that value from a theoretical zero point.
Normally, if I move to X80 and return by pressing the endstop blade, the actual and reported coordinates should be close (accounting for endstop accuracy), but currently, they are not. I do this out of curiosity to see "how much."
Hope this make sense

Hello everyone!

I got a strage issue with my printer, after an 8 hours print, i got this error:

Sadly I cannot get a M122 report for two reasons:
In DWC with 3.6.x I cannot get an M122 report even if other comands works as expected
Over USB, I needed to do an emergency stop wich cleared the relevant report..

My board is a Duet 2 WiFi + Duex5 with MMU3

Anyway, I will upload my config files to google drive and update this post.
All that I have is the gcode and the aproximate layer height when the error occured

By the way, with beta 1 for only one print I got the exact same error, the next day I do a simulation wich completed as expected, printed the exact same gcode without any problems. So, seems to be a random issue wich I can't reproduce myself twice. I started a slightly modified print now to see how it goes

Thank you in advance, and any help is welcomed!

Update:
This is the gcode in question: Jack Case_STEC7_0.2mm_PLA_5h24m.gcode
The error occurred on layer 312 / Z height 62.40 most likely somewhere around line 117292 in that gcode

This is my config/SD card https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=sharing

Started now a print. Pause and resume works as expected, skew compensation is active

Axis compensations - XY: 0.00690, YZ: 0.00000, ZX: 0.00000

Inducing a "power failure" and resuming:

Axis compensations - XY: 0.00690, YZ: 0.00000, ZX: 0.00000

So skew compensation is still active and correctly applied, but the shift is there

@T3P3Tony Confirm no motion errors with the beta4