Posts made by pandaym

@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:

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

Make sure you checkout the LVGL repo at exactly this commit:

git checkout c1f43bfb090df293059ab52baabbdbdd8df00712

Once again thank you.

After having sort of found out what commits are etc. I hope I found out the way to check it out at that. Is it correct that after cloning I navigate to RepPanel_ESP32\externals\lv_port_esp32 and run the "git checkout c1f43bfb090df293059ab52baabbdbdd8df00712". This gives me the following message:

HEAD is now at c1f43bf Merge pull request #139 from an-erd/fix_mono_disp

Have I gotten that right?

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

You have two separate SPI connections. One for the TFT and one for the touch controller. So the "0" in your display pin assignment are wrong since MOSI must be 13, MISO does not matter I think, DC (Data) must be 2 - just as we said above.

Alright, I understand most of that now. I have just rearranged the wiring according to the config to make it easier to see the correlation. It seemed as then I was missing the MOSI for TFT. I have tried to rework it, hopefully this sorts it out:

Full Wiring - ESP -> LCD

Power:
3.3V -> Pin 1
GND -> Pin 6

TFT:
GPIO 13 -> 19 MOSI
GPIO 18 -> 23 Serial Clock (Shared between TFT and Touch)
GPIO 15 -> 24 - Slave select
GPIO 2 -> 18 - Data
GPIO 4 -> Pin 22 - Reset

Touch:
GPIO 19 -> 21 MISO
GPIO 18 -> 23 Serial Clock (Shared between TFT and Touch)
GPIO 5 -> 26 Slave select
GPIO 25 -> 11 IRQ

Other than that I got:
Touch controller:

Display controller:

Am I getting there?

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

@pandaym Sorry my bad. Chip select for the touch must be GPIO 5 -> 26. I corrected it.

Yes. Looks good! All in all its just about knowing SPI wiring in general and then matching the inputs & outputs. The software/compile process will allow you to change some GPIOs, but with this most stuff should already be configured correctly.

Arh, thanks! Really appreciate you helping me out!

I guess my challenge is I don't even know wiring in general, let alone SPI wiring.

So this is how I wired it now:

ESP > LCD:
3.3V -> Pin 1
GND -> Pin 6
GPIO 4 -> Pin 22 (Reset - TFT related)
GPIO 15 -> 24 (Slave/Chip select for TFT)
GPIO 23 -> 19 MOSI Touch - (but should not be needed?!)
GPIO 19 -> 21 MISO Touch
GPIO 18 -> 23 CLK Touch (same clk for touch and tft)
GPIO 5 -> 26 Chip select Touch
GPIO 25 -> 11 Interrupt Touch
GPIO 2 -> 18

Connection to the Duet, as far as I understand, can be done either wirelessly or wired like this, right?
GPIO 16 -> TX PanelDue port (which I assume on a Duet 3 is IO_0_out ?)
GPIO 17 -> RX PanelDue port (which I assume on a Duet 3 is IO_0_in ?)

The controllers you mentioned seems to be right according to this: http://www.lcdwiki.com/3.5inch_RPi_Display , so ILI9486 and XPT2046.

So to get started on the software side I:

• Installed ESP-IDF
• Cloned the project
• Replaced the contents of externals/lv_port_esp32/components/lvgl/lv_conf.h with that of main/lv_conf_back.h
• Ran idf.py menuconfig

So for TFT display controller I have it set up like this for starters:

I hope it is correctly assumed that there is nothing pre-defined, so I have to do it like that. For the board pinouts, it looks like ESP32 V4 with 38 pins should be correct for the ESP32-DevKitC-32D ?
Then I just chose ILI9486 and left the rest of the main page as is.

For the pin-out I have this, but I don't know if something is missing or wrong here?

Touch controller I set up like this:

With this assignment:

Last thing is the WiFi connection. I cannot tell where I add my SSID and password for it. Am I overlooking something?

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

Your touch screen is connected via a second SPI. Mine is I²C. The second SPI and all other pins will be a config thing during compilation (menuconfig settings) The default for LVGL should be the following HSPI for TFT and VSPI for the touch controller - I think you can choose the "RPi MPI3501" config during the build. The pins can be selected/changed but this should work:
GPIO 15 -> 24 (Slave/Chip select for TFT)
GPIO 23 -> 19 MOSI Touch - (but should not be needed?!)
GPIO 19 -> 21 MISO Touch
GPIO 18 -> 23 CLK Touch (same clk for touch and tft)
GPIO 5 -> 24 Chip select Touch
GPIO 25 -> 11 Interrupt Touch
GPIO 2 -> 18
Looks like the backlight is on automatically

