Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toolbar is functional but invisible; Settings are not preserved over restart #12

Closed
oloendithas opened this issue Dec 25, 2022 · 48 comments

Comments

@oloendithas
Copy link

oloendithas commented Dec 25, 2022

Describe the bug
I have built your wonderful repo for my Aquila S2. Now everything is working, I'm experiencing several bugs:

  1. Toolbar is functional but invisible;
  2. Not any of settings are preserved over restart, except for the bed leveling mesh.

To Reproduce
Steps to reproduce the behavior:
I used the default branch Mriscoc-Fall. Maybe I should use the 2.1.3 tag?
These are configs I build with
Configuration.h
Configuration_adv.h

Should it be visible? May by I disabled some required thing?

Also applied couple of bugfixes:

  1. Raise the nozzle before travel Y on abort. Otherwise it was just dragging the nozzle over the bed:
diff --git a/Marlin/src/lcd/e3v2/proui/dwin.cpp b/Marlin/src/lcd/e3v2/proui/dwin.cpp
index 9fc4e16..9da8f38 100644
--- a/Marlin/src/lcd/e3v2/proui/dwin.cpp
+++ b/Marlin/src/lcd/e3v2/proui/dwin.cpp
@@ -1660,8 +1660,8 @@ void DWIN_Print_Finished() {
 void DWIN_Print_Aborted() {
   TERN_(DEBUG_DWIN, SERIAL_ECHOLNPGM("DWIN_Print_Aborted"));
   #if ProUIex
-    char cmd[21] = "";
-    sprintf_P(cmd, PSTR("G0 F3000 Y%i\nM84"), PRO_data.Park_point.y);
+    char cmd[31] = "";
+    sprintf_P(cmd, PSTR("G0 F3000 Z%i\nG0 F3000 Y%i\nM84"), PRO_data.Park_point.z, PRO_data.Park_point.y);
     queue.inject(cmd);
   #endif
   DWIN_Print_Finished();

  1. Max X/Y for mesh inset was misplaced:

diff --git a/Marlin/src/lcd/e3v2/proui/dwin.cpp b/Marlin/src/lcd/e3v2/proui/dwin.cpp
index 9fc4e16..7cf5b74 100644
--- a/Marlin/src/lcd/e3v2/proui/dwin.cpp
+++ b/Marlin/src/lcd/e3v2/proui/dwin.cpp
@@ -1777,9 +1777,9 @@ void DWIN_SetDataDefaults() {
     #if HAS_MESH
       PRO_data.grid_max_points = DEF_GRID_MAX_POINTS;
       PRO_data.mesh_min_x = DEF_MESH_MIN_X;
-      PRO_data.mesh_max_x = DEF_MESH_MAX_Y;
+      PRO_data.mesh_max_x = DEF_MESH_MAX_X;
       PRO_data.mesh_min_y = DEF_MESH_MIN_Y;
-      PRO_data.mesh_max_y = DEF_MESH_MAX_X;
+      PRO_data.mesh_max_y = DEF_MESH_MAX_Y;
     #endif
     #if HAS_BED_PROBE
       PRO_data.zprobefeedslow = DEF_Z_PROBE_FEEDRATE_SLOW;

diff --git a/Marlin/src/lcd/e3v2/proui/proui.h b/Marlin/src/lcd/e3v2/proui/proui.h
index 46ca6f4..cfe6cb1 100644
--- a/Marlin/src/lcd/e3v2/proui/proui.h
+++ b/Marlin/src/lcd/e3v2/proui/proui.h
@@ -65,7 +65,7 @@ constexpr int16_t DEF_Z_MAX_POS = Z_MAX_POS;
     #define MESH_MAX_X  X_BED_SIZE - (MESH_INSET)
   #endif
   #ifndef MESH_MAX_Y
-    #define MESH_MAX_Y  X_BED_SIZE - (MESH_INSET)
+    #define MESH_MAX_Y  Y_BED_SIZE - (MESH_INSET)
   #endif
   constexpr int16_t DEF_MESH_MIN_X = MESH_MIN_X;
   constexpr int16_t DEF_MESH_MAX_X = MESH_MAX_X;

I hope, this is gonna be useful

@classicrocker883
Copy link
Owner

hey @oloendithas. thank you very much for addressing and helping with any issues. it's much appreciated.

so as for the toolbar disabled, that happens when you change the authors name in the Configuration.h. I see that in the file u provided, that is the case. it should remain whatever it was originally. its not really fixable unless you know how to open and edit the lib files ending .a

as for the mesh inset not saving from restart, I've been trying to figure that one out.

This happens with a BL touch, it subtracts the offset from the max inset in order to make all points accessible by the probe. I believe changing the grid to either 5x5 or 3x3 may solve this, I'll have to check that though. but with 7x7 I find works great, it probes almost all the points except for the right most column but it estimates what those values will be anyway, and pretty accurately BTW.

I'll look at the code and see about updating the files soon.

thanks again.

@classicrocker883
Copy link
Owner

classicrocker883 commented Dec 29, 2022

so for raising the nozzle, I see you added extra and it comes out to 31 characters

cmd[31] = "";
sprintf_P(cmd, PSTR("G0 F3000 Z%i\nG0 F3000 Y%i\nM84"), PRO_data.Park_point.z, PRO_data.Park_point.y);

as u notice the previous code said 21 but it was less than that. I found it was an issue changing it to the actual length. I think it's because of the 'spaces'. the code may need to read spaces as %20so for the new code that should be changed to a greater number than '31' the characters in the command. so it's the characters plus spaces. so it doesn't hurt for having even a higher number.

@oloendithas
Copy link
Author

the code may need to read spaces as %20so for the new code that should be changed to a greater number than '31' the characters in the command

Yeap, it gives me the warning:
'sprintf' output between 28 and 38 bytes into a destination of size 31
but as I'm not a C++ pro (more like a C#), this was just a guess from my part and since it worked with my Y/Z values, I left it like this. Will try to change to 38 and see, if it will clear the warning. Thanks for the clue)

@oloendithas
Copy link
Author

that happens when you change the authors name

That dependency was completely unexpected)) Restored the authors name and now toolbar is visible and even more, thee settings are preserved over the restart. Except toolbar buttons, but I'll hardcode that)

Regarding the mesh settings, I was using the manual mesh setup then. Now trying to connect the 3D Touch sensor, bu not succeeding yet. So now built with AUTO_BED_LEVELING_BILINEAR and GRID_MAX_POINTS_X 7.

@classicrocker883
Copy link
Owner

the 3d touch isn't working? but there's nothing actually wrong with it, just something in the code?

in Configuration_adv.h line ~910 you can try #define BLTOUCH_FORCE_SW_MODE
and BLTouch_Delay

don't enable 5v mode, im pretty sure that may break something. but u can also disable HS mode and see if that works.

@oloendithas
Copy link
Author

oloendithas commented Dec 29, 2022

the 3d touch isn't working? but there's nothing actually wrong with it, just something in the code?

Well, it's a cheap chinese clone, so anything can be wrong. By now it goes it's internal deploy test on start and nothing more. Also, if try to Home, all start moving with vibration and noise. Before I try to access the sensor, they move smoothly.
When I press "Deploy probe" in LCD menu, it raises Z a bit and nothing more. May be some pin number is wrong. Wiring looks correct. Also, I have no idea, what's the difference between last two pins of the BLTouch port (OUT/G) and the actual Z-MIN port. Tried them both, but I guess this will not have effect until IN will work and deploy the probe.

20221229_121808_LMC84

UPD: Just tested the sensor on Arduino and it seem to be working. Maybe some In pin number is not right for my N32 board?

VID_20221229_131116_edit.mp4

@classicrocker883
Copy link
Owner

ahh I see. do not plug it into the Z port. you must remove pins from the connector and put them in the 2 missing in the other plug.

in the firmware there may be a way to enable this so u don't have to do that. but for all intensive purposes u should have all wires on one plug.

a quick look at another connector with all 5 pins shows the black is on the outside, left most in picture.

@classicrocker883
Copy link
Owner

classicrocker883 commented Dec 30, 2022

did I read you DID try that? then I would try the force_sw_mode and delay from previous comment. but what you can do is leave the plugs separate like they are in picture - two in the Z_min port, and in Configuration.h @ line 1284

uncomment

//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN // Probe connected to BLTouch port

and comment

// Force the use of the probe for Z-axis homing
#define USE_PROBE_FOR_Z_HOMING

as an option you can uncomment

//#define Z_MIN_PROBE_PIN PB1

double check that PB1 is the correct pinout. I believe it is since I think I put it there.

@oloendithas
Copy link
Author

Yes, I already tested by multimeter which pin goes to te PB0 of the controller, and it't the fith pin of the BLTouch port (OUT), tried to connect to it, but it doesn't help, because the problem for now is not working servo pin (IN), PB1, if I remember correctly. Did set NUM_SERVOS 1/3, tried to run M280 P1 S10/S90. The prode shaft is not moving. Running out of versions.
Did tried force_sw_mode and the delay. Havent trieb to tinker with #define Z_MIN_PROBE_PIN PB1. In my config it says 32, instead of PB1.
I have some assumptions regarding 5V, but in gives me a bunch of compilation errors and the first one is "cannot be used with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN".
I've seen some guide suggesting to use sw_mode with 5v. Maybe I should try this way.
So, for now the problem is in not working servo IN.

@classicrocker883
Copy link
Owner

@oloendithas also, I updated the code with the fixes u suggested. unfortunately the Mesh Inset resets after printer restart. like it says for X_max 185 (or whatever you have for the probe offset), and say I change it to 210. it changes back to 185 after restart.

ive tried looking into this, but it could be out of reach because of the proui lib.a files which aren't editable. so if you can find a work around, maybe just making a new variable and definition or reference would fix it? but all I know it's doing a recursive link to some equation.

I'd look into proui.h, bedlevel_tools.h, and dwin.cpp.
specifically DEF_MESH_MAX_Y or MAX_MESH_INSET or probe.offset.x

@oloendithas
Copy link
Author

oloendithas commented Dec 30, 2022

As the mater of fact I don't understand, how things are stored into the EEPROM. I haven't studied it yet in the Arduino school of myself) The ones I can see from the M503 command, are stored well. But why, for instance, color settings are preserved only with correct author's name is a total magic for me. I can try to dig in when return after a week.

