Posts made by fotomas

After finding and adressing several issues I belive it is working fine now.

I have:
Lowered the jerk value for Z to 15
Let the bed soak properly before do bed mesh (temp 80 )
Replaced lost screw, one of three holding the hotend to the heatsink. This was hidden by the silicon sock on my Phaetus Rapido hotend.

I think the jerk value was the thing but the other two brought a fair amount of inconcistency too.

So i will end this thread/question here. Thank you for all the help and a little extra to Phaedrux.

Reading about E3D's new PZ Probe https://e3d-online.com/products/pz-probe

I wonder if it would be possible to connect to Duet3D's Toolboard. The wireing instructions states that it should be connected to the PanelDue port.

Also, the stand-alone version of PZ Probe should/can it be connected between the hotend heatsink and toolhead. Looking at the Voron version, it seems to be "inside" the heatsink somehow.

@timschneider There is no M207 in config.g or print code.

I have done more testing.

• Starting out with a 0.2 mm baybystepping does NOT make it change more between prints.
• I happens even without any initial baby stepping.
• "Print Again" on PanelDue or sending new G-Code file makes no difference.
• Homing Z makes it OK again

So it does not seem to relate to babystepping. I started thinking in terms of loosing steps on Z-Axis, below is my motor settings, start and end GCode (if any Z-moves messes things up)

... I am running out of ideas here, does any one hava any ideas for some controlled approach to narrow down the possibilities?

speed settings

M566 X600.00 Y600.00 Z500.00 E120.00 P1      ; set maximum instantaneous speed changes (mm/min) and jerk policy
M203 X30000.00 Y30000.00 Z1200.00 E6000.00 ; set maximum speeds (mm/min)
M201 X20000.00 Y20000.00 Z300.00 E5000						; set accelerations (mm/s^2)
M204 P10000 T20000

Start of print code

M140 S80 ; set bed temp and continue
M109 S245 ; set nozzle temp and wait
M190 S80 ; set bed temp and wait

M150 R255 U255 B255 W255 P255 S120 F0 ; Print lights

G1 X100 Y4 Z5 F5000
M73 P1 R1
G1 Z0.6
M73 P2 R1
G1 X200 Y4 E30 F1500

End of print code

M106 S0
M400 G91; relative positioning
G1 H2 Z25 F12000 ; lift Z relative to current position
G90 ; absolute positioning
G1 Y270 X10 F5000; move head back
M150 U255 P255 S120 F0 ; Print done lights, green
M0

I start my printer with bed.g G32 (code borrowed and tweaked) from someone at this forum:

M290 R0 S0      ; clear baby stepping
M561            ; clear any bed transform
M400            ; finish all moves, clear the buffer

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
	G28             ; home all

M201 X1000 Y1000  ; reduce acceleration

; calibrate bed
while true
  if iterations = 5
    abort "Auto calibration repeated attempts ended, final deviation", move.calibration.final.deviation ^ "mm"
  G30 P0 X5 Y10 Z-99999 ; probe near a leadscrew
  if result != 0
    continue
  G30 P1 X150 Y275 Z-99999 ; probe near a leadscrew
  if result != 0
    continue
  G30 P2 X270 Y10 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors
  if result != 0
    continue
  if move.calibration.initial.deviation <= 0.05
    break
  echo "Repeating calibration because deviation is too high (" ^ move.calibration.initial.deviation ^ "mm)"
; end loop
echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
G0 X150 Y150 F12000

G28 Z                     ; rehome Z as the absolute height of the z plane may have shifted
G29 S1                    ; load saved mesh
M98 P"0:/sys/setspeeds.g" ; set speed and acceleration

@oliof No the value on PanelDue and DWC remains at 0.1

@gloomyandy That is a good question. I will test that ASAP

@oliof I set babystepping via PanelDue, see OP.

After som testeing I have drawn the conclusion that babystep settings accumulates between each print.

These are three consecutive prints (sorry for the green light, LED strip signaling finished print).
Baystep is set to 0.1 mm "higher" and as can be seen it prints higher and higher for each print.

Babystep is set by PanelDue FW 3.5.0
RepRapFirmware for Duet 3 Mini 5+ version 3.5.2 (2024-06-11 17:14:16) running on Duet 3 Mini5plus WiFi (standalone mode)

config.g and g-code for the print attached, sliced with Orca Slicer.

What can be the cause of this?

config.g
Cube_0.2mm_PETG_1m2s.gcode

Posted this part in the RatRig discord server. But it has a limited Duet3D fan base. So posting here too.

https://www.printables.com/model/967347-eva3-back-plate-tension-less-duet3d-tool-board

