Posts made by resam

@chrishamm any insights into the error posted by @NikA ?
Was there a code change that I need to integrate into the Cura plugin to make it work with the latest DSF beta?

@cdoe are you running with an SBC / Raspberry Pi?

I recall similar issues with my printer when there was a lot of tiny moves due to high-fidelity / super smooth geometry that resulted in SPI data transfer queue issues.

I was able to work-around the issue by tweaking the SPI and transfer queue sizes in the DSF config.

Thanks all for questioning my setup! I now managed to get it fixed / changed in the following way:

# define Z probe
G31 X0 Y60 Z3.80 P25  # Y was -50 before

# bed leveling with left+right lead screws
G30 P0 X10 Y130 Z-99999          # Y was 20
G30 P1 X240 Y130 Z-99999 S2  # Y was 20
G28 Z 

# mesh leveling
M557 X20:240 Y55:230 P9:9  # Y was -49:137

So I had to roughly add 3 x probe_offset to most positions compared to my previously (flawed) configs.

Now the visual heightmap in DWC looks reasonable.

@droftarts thanks for your response. The physical movements are correct, so I don't understand how the probe offsets would be wrong.

One thing I noticed: M557 ... Y0:137 ... actually starts probing at Y=50. So the M557 coordinates are probe coordinates. My probe is offset from the nozzle in Y by -50, see my G31 command. Thats why in my M557 I want to probe at Y=-49 to move the tool head as far forward as possible.

The generated heightmap.csv starts like this:

RepRapFirmware height map file v2 generated at 2024-08-28 18:44, min error -0.217, max error 0.199, mean 0.046, deviation 0.088
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,15.00,245.00,-49.00,137.00,-1.00,28.75,23.25,9,9
...

Searching through https://github.com/Duet3D/DuetWebControl/blob/v3.5-dev/src/plugins/HeightMap/HeightMap.vue and similar files, I don't see the probe offsets being used anywhere.

Is the heightmap visualization aware of probe offset?

I'm on RRF+SBC 3.5.2 on my Duet2.

I recently started again using mesh bed leveling.
I have a CoreXY gantry with the bed moving up and down.
The extruder on the XY gantry has a normal nozzle with an inductive probe mounted "behind (Y axis)" the nozzle.

config.g:

; Z probe
M558 P8 C"exp.e5stop" H3 F200:50 T7000 A3 S0.05 ; use E5_STOP as inductive-NPN probe, dual speed, multi-probe

G31 X0 Y-50 Z3.80 P25                 ; Z probe: set the probe XY offset, Z height and signal threshold

; Axis dimensions
M208 X0:265 Y0:244 Z0:240                       ; axis maxima
M671 X-52:306 Y113:113 S10                      ; define positions of Z leadscrews
M556 S100 X0 Y0 Z0                              ; axis compensation

Macro to run the mesh:

M561                            ; clear any existing bed transform
G32                             ; home and level
M557 X15:245 Y-49:137 P9:9      ; set probe coordinates
G29                             ; detailed Z probe

After running the mesh, DWC shows me this heightmap:

(please ignore the actual shape and deviation)

My concern here is the Y shift of the bed relative to the 0,0 coordinate origin. It looks like the coordinate system is incorrect by about the same amount as the nozzle-to-probe offset.

The probing points are aligned in such a way that the inductive probe is moved to the edges of the bed as far as possible.

Is this a visual-only bug in DWC, or is the actual compensation matrix incorrectly computed and therefor also affecting the compensation during printing? How do I move my probed bed to Y=0? The actual physical movements and probing points are correct and how I want them to be.

@Phaedrux not sure why you moved this to "Beta Firmware" -- v3.5.1 is marked stable, unless the Duet2-SBC variant is officially not supported any more?

I'm running a Duet2 with SBC on the latest 3.5.1.

I uploaded a new print gcode file and started a simulation job via the SBC HTTP API. This piece of code is able to talk to SBC and direct-RRF boards using the new API and old rr_* API. It first tries the old API, which used to fail with a clear error, to then switch into "new-API" mode and try again.

In the DSF changelog I found this:

Added rr_ compatibility layer to DuetWebServer (HTTP calls in standalone mode)

This means that my code now always auto-detectes the old rr_* API, instead of switching over to the new one when available.

Now to the actual issue at hand:

Sending the following request causes the printer to actually start printing the file, instead of running a simulation job as intended by M37!

curl -vvv 'http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22'

Producing these SBC log from DWC/DSF/DCS:

May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - -
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 2d8c1c548454408ab4a470c857aa2725 added (readWrite)
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "RepRapFirmware"}.
Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(System.String) on controller DuetWebServer.Controllers.RepRapFirmwareController (DuetWebServer).
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Controllers.RepRapFirmwareController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1] Executing ContentResult with HTTP Response ContentType of application/json
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Executed action DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer) in 104.242ms
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Executed endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - - - 200 27 application/json 163.1642ms
May 26 12:40:57 voron DuetControlServer[1649]: [info] Selected file 0:/gcodes/test.gcode
May 26 12:40:57 voron DuetControlServer[1649]: [info] Starting file print
May 26 12:40:57 voron DuetControlServer[1649]: [info] Simulation mode: off, move time: 0.0 sec, other time: 0.0 sec

This just caused my printer to crash and bend it's carriage rods, before I was able to jump to the E-stop button.

I'm the author of the Cura Duet-RRF Plugin, which is using the above mentioned auto-detection code. Meaning, potentially all users of Cura running the latest RRF 3.5.1 in SBC mode and the plugin who want to simulate a job are at risk of damage due to unplanned real printing activity instead of simulation.

What's the expected behaviour in this case?
Is this a bug in the emulated rr_* API in DSF, or something else?

