Topics created by R006

@Phaedrux
Homeall.g

G91 G1 H2 Z2 F100 G1 H1 X-300 Y-300 F600 G1 H2 X5 Y5 F1000 G1 H1 X-300 Y-300 F200 G1 H2 Z-5 F100 G1 H1 Z304.1 F300 G1 H2 Z-2 F100 G1 H1 Z304.1 F100 G92 X0 Y0 G90 G92 Z304.1

homex.g

G91 G1 H2 Z2 F100 G1 H1 X-300 F600 G1 H2 X5 F600 G1 H1 X-300 F200 G1 H2 Z-2 F100 G92 X0 G90

homey.g

G91 G1 H2 Z2 F100 G1 H1 Y-300 F600 G1 H2 Y5 F600 G1 H1 Y-300 F200 G1 H2 Z-2 F100 G92 Y0 G90

homez.g

G91 G1 H2 Z2 F300 G1 H1 Z304.1 F360 G1 H2 Z-5 F240 G1 H1 Z304.1 F200 G90 G92 Z304.1

config.g

M552 S1 ;M552 S-1 M586 P0 S1 M586 P1 S0 M586 P2 S0 ; Drives M569 P0 S1 M569 P1 S1 M569 P2 S1 M569 P3 S1 M569 P4 S1 M569 P5 S1 M584 X0 Y1 Z2:3:4 E5 M350 X32 Y32 I0 M350 Z16 E16 I1 M92 X160.0 Y160.0 Z2133.33 E932.00 ;change as per machine M566 X720.00 Y720.00 Z300.00 E600.00 M203 X8400.00 Y8400.00 Z420.00 E8400.00 M201 X3000.00 Y3000.00 Z30.00 E250.00 ;M-curr M906 X1600 Y1600 Z1600 E800 I50 M84 S30 ; Axis Limits M208 X0 Y0 Z0 S1 M208 X300 Y300 Z304.1 S0 ; filament Sensor M591 D0 P7 C"exp.e3stop" R15:300 L7 E17 S1 ; Endstops M574 X1 S1 P"xstop" M574 Y1 S1 P"ystop" M574 Z1 S1 P"zstop+e0_stop+e1_stop" ; Z-Probe M950 S0 C"exp.heater3" M558 P9 C"^zprobe.in" H5 F120 T6000 G31 P500 X0 Y0 Z1.038 ; Auto level, coordinates as per motor order in M584 M671 X-17.66:297.34:140.00 Y-5.00:-5.00:327.61 S5.0 F1.2 ; define mesh grid M557 X30:300 Y30:300 S20 M376 H5 ; End Limits M950 J1 C"exp.e4stop" M581 P1 T2 R0 S1 M582 T2 M581 P-1 T2 M581 P1 T0 R0 S1 ;PA M572 D0 S0.045 ; Bed Heater M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 M950 H0 C"bedheat" T0 M307 H0 B0 S1.00 M140 H0 M143 H0 S105 ; Extuder Heater M308 S1 P"e0temp" Y"pt1000" M950 H1 C"e0heat" T1 M307 H1 B0 S1.00 M143 H1 S320 ; cooling Fans M950 F0 C"fan0" Q500 M106 P0 S0 H-1 M950 F1 C"fan1" Q500 M106 P1 S0 H-1 ; Tools M563 P0 D0 H1 F0 G10 P0 X0 Y0 Z0 G10 P0 R0 S0 M575 P1 S1 B57600 M501 M911 S21 R22.5 P"M913 X0 Y0 G91 M83 G1 Z5 E-5 F1000" M929 S3 P"/macros/SERVICE/log/STPL_DEBUG.txt"

@R006 that command refers to paths that have spaces in them (between Program and Files) so in each case the whole path/filename needs to have quotation marks around it. I'm not a user of CMake so I don't know how to make that happen, unless that whole line appears in CMakeLists.txt and you can just edit it. Developers who build under Linux typically avoid spaces in file and folder names to avoid this sort of problem.