Thanks a lot for the help. I apologize, but I am a complete newbie in all of this stuff, so it is a bit much to chew

Wonder if I understand it correctly. So I still use the pins for 3.3v, gnd and reset like I set them, and add the ones you mentioned? This should make the full wiring this:

ESP > LCD:
3.3V -> Pin 1
GND -> Pin 6
GPIO 4 -> Pin 22 (Reset - TFT related)
GPIO 15 -> 24 (Slave/Chip select for TFT)
GPIO 23 -> 19 MOSI Touch - (but should not be needed?!)
GPIO 19 -> 21 MISO Touch
GPIO 18 -> 23 CLK Touch (same clk for touch and tft)
GPIO 5 -> 24 Chip select Touch
GPIO 25 -> 11 Interrupt Touch
GPIO 2 -> 18

And ESP > Duet 3:
GPIO 16 -> TX PanelDue port
GPIO 17 -> RX PanelDue port

Does this mean I have to bridge it so that both GPIO 15 and GPIO 5 go to the 24 pin on the screen?

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

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

@pandaym Your hardware looks good to me! The DevBoard is standard so that's perfectly fine. The screen is tricky but it should work. Its touch controller is a XPT2046 which definitely supported by LVGL. I did some searching and my best guess is that the display is from waveshare. Looking at their driver code the chip should be a ILI9486 which is also supported by LVGL and thus by RepPanel

Thanks a lot, that sounds good! I will dive into it and see if I can figure out how to wire and program it

@seeul8er any chance I could get some help finding the right way to wire it? I have started, but I got stuck trying to figure out the naming and what was what.

So I got:
ESP > LCD:
3.3V > Pin 1
GND > Pin 6
GPIO 13 > Pin 19 (MOSI - Data line to TFT)
GPIO 14 > Pin 23 (SCL - SPI CLK for TFT)
GPIO 15 > ?!?!? (Slave Select - SPI)
GPIO 22 > ?!?!? (SCL - I2C - touch)
GPIO 21 > ?!?!? (SDA - I2C - touch)
GPIO 4 > Pin 22 (Reset - TFT related)
GPIO 2 > ?!?!? (Data - TFT related)
GPIO 27 > ?!?!? (Backlight - Turn on/off TFT backlight)
And lastly I got GPIO 17 and 16 that will go to the Duet

Mind helping me figure out where the last ones go?

@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!

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

@pandaym Your hardware looks good to me! The DevBoard is standard so that's perfectly fine. The screen is tricky but it should work. Its touch controller is a XPT2046 which definitely supported by LVGL. I did some searching and my best guess is that the display is from waveshare. Looking at their driver code the chip should be a ILI9486 which is also supported by LVGL and thus by RepPanel

Thanks a lot, that sounds good! I will dive into it and see if I can figure out how to wire and program it

I really like your solution, and decided to try and grab a few pieces for it, as I was already ordering a lot of other stuff off Mouser.com
Since stuff like this is COMPLETELY new to me, could you maybe take a look at these parts I grabbed and see if you think it will work?

ESP32:
https://www.mouser.dk/ProductDetail/Espressif-Systems/ESP32-DevKitC-32D?qs=%2Fha2pyFadugghcwsr%252BfCfoiPKVRrwUbD0eThxd%2FUYFY7U8Wh9XQ4LHYEl5esmHGZ

Screen:
https://www.mouser.dk/ProductDetail/Seeed-Studio/308010014?qs=%2Fha2pyFadujFrWe34c%2Fp962d7Tsl7GBwUGpbcqXmB9KgWxdyEeTeaQ%3D%3D

I have no idea where to begin, but I will figure that out I would just like to know if I overlooked something in the specs for the stuff I needed to find. I just went for ESP32 devkit and from the details of the screen, I saw it was 320x480 and had SPI connection: https://www.seeedstudio.com/3-5-Inch-TFT-Display-for-Raspberry-Pi-Resistive-Touch-Screen-p-2248.html

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

Can you do some tests with the BLTouch self-test command? It should place it into a deploy and retract loop for a few times. This used to be continuous until canceled which was nice to be able to test the pin for reliability, but in recent v3 of the bltouch it only does a few tests and stops. So you may need to create a macro that has many of the commands in a row, or even just many M401 and M402 commands in a row to confirm if the probe will reliably deloy time after time. Also test with the printhead in different locations incase it's a bad wire connection that gets triggered from a certain position.

