Thermal runaway?

[tautomer]

Describe the bug It seems whenever the printer starts homing, temperature of the hotend or the bed will drop.

Octoprint reports the following error

Your printer's firmware reported an error. Due to that the ongoing print job will be cancelled. Reported error: MINTEMP triggered, system stopped! Heater_ID: bed - echo:busy: processing

The temperature graph looks like this

The heating part also looks weird. I don't think there was a slowdown in temperature increase when using Alex's firmware.

Version (please complete the following information): Tested with both releases (N32-UBL-7x7.bin and N32-UBL_ProUI_BLT.bin). The printer is an N32 Aquila X2.

Anything else I can provide to help pinpointing the issue?

[classicrocker883]

hard to say what and why that would happen. are you sure that your thermistor is in its spot securely?

so right away I want to say this can be hardware related rather than firmware.

if you had another way of recording temp, like an IR camera or a multimeter with a temp sensor, that might point to thermistor itself.

[tautomer]

I suspected it was the thermistor's issue as well, but Alex's firmware seems to work fine.

The heating part looks normal. The small bump in the hotend temperature was during homing (not sure if it's supposed to happen), but otherwise printing is fine.

BTW, Alex's firmware also had a thermal runaway issue when trying to build the mesh while heating is on. https://github.com/alexqzd/Marlin/issues/8 So I can only use M420. Not sure if it's related.

Also, I just realized I forgot to do a PID calibration after flashing new firmware. Let me flash back your firmware tonight and try again.

[tautomer]

So I reflashed the January firmware, and tuned PIDs, then did two tests. Temperature graph from octoprint looks like below.

Both jobs were killed due to the temperature issue. Even though both temperatures (also read from the printer's display) were fine when the jobs failed.

After some googling, this sounds more like "heating failed" than "thermal runaway". Could it be related to these two parameters?

watch_temp_increase                      = 2
watch_temp_period                        = 20

[classicrocker883]

have you compiled your own firmware? because I will be posting a new release soon.

for now I can post something you can test, the newer updated release has some changes to the temperature files so this may help.

what firmware file do you use? GD32 N32? UBL? MM? I'll make one up.

[tautomer]

have you compiled your own firmware? because I will be posting a new release soon.

Not yet. I have some very limited experience with Arduino and PlatformIO on VS Code. I figured it could take me a few hours struggle to get the firmware compiled for the first time, so I will probably try it out myself when I have a full night free.

My board is N32 with UBL. TIA!

[classicrocker883]

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3t

here u go, let me know how it is

[tautomer]

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3t

here u go, let me know how it is

Thanks a lot for the update, but I still got the same problem.

BTW, I'm trying to compile the firmware (the april branch) myself. While no probe or manual mesh compiles fine, anything with bltouch is too big to fit in the rom. The error message is like

.pio/build/STM32F103RC_voxelab_maple_N32/firmware-20230419-004328.elf section `.rodata' will not fit in region `rom'
region `rom' overflowed by 228 bytes

Even if I add -Os flag, it doesn't seem to change the file size at all.

Branch Mriscoc-2023 works fine though.

Also, if I change the numbers in Marlin/config.ini, the corresponding values in configuration.h and `configuration_adv.h will be overwritten, right?

[tautomer]

I also noticed that this problem seemed to show up exactly the moment the bltouch sensor touched the bed.

Then I can find a ton of results with similar issues on Aquila + bltouch, even without Aquila in the keywords. Weirdly, most of them also suffer from the issue with Alex's firmware, but mine works fine unless I try to build the mesh while the bed is heated.

I will double check my bltouch wiring. For the time being, I can avoid the problem by simply modify my cura settings to heat up the bed first, turn off heating, home all axes, and then enable heating again.

I guess it will make sense to close the issue for now.

[classicrocker883]

I do not thinkj the config.ini has an effect to the configuration.h /_adv.h files yet. or if there is, there must be a certain workflow or action that allows it.

youre so close to compile OK, ~200 bytes is so very little, ive tried disabling the least used options, and for that low amount of bytes you can probably disable #define PREHEAT_2_LABEL "ABS" and the other PREHEAT_2_LABEL's. you should be able to look through any other options that have #define and just comment them out with // , or a shortcut is (ctrl+?/).

in configuration.h - you can disable such as TRAMWIZ_MENU_ITEM, or PLOT_TUNE_ITEM. what plot tune item does is while youre printing something, you have the option to go into the Tune menu and view the Graph of the temperature for the Hotend or the Bed. are you able to view the Hotend PID graph and see if that confirms the same kind of plot graphic with octoprint? that would mean it can be an issue with the octoprint plugin, so what you may do is change the Buffer settings in configuration_adv.h, look for // @section serial TX_BUFFER_SIZE or RX--- ADVANCED_OK ect... u can try messing with those values, or I recall one allows decimal point precision.

so you think this can be related with the Mesh and being heated?

[tautomer]

youre so close to compile OK, ~200 bytes is so very little, ive tried disabling the least used options, and for that low amount of bytes you can probably disable #define PREHEAT_2_LABEL "ABS" and the other PREHEAT_2_LABEL's. you should be able to look through any other options that have #define and just comment them out with // , or a shortcut is (ctrl+?/).

I thought about disabling options, but didn't realize which one could be the safe one that wouldn't break any functionality. The preheat labels are indeed a good one. I actually noticed you disabled it in the test firmware. I will give it a shot tonight.

are you able to view the Hotend PID graph and see if that confirms the same kind of plot graphic with octoprint?

The thing is once the error is thrown, the printer will be killed, so maybe I should be in the graph menu before it crashes and hopefully, I can see the temperature reported the moment before the crash.

so you think this can be related with the Mesh and being heated?

Not exactly, very likely this is some wonky stuff going on with the probe. Some people suspect the sensor will trigger a 0 reading in temperature. So whenever you need a non-zero temperature reading, probing will trigger thermal runaway issue. Both building mesh while bed heating on or homing Z before printing fall into this case. Also explains why I can print if I do something like

G28
M106 S0
M140 S60 
M190 S60
;G28 ;originally here which triggers MINTEMP error
M420 S1
M109 S210 T0

https://www.reddit.com/r/VoxelabAquila/comments/tyke5o/comment/i3swbx9/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/VoxelabAquila/comments/tpxvdy/comment/igcw512/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/VoxelabAquila/comments/12f4hd2/thermistor_dropouts_while_bltouch_probing/

It seems several people had good experience with switching to CR Touch or use the stock firmware (which did work for me as well). I was a little luckier that I could print with certain Alex's firmware, but some people couldn't even get it to work without messing around.

I will double check the wiring of my 3D Touch (I guess it's a knockoff of the "BL Touch") this weekend, but it's more likely just the probe itself. I can't believe so many people all messed up the wiring and are all Aquila users lol.

[classicrocker883]

I will double check the wiring of my 3D Touch (I guess it's a knockoff of the "BL Touch") this weekend, but it's more likely just the probe itself. I can't believe so many people all messed up the wiring and are all Aquila users lol.

yeah for some reason the BL or 3D touch has some incompatibly, i have a CR touch and haven't had any issues. There are some changes in the firmware that has helped mitigate problems using the bed probes. like adding a delay. and some have switched to the stock firmware and reinstalled the new one and it worked fine. if I had to guess, there may actually be a slight difference in where the code begins and ends in the RAM or ROM. for instance is the origin 0x08007000, then it puts out a length minus the bootloader. its possible that Voxelab may have it different than what we have in the source code, maybe not. that is why you see things fixed by reflashing the firmware.

how about after it homes, you unplug the 3D touch. so it seems the issue with thermal errors are related that way. My guess is when there is some interference between those two, thermistor and the bed probe. I saw somewhere someone had put ferrite cores around their BL touch wires. are you familiar with those?? theyre suppose to hinder EMI, electro magnetic interference.

ive seen them use loops around a couple times, and some just clamp right on. i dont know the right or wrong way of doing it, but if youre able to find these laying around, they sell them cheap, or you can always find old electronics youre not using and remove the inductor to use that.

but I say try unplugging the touch after it Homes. also, does the issue come up when you manually set the temp?

[tautomer]

So I compiled the latest commit, and the problem was somehow gone. I really don't know why but I can finally print without messing around with the gcodes. If this problem shows up again, I will try to set the BED_MINTEMP to a negative value and see.

BTW, I guess I found what caused the mesh inset problem, but I'm not very familiar with the proui codes, so I don't know how to fix it.

The source of the problem is the probe offset. I realized it was this variable because 185 (value of mesh max x) + 45 (probe offset) = 230 (the X_MAX_POS you set). Whenever the x offset is given, the x max will be wrong and even if you change the x offset, the x max will remain unchanged. Changing NOZZLE_TO_PROBE_OFFSET to 0, 0, 0 will give the correct x max (210), but once you give an x offset in the UI, the x max will be wrong again and you have to do M502 and reconfigure everything.

The home offset could be used instead to set a correct home position, but it doesn't seem to work in the current firmware. As a result, I have to give a probe x and y offset to print. Hence, I still have to change the mesh x max every time after rebooting.

Hope the information is useful for you to finally fix this mesh x max thing.

[classicrocker883]

again this is good news, im glad to hear its acting as it should. i wanted to ask, have you had issues with the stepper motors? apparently some have heard them more noisy, and it isn't consistent, as in I haven't been able to find out the cause, if it is even firmware related or chip specific.

yes i realize that the x max inset and the nozzle_to_probe_offset are related. the way you explained how to go around it seems plausible but I think its easiest in the readme I explain you must change the x max inset from every restart. its not so much a big issue. the idea is so the probe can reach all of the bed, yet probing a new mesh will account for any points it cannot reach and with good accuracy as I have experienced. so I find 7x7 to work best, because you only end up with the last row of 7 not able to reach, and it automatically calculates what it should be, and you can check it manually if you want, and I can say it checks out! I haven't really tried to see if say a 3x3 or 5x5 lets you probe every point and if mesh inset still isnt what it should be.

otherwise I tried a way around, it reads from the library code no matter what.

unfortunately i have tried a few things, but since this firmware is Mriscoc's and he has his proui library encrypted. I tried opening the "lib/proui.a" files and view them but I wish I knew how, if there is some way to... If i'm able to see that code and to be able to change it... so it has to do with some safeguard i guess, because the code is very much protected, i suppose consider ourselves lucky being able to get what we got, since i heard he was reluctant releasing the source code, and i dont blame him with all his work put into it.

i do converse with him time to time and he does release updates, but thanks for the reminder ill bring this issue back up and see if he will get it fixed for the next update release.

[tautomer]

have you had issues with the stepper motors?

I did see some people reported this issue, so I'm more or less preconceived that it's more noisy than before. I guess I have to flash Alex's firmware back and do a proper comparison. I should have time to check it out this week.

you must change the x max inset from every restart.

Do you know it's possible to change the value via the terminal? I know there is a "C29" code, but it doesn't seem to work once the printer gets the wrong number. I can indeed go to the printer and change it, but now as I use a WiFi plug to auto turn on both Octoprint server and the printer, I really don't have to deal with the printer physically.

I find 7x7 to work best, because you only end up with the last row of 7 not able to reach, and it automatically calculates what it should be

This is totally acceptable. I have only printed such a large model maybe twice.

unfortunately i have tried a few things, but since this firmware is Mriscoc's and he has his proui library encrypted. I tried opening the "lib/proui.a" files and view them but I wish I knew how, if there is some way to... If i'm able to see that code and to be able to change it... so it has to do with some safeguard i guess, because the code is very much protected, i suppose consider ourselves lucky being able to get what we got, since i heard he was reluctant releasing the source code, and i dont blame him with all his work put into it.

Well, I totally understand his choice and hopefully you guys can get it fixed in the future.

[classicrocker883]

yea unfortunately it seems to only happen with the aquila boards, i believe it has something to do with timing/timers and ISR values. if youd like to look through the code, in /src/module/stepper.h youll see ISR_STEPPER_CYCLES and a bunch of other ones, there is a difference between these values and Alexs, so if you want to compile your own firmware I would suggest experimenting with the values of Alexs here

ill probably make a 2nd branch for testing, it is just odd how Marlin changes their values several times even in the past few months. my guess is because these GD32 and N32 are clones, they have different CPU clock speeds, therefore ISR CYCLES may not end up being the same as well, as I haven't experienced problems with the motors using Creality 427. I brought this up over at Marlin issues, and didn't get a full answer.

the only other thing I experienced is when I got myself an aftermarket stepper motor, when I plugged it in, I experienced horrible grinding noises and the motor just stopped working. I swapped the two inner wires of the connector and everything worked fine.

if i had to guess, if those noises and grinding were anything like I experienced, for some reason the pins or something have switched and a simple fix would be swapping those wires, however I still dont think that is likely the same problem and fix, but its possible.

i do think since the stepper ISR CYCLES values are different, putting that back to what Alex had may be the actual right fix.

let me know if you end up doing this, or need help or anything.

[classicrocker883]

update: i did upload IS-steppers-noisy branch and its the same as the newest April one except I changed the ISR values like in Alexs file from above, you should be able to compile and test it out, id appreciate to know how it goes regarding the motors and any noise.

[classicrocker883]

I may have found a way around the Mesh Inset Max X / probe offset issue. in /lcd/e3v2/proui/dwin.cpp look for DWIN_SetDataDefaults() i believe this is what initializes the data when first loading. under #if HAS_MESH append the line

PRO_data.mesh_max_x = DEF_MESH_MAX_X + abs(probe.offset.x);

otherwise if that doesn't correct it.... in /proui/proui.h

  float mesh_max_x = DEF_MESH_MAX_X + abs(probe.offset.x);

or if you notice line ~67 constexpr int16_t DEF_MESH_MAX_X = MESH_MAX_X; . perhaps change the constexpr to something else or remove it altogether. I haven't tested this but thought id throw this out there if youd like to give it a shot.

[tautomer]

update: i did upload IS-steppers-noisy branch and its the same as the newest April one except I changed the ISR values like in Alexs file from above, you should be able to compile and test it out, id appreciate to know how it goes regarding the motors and any noise.

The z -axis motor is indeed louder than before. Here are the videos https://filetransfer.io/data-package/mzHwGbuz#link. I can't turn off the part cooling fans, so my phone mostly picked up the fan noise. If you increase the volume or a good speaker (with bass maybe?), you should be able to hear the noise from z-axis. I had to max out the volume on my phone to hear the stepper noise, but on my computer, the soundbar did a pretty good job.

Alex' firmware is pretty quiet. I guess it's probably related to how fast the printer moves in z? I think Alex' firmware is drastically slower.

Again, I didn't try to print here, just randomly moving z up and down.

[tautomer]

I may have found a way around the Mesh Inset Max X / probe offset issue. in /lcd/e3v2/proui/dwin.cpp look for DWIN_SetDataDefaults() i believe this is what initializes the data when first loading. under #if HAS_MESH append the line

PRO_data.mesh_max_x = DEF_MESH_MAX_X + abs(probe.offset.x);

otherwise if that doesn't correct it.... in /proui/proui.h

  float mesh_max_x = DEF_MESH_MAX_X + abs(probe.offset.x);

or if you notice line ~67 constexpr int16_t DEF_MESH_MAX_X = MESH_MAX_X; . perhaps change the constexpr to something else or remove it altogether. I haven't tested this but thought id throw this out there if youd like to give it a shot.

I tried this, but it's still the same.

Removing constexpr will result in a "multiple definition" error. I'm no cpp expert, but I guess it's because this header file is included many times?

BTW, proui.h doesn't have the probe constructor, so I allocated a new array for the test.

constexpr float DEF_MESH_MAX_X = MESH_MAX_X; // float doesn't seem to do anything
.....
constexpr float offset[] = NOZZLE_TO_PROBE_OFFSET; // allocate offsets
......
float mesh_max_x = DEF_MESH_MAX_X + abs(offset[0]);

dwin.cpp was modified as well, but the inset still behaves the same.

BTW, it seems if the offset <= inset value, the max value will be correct. I compiled the firmware with initial offset set to 0, 0, 0. When I manually change x offset to -3, the x max was still 210, which is right. This agrees with the fact that we have only noticed the problem on x max. y offset is -7 by default, so y max always good.

It behaves very much like this block, even though it was commented out already.

      //#if HAS_BED_PROBE
      // PRO_data.mesh_min_x = _MAX(PROBING_MARGIN_LEFT, probe.offset.x);
      // PRO_data.mesh_max_x = _MIN(X_BED_SIZE - PROBING_MARGIN_RIGHT, X_MAX_POS + probe.offset.x);
      // PRO_data.mesh_min_y = _MAX(PROBING_MARGIN_FRONT, probe.offset.y);
      // PRO_data.mesh_max_y = _MIN(Y_BED_SIZE - PROBING_MARGIN_BACK, Y_MAX_POS + probe.offset.y);
      //#else

[tautomer]

Well, I got the MINTEMP problem again with the N32 firmware you just released. Could you share Configuration.h and Configuration_adv.h you used to compile N32_UBL-ProUI.bin with me? By comparing the configuration files, I guess we can pinpoint which option is causing the problem.

[classicrocker883]

hey sorry for the late reply i dont know why I didn't see the notification until now. yeah here is the config files UBL.zip

some changes may be different from the exact configs I used to compile, but theyre the same none the less. I am working on an updated version since Marlin has updated their source, im working on merging with the new stuff.

perhaps it can fix the issue? but I wanted to ask your PID settings, did you do a PID tune? and/or did you copy your settings from Alex's and try with the ProUI? that can cause the mintemp issue.

so there is another type of tuning you can do, it is called MPCTEMP, you can disable PIDTEMP and enable MPC, youll have to also enable MPC_AUTOTUNE AUTOTUNE_MENU and the MPC_EDIT_MENU options. if you get an error saying PROUI doesn't support, just comment out that error in the file. its compatitble.

it takes a bit more memory so you may have to disable something else inorder so it fits to flash.

as for the mesh_inset issue, I found a way around, and its probably the best were gonna get, unless someone else can look into it, or maybe if I can get a good answer from ChatGPT. I went and tried changing the values of the definitions, but it take the values regardless, like those lines of codes can be totally omitted and it has no effect. what is odd is say you go to set the mesh insets in the LCD screen menu, all the values save except for the Max X, right? but if you go less than the [default value 185], it will save that, like < 184, but not if it goes any higher. so what I did, it should be in the branch now, was apply the mesh limits on startup. basically I arbitrarily set it to

PRO_data.mesh_max_x = X_BED_SIZE - MESH_INSET;

granted you may be stuck with the default value, so if you wanted that to be something else, i could do some more work arounds and probably add a second variable. but for now its better than it was.

[classicrocker883]

Hi I just wanted to mention that I have made a work around pertaining to the Mesh Inset issue with UBL or bl touch probes. it now works as it should. if you want to check it out it's in the latest May branch. I'll be posting the .bin files soon.

[tautomer]

Hi I just wanted to mention that I have made a work around pertaining to the Mesh Inset issue with UBL or bl touch probes. it now works as it should. if you want to check it out it's in the latest May branch. I'll be posting the .bin files soon.

Thanks! I didn't have time to check this thread or my printer at all. There will be a conference in two weeks which I need prepare for. I will probably have some time after that.

Sorry about this.

[Supertommino]

Hi, Same problem on my N32 Aquila X2, every time I start printing, when the 3D touch touches the plate during homing, the printing stops with the error: MINTEMP

[classicrocker883]

its possible that something is causing a short or grounding itself. I had installing a creality 4.2.7 board because if at all it is touching the frame of the printer it shorts itself and causes that error. no damage happens, its just an annoyance. so for me I had to use electrical tape or some kind of insulator along the edges and under the board so it doesn't contact the printer. this may be a sort of similar situation.

you can test this by unscrewing the mainboard and sort of having it hang or loose enough so its not contacting the printer. if the error still happens right as it probes, this may be an issue with the 3D touch itself, or some how causing a short/ground out when the Z probe is triggered.

but also, it may be giving the error because it isn't register homing. that is taking too long to Home. you can test this out if you have your old Z min switch, usually the 3D touches have two different connectors, one with 3 and one with 2 with black and white wires.

so if you can plug the old Z switch into where the 3D touch black and white wires are, when it goes to Home Z, manually trigger the switch.

if you dont get the error then it may be something with the 3D touch, since all I hear are some compatibility issues.

you can also try using a ferrite core around the wires image of what i mean

read up about it here

here is more information https://www.antclabs.com/bltouch-v3

so on the antlabs site, they talk about removing a capacitor which should help with the signal. however I dont recommend this is something to be done but as a last last last resort because its basically irreversible.

what I can do on my end, or what you can do if you can compile your own firmware, is change a couple values such as the delay, which can help with the signal, or force 5v logic level (which im not sure if the board is 3.3v or 5v or doesn't matter - would need to do some research)

im sure if you had a different version of the 3D touch, or something like a CR touch or possibly BL touch this issue wouldn't exist, but those are some tests you can try. I suspect that the trigger isn't being pulled high or low and that triggers a low temp.

[classicrocker883]

// Voltage Setting (if enabled). At every Marlin initialization: // BLTOUCH < V3.0 and clones: This will be ignored by the probe // BLTOUCH V3.0: SET_5V_MODE or SET_OD_MODE (if enabled). // OD_MODE is the default on power on, but setting it does not hurt // This mode will stay active until manual SET_OD_MODE or power cycle // BLTOUCH V3.1: SET_5V_MODE or SET_OD_MODE (if enabled). // At power on, the probe will default to the eeprom settings configured by the user

this is what it says in the code. what ver. touch do you have?

it also says #define Z_MIN_PROBE_ENDSTOP_HIT_STATE HIGH

i can set this to LOW and see if that changes anything

[classicrocker883]

try with HS highspeed mode disabled under Probe settings in Level menu

[Supertommino]

Thanks, I'll try it this week and let you know. My 3D Touch version is 3.2

[tautomer]

try with HS highspeed mode disabled under Probe settings in Level menu

Oh, that makes a whole lot of sense. I can probe with HS disabled. The firmware I compiled had HS mode commented out to save space, and it has been working great.

I can recall that Alex' HS firmware also had a restriction of only working with the original BL touch.

[Supertommino]

Indeed the problem was the highspeed mode, when disabled it works, in the next days I'll try with the original BLTouch and see if it works with that I'll let you know

[classicrocker883]

Indeed the problem was the highspeed mode, when disabled it works, in the next days I'll try with the original BLTouch and see if it works with that I'll let you know

that is strange it does that. I have uploaded a new release, cant say the changes made would make a difference regarding that, but you can flash the new firmware on and let me know. ill look into why high speed mode would make an error. I say change the Extra Probing to a different setting, either 2 or 0, and see if the error still happens.

anyway there isnt a whole lot I can do code wise when it comes to probing because the main code is sort of locked away in the provided Library. however there is a NoPro version you can also test with to see, or Marlin just updated their source code with a more recent ProUI by Mriscoc. that may help a bit since you could post the issue over there and probably someone there would know exactly.

[Supertommino]

I tried the new version, and also the NoPro version but the problem is still there, I also noticed that when homing with HS disabled the nozzle lost temperature, maybe the 3D touch has many problems, the next few days I get the original BLTouch, we'll see if that solves all the problems. Thanks, I'll let you know.

[classicrocker883]

well sounds good! Hopefully that solves it. otherwise if you want what I can do is change those parameters to see if that might help. or I can make a vanilla Marlin version - basically NoPro - to see if the issue remains, that would confirm some things.

[Supertommino]

I have installed the BL Touch and it fixed the problem with HS mode. Anyway, if you need me to test something let me know.

[classicrocker883]

I cant seem to find any real issues, everything seems to be working okay. you have the latest release?
if anything else pops up just post a new issue. for now im merging with the Marlin updates, expect a pre-release soon ill chime in when thats ready if youd like to test that.
nothing of major to make note so far as far as changes go, just optimizations.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[sT4sHi]

I would like to get involved here. I have a N32 board myself and exactly the same problem. I have already used an older Marlin version from alexqzd, the version 1.3.5 works without problems. What I just noticed, when I tried it without HS function, the Min Temp error came only on the second "try". In addition, of course, the Z-axis now stopped at the bottom, since the restart, the BLTouch sensor flashes and the temperatures are both displayed with -14 °C.

[sT4sHi]

Small update: I´ve checked the extra probe option and set this to 3. Actual the auto-leveling works and also printing.

[classicrocker883]

oh yes, I don't know if I may have addressed this somewhere else, but after the May update from MRiscoC's head repo, the HS-mode didn't work as it did.

that is before we were able to set multiple probing to 2. but now that has been changed to "Extra Probing" and won't allow a value of 1. Extra probing means having additional probes. so 0 would me zero extra probes. 2 means two additional probes and so on. however, 1 doesnt want to work. in otherwords, anything but 2 probes will work. so 1 single probe, or 3+ probes is fine, but 2 probes causes the issue.

there is an updated release to the firmware, I believe it defaults to 0 or 2. if at all any other issue related issue exists, just disable HS-mode. but please post another Issue about it.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.