@classicrocker883
Copy link
Owner

classicrocker883 commented Dec 31, 2022

there is just something the original author, Mriscoc, implemented as a sort of safeguard for those wanting to steal his work. he was reluctant at first to release the source code. so he left a good amount of details out and encrypted them in his special little library in the lib folder.

the toolbar is his making, and without giving him credit as the author, he made it so it disappears. In the tests ive done, when comparing Mriscoc ProUI and the Marlin code he based it off, something about changing the delays made a couple things not work. i think what i did was change the delay for startup and the cr touch i have wouldnt work. anyway, just becareful with changing the bl touch to 5v, and see if u can look up more about what yours might be, because i read the warnings pertaining to changing it from open drain to 5v, and it may damage something so do so at your own risk. good luck.

also, u can check out his repo here https://github.com/mriscoc/Ender3V2S1

mriscoc#509
others may have issues with using the bl touch and post about it.

@oloendithas
Copy link
Author

I have to check first, is this 5v for servo or for Zmin. Because servo out is already giving 5v and the sensor is rated to 5v, but still servo IN is not working. While the Zmin gives 3.3v. I suspect that this 5v feature is for Zmin switch.
I certainly have no intention to steal anybody's work) But still I'd like to have Toolbar settings preserved over reboots, while now it's not. I can't even get, how the items are assigned, to hard code them. I found some item numbers, but changing then gives unpredictable effect.