edit
After some more debugging, it turns out that even using the new API is causing a simulation job to be executed as real print job!

This can also easily be triggered using DWC by right-clicking on a gcode file and selecting "Simulate File", upon which it will send the correct gcode M37 but will in fact start heating the hotend and bed and start homing!

May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 POST http://192.168.1.42/machine/code application/x-www-form-urlencoded 68
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer)'
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "Machine"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(DuetWebServer.Singletons.ISessionStorage, Boolean) controller DuetWebServer.Controllers.MachineController (DuetWebServer).
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 5fbbc7e78464425b8c043dc244cf336f started a long-running request
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Controllers.MachineController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 13:54:01 voron DuetControlServer[9372]: [info] Selected file 0:/gcodes/test.gcode
May 26 13:54:01 voron DuetControlServer[9372]: [info] Starting file print

Is something wrong with my machin and setup - or was such a potentially dangerous bug not caught during testing and beta/RC releases?

@chrishamm Thanks! I installed the new package, and it updated fine - seems to work now!

@achrn not sure such a hard stance is needed here. Its perfectly fine to override this behaviour if you know what you are doing. The pip output you posted contains all instructions you need:

You can override this, at the risk of breaking your Python installation or OS,
by passing --break-system-packages.

Not pretty, I agree, but certainly an easy fix to get the package installed "the old way".

I am running an Duet2 Wifi with the SPI adapter to connect an SBC.

I tried upgrading from a working 3.4.6 setup to 3.5.1 using apt upgrade. DCS, DWC, etc. all upgraded nicely. The reprapfirmware package also updated and flashed the new firmware as expected, however, then the SPI connection to the Duet2 failed to re-establish.

After some troubleshooting, it turns out, that installing the Duet2Firmware_SBC.bin for 3.5.1 on my Duet board, it will simply crash loop the board.

DCS fails to connect with:

May 04 16:27:56 voron DuetControlServer[952]: Duet Control Server v3.5.1
May 04 16:27:56 voron DuetControlServer[952]: Written by Christian Hammacher for Duet3D
May 04 16:27:56 voron DuetControlServer[952]: Licensed under the terms of the GNU Public License Version 3
May 04 16:27:57 voron DuetControlServer[952]: [info] Settings loaded
May 04 16:27:58 voron DuetControlServer[952]: [info] Environment initialized
May 04 16:27:58 voron DuetControlServer[952]: [warn] Restarting full transfer because a bad header format code was received (0xff)
May 04 16:27:58 voron DuetControlServer[952]: [fatal] Could not connect to Duet: Timeout while waiting for transfer ready pin
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Main process exited, code=exited, status=69/UNAVAILABLE
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Failed with result 'exit-code'.
May 04 16:27:58 voron systemd[1]: Failed to start duetcontrolserver.service - Duet Control Server.
May 04 16:27:58 voron systemd[1]: duetcontrolserver.service: Consumed 2.409s CPU time.

Flashing back 3.4.6 via USB and bossac is recovering the device.
When working with 3.4.6 I can use USB-serial to connect to the Duet2 directly and get this output:

<CONNECTED>
RepRapFirmware for Duet 2 SBC version 3.4.6
<DISCONNECTED>

After bossac-flashing the 3.5.1 binary, the USB-serial port vanishes and re-appears about once per second. This matches the LED next to the USB port on the Duet2 briefly flashing red. I can't capture any debug output on this USB-serial console as it disappears before I can connect.

I noticed that the 3.5.1 binary is using 927 flash pages (474572 bytes), while the 3.4.6 uses only 877 pages (448900 bytes).

Is Duet2 + SBC over SPI still a supported setup?

@matej1006 it is possible - if you can change the code and build it
But you would have to do that yourself - all the code is open source and available on GitHub.

@tfjield I've pushed a change to the next branch at https://github.com/Kriechi/Cura-DuetRRFPlugin/tree/next

Would love to hear your feedback if this works for you!
Please follow the Manual Installation + Install from Source instructions in the readme.

@gnydick https://github.com/Duet3D/DSF-Plugins/blob/f0d441fb7e3b4ff493a5e0be7cb740ae7c57bc46/InputShapingPlugin/src/InputShapingChart.vue#L123 and the config options around it.

@tfjield thanks! I'll take a look on how to best integrate it into the existing plugin!

If anyone wants to give it a try and send me a pull request - I'd be happy to review and merge it!

@oliof yes this should be possible - I had it on my ToDo list for a while, but so far either not enough people asking for it, or simply no time.
I wanted to start by "importing" the bed size and other parameters from the printer - and speed and accel setting would be great addon to that!

PRs are welcome and will be reviewed and merged!

@tfjield short answer: the "Save to Disk" option is from plain Cura - not my plugin. If you want a dedicated "Save to Disk with thumbnails"-like option, let's move the conversation to a new thread.

@baenwort there are various forum posts about small adapter-PCBs to tap off the SPI interface from the Wifi/Ethernet modules to attach a RaspberryPi SBC.

I think there are dedicated Wifi and Ethernet versions of similar style: https://forum.duet3d.com/topic/17203/duet-2-ethernet-and-sbc/183?_=1651350921819

@johanv yes - search the forum and look at https://www.duet3d.com/duetethernet_module

@tapirath thats a Cura problem - so please report it to them. I'm not even sure if they built this specifically to be compatible with Duet / RepRapFirmware.

@tapirath I didn't specifically comment about your case - just general information.

But regarding your case: the post-processing script is not generating valid thumbnail comments:
https://github.com/Ultimaker/Cura/blob/5330e53ae60030d6ac4061642e818fb40ffafcb1/plugins/PostProcessingPlugin/scripts/CreateThumbnail.py#L40

the width and height need to be separated by an x, not a space character. At least that's what the plugin is doing - and its working there.