I built PanelDueFirmware successfully under Eclipse/Windows a few days ago. I have the same space in the file paths as you do and Eclipse puts the quotation marks in automatically.

@Phaedrux
okay
Thank you

@dc42 said in Modify Panel-due:

@R006 https://github.com/Duet3D/PanelDueFirmware

Thank you!
Could you please guide me on which file I need to modify to apply these changes?

@dc42
Okay,
but why print is paused after that information?

microsteps M350 X8 Y8 Z16 E16:16 I1

@droftarts, I am waiting for your response.

Please check my config.g file:

M558 K0 P11 C"100.i2c.ldc1612" F36000 T36000 ; configure SZP as probe 1, type 11, on CAN address 120 M308 A"SZP coil" S10 Y"thermistor" P"100.temp0" ; thermistor on SZP coil G31 P500 K0 Z3 Y-17 H10 ; define probe 1 offsets and trigger height M558.2 K0 S23 R164530 M558.1 K0 S2

Let me know if I am doing something wrong.

At some points, I get trigger heights like 3.00, -2.55, or -2.99.

In DWC, my Z-probe value is not steady; it fluctuates between 0, 9097, and 999999.

Additionally, I am using a proximity sensor for homing the Z-axis.

provide me solution for that.

@R006 I would say first update the firmware from 3.5.2RC1 to the full release version of 3.5.2 There has been a lot of bug fixes since RC1

@R006 For the cable between the SZP board and coil, we use a 4-core FFC cable, with 0.50mm pitch, opposite side contacts. We supply 5cm and 15cm cables, and I've seen a 20cm cable in the kits that come with Mellow Fly toolboards. I'm not sure how much longer you can go than that before there are issues with interference; I don't have any longer ones to test with.

Accuracy is limited by two factors:

noise in the reading, which limits the resolution. On the test machine this varies from about +/- 1.2um at 4mm distance from the bed to +/- 3um at 6mm distance. Some of this noise may be caused by vibration of the machine. Like all inductive sensors, it is temperature-sensitive. So the absolute accuracy depends on how well you calibrate it for changes in temperature of the bed and/or the sensor. There is a thermistor on the sensor to help with this.

We suggest a maximum ambient temperature of 75°C, and an absolute maximum board temperature of 85°C. The coil can likely cope with higher temperatures than this, having no active components. Our FFC cables are rated at 80°C, but you can get FFC cables that are rated to 105°C from Molex.

Ian

Further documentation:

https://docs.duet3d.com/en/User_manual/Tuning/Defining_tool_and_Z_probe_offsets

https://docs.duet3d.com/User_manual/Reference/Gcodes#g0-rapid-move

https://docs.duet3d.com/User_manual/Reference/Gcodes#g10-set-workplace-coordinate-offset-or-tool-offset

https://docs.duet3d.com/User_manual/Reference/Gcodes#g31-set-or-report-current-probe-status

https://docs.duet3d.com/User_manual/Reference/Gcodes#g60-save-current-position-to-slot

https://docs.duet3d.com/User_manual/Reference/Gcodes#m557-set-z-probe-point-or-define-probing-grid

https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing

@R006 said in Issue with Heater 1 Predicted Maximum Temperature Warning:

Now, I want to add a comment about this in RRF 3.4b3, but I am encountering multiple errors.

Best to start a new thread about your build errors.

@R006 said in random jerk change after Resume APF:

However, on the other machine, the values change to X6 Y6 Z6 E600, resulting in vibrations during printing.

That's a very strange figure, and seems like what a slicer would put in the Gcode when using mm/s, rather than using the RRF convention of mm/min. Possibly set using M205 (Marlin compatibility version of M566, but set in mm/s).

Test by turning the machine on, and sending M566/M205. It should be set to what is in config.g, which is also run on resume after power failure. If it's correct then it's the Gcode that is changing it.

Ian