@classicrocker883
Copy link
Owner

classicrocker883 commented Jan 5, 2023

so by going into Control settings, under setup Toolbar, and changing any of the toolbar buttons to something else doesn't actually save after a restart? I am unable to reproduce this. It is working normally for me, that is I am able to change any of the toolbar buttons to something else and it remains after restart.

remember, that changing the Author in Configuration.h is not recommended. leave this as it originally was #define STRING_CONFIG_H_AUTHOR "Miguel A. Risco-Castillo (MRiscoC)"

in file Marlin/src/lcd/e3v2/proui/dwin_defines.h
under line 94

#if HAS_TOOLBAR
#define TBMaxOpt 5 // Amount of shortcuts on screen
#if HAS_BED_PROBE
#define DEF_TBOPT {9, 8, 0, 1, 4} // Default shorcuts for ALB/UBL
#else
#define DEF_TBOPT {7, 0, 6, 2, 8}; // Default shortcuts for MM
#endif
#endif

changing the numbers in the DEF_TBOPT array will hard code the toolbar on the main menu.

the number represent the order as listed in file toolbar_def.h

@oloendithas
Copy link
Author

oloendithas commented Jan 7, 2023

Working fine for you? That's weird. I wonder, what am I doing wrong.
I tried to tinker with the DEF_TBOPT and it changes the toolbar buttons unpredictably.

