Hyperfine bed leveling?  

Re: Hyperfine bed leveling?

Checkout https://shop.prusa3d.com/forum/original-prusa-i3-mk2-f23/firmware-3-1-0-rc2-mk2-multi-material-mk2-s-mk1-t6454.html#p45064

Re: Hyperfine bed leveling?

I used the file from the bottom of the page from the link above. It was 20171014v5-3.1.0-RC1-Hyperfine for the Rambo 13A. The funny thing is I went through the menu and printed a few small things and it worked fine until I turned off the printer and turned it back on. The LCD would be slow and blink on occasion and when pressing the menu button, instead of a chirp from the buzzer, it would be a loud buzz. Pressing the X reset button would make it work normally again. I used another laptop to upload the fw and did the same thing. I had said that the other RC1 file without hyperfine worked normally but it did exactly the same thing except updating the firmware gave no errors. I printed a fairly large piece with that RC1 without hyperfine before turning the printer off and back on thinking everything was fine. I repeated these tests several times. I went back to the RC2 from June I think it was and the printer is back to normal. Now I see where these files are gone now with warnings.

Re: Hyperfine bed leveling?

Hi Ray,

please read my comment above and don't use any 3.1.0-RC1 firmware or be really careful with.

The slow LCD screen is an known issue which was solved after the release 3.1.0-RC1 Check https://github.com/prusa3d/Prusa-Firmware/pull/241

I will upload a new release 3.1.0-RC2 in the next days and let you know my upgrade went.

And as the release says it is a Release Candidate and may have issues. Thanks for reporting. You also can report these in my Github if you think it is build related.

Waldemar

Re: Hyperfine bed leveling?

This is a really great mod and I'm looking forward to trying it out once RC2 is merged in. I just have a question regarding general bed leveling that I wasn't sure where to post. Recently I removed the XY axis from the Z frame and releveled everything, then put everything back together. After some calibration I have a Z height adjustment well within the 1mm margin of error (-0.370), but for the first time I've had to correct my L and R values in the stock firmware beyond the limits of the LCD. I've added the G80 line within my startup script:

G80 L-70 R70 F0 B20

My question is, should the limits of the LCD be taken as a suggestion to further physically correct the bed level, or should I feel ok with +/-70um increments on either side? As it is it's nearly perfect, printing a 5-square calibration file (for LRFB and center leveling) the only thing wrong is the right side needs to be adjusted a hair lower (very minor scraping). I generally don't like needing to go outside the capabilities of the printer, but it's so good right now I'm reluctant to mess with it any further. The fact that the gcode and firmware allow for this is at odds with the LCD constraint, so I'm interested to hear what other people do in situations like this.

Re: Hyperfine bed leveling?

I have read that the sensor targets in the bed could be uneven so your machine may be a perfect build but you can't level the bed all around. I'm looking forward to testing the next hyperfine release as my stock bed correct can't quite reach what I need.

Re: Hyperfine bed leveling?

Also the sensor response can be affected by the frame on the right and the heated bed connection at the rear left.

Peter

Re: Hyperfine bed leveling?

Peter,

Do I understand you?

And then,

Thanks,
Bill

Re: Hyperfine bed leveling?

Peter,

Do I understand you?

be careful with the 3.1.0-RC1 hex files! Prusa mentioned a WARNING that can damage your printer ❗
I removed the hex file from the release because of that WARNING and placed notices in all forum topics where users may have download from.

I messed my Github a bit and it took me a while to get it back in order, hope to get the 3.1.0-RC2.7 release tomorrow or next day published.

Not all branches are up-to-date and so is the Hyperfine-bed leveling, FRS and some others. Please don't compile at this moment from my github.

Check the next days https://github.com/3d-gussner/Prusa-Firmware/releases i will also post it in the forum as it is uploaded.

My printer is printing now and so i cannot test the newest release today anymore.

And then,

Thanks,
Bill

You find also in the release notes some helpful infos, but still the best seams to be https://shop.prusa3d.com/forum/prusa-i3-kit-building-calibrating-first-print-main-f6/hyperfine-bed-leveling--t4330-s110.html#p41311

Waldemar

Re: Hyperfine bed leveling?

Thanks Waldemar,

Somehow I managed to download the zip file but not read the post that went with it. Senior moment maybe.

I will wait for your post.

Cheers,
Bill

Re: Hyperfine bed leveling?

Hi,

got finally the new 3.1.0-RC2 firmware for Prusa i3 MK2/S/MMU with Hyperfine Bed Tuning and Filament Runout Sensor tested and released.
Check my github https://github.com/3d-gussner/Prusa-Firmware/releases for the latest version.

Re: Hyperfine bed leveling?

Hi,

got finally the new 3.1.0-RC2 firmware for Prusa i3 MK2/S/MMU with Hyperfine Bed Tuning and Filament Runout Sensor tested and released.
Check my github https://github.com/3d-gussner/Prusa-Firmware/releases for the latest version.

I was so excited to use this I had to try compiling and flashing before going to sleep! Unfortunately I'm getting this:

avrdude.exe: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude.exe: Device signature = 0x1e9801 (probably m2560) avrdude.exe: reading input file "./fw.hex" avrdude.exe: input file ./fw.hex auto detected as Intel Hex avrdude.exe: writing flash (261406 bytes): Writing | ################################################## | 100% 44.49s avrdude.exe: 261406 bytes of flash written avrdude.exe: verifying flash memory against ./fw.hex: avrdude.exe: load data flash data from input file ./fw.hex: avrdude.exe: input file ./fw.hex auto detected as Intel Hex avrdude.exe: input file ./fw.hex contains 261406 bytes avrdude.exe: reading on-chip flash data: Reading | ################################################## | 100% 33.41s avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x3e1b9 0x79 != 0x72 avrdude.exe: verification error; content mismatch avrdude.exe done. Thank you.

Here's what I did:

1. Clone repository (downloaded as a zip since I was on my Windows desktop)
2. Downloaded Arduino 1.6.8
3. Renamed LCD library (added _ to the end)
4. Added hardware and library folders to the installation directory
5*. Copied stk500boot_v2_mega2560.hex from arduino/avr/bootloaders/stk500v2 to marlin/avr/bootloaders/
6. Copied 1_75mm_MK2-RAMBo13a-E3Dv6full.h to the parent folder as Configuration_prusa.h (verified device version prior to flashing)
6. Opened .ino and verified & compiled successfully
7. Exported as binary, found the .hex file in the Firmware folder as expected
8. Tried flashing, got above error
* I originally downloaded stk500boot_v2_mega2560.hex from this link with the same issue.

Here's the compilation log:

WARNING: Category '' in library Wire is not valid. Setting to 'Uncategorized'
WARNING: Spurious .github folder in 'ArduinoJson' library
WARNING: Spurious .github folder in 'IRremoteESP8266' library
WARNING: Spurious .github folder in 'RTClib' library
Warning: platform.txt from core 'Marlin AVR Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.

Sketch uses 255,804 bytes (99%) of program storage space. Maximum is 258,048 bytes.
Global variables use 6,110 bytes of dynamic memory.


I flashed back to 3.0.12 successfully for the moment. Any advice is appreciated! Thanks!

Re: Hyperfine bed leveling?

Hi,

got finally the new 3.1.0-RC2 firmware for Prusa i3 MK2/S/MMU with Hyperfine Bed Tuning and Filament Runout Sensor tested and released.
Check my github https://github.com/3d-gussner/Prusa-Firmware/releases for the latest version.

I was so excited to use this I had to try compiling and flashing before going to sleep! Unfortunately I'm getting this:

avrdude.exe: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude.exe: Device signature = 0x1e9801 (probably m2560) avrdude.exe: reading input file "./fw.hex" avrdude.exe: input file ./fw.hex auto detected as Intel Hex avrdude.exe: writing flash (261406 bytes): Writing | ################################################## | 100% 44.49s avrdude.exe: 261406 bytes of flash written avrdude.exe: verifying flash memory against ./fw.hex: avrdude.exe: load data flash data from input file ./fw.hex: avrdude.exe: input file ./fw.hex auto detected as Intel Hex avrdude.exe: input file ./fw.hex contains 261406 bytes avrdude.exe: reading on-chip flash data: Reading | ################################################## | 100% 33.41s avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x3e1b9 0x79 != 0x72 avrdude.exe: verification error; content mismatch avrdude.exe done. Thank you.

Here's what I did:

1. Clone repository (downloaded as a zip since I was on my Windows desktop)
2. Downloaded Arduino 1.6.8
3. Renamed LCD library (added _ to the end)
4. Added hardware and library folders to the installation directory
5*. Copied stk500boot_v2_mega2560.hex from arduino/avr/bootloaders/stk500v2 to marlin/avr/bootloaders/
6. Copied 1_75mm_MK2-RAMBo13a-E3Dv6full.h to the parent folder as Configuration_prusa.h (verified device version prior to flashing)
6. Opened .ino and verified & compiled successfully
7. Exported as binary, found the .hex file in the Firmware folder as expected
8. Tried flashing, got above error
* I originally downloaded stk500boot_v2_mega2560.hex from this link with the same issue.

Here's the compilation log:

WARNING: Category '' in library Wire is not valid. Setting to 'Uncategorized'
WARNING: Spurious .github folder in 'ArduinoJson' library
WARNING: Spurious .github folder in 'IRremoteESP8266' library
WARNING: Spurious .github folder in 'RTClib' library
Warning: platform.txt from core 'Marlin AVR Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.

Sketch uses 255,804 bytes (99%) of program storage space. Maximum is 258,048 bytes.
Global variables use 6,110 bytes of dynamic memory.


I flashed back to 3.0.12 successfully for the moment. Any advice is appreciated! Thanks!

Hi,

even Prusa is compiling the firmware with Arduino IDE 1.8.x. I will update the Build instructions later.

Check this https://shop.prusa3d.com/forum/prusa-i3-kit-building-calibrating-first-print-main-f6/compiling-on-latest-arduino-ide-t6211.html#p43518

The new https://raw.githubusercontent.com/ultimachine/ArduinoAddons/master/package_ultimachine_index.json (16 days old) generates just one hex file, which can be uploaded using the Prusa uploader tool. You need to go to Sketch->Export compiled Binary (Ctrl+Alt+S).

If you have a Prusa i3 MK2/s without a Multi Material Upgrade you can download the 20171107v8-3.1.0-RC2_Hyperfine_FRS_1_75mm_MK2-RAMBo13a-E3Dv6full.hex file and flash your printer.

Using the Arduino IDE 1.8.5 I don't get any warnings even with Compiler warnings set to 'More'
Just tried setting the Compiler warnings to 'All' and also no errors.

Here the result:
Sketch uses 246232 bytes (95%) of program storage space. Maximum is 258048 bytes.
Global variables use 6096 bytes of dynamic memory.

Hope that helps,

Waldemar

Re: Hyperfine bed leveling?

Thanks for the quick follow-up Waldemar. I was successful, but a few notes:

- I got that first byte mismatch error even with your .hex file; however, it appears to have flashed successfully.
- My SD card is inserted and the info screen says "Card Inserted", however when I go to the top level settings I get "No SD card". [Edit] This appears to have resolved itself, my card is now properly detected.
- Initially half the HF bed leveling settings are set to -1, the other 0. A quick reset put them all at 0.

I'll mention anything else I notice (tomorrow, I'm going to bed :D). The SD card one isn't a huge deal as I print pretty much exclusively through OctoPrint anyway, but I'm curious if anyone else experiences that.

Re: Hyperfine bed leveling?

I just quickly uplaoded the hex before leaving for work and had no errors this time as I had an error every time with the last hyperfine revision. If I have any issues tonight I'll report them on github. Thanks for all the work 😀

Re: Hyperfine bed leveling?

The SD card issue resolved itself, but there's some strange behavior with the first layer calibration. It first asks if there's filament loaded (there is, so I select yes); it then unloads the filament and beeps until I've reloaded it and click the button. It then loads filament, and then asks if the filament was loaded properly. After hitting yes, it simply goes back to the first step (crossing from one end of the X axis to the other in the process) and unloads the filament again and has me repeat the process. Am I missing something?

[Edit] I had to roll back to the official 3.1.0-RC2 as I can't get past the first layer calibration and I appear to not be able to print without running it.

Re: Hyperfine bed leveling?

The SD card issue resolved itself, but there's some strange behavior with the first layer calibration. It first asks if there's filament loaded (there is, so I select yes); it then unloads the filament and beeps until I've reloaded it and click the button. It then loads filament, and then asks if the filament was loaded properly. After hitting yes, it simply goes back to the first step (crossing from one end of the X axis to the other in the process) and unloads the filament again and has me repeat the process. Am I missing something?

[Edit] I had to roll back to the official 3.1.0-RC2 as I can't get past the first layer calibration and I appear to not be able to print without running it.

This firmware has the filament runout sensor procedure active!

It should be OFF as default, but if the EEPROM value space has been used before and set to 1 or 2 then it expects a connected sensor.

Please read the release notes 🙂

If you don't have a filament runout sensor then go to Settings and set 'Fil.RS [OFF]' otherwise it will expect a connected sensor on y-max (pin 24).

You can check the status of the sensor via:
- G-code M503
- M119
- LCD menu Calibration->Show endstops

Hope that helps.

Re: Hyperfine bed leveling?

This firmware has the filament runout sensor procedure active!

It should be OFF as default, but if the EEPROM value space has been used before and set to 1 or 2 then it expects a connected sensor.

Please read the release notes 🙂

If you don't have a filament runout sensor then go to Settings and set 'Fil.RS [OFF]' otherwise it will expect a connected sensor on y-max (pin 24).

You can check the status of the sensor via:
- G-code M503
- M119
- LCD menu Calibration->Show endstops

Hope that helps.

Thanks again for the response Waldemar. I did check that Fil.RS was set to [OFF] and that it reported as OFF in the Show endstops menu, but I missed the part about the EEPROM value space. I'll try reflashing and giving it a toggle to clear it.

Re: Hyperfine bed leveling?

Thanks again for the response Waldemar. I did check that Fil.RS was set to [OFF] and that it reported as OFF in the Show endstops menu, but I missed the part about the EEPROM value space. I'll try reflashing and giving it a toggle to clear it.

Updated the release notes you may check them.
Strange that your printer started to change the filament having the 'Fil.RS [OFF]'. I tested this firmware quite often and had no issues.
Please let me know how it works.

Re: Hyperfine bed leveling?

Hi waldemar,
just updated my printer with your -all-in-one- v3.1.0-RC2-HF here (used previously your v3.1.0-RC1-All_IN_ONE version) and I had a similar issue with the FRS setting.
after starting a print I ended up in an unload/load filament loop.
so I looked into the settings menu and noticed that the printer was set to "S to Vcc", just the inverted value it had before.

I'm still thinking that my suggested "auto-mode" for the FRS might be a good idea 🙄 .

anyway: a big THANK YOU for providing the HFS releases at your github !

Cheers,
Jeff

Re: Hyperfine bed leveling?

Hi waldemar,
just updated my printer with your -all-in-one- v3.1.0-RC2-HF here (used previously your v3.1.0-RC1-All_IN_ONE version) and I had a similar issue with the FRS setting.
after starting a print I ended up in an unload/load filament loop.
so I looked into the settings menu and noticed that the printer was set to "S to Vcc", just the inverted value it had before.

Hi Jeff,

i tried to simplify the use of the FRS and have chosen to use the same EEPROM space as it was for the 'Fil.Runout S [ON/OFF]' in 3.1.0-RC1-All. Also having as less as possible values in the EEPROM for any new feature.

As you have a Filament Runout Sensor connected and it was ON which means the EEPROM value was set to 1 and this means now 'Fil.RS [S to VCC]'
0 = 'Fil.RS [OFF]'; 1 = 'Fil.RS [S to VCC]'; 2= 'Fil.RS [S to GND]' you got an issue. Somebody with the other type of FRS would be lucky.

Sorry !!! 😳

I'm still thinking that my suggested "auto-mode" for the FRS might be a good idea 🙄 .

Still struggling how to implement an auto-mode for the FRS.
The issue i have is, that depending on what kind of sensor somebody uses, it has to be inverted or not and the internal pull-up must be set or not.
So how can i detect which type of sensor is connected? What if during recognize FRS no filament is loaded?

anyway: a big THANK YOU for providing the HFS releases at your github !

Cheers,
Jeff

That is kind 😉

Waldemar