@R006 said in mesh bed compensation:

Please provide some suggestions? how to i find the problem's root cause?

Twist in the XY gantry movement can alter the print head position and change the angle of the print head, meaning the bltouch to nozzle offset is incorrect at those positions. This is the usual cause for when the mesh doesn't seem to work correctly in certain areas of the bed such as those shown on your map near the back. This is also a common area for the X Y gantry to have inconsistencies in the build.

One way to check this is to set your M558 probe type to P0 which enables manual probing. With manual probing you will be prompted to manually jog the nozzle down to touch the bed surface.

@R006 This does seem like an odd failure. Let's replace it under warranty.

Please send an email to warranty@duet3d.com. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

Ian

@R006 it looks to me that you have a very old branch or version of WiFiSocketServerRTOS in your workspace. This is what mine looks like in Eclipse:

bc065b83-432b-45c2-b0e9-530ec4aea22b-image.png

The contents of MessageFormats.h in that project should be the same as at https://github.com/Duet3D/WiFiSocketServerRTOS/blob/main/src/include/MessageFormats.h.

@oliof i have already add for windows
and thank you

Having thought about this more, I think it suits my sand table more than the 'classic' homing approach, so I'm going to adopt it. Thanks @R006 for highlighting it. (On teh other hand, 99% of the time I don't need the table homed on this axis - the pattern will just face a different direction, and it's truly unlimited continuous rotation mechanically.)

My previous code snippet misbehaves if the endstop is already triggered when first called and the 'touch more' movement drives it out of triggered, so I've actually adopted:

G91 ; relative moves M574 Y1 S1 P"ystop" ; proper endstop polarity if sensors.endstops[1].triggered = false G1 H1 Y-720 F1800 ; do homing move @1800 (5 rpm, 12 secs per rev) G1 H2 Y-2 F1800 ; move slightly further - endstop zone is approx 6 wide M574 Y1 S1 P"!ystop" ; reverse polarity G1 H1 Y10 F360 ; home to release at 1 rpm G92 Y0 ; set zero M574 Y1 S1 P"ystop" ; reset endstop polarity G90 ; absolute moves

@gloomyandy

20240424_144735.jpg

Capture_gcode.PNG

also i am try to simulate same Gcode with RRF 3.5.0 rc4 in that only one gcode give the bad command error (2 time simulated and giving two different error which is attached in image)

20240425_105145.jpg 20240425_105222.jpg

also attached Gcode SS

Capture_gcode_1.PNG

@Phaedrux

My resurrect-prologue.g
``

G1 Z{param.Z}
G28 X Y
M116
M83
M21 P1
G1 E5 F500
;mesh
G29 S1
;Buzz
M300 S600 P100
;Buzz
M300 S700 P1200
;Buzz
M300 S500 P300
;Abs
G90

homeall.g

G91 ; relative positioning
G1 H2 Z2 F100 ; lift Z relative to current position
G1 H1 X-300 Y-300 F600 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 H2 X5 Y5 F1000 ; go back a few mm
G1 H1 X-300 Y-300 F200 ; move slowly to X and Y axis endstops once more (second pass)
G1 H1 Z304.1 F300 ; Z down
G1 H2 Z-2 F100 ; back
G1 H1 Z304.1 F100
G92 X0 Y0
G90 ; absolute positioning
G92 Z304.1

@R006 sounds like its a mechanical issue or you've set speed limits that are higher than your machine is capable of.
if it was a firmware issue, everyone would be affected

@dc42 :

with RC4, sometimes it resumes fine with minimal offset. Whereas sometimes it shift by 5-8mm in Y direction for me on resume after power failure. Mostly it shifting by >5mm happens when print height is <5mm. So i disabled meshbed compensation & tried. It still has the same problem.

There are instances when even at height 3mm, it resumes fine.
skew in YZ is included. Does that have any effect?

What should I check for ?
Shift is always in Y axis & amount of shift is more w.r.t X axis.