The good news! I've finally fixed the probe servo pin. Edited timers.h to have MF_TIMER_SERVO0 = 3, rather than 1.
I don't understand why this works for Ender3 V2, since STM32F103R has the same mapping here. By default PB0 is bound to Timer3 and in board.cpp it's on &timer3 {&gpiob, &timer3, &adc1, 0, 3, 8}, /* PB0 */
image

Why in timers.h it gets #define MF_TIMER_SERVO0 1 // SERVO0 or BLTOUCH and how this suppose to work, I don't get. I can see in datasheet, that it can be redefined to TIMER1, but where and when this should happen?
Anyway, deploy and stow now are working.
The new battle is to make Z stop when the probe's shaft is pushed in. By now it doesn't stop.

Author: oloendithas <oloendithas@gmail.com>  2023-01-07 12:53:51
Committer: oloendithas <oloendithas@gmail.com>  2023-01-07 12:53:51
Parent: 1ac9c445e2713a2725910c3889a3fd343205c0e6 (current MM config)
Branch: master
Follows: 2.1.3
Precedes: 

    fix probe servo pin for Voxelab N32

----------------------- Marlin/src/HAL/STM32F1/timers.h -----------------------
index 0cd807f..8a23186 100644
@@ -80,7 +80,7 @@ typedef uint16_t hal_timer_t;
   //#define MF_TIMER_TEMP       4  // 2->4, Timer 2 for Stepper Current PWM
 #endif
 
-#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3)
+#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3, VOXELAB_AQUILA)
   // SKR Mini E3 boards use PA8 as FAN_PIN, so TIMER 1 is used for Fan PWM.
   #ifdef STM32_HIGH_DENSITY
     #define MF_TIMER_SERVO0  8  // tone.cpp uses Timer 4

@oloendithas
Copy link
Author

Victory at last!
So this 3D Touch sensor is totally now working in SW mode.
The next weird thing was, that following this setting #define Z_CLEARANCE_DEPLOY_PROBE 10 when probing it raises the nozzle on by 10mm, then goes down by 5mm and throws error because it haven't found the bed. Changing this to #define Z_CLEARANCE_DEPLOY_PROBE 5 fixed this problem.

Overall, it took this servo fix and these configs:


----------------------- Marlin/src/HAL/STM32F1/timers.h -----------------------
index 0cd807f..8a23186 100644
@@ -80,7 +80,7 @@ typedef uint16_t hal_timer_t;
   //#define MF_TIMER_TEMP       4  // 2->4, Timer 2 for Stepper Current PWM
 #endif
 
-#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3)
+#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3, VOXELAB_AQUILA)
   // SKR Mini E3 boards use PA8 as FAN_PIN, so TIMER 1 is used for Fan PWM.
   #ifdef STM32_HIGH_DENSITY
     #define MF_TIMER_SERVO0  8  // tone.cpp uses Timer 4

Aquila_N32_ABL_config.zip

Shouldn't I move this all to a new issue with a proper title or it's ok to leave it all here?

@oloendithas
Copy link
Author

Regarding saving toolbar properties: indeed, they a preserved for me, but only if I don't touch the first button which is disabled by default. If I change the first one and restart, weird things happen)

@classicrocker883
Copy link
Owner

in the updated new years version, there are fixes and the toolbar is one of them. I've been testing it out and am about ready to compile some files. so the newer code is labeled Mriscoc-2023 if you want to check it out.

but I'll soon incorporate those other fixes, not need to make another issue. I suppose u could if you have more details to add from here. it's great uve been helping and finding the fixes.

I just wonder if it is board/chip or BL touch specific.

@classicrocker883
Copy link
Owner

MarlinFirmware/Marlin@01e58de

check this out, will this be helpful?

@oloendithas
Copy link
Author

oloendithas commented Jan 12, 2023

New yeary update? Fantastic! Of course I'll try it. Thank you so much for sharing your work!

I just wonder if it is board/chip or BL touch specific.

