Hi Duet,

I have lately gotten a lot of experience with Klipper, that I am currently running on my MK3S Bear on the original Einsy board. I do own a Duet WiFi and a Duet 3 too, and would very much like for these to get out of the drawer and onto my printers

I would therefore like to know what the plans are for implementing some of the features, that I find really good in Klipper:

• Input shaper - The implementation in Klipper to me is a complete gamechanger, and gave me the biggest benefit of any upgrades or tuning I have ever done to a 3D printer. I would really much like to see the same implementation in Duet soon. I have found a couple of discussions about it, but I only saw mention that something may be in the works for a later version, nothing too specific. Can you elaborate on these plans?

• Acceleration / square corner velocity / jerk - To be honest I do not fully understand the ins and outs of this. In my experience with RRF and Marlin, tuning jerk has always been something that caused problems, and I never really knew if I were "there". In Klipper, jerk is gone, and I believe this is one of the reason I found it much simpler to tune my printer that runs Klipper. Any chance we could see a similar functionality in RRF?

• Calibration scripts - Another thing that makes it really simple to calibrate a printer running Klipper are the integrated scripts. An example is pressure advance, which I have found to be much easier to deal with due to integrated calibration script. Is this something we can look forward to?

I hope you guys can elaborate on these points, and that there are plans in these regards to RRF.

Hey everyone,

First of all, I am a completely new Duet user, so excuse my lack of experience.

I just finished the initial assembly of my CoreXY 3D printer, running a Duet 3. When I wanted to start my first test print, I realized I had to change some things up, and therefore paused and cancelled it. I started printing again afterwards, but during homing, the nozzle crashes straight into my bed and made a hole in it - damn!

I cannot seem to figure out exactly why it crashed the bed, or how I can ensure it does not happen again. What I think is that when homing X or Y fails, it for some reason still goes on with the movements to home Z, but without deploying the probe. I plan to tune the sensorless homing to be more reliable, or even add micro switches for homing, but I would still like for this to not happen if something is off.

I don't know exactly which of these errors relate, but these are what I could find in my console:
16.6.2020 23.28.22 G28
Error: G0/G1: insufficient axes homed
16.6.2020 23.32.24 Error: Z probe was not triggered during probing move
Error: Z probe was not triggered during probing move
16.6.2020 23.33.29 M120 G91 G1 Z25 F6000 G90 M121
Error: G0/G1: insufficient axes homed

What I think might be relevant from my setup:

• Sensorless homing on X and Y and BLTouch on Z.
• All my motors are the E3D high torque motor.
• I am running true bed levelling

Trying to attach the relevant configs and the gcode I was trying to print here. It got flagged as spam when I initially tried. Hopefully this works:
3DBenchy.gcode
config.g
homeall.g
homey.g
homex.g
homez.g
bed.g

Here is a picture of what the printer looks like at the moment. Thank you in advance!

@bearer said in Nozzle crashed into bed while homing - can this be avoided?:

Nozzle crashed into bed while homing - can this be avoided?

in general test limit switchs first
then test motor directions with small moves
and use normally closed limit switches so that any failure of the switch will prevent movement when homing.

I was considering whether I should use switches, but I thought that, since I don't need that much accuracy on homing (unless if I have to resume after power loss), it should be fine without for the time being. I did test the motor directions and sort all of that out first, and also got sensorless homing working. It just seems that it sometimes fail homing X/Y when the tool head starts from the middle of the bed instead of close to where it homes against.

But is there not a way to halt everything in case it misses homing an axis instead of it just continuing to move stuff?

@Phaedrux said in Z probe was not triggered during probing move - bed crash:

Please keep us posted on if it continues to happen and if you remove the cancel.g file if that causes it to happen reliably again.

In addition to the motor current drop you can also add the BLTouch alarm release command to the start of homeall to clear any error state and retract the pin as a precaution. I think I may have mentioned that already.

Sorry, I did not press submit on the answer I had written here.

I disassembled the printer to redo some wiring etc. to finish it off. When I am done, I will continue testing it, and I will get back if it keeps happening. Also I will add the alarm release, just to have an extra precaution.

Thanks a lot for the help!

@phaedrux said in [3.3.0] - Folder structure issues?:

How did you update to 3.3?

If you used bossa to flash it I'm not sure if it would get created automatically.

Pull the SD card and manually create a firmware folder in the root if it isn't already there.

Then put the SD card back in the board and power on.

Download this zip file.
https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/Duet2and3Firmware-3.3.zip

Go to DWC and go to the system tab and upload that zip file as is, don't extract it first. That should get you all squared away.

Then if you want to clean up the system folder itself you can delete all the .bin files since they now live in the /firmware folder.

I used bossa to flash the older (3.1 or 3.2 I believe) firmware that was on the SD back to the board.
Then I downloaded the 3.3 zip that you are linking, uploaded it, and it automatically updated. (Did not unpack first)

So this procedure does not seem to create and populate a firmware folder.

I just threw the zip on there again, and this time it updated differently. It seems only version 3.3 has the necessary abilities to actually upgrade correctly to 3.3 then?

Looking at the folder structure after, I notice that not all bin files are in the firmware folder, or I have too many. In the firmware folder I have 13, but in sys I have 16. Is it safe to delete all 16?

Hey,

Unfortunately I have had a very hard time understanding the firmware updating instructions, and understanding the big picture of all the different stuff that gets updated, what goes where etc.

I just reverted my Duet WiFi board back from Klipper to RRF, and updated the board to the new 3.3. I noticed the addition of a "firmware" folder, but the instructions do not seem to explain how to deal with it. I am not sure if this is a preparation for future upgrades, and not working yet, but for now, nothing happens when I use the drop down to switch between the two. It just shows the exact same file list:

System directory:

Firmware directory:

I don't know exactly what my question is to be honest. I guess I would just like to know if I am good to go, or whether I need to move some stuff around and clean up?

Hi Duet,

I have lately gotten a lot of experience with Klipper, that I am currently running on my MK3S Bear on the original Einsy board. I do own a Duet WiFi and a Duet 3 too, and would very much like for these to get out of the drawer and onto my printers

I would therefore like to know what the plans are for implementing some of the features, that I find really good in Klipper:

• Input shaper - The implementation in Klipper to me is a complete gamechanger, and gave me the biggest benefit of any upgrades or tuning I have ever done to a 3D printer. I would really much like to see the same implementation in Duet soon. I have found a couple of discussions about it, but I only saw mention that something may be in the works for a later version, nothing too specific. Can you elaborate on these plans?

• Acceleration / square corner velocity / jerk - To be honest I do not fully understand the ins and outs of this. In my experience with RRF and Marlin, tuning jerk has always been something that caused problems, and I never really knew if I were "there". In Klipper, jerk is gone, and I believe this is one of the reason I found it much simpler to tune my printer that runs Klipper. Any chance we could see a similar functionality in RRF?

• Calibration scripts - Another thing that makes it really simple to calibrate a printer running Klipper are the integrated scripts. An example is pressure advance, which I have found to be much easier to deal with due to integrated calibration script. Is this something we can look forward to?

I hope you guys can elaborate on these points, and that there are plans in these regards to RRF.

@littlehobbyshop said in RepPanel - A DIY alternative to the PanelDue with WiFi support:

I still can't get my SPI touchscreen working. Feeling I'm in over my head. I just don't know how to troubleshoot this stuff.

Sorry man, I completely forgot to answer you. Where are you with this now? I absolutely do not know what I am doing with stuff like this, so I just lucked out getting it working. I can try and figure out some details if you still need it?

After a ton of work, it's finally alive:
https://www.youtube.com/watch?v=LbLHOhdqSiE

I had to set both display and touch to HSPI and change some GPIOs for some reason. But in the end it worked. The resisitive touch screen just isn't that great - should have gotten capacitive

I have managed to get the screen alive, but without any touch.
If I just set the touch panel to none in the menuconfig, then the screen comes alive. But if I actually configure the touch, it just blanks it out.

Any idea?

@seeul8er said in RepPanel - A DIY alternative to the PanelDue with WiFi support:

@pandaym said in RepPanel - A DIY alternative to the PanelDue with WiFi support:

Shall I try and wire it back up? Also, what do you think I have to do about power? Still haven't figured whether I should need to connect both a 5V and a 3.3V cable from the ESP32 to the screen.

Try using only the 5V input. I am pretty sure you do not need both.
Looking at the logs I'd say that the flash and startup of RepPanel were a success. I'd go wire it up again. Can only be a GPIO config or wiring issue.
Does your display feature any switches/bridged pins? Read something about that in the forums.

Still no luck unfortunately.

I tried wiring it up to a Raspberry, just to confirm that it works. And that worked fine.

Must be a wiring issue, but I cannot find any diagram for it anywhere, I have just been counting them out and using their table.

@seeul8er said in RepPanel - A DIY alternative to the PanelDue with WiFi support:

@pandaym Check the docs on that. Further down it says changing the Main XTAL frequency might solve the output issue. Maybe autodetect does the trick.

Same thing regardless of XTAL frequency. I rebuilt and reflashed between attempting them. Then I disconnected all my wiring to run the ESP32 on its own, still no luck.

I then navigated to the examples and tried to build and flash the hello world example - this works fine:

I went through the menuconfig on this vs. RepPanel, and found some differences in flash size and baud rate for monitor. I changed the Flash size to 2 like on Hello World, but then it would not flash because of insufficient space. I then tried changing idf.py monitor baud rate to 115200, while keeping 4mb flash size, and then I got monitor running:

Shall I try and wire it back up? Also, what do you think I have to do about power? Still haven't figured whether I should need to connect both a 5V and a 3.3V cable from the ESP32 to the screen.

@seeul8er said in RepPanel - A DIY alternative to the PanelDue with WiFi support:

@pandaym Your config looks good now. Yes you got the commit thing right. Otherwise you'd get a compile error.
Can you check the debug log please? You can do that by running:

idf.py monitor

The 5V & 3.3V thing is strange. I'll take a look at the data sheet later.

I ran idf.py monitor, and it looks like something from the Matrix. Still haven't gotten anything on screen.

I thought I would just give it a try to see if something showed up. So I:

• Saved the configuration in the menuconfig
• Ran idf.py build
• Connected USB to the ESP32 and found that it was on COM9
• Ran idf.py -p COM9 flash

Unfortunately, the display never came on. So I wondered if it needed power on other pins and used my multimeter to check. I could see that the two 3.3V pins on the screen are internally connected, so are the two 5V pins and the five ground pins.

So I thought that it probably needs both 5V and 3.3V, so I wired 5V from the ESP32 to pin 2 on the screen.

When I plugged USB back in, the screen lit up, but nothing happened: