Posts made by cjccjj

@dc42 Thank you. This is very helpful, I have made changes accordingly I think it will print fine.

@Phaedrux Yes, simulation reports issues mostly in starting gcode. I have made modification it will print fine I believe. Thank you.

Hi,

I am having to run G-code sliced in Marlin flavor on RRF machine, so I think I need some suggestion before printing,
1, is there some conversion software that I can convert the G-code flavor? I didn't find any
2, if I have to do it manually, what are the G-code that I should look for and replace that is Not standard in Marlin and RRF
3, if the G-code passes the on-board simulation, I think it should be mostly fine to print ?

thank you!

@stuartofmt the root key with flags? I just opened DWC with Chrome developer tool, and looked how it updates. It communicates using rr_model?flags=d99fn which is actually explained here https://docs.duet3d.com/User_manual/Reference/Gcodes#m409-query-object-model

@stuartofmt Thank you, the comments and suggestions are very helpful.

I was able to get it running over the weekend. It now shows basic printing job information and status, and can also run any Gcode stored on the board SD (thanks to the M98 command).

The coding is pretty sloppy and not very useful to others as I didn't handle the Json response very well it only works on my specific setup, but I uploaded it to https://github.com/cjccjj/Duet-ESP32-WIFI-Controller for my own record and just in case anyone want to take a look.

@dc42 This saved me a lot of time. I looked into DWC and copied the flag set in it. Thank you.