The MF_TIMER_SERVO0 looks board specific. Still, as I were saing, this Notion controller is an exact clone of the STM32T103. But, on the other hand, the HAL.cpp has a huge new code block for this clone, so I guess, there are some differences. I have superstitions, but my knowledge is poor here

The Z_CLEARANCE_DEPLOY_PROBE looks totally code specific: plus number to go up, minus number to go down. But why than I am the only who have a problem with it then? That's a mistery. I haven't found where this travel down distance is defined, but I wasn't looking too thorough. Actually, I imagine, thet multiple probing procedure with twice longer up/down distance will take almost twice much time.

@oloendithas
Copy link
Author

Regarging mesh inset values, which are not saved over restart, I wonder, if they are used only once for creating a new mesh or all the time during printing with bed leveling on?

Slowly moving to investigate this issue. By now spent the whole yesterday fighting bulging corners. Tried everithing. Close to give up and move along)

@classicrocker883 classicrocker883 self-assigned this Jan 14, 2023
@classicrocker883
Copy link
Owner

the BL touch issue happens to a few, I havent tested how a 3D or BL touch is on a creality 4.2.7 board if there are issues with that. but using a CR touch there are no problems, even on a GD32 aquila board. however, with the GD32 chip, or just G32, the ProUI doesnt seem to work on it. that is some of the extra features do not want to work. but it does fine with the N32 and STM32.

i also notice that anything larger than 256k memory will not work, its suppose to hold 512k, but any firmware larger than half the size it says it can hold will not work - the screen remains black on flashing.

can you explain what you mean by

fighting bulging corners

so i should write this in the Readme and the release page...
when you first turn on the printer and go to Level / Mesh Settings / Mesh Inset you will see Mesh X Maximum
set this to the value that is Mesh Y Maximum (or another value as to not hit the bed clips).
this next part may be optional, but its recommended to do anyway.
so then go back to the Level menu, look for Load Bed Mesh and select it. a status message should then confirm its loaded. (before that, select which mesh from the Memory Slot).

the Mesh Inset doesnt actually save after restart. so it must be done after its turned on every time until the issue is fixed.

@classicrocker883 classicrocker883 removed their assignment Jan 14, 2023
@classicrocker883
Copy link
Owner

did u have to enable BLTOUCH_DELAY 500 with BLTOUCH_FORCE_SW_MODE?

@oloendithas
Copy link
Author

i also notice that anything larger than 256k

Oh, indeed, right wanted to ask about this: if I try to build with UBL, .bin size gets to 239kB and doesn't flash. So staying on ABL for now, for it takes 225kB. But would like to solve this issue also.

can you explain what you mean by

It's like this:
image
But mines are got better now. It's my first 3D and I'm playing with it for a month now, so I'm still new to all this jerks and linear advances)

the Mesh Inset doesnt actually save after restart. so it must be done after its turned on every time until the issue is fixed.

Yes, the thing I was wondering regarding this, is this mesh inset used only for building a new mesh, so it's obligated to set it properly before probing the bed, or it is used during printing, so it should be set every time printer starts?

did u have to enable BLTOUCH_DELAY 500 with BLTOUCH_FORCE_SW_MODE?

Yeap, I tried this combination also. Now I'm having BLTOUCH_DELAY 200. Actually, forgetting to try to disable it and see if probe will work. But with BLTOUCH_FORCE_SW_MODE it strictly refused to work.

@classicrocker883
Copy link
Owner

oh yes I almost forgot about the size limit. having it compile under Maple increases the file size. it can be from the added libraries. when making the 427 firmware, the default_env: STM32F103RE_creality uses 10 libraries and the Maple (STM32F103RE_creality_maple from src/ini/stm32f1-maple.ini) uses 27. this increases in file size, but as far as I've tested, only the Maple env works with the Aquila boards, but maybe it's possible to disable some of the libraries to save space.

what you can do for now is comment out some of the features, like G26. that will save room and u can get UBL to a small enough size. I'll look through at what else can be disabled, in Configuration_adv.h there is NO_WORKSPACE_OFFSETS that can be enabled which may save some memory.

as for your 3D print is good, the lines look straight. temperature may be a little high for hotend, that's what the little blobs/over extrusion can be from. as for linear advance, that is to help with the corners, you see how it is pointy? I don't know if having a default zero (0.00) value means it is turned off, or if it affects prints. u can try doing the Linear Advance calibration, there is a guide to do it somewhere. or u can try and test it out by setting an arbitrary value like 0.40 or 0.20. the purpose is so it will make the corners sharper and straight, not round and pointed.

I noticed that decreased flow % can make the printed cubes have pointy corners.

Yes, the thing I was wondering regarding this, is this mesh inset used only for building a new mesh, so it's obligated to set it properly before probing the bed, or it is used during printing, so it should be set every time printer starts?

when it comes to the Mesh Inset resetting on printer turn on/restart, yes it should be set every time you do both probe for building a new Mesh and before you start a print.

@raybonz1
Copy link

Any possibility of doing this for the Aquila D1 with touchscreen? This printer would be great with your firmware! Keep up the great work!
Thanks,
Ray

@classicrocker883
Copy link
Owner

Any possibility of doing this for the Aquila D1 with touchscreen? This printer would be great with your firmware! Keep up the great work! Thanks, Ray

@raybonz1 if youre able to find out the touchscreen as to what it is, like this one for example
such as if it is exactly like the Ender 3 v2 touchscreen, that would be helpful, and a lot easier to implement and make firmware for.

@classicrocker883
Copy link
Owner

@oloendithas hey so i was able to have my CR touch work with the BLTOUCH_force_SW_mode with the different timing in timers.h, it works either way. so 3D or BL touch may need those specific settings to work. I only have the cr touch so I'm unable to test it myself. but I uploaded a new release https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3b

if u can verify it works for yours i really appreciate that. and thanks again 👍

@oloendithas
Copy link
Author

oloendithas commented Jan 20, 2023

as for your 3D print is good, the lines look straight

Oh, sorry, this isn't my print, just a random Google image demonstrating the term. Mine has got much better, so don't have live example any more) By the way, regarding the Linear Advance: as far as I understand, this depends from material. For instance, calibration on PLA shown 0.07, while on TPU 0.27. Same goes for the ABL mesh for heated bed and for cold bed (for TPU). For now I just store M503 result to .txt files and when switching materials, entering all G29, M851 and M900 commands. Not a big deal, but still. May be I'm missing something?

oh yes I almost forgot about the size limit

Isn't this about those promised 512kB of flash memory for RE models? I thought than .BIN file contains all, what's gonna be flashed. So why the available memory for us is limited. Maybe some bootloader stuff utilizes it?
Will play with .BIN size. Thanks for clues!

if u can verify it works for yours i really appreciate that. and thanks again 👍

Oh, of course I'll try now it. I guess this one: N32-UBL_ProUI_BLT.bin
UPD: testing right now, and 3D Touch works just fine out of the box

@oloendithas
Copy link
Author

A little offtop: finally integrated the Orange Pi right into Aquila's body))
By the way, I've connected it directly to UART pins on the mainboard. Connection to USB was very unstable.

20230120_185914_LMC84
20230120_190538_LMC84

And also added this rocker switch to turn off the main fan (the one on the thermal barrier) during bed probing, for it gives some very clear vibrations. As far as I understood, it connected directly to the main 24V line, so can't be controlled by software. And thus the rocker switch))

20230120_190530_LMC84

@oloendithas
Copy link
Author

By the way, regarding the Mesh Inset: for me X Max and Y min a preserved over restart. Only X Min and Y Max a reset. That is at least point to that some function is implemented, but needs to be fixed.
Trying to look at those .a libs with the Hopper disassembler))

@oloendithas
Copy link
Author

I updated the code with the fixes u suggested. unfortunately the Mesh Inset resets after printer restart. like it says for X_max 185 (or whatever you have for the probe offset), and say I change it to 210. it changes back to 185 after restart.

Let me guess, your CR Touch is installed to the left from the nozzle?
The thing I've realized just now, that the Mesh Inset is saved properly, but subtracting areas, unreachable for the probe. So me probe offsets are: X=24, Y=-25.5, and thus my Mesh Insets are Xmin=24(0+24), Xmax=210, Ymin=10, Ymax=204.5 (230-25.5). So it looks working properly. No?

@classicrocker883 classicrocker883 pinned this issue Jan 25, 2023
@classicrocker883
Copy link
Owner

that is a good idea, to save what you need to so u can change the values with different materials. it seems about right having a different LA value for pla vs tpu or another filament. it's possible to put those in the start Gcode, either in the slicer settings or putting in a custom Gcode.

as for the cpu chips, yes it should be limited to 512k. that is most definitely not the case because anything more than half that will not flash for whatever reason. I'm sure the chip is correct, but I think your right voxelab might have limited it with a boot loader or something.

as for the raspberry pi connection to UART, I'm interested to see how that is done, and if you found some documentation on how to do that or was that something only you just did. even though I don't always use my pi zero 2, I don't think I've had a problem with usb. but having a more secure connection would be a good option to consider, because printing through the pi and a small wiggle of the USB cable will it to lose connection and fail, even halfway through the print. as to why yours may be unstable I would suggest either a different USB data cable, and/or increase the baud rate to 250000 from 115200.

Let me guess, your CR Touch is installed to the left from the nozzle?

Yes, it is mounted using the two holes on the left side of the bracket, using 1 of the metal mounts provided in the kit. for me the value is the same as the default -45.0 in the X, I figure that would be about the same for anyone else.

I was about to say when looking through your Configuration.h files I saw yours mounted differently, and that is why it saved or didn't save the same.

the goal is you want as big of a mesh as possible. the idea of it using the probe offset values to calculate the mesh area is already done when performing the mesh building. so since it is a smaller mesh, it is literally probing a smaller area of the bed. the purpose is supposed to make it so the probe can reach all the points of the grid. but when building the mesh normally with the maximum size, the parts of the bed the probe can't reach are automatically calculated at the end, and pretty accurately. so you can use all of the bed when printing. u can test this by manually doing G29 P1 to build the mesh after selecting maximum mesh Inset. it will leave parts of the bed unprobed. basically you can then manually probe the mesh in those areas using the nozzle like it does for manual mesh (G29 P2). otherwise G29 P3 guesses and fills in the spots not probed automatically.

so the purpose of Mesh Inset is to accommodate and account for bed clips that might be on the edge of the bed. basically you don't want to hit them when printing so you set the Inset by however much u need to be away from the edge.

technically you want the biggest mesh possible to fill the bed. it is just not necessary for the mesh to be smaller just so the probe can reach all the points when it does a good job automatically calculating the points it doesn't actually reach.

you can read up on it here

@classicrocker883
Copy link
Owner

20210819_032351

I too added a rocker switch to the front lol. and since added a red indicator light. underneath are mosfet power modules.

@oloendithas
Copy link
Author

oloendithas commented Jan 25, 2023

but I think your right voxelab might have limited it with a boot loader or something.

Indeed, it's not crushing during flash process. Bootloader just don't accept it. Probably, they use the same bootloader for all models.

as for the raspberry pi connection to UART, I'm interested to see how that is done

Oh, I've just soldered to RX/TX/GND pins of the CH340G USB serial adapter chip) CTS/RTS are unavailable on the controller, so I didn't soldered them.
Screenshot_2023-01-25-11-22-02-968-edit_org mozilla firefox
And yes, now I have a stable 250kb connection. Those MicroUSB ports are most unreliable of all the family, on my opinion. Connection drops after a couple of hours printing were driving crazy.

the goal is you want as big of a mesh as possible. the idea of it using the probe offset values to calculate the mesh area is already done when performing the mesh building.

Hell! Silly me thought I found something) So we want Mesh Inset to be an absolute values, not calculated. I see.

underneath are mosfet power modules.

Why two MOSFETs? I can guis that one for a software on/off. I'm thinking to accomplish this with a relay on AC. But why two MOSFETs?)

@classicrocker883
Copy link
Owner

classicrocker883 commented Jan 25, 2023

as for the PI, did u use the header pins to connect to the mainboard? or use the PI USB port and cut the end of a cable?

the mesh inset values are calculated yes, because they are adjustable. if only I were able to remove the offset from the calculation, or cancel it out. I tried to manually add the probe offset back to the value in the code, but this did not work. maybe I missed something and I can lead you to what I was trying to do and we can solve this together. otherwise I think it is hard coded in the Marlin/lib/proui/stm32f1(gd32f10)/libproui_*.a library.

and yes two mosfets, I got ones just like these here. they are supposed to take the load off the mosfets on the board as to prevent them overheating or melting and causing a fire.