I found out that if you run self-test, then when it stops, you can run M401, then M402, then clear alarm and it allows you to run self test again. So I made it loop and moved the head around a ton. It did not fail once.

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

So for testing I was suggesting you create a cancel.g file and put some commands in it. But if you are able to reproduce the problem without doing the pause/cancel there may be no point.

I have made a cancel.g based on yours:

; cancel.g
;
; Run when the print is paused, and then canceled.
;
 
G10 P0 R0 S0		; Set hotend temp to 0
M140 S0				; Set bed temp to 0
M106 S255 			; Fan at 100 to cool nozzle and bed
M220 S100			; Set speed factor back to 100% in case it was changed
M221 S100			; Set extrusion factor back to 100% in case it was changed
G28 XY				; home XY
M84					; turn off steppers
G4 S60				; wait 1 minute for nozzle to cool
M107				; turn off the fan

Actually, since I did that, I tested 3 times with the reproducible case, and now I could not make it fail anymore. Maybe solved?

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

The only way to safeguard in the event of a head crash is to lower the motor current during homing.

I have added to my homeall and homez that my Z motors drop to 50% current during homing. At 40% they don't run up well at all. This is a great idea, and of course a good way to ensure that if it happens, it might only be the PEI sheet that is damaged, nothing too serious.

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

Is the pause/cancel part required for duplication? Does the probe consistently retract and deploy otherwise?

Unfortunately, it is not the only situation it happens. I just found out I can reproduce it every single time by doing this.

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

Can you post the contents of your pause/cancel macros as well? If they are empty or don't exist can you create them and test again?

pause.g:

; pause.g
; called when a print from SD card is paused
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Sun Jun 14 2020 14:49:37 GMT+0200 (Centraleuropæisk sommertid)
M83              ; relative extruder moves
G1 E-2 F2500     ; retract 10mm of filament
G91              ; relative positioning
G1 Z5 F5000      ; lift Z by 5mm
G90              ; absolute positioning
G1 X20 Y20 F6000 ; go to X=20 Y=20

By cancel, you mean stop.g right? I have it, but it's empty:

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Sun Jun 14 2020 14:49:37 GMT+0200 (Centraleuropæisk sommertid)

On my Duet 3, I am experiencing problems with the BLTouch probe not deploying, and the nozzle therefore crashing the bed. I have not found determined exactly what causes it, but I can reproduce it by doing the following:

1. Home all
2. G32 - True bed levelling
3. Start a print
4. Pause the print
5. Cancel the print
6. Home all again - Here the probe won't deploy, it will throw an error, but the bed will continue to move up until it crashes the nozzle

Here is a video showing off the above sequence: https://www.youtube.com/watch?v=X0Y9zfQB8J0

The error in my console is:

Error: Z probe was not triggered during probing move
Error: Homing failed