@stuartofmt Thank you for the reminder and the examples. I think I now have a basic idea how to code the controller, that I send request as follows, parse the responses, add some logic and organize the information on the screen ( I am using a standalone board, /machine/status doesn't work)

url = "printer/rr_connect"  #Connect
url = "printer/rr_filelist?dir=0:/gcodes/" #List job files
url = "printer/rr_gcode?gcode=" #Run Gcode
url = "printer/rr_model?key=state&flags=v" #Get object at the key of "state"

One thing I am not sure about is how to constantly get the most common status. The "state" key of the object model is not a replacement of "rr_status". It seems to me it will require several http requests to collect status information across the model at different keys (one request per key). It is not very efficient and perhaps will slow down the update routine and performance.

@stuartofmt Thank you for the help and yes interfaces and network would be fine as I have done similar I think what I need is to understand the structure, and a little encouragement. I am just learning these in spare time and found it fun to play with both hardware and software.

@dc42 Thank you, I will definitely look into it. I have been using ArduinoJson library for some simple project, I think it will work.

@o_lampe ESP32 has 520KB of ram, I think it is more then enough to show file list. I will still use PC but it is located in another room than the printer. So the controller is only for quick easy operations that have to be done in front of the printer.

@stuartofmt Thank you for the reply, yes, it has http client. My question is more about the coding difficulties for my use. The Json response like rr_status looks clear but is depreciated or soon will be. The more powerful Object Model Framework looks very complicated to me, and I didn't find examples that can be direct reference. So, as I just want it to be a simple interface that shows minimal status and send a few Gcode, I wonder if I there is simpler way to write code for this.

Update:
Thanks for the support from this community, the controller is now working. Here are some pictures.
It is quite basic but if you want to take a look into the code here it is https://github.com/cjccjj/Duet-ESP32-WIFI-Controller

Hi, I have a ESP32 board that integrated with a small OLED display and a few buttons. I want to make it a simple wifi controller for my Duet Printer which doesn't have a screen. It will only do simple tasks like start / stop / pause / resume / load upload filament / and maybe a few Gcode macro. After some research I am thinking to make use of the Telnet communication, to send Gcode to Duet board, which seems to be the easiest way. Is Telnet the best way for this? Please if anyone has any suggestion. Thank you!

@moth4017
It didn't show a difference for my recent prints, both have quite nice first layer. However those are small prints at the center of the bed. My printer is a small one the bed is 230x150, and seems pretty flat from height map, I had been watching but never found any movement of Z when it prints first layer with height map enabled.
Actually for most prints the first layer is good enough, the difference is fine vs perfect only for large print. I guess the inconsistent comes from the whole system. I see videos of the Bambulab printer does pretty long calibration for every print, and it vibrates a lot when calibrating. Maybe that vibration not only helps input shaping but also help the whole mechanical system to settle down to the same state.
Thank you for the input! And btw, the spamming system of this forum stops me from posting or replying or editing twice in the same day, I have to wait a day or two to reply....

@moth4017
I did a few test on my setup. First 2 groups of test that I home XY or XYZ between tests, it seems that the inductive probe itself is quite accurate, that the deviation is below 0.005. Homing by end-stop doesn't affect the value as expected.

In the 3rd group of test, homing is executed and I manually remove the print surface from bed, bend it a few times and reinstall it back between tests. Now the deviation increased a bit but still at about 0.005 which is good, but for 2 times that the deviation is 0.021, which is 4 times greater. Also the mean value seems shifted about 0.1mm (which should not be a problem). I have no idea why these 2 times have a greater deviation that is big enough to affect first layer quality.

;Home XY between every test
G32 bed probe heights: -0.168 -0.170 -0.173 -0.173 -0.174 -0.174 -0.175 -0.178 -0.178 -0.178, mean -0.174, deviation from mean 0.003
G32 bed probe heights: -0.170 -0.173 -0.175 -0.175 -0.176 -0.178 -0.178 -0.180 -0.180 -0.180, mean -0.176, deviation from mean 0.003
G32 bed probe heights: -0.169 -0.171 -0.174 -0.174 -0.175 -0.176 -0.176 -0.178 -0.178 -0.178, mean -0.175, deviation from mean 0.003
G32 bed probe heights: -0.169 -0.171 -0.174 -0.174 -0.176 -0.178 -0.178 -0.178 -0.178 -0.178, mean -0.175, deviation from mean 0.003

;Home XYZ between every test
G32 bed probe heights: -0.161 -0.163 -0.165 -0.165 -0.165 -0.165 -0.165 -0.166 -0.166 -0.165, mean -0.165, deviation from mean 0.001
G32 bed probe heights: -0.156 -0.159 -0.161 -0.161 -0.163 -0.163 -0.163 -0.166 -0.166 -0.166, mean -0.162, deviation from mean 0.003
G32 bed probe heights: -0.164 -0.168 -0.168 -0.169 -0.169 -0.170 -0.170 -0.170 -0.173 -0.174, mean -0.169, deviation from mean 0.003
G32 bed probe heights: -0.169 -0.173 -0.174 -0.175 -0.175 -0.176 -0.178 -0.176 -0.175 -0.178, mean -0.175, deviation from mean 0.002

;Home XYZ and manually remove and put back steel sheet between every test
G32 bed probe heights: -0.164 -0.168 -0.169 -0.170 -0.170 -0.174 -0.173 -0.174 -0.173 -0.174, mean -0.171, deviation from mean 0.003
G32 bed probe heights: -0.175 -0.178 -0.178 -0.180 -0.180 -0.183 -0.183 -0.183 -0.183 -0.185, mean -0.181, deviation from mean 0.003
G32 bed probe heights: -0.308 -0.304 -0.298 -0.283 -0.274 -0.270 -0.265 -0.261 -0.253 -0.240, mean -0.275, deviation from mean 0.021
G32 bed probe heights: -0.136 -0.134 -0.130 -0.128 -0.126 -0.125 -0.123 -0.123 -0.121 -0.120, mean -0.127, deviation from mean 0.005
G32 bed probe heights: -0.285 -0.271 -0.261 -0.256 -0.253 -0.249 -0.241 -0.230 -0.221 -0.216, mean -0.248, deviation from mean 0.021
G32 bed probe heights: -0.136 -0.133 -0.131 -0.129 -0.126 -0.126 -0.125 -0.125 -0.123 -0.120, mean -0.127, deviation from mean 0.005

Hi, I have an inductive sensor as Z probe with my setup. The print is a corexy setup that the bed has a removable steel sheet with PEI film that is driven up and down by one stepper motor.

I followed the calibration guide and set Z probe trigger height with G31, after some finetuning of the Z trigger height, and G30/G29 probing/mapping, I got perfect first layer test prints.

Then I added G30 to do a single probe and then G29 S1 to load height map to my slicer starting code, I did get perfect first layer for a few prints.

However the other day I printed again, the first layer is not perfect (not too bad but not perfect) , by observing the print I have to reduce the Z probe trigger height a bit to get perfect first layer again (no change to height map).

Bed is heated to the same temperature for all calibration and actual print, and I haven't moved my printer around. Is there any mistake in my process? Where should I look at to get perfect first layer automatically every time?

Thank you!

@jay_s_uk Thank you. so this is the correct way to do it. It is just a bit strange to use G29 to call a script and run itself within it, so I was not so certain about it.

@dc42 Thank you for the quick reply, I believe that will solve the warning issue. But I am not quite sure about how to write the mesh.g file.

So in mesh.g, after moving the head and G30, I must use G29 with S parameter, otherwise, it will call itself again in a dead loop, is that so?

Hi, I newly setup a Z probe for my system running Maestro, which is an Inductive sensor.

; Z-Probe
M558 P5 C"!zprobe.in" H3 F120 T3600				; Z probe setup
G31 X-31 Y-0.7 Z1.050 							; Z height 1.050mm, X offset Y offset
M557 X10:190 Y7.5:142.5 S20:15                  ; define mesh grid

It all worked fine when the bed is cold

g29
100 points probed, min error -0.157, max error 0.018, mean -0.089, deviation 0.045
Height map saved to file 0:/sys/heightmap.csv

but when I run G29 while heating the bed to 60 degree, I get a notification of response time too long and a warning as below.

g29
Warning: the height map has a substantial Z offset. Suggest use Z-probe to establish Z=0 datum, then re-probe the mesh.
100 points probed, min error -0.140, max error -0.035, mean -0.076, deviation 0.019
Height map saved to file 0:/sys/heightmap.csv

The results seem fine despite the warning. Should I change anything about it?

I was using this fan as a hotend cooling fan, it is too strong and loud therefore I don't want it always running and was trying to limit it speed at 50% when printing. I end up using L and X with M106 to achieve this.

M106 P1 L127 X128 S255 B1 H1 T40

I didn't try the code further as it is difficult to judge the actual speed of a fan just by listening to it noise, and I found that PWM control on 2 pins normal fan isn't working really well. So then I changed to another lower speed fan and let it run at 100%.

However, I think documentation on how to use range / proportional fan control does need some work.