@jay_s_uk
Is it ok to connect to LED strip in parallel? Would it work and both behave the same, as a mirror image of eachother?

@jay_s_uk I do not want to argue but then then power to the LED strip is just one lead. It will only join on the AC side. I do not understand... ahhh negative to negative between the PSU's

But I have an answer how to connect things, thank you!

When using an external PSU for led strip how is it supposed to be connected?

If +/- of the LED PSU goes directly to LED strip will it work connecting the single LED strip signal wire to a Mini5 board LED parts signal pin?

In my limited knowlege of these things I would think thar the duet board need at last two wire to send a signal. Like signal.and ground, so the pixies/electrons has somewhre to go... 🥴

@chrishamm Thank you, it may be possible then, with some luck
I will do some experiments to see how far I get.

@chrishamm Can you explan the issue with having it in stand alone mode? Is it not a just a webserver serving files?

A blazor site can be compleatly clientside. In this case it is my understanding that the only thing the DuetBoard needs to do is serve the files?

I got the idea to white a util in Blazor and put it on the duet board. In a sub or parallel folder to the DWC.

I am thinking a blazor page, without any server side parts, querying the json structure and sending some G-Codes.

Is this possible withe current firmware and are there any limitations I should be aware of?

I am trying to write an application interacting with a DuetBoard.
I have got a Working example, a .Net c# console application using DuetHttpClient.

I have two questions:

• How do I get hold of an updated model after connection is established? In my code example a command must be sent ("G31") to get a populated model.

• Are there any pattern/thoughts on monitoring changes in the model? Looping with a delay and sending "G31" seems crude...

I have not found any info or code on this, there probably is. So some help pointing me in the right direction would be much appreciated.

/Tomas

using DuetHttpClient;

var options = new DuetHttpOptions
{
    ObserveObjectModel = true,
    ObserveMessages = true,
};

var session = await DuetHttpSession.ConnectAsync(new Uri("http://192.168.0.117"), options);

await session.SendCode("G31");

var model = session.Model;

foreach (var a in model.Move.Axes)
{
    Console.Write(a.Letter);
    Console.Write(": ");
    Console.WriteLine(a.UserPosition);
}

Console.ReadLine();

@jay_s_uk Great tip, thank you. i will look into that.

Both that wiki and the GCode Dictionary explains thing with the term "Z leadscrews" which is correct in some hardware configurations. But it fooled me, maybe reading too quickly and not fully comprehending tings.

I propose a change to the use of "pivot point" or equivalent to make things a bit less likely to misunderstand.

@dc42 I have made some corrections and tests. A second G32 now results in a much smaller correction compared to before.

And the first layer is so much better than before. Things went a big step away from black magic towards science. Thank you!

I am guessing since the two Z-Motors may be more or less off for each start and the result of correction by G32 varied from each start (due to incorrectly configured M671). This would make the compensation by the mesh bed leveling more or less successful. If so that would explain my intermittent problem with a good first layer, and mostly on the side of the bed making the G32 correction.

During some re-calibration and reading the G-Code dictionary I think the leveling points a defined wrong in my Core-XY printer. (Board: Duet 3 Mini 5+ Firmware: 3.4.0 )

M671 X-19:316 Y146:146 S10.0 

(print area is 290 x 290)

I have two independent Z-axis motors (see image) and so far I have set the leveling points to the center of the lead screws. Reading the instructions for M671 I know believe that the M671 should have the coordinates where the yellow lines cross in the picture. This is where height correction screws are positioned and where the bed pivots. Correct?

A a second bed leveling, done after each other, should not result in any correction, right? Can this be used as way to verify correct vales for the M671 command?

Doing a bed mesh leveling after a bed leveling should also result in the same height near the pivot points (see purple circles in heightmap below)?

image url)

@droftarts I think you misunderstood. This is regarding the configtool, in the configuration tool forum.

/Tomas

Went trough all steps wit default settings except these settings:

Start
RepRapPro Fisher
General
Board: Duet2WiFi
Firmware Version: 3.3 or later (stable)
Network
WiFi Access Point Name ...
WiFi Password ...
Finish
Unchecked DWC firmware and latest stable firmware

Error in browser console:
vue.runtime.esm.js:3020

TypeError: Cannot read properties of null (reading 'output_pin')
    at Template.js:410:37
    at Array.forEach (<anonymous>)
    at Object.validatePins (Template.js:409:20)
    at a.goToNextPage (App.vue:182:1)
    at click (App.vue:1:2431)
    at Ln (vue.runtime.esm.js:2988:30)
    at n (vue.runtime.esm.js:1786:20)
    at link.js:181:19
    at Array.forEach (<anonymous>)
    at a.onClick (link.js:180:12)