that is why slicers start their gcode with heating the bed or hotend one at a time. having these make it much safer to heat both at the same time.

@oloendithas
Copy link
Author

as for the PI, did u use the header pins to connect to the mainboard? or use the PI USB port and cut the end of a cable?

Yeap, to pin header UART to UART without any conversions.

to take the load off the mosfets on the board as to prevent them overheating or melting and causing a fire.

Built-in MOSFETs can burn? 😨 Hell! What do I know.

@classicrocker883
Copy link
Owner

classicrocker883 commented Feb 23, 2023

Any possibility of doing this for the Aquila D1 with touchscreen? This printer would be great with your firmware! Keep up the great work! Thanks, Ray

@raybonz1 hey I wanted to ask you if you know anything of the touchscreen, I'm wondering if it is the same as the Aquila Pro's touchscreen and the same as the Creality CR-6 who's part number is DMG48270C043_03WTC

if you're at all able to look at the back of the board, take some pictures or write down any relevant part number information, I can see if it's possible to use this ProUI for that printer. I would also need to know the main board's chip. because if the screen is like any of the options in the Configuration.h file, this will be easy to set up for. after that is confirmed, then the other issue would be which DWIN_SET to use. I'm guessing based on how the creality touchscreens look, it's possible to use the same sets.

@raybonz1
Copy link

raybonz1 commented Feb 26, 2023 via email

@raybonz1
Copy link

raybonz1 commented Feb 26, 2023 via email

@raybonz1
Copy link

raybonz1 commented Feb 26, 2023 via email

@raybonz1
Copy link

I don't see the D1 images that I sent via email so here they are. Thanks Andrew!
Voxelab D1 touchscreen
Voxelab D1 Main Board

@classicrocker883
Copy link
Owner

@raybonz1
thank you for the info and the pictures they are helpful. I'll look into seeing if the source code is compatible. looks promising so far. I'll need some time to look it over but I'll report back as soon as I can if it's feasible or not

@raybonz1
Copy link

raybonz1 commented Mar 5, 2023 via email

@classicrocker883
Copy link
Owner

classicrocker883 commented Mar 5, 2023

I just realized that the ProUI may not be the same to work with the touchscreen. the ProUI runs on 480x272, and the touch screen is 800x480. I'm not sure how the layout is setup, if the code would be compatible as to basically copy and paste and change whatever location parameters so it can fit.

the good news is I'm able to get things working as I have what I was looking for, but I'm just not sure how to go about getting the layout to work and be the same or close to it.

I've found tools and programs that would allow me to tweak or create my own display layout and design, but I'm afraid that would take starting from scratch. we're unfortunately getting into something much higher than my (free time) pay grade ⌚. so for now the only hope as to getting an exact copy of the UI to touchscreen would be a simple copy and paste and whatever little tweaks need to be done, otherwise we're looking at starting from scratch and building the DWIN set and layout and design - using the ProUI as a base to go off of.

I bet you can find someone who knows more about this and has experience make such things for DGUS touchscreens. my suggestion is reach out to them and get another opinion.

for now I'll actually see about if I can more or less implement the proui to the touchscreen on my own and find out what else may be needed.

otherwise what I can probably do is give a updated firmware using the newer Marlin versions, so it's not all a total loss.

@raybonz1
Copy link

raybonz1 commented Mar 5, 2023 via email

@classicrocker883
Copy link
Owner

@raybonz1
so there is no real issue I would say, but the concern is how you'd like to control the printer - if you say got a screen with a knob that works with the ProUI I'm not sure if it is the same connections. if u look at the top on the back of the screen, is it that white connector that says RX TX 5V Gnd ect...? if so then it may be possible for a different screen however that would involve cutting wires and connectors, and for how guessing which one goes where. unless the board has the same 10p connector for the lcd as the other boards.

I suggest if you were to keep the board and screen I can enable some features and options that may not already be available on the D1, including the updated version of Marlin, as I can see the source code Voxelab provides is a bit dated. what you can do is pick a DWIN set, like color and layout or keep the stock one.

as for what added features I'm not exactly sure, but for now I can make a firmware file you can flash and try out, let me know how it goes and if there is anything you might wanted to add or change that you couldn't otherwise.

@github-actions
Copy link

github-actions bot commented Aug 8, 2023

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.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants