Development/Testing

[Lord-Memester]

Hey, @classicrocker883, making this discussion so you don't have to. Figured the conversation in the compilation issue would be better served as an actual discussion, given that it's sort of what it's become.

I'll put my most recent comment on the issue here for continuity purposes:

I merged the most recent Marlin bugfix into the repo - its 2023-May, its the default. let me know how it goes, ill be working on getting .bin files made.

My own build seems to not die. I've only run the same tuning file twice so far, and I need to change my config back to get the bed back to normal, but I'd say I'm currently cautiously optimistic. LA doesn't seem to have any issues on my printer since the merge, but I haven't tested it sufficiently to say it works for sure.

[classicrocker883]

ok i see what you are saying, so what now?
you said

My own build seems to not die.

and change your config back to get the bed back to normal. could you elaborate? and we can work this out

[Lord-Memester]

I chose the very un-scientific method of modifying a lot of variables at once, so I need to cross-reference my previous versions in the commit history. However, it's late where I am, so it's a tomorrow problem.

[Lord-Memester]

It seems to be working! All of the cube currently pictured has been printed with linear advance on and tuned to a K-factor of 0.198!

[classicrocker883]

this is awesome, look out for further updates, ive been merging with Marlin nearly everyday.

[mindxkilla]

Grid Mesh still doesn't save between power cycles. Running HC32-MM-ProUI.bin 2.1.3c-hc

Otherwise this firmware is pretty awesome, i'm coming from Alex's ManualMesh-3x3-H32.bin and custom dwin set.

[classicrocker883]

yeah it is, were so lucky someone was able to actually make support for the HC32 chip in VS code. ProUI wouldn't be possible without it.

I managed a work around so the grid mesh inset loads a better value. but the inset not saving after restarting is more an issue with auto bed leveling probes. because having a probe takes the offset in consideration and gives a value of the difference, which is not necessary because the grid mesh process automatically accounts for any probed rows - very accurately.

so what I did was make it so it loads the max possible mesh minus the default inset (which is 10, to account for any bed clips).

hopefully Mrsicoc will post an update soon with this fix, otherwise for now my fix is temporary.

have you compiled your own firmware using this? because then you can use the fix set and forget to your own custom value. for your Manual Mesh, is the default max and min values set to 210 and 10? or do you need it to be something else?

[mindxkilla]

My inset is currently set to 0 and 220 since I have a magnetic pei sheet on my x2. This time I was able to recover my mesh by loading setting in the advanced menu tab. I must've missed a step last time, my bad.

I haven't compiled Marlin before. Last firmware I edited was on the Arduino 8 bit chips. Haven't learned how to find certain parameters in VSCode. You're a life saver for that since this UI lets us just change settings (bed size, z height, extruder steps for a different ratio) from the display. And you enabled pretty much the rest in the config file. I'll eventually learn how to compile this.

When this UI becomes compatible with a touch screen I'll be willing to buy one to test it lol. Right now I've got some structural parts I need to print.

[classicrocker883]

the mesh Inset should save on restart, if it's the max bed size.

as for the UI for touch screen, that may not entirely be possible. that's a whole other animal. I looked into it such as compiling for the Aquila D1, and ran into that road block. what would need to happen is someone would need to download the screen making software and basically start from scratch. it would be like translating two different languages. I was able to find the software, but I haven't got a clue how to use it, and on top of that, there isn't really any tutorials, and if there were it would be in Chinese. I'm sure there might be someone out there who could either figure it out or knows what they're doing. since this is open source (not backed by money) id imagine this person would want something because of what is involved.

anyway, it's not outside the realm of possibility, it's just outside what I'm able to do myself.

[Lord-Memester]

I'm trying to figure out how to get the frequencies for Input Shaping using an MPU-6050 and an Arduino Nano. If Klipper can do it with the same IMU, why couldn't an ATmega328P?

I made a post on the Arduino forums about it because of my limited programming knowledge. If anyone here can help establish a procedure and/or code for it, that would be great.

Also a promising section in the Klipper docs that says you can calculate it offline by putting CSV files into some scripts, most of which seem to be located here. The script that performs the autocalibration is here.