The probe is a genuine BLTouch 3.1 connected to IO_7, and I can confirm it is wired correctly. I have also checked the crimps, and tested for continuity, I cannot find any issues with the wiring. I have also checked the pin itself which looks fine, and it is completely clean (it's brand new too). Also went through all of this, and altered my configs based on it: https://duet3d.dozuki.com/Wiki/BLTouch_Troubleshooting?fbclid=IwAR0hujQNUo7lwXghMRnpp-jbP4PYaaVPBfTyRK0iT_9Y5nwZFxxtn6oxJ7c

I am hoping there is a way to make sure the Duet at least stops the bed from continuing to move up when the probe does not deploy to avoid crashes. But also obviously want to make sure the probe always deploys when it has to.

My configurations

config.g:

; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Sun Jun 14 2020 14:49:36 GMT+0200 (Centraleuropæisk sommertid)

; General preferences
G90                                                   ; send absolute coordinates...
M83                                                   ; ...but relative extruder moves
M550 P"CoreXY"                                        ; set printer name
M669 K1                                               ; select CoreXY mode

; Network
M540 PBE:62:38:32:53:34                               ; set custom MAC address
M552 P0.0.0.0 S1                                      ; enable network and acquire dynamic address via DHCP
M586 P0 S1                                            ; enable HTTP
M586 P1 S0                                            ; disable FTP
M586 P2 S0                                            ; disable Telnet

; Drives
M569 P0.0 S0                                          ; X motor - physical drive 0.0 goes forwards
M569 P0.5 S0                                          ; Y motor - physical drive 0.5 goes forwards
M569 P0.1 S1                                          ; Z motor 1 - physical drive 0.1 goes forwards
M569 P0.3 S1                                          ; Z motor 2 - physical drive 0.2 goes forwards
M569 P0.4 S1                                          ; Z motor 3 - physical drive 0.2 goes forwards
M569 P0.2 S1                                          ; Hemera motor - physical drive 0.2 goes forwards
M584 X0.0 Y0.5 Z0.4:0.1:0.3 E0.2                      ; set drive mapping - X Y frontLeftZ FrontRightZ RearZ E

M671 X-35:335:150 Y173:173:335 S15 	                  ; Bed rotational center - front left, front right and rear center

M350 X16 Y16 Z16 E16 I1                               ; Microstepping with interpolation
M92 X160.00 Y160.00 Z800.00 E381.81                   ; Steps/mm

M566 X600 Y600 Z200 E3600                             ; Maximum jerk speeds (mm/min)
M203 X24000 Y24000 Z900 E3600.00                      ; Maximum speeds (mm/min)
;M203 X24000 Y24000 Z200 E3600.00                      ; Maximum speeds (mm/min) LOW Z SPEED FOR TESTING
M201 X1750 Y1750 Z250 E1500                           ; Accelerations (mm/s^2)
M906 X1260 Y1260 Z1260 E1000 I30                      ; Motor currents (mA) - E3D HT Motor rated at 1680 => 75% = 1260 mA | Hemera rated at 1330 => 75% = 1000 | 30% idle factor
M84 S30                                               ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1                                      ; set axis minima
M208 X250 Y250 Z250 S0                                ; set axis maxima

; Endstops
M574 X1 S3                                            ; configure sensorless endstop for low end on X
M574 Y1 S3                                            ; configure sensorless endstop for low end on Y
M574 Z0                                               ; configure BLTouch as Z endstop

; Z-Probe
M950 S0 C"io7.out"                                    ; create servo pin 0 for BLTouch
M558 P9 C"^io7.in" F100 H5 R0.2 T6000 A3 B1           ; set Z probe type to bltouch and the dive height + speeds
G31 P25 X1 Y24 Z0.80                                  ; set Z probe trigger value, offset and trigger height
M557 X15:250 Y15:250 S40                              ; define mesh grid

; Heaters
M308 S0 P"temp0" Y"thermistor" T100000 B3950          ; configure sensor 0 as thermistor on pin temp0
M950 H0 C"out0" T0                                    ; create bed heater output on out0 and map it to sensor 0
M307 H0 B0 S1.00                                      ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0                                               ; map heated bed to heater 0
M143 H0 S200                                          ; set temperature limit for heater 0 to 200C
M308 S1 P"temp1" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin temp1
M950 H1 C"out1" T1                                    ; create nozzle heater output on out1 and map it to sensor 1
M307 H1 B0 S1.00                                      ; disable bang-bang mode for heater  and set PWM limit
M143 H1 S300                                          ; set temperature limit for heater 1 to 300C

; Fans
M950 F0 C"out7" Q500                                  ; create fan 0 on pin out7 and set its frequency
M106 P0 S0 H-1                                        ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"out4" Q500                                  ; create fan 1 on pin out4 and set its frequency
M106 P1 S1 H1 T45                                     ; set fan 1 value. Thermostatic control is turned on

; Tools
M563 P0 S"Hemera" D0 H1 F0                            ; define tool 0
G10 P0 X0 Y0 Z0                                       ; set tool 0 axis offsets
G10 P0 R0 S0                                          ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

; Miscellaneous
T0                                                    ; select first tool
M501												  ; load saved data from non volatile memory

homeall.g:

; homeall.g
; called to home all axes
;Prepare for homing
M400                         ; Finishes all current moves and and thus clears the buffer
G91                          ; Set to Relative Positioning
G1 Z5 F1200 H2               ; Move the bed down slightly

;Prepare for sensorless homing
M913 X30 Y30                 ; Set motor currents to 50% 
M201 X500 Y500               ; Set acceleration on X/Y to 500 to improve reliability of stall detection
M915 X Y S1 R0 F0 H400       ; Configure motor stall detection on X and Y as they work together on corexy - sensitivity 1, don’t take action, don’t filter, 400steps/sec


;Sensorless homing X
G1 H1 X-300 F4000            ; Move 300 mm left, stopping at the endstop - Speed is 4000 which is about twice the Hmin due to two motors working together on Corexy
G1 X30 F2000                 ; Move 30 mm out from Xmin

;Sensorless homing Y
G1 H1 Y-300 F4000            ; Move 300 mm back, stopping at the endstop - Speed is 4000 which is about twice the Hmin due to two motors working together on Corexy
G1 Y30 F2000                 ; Move 30 mm out from Xmin

;End of sensorless homing
M913 X100 Y100               ; Set motor currents back to 100%
M201 X2000 Y2000             ; Set acceleration back to 2000
G90                          ; Set to Absolute Positioning

;BLTouch home Z
G1 X150 Y117 F12000 		 ; Move probe to middle of bed
M558 F500 					 ; Set the first probing speed
G30 						 ; First Z probe
M558 F50  					 ; Set a slower probing speed
G30							 ; Second Z probe

;End of homing
G90                          ; Ensure we are in Absolute Positioning

bed.g:

; bed.g
; called to perform automatic bed compensation via G32
;
M561 						; Clear any bed transform
G30 P0 X35 Y173 Z-99999  	; Probe near front-left leadscrew
G30 P1 X265 Y173 Z-99999 	; Probe near front-right leadscrew
G30 P2 X150 Y290 Z-99999 S3 ; Probe near rear-center leadscrew and adjust bed parallel to corexy kinematics
G1 X15 Y15 F12000			; Move close to home
G29 S1						; Load heightmap.csv

homex.g:

; homex.g
; called to home the X axis
;
;Prepare for homing
M400                         ; Finishes all current moves and and thus clears the buffer
G91                          ; Set to Relative Positioning
G1 Z5 F1200 H2               ; Move the bed down slightly

;Prepare for sensorless homing
M913 X30 Y30                 ; Set motor currents to 50% 
M201 X500 Y500               ; Set acceleration on X/Y to 500 to improve reliability of stall detection
M915 X Y S1 R0 F0 H400       ; Configure motor stall detection on X and Y as they work together on corexy - sensitivity 1, don’t take action, don’t filter, 400steps/sec

;Sensorless homing X
G1 H1 X-300 F4000            ; Move 300 mm left, stopping at the endstop - Speed is 4000 which is about twice the Hmin due to two motors working together on Corexy
G1 X30 F2000                 ; Move 30 mm out from Xmin

;End of sensorless homing
M913 X100 Y100               ; Set motor currents back to 100%
M201 X2000 Y2000             ; Set acceleration back to 2000

;End of homing
G90                          ; Set to Absolute Positioning

homey.g:

; homey.g
; called to home the Y axis
;
;Prepare for homing
M400                         ; Finishes all current moves and and thus clears the buffer
G91                          ; Set to Relative Positioning
G1 Z5 F1200 H2               ; Move the bed down slightly

;Prepare for sensorless homing
M913 X30 Y30                 ; Set motor currents to 50% 
M201 X500 Y500               ; Set acceleration on X/Y to 500 to improve reliability of stall detection
M915 X Y S1 R0 F0 H400       ; Configure motor stall detection on X and Y as they work together on corexy - sensitivity 1, don’t take action, don’t filter, 400steps/sec

;Sensorless homing Y
G1 H1 Y-300 F4000            ; Move 300 mm back, stopping at the endstop - Speed is 4000 which is about twice the Hmin due to two motors working together on Corexy
G1 Y30 F2000                 ; Move 30 mm out from Xmin

;End of sensorless homing
M913 X100 Y100               ; Set motor currents back to 100%
M201 X2000 Y2000             ; Set acceleration back to 2000

;End of homing
G90                          ; Ensure we are in Absolute Positioning

homez.g:

; homez.g
; called to home the Z axis
;
;Prepare for homing
G91                          ; Set to Relative Positioning
G1 Z5 F6000 H2               ; Move the bed down slightly
G90                          ; Set to Absolute Positioning

;Probe Z
G1 X150 Y150 F4000  		 ; Move probe to middle of bed
G30 						 ; First Z probe
G1 H2 Z5 F400				 ; Lift Z relative to current position

deployprobe.g:

; deployprobe.g
; called to deploy a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Sun Jun 14 2020 14:49:36 GMT+0200 (Centraleuropæisk sommertid)
M280 P0 S10 ; deploy BLTouch

retractprobe.g:

; retractprobe.g
; called to retract a physical Z probe
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Sun Jun 14 2020 14:49:36 GMT+0200 (Centraleuropæisk sommertid)
M280 P0 S90 ; retract BLTouch

*** Note: I have another thread based on this issue, but I decided to make this new post to make it more specific to the issue. The other one included alot about my sensorless homing for X and Y, which works perfectly now.