Toolbar is functional but invisible; Settings are not preserved over restart #12
Comments
|
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 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. |
|
so for raising the nozzle, I see you added extra and it comes out to 31 characters
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 |
Yeap, it gives me the warning: |
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. |
|
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 don't enable 5v mode, im pretty sure that may break something. but u can also disable HS mode and see if that works. |
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.
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 |
|
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. |
|
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
and comment
as an option you can uncomment
double check that PB1 is the correct pinout. I believe it is since I think I put it there. |
|
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. |
|
@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. |
|
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. |
|
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 |
|
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. |
|
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 in file Marlin/src/lcd/e3v2/proui/dwin_defines.h
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 |
|
Working fine for you? That's weird. I wonder, what am I doing wrong. The good news! I've finally fixed the probe servo pin. Edited timers.h to have MF_TIMER_SERVO0 = 3, rather than 1. Why in timers.h it gets |
|
Victory at last! Overall, it took this servo fix and these configs: Shouldn't I move this all to a new issue with a proper title or it's ok to leave it all here? |
|
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) |
|
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. |
|
check this out, will this be helpful? |
|
New yeary update? Fantastic! Of course I'll try it. Thank you so much for sharing your work!
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. |
|
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) |
|
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
so i should write this in the Readme and the release page... the Mesh Inset doesnt actually save after restart. so it must be done after its turned on every time until the issue is fixed. |
|
did u have to enable |
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.
It's like this:
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?
Yeap, I tried this combination also. Now I'm having |
|
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 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 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.
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. |
|
Any possibility of doing this for the Aquila D1 with touchscreen? This printer would be great with your firmware! Keep up the great work! |
@raybonz1 if youre able to find out the touchscreen as to what it is, like this one for example |
|
@oloendithas hey so i was able to have my CR touch work with the if u can verify it works for yours i really appreciate that. and thanks again 👍 |
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?
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?
Oh, of course I'll try now it. I guess this one: N32-UBL_ProUI_BLT.bin |
|
A little offtop: finally integrated the Orange Pi right into Aquila's body))
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))
|
|
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. |
Let me guess, your CR Touch is installed to the left from the nozzle? |
|
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.
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 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. |
|
I too added a rocker switch to the front lol. and since added a red indicator light. underneath are mosfet power modules. |
Indeed, it's not crushing during flash process. Bootloader just don't accept it. Probably, they use the same bootloader for all models.
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.
Hell! Silly me thought I found something) So we want Mesh Inset to be an absolute values, not calculated. I see.
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?) |
|
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)/ 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. |
Yeap, to pin header UART to UART without any conversions.
Built-in MOSFETs can burn? 😨 Hell! What do I know. |
@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 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. |
|
Hello Andrew,
Sorry I took so long to get back to you. This is an N32 board and attached are the pics of the main board and the display. Hope this helps!
Thanks,
Ray
From: Andrew ***@***.***>
Sent: Thursday, February 23, 2023 3:44 AM
To: classicrocker883/MriscocProUI ***@***.***>
Cc: raybonz1 ***@***.***>; Mention ***@***.***>
Subject: Re: [classicrocker883/MriscocProUI] Toolbar is functional but invisible; Settings are not preserved over restart (Issue #12)
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<https://github.com/raybonz1> hey I wanted to ask you if you now 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.
—
Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUIYXMNBCCGBLLA5DHAPPRTWY4PMVANCNFSM6AAAAAATJE3HTY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Hi Andrew,
Did find this at Ali Express.. Probably same screen minus the Z15 at the end of the model number.
***@***.***
From: Andrew ***@***.***>
Sent: Thursday, February 23, 2023 3:44 AM
To: classicrocker883/MriscocProUI ***@***.***>
Cc: raybonz1 ***@***.***>; Mention ***@***.***>
Subject: Re: [classicrocker883/MriscocProUI] Toolbar is functional but invisible; Settings are not preserved over restart (Issue #12)
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<https://github.com/raybonz1> hey I wanted to ask you if you now 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.
—
Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUIYXMNBCCGBLLA5DHAPPRTWY4PMVANCNFSM6AAAAAATJE3HTY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Andrew,
Finally, this is the link to the D1 source code: https://github.com/Voxelab-64/Aquila_D1. The touchscreen at Ali Express is same number except for a Z15 at the end of the part number. That is encouraging. Good luck and thanks for taking a look 😊.
Ray
From: Andrew ***@***.***>
Sent: Thursday, February 23, 2023 3:44 AM
To: classicrocker883/MriscocProUI ***@***.***>
Cc: raybonz1 ***@***.***>; Mention ***@***.***>
Subject: Re: [classicrocker883/MriscocProUI] Toolbar is functional but invisible; Settings are not preserved over restart (Issue #12)
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<https://github.com/raybonz1> hey I wanted to ask you if you now 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.
—
Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUIYXMNBCCGBLLA5DHAPPRTWY4PMVANCNFSM6AAAAAATJE3HTY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
I don't see the D1 images that I sent via email so here they are. Thanks Andrew! |
|
@raybonz1 |
|
Great thanks Andrew.
From: Andrew ***@***.***>
Sent: Saturday, March 4, 2023 5:59 PM
To: classicrocker883/MriscocProUI ***@***.***>
Cc: raybonz1 ***@***.***>; Mention ***@***.***>
Subject: Re: [classicrocker883/MriscocProUI] Toolbar is functional but invisible; Settings are not preserved over restart (Issue #12)
@raybonz1<https://github.com/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
—
Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUIYXMILIO6MJ5I3F6XKCLLW2PCJRANCNFSM6AAAAAATJE3HTY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
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. |
|
Hi Andrew,
Thank you for your time. So the main control board is OK but the screen is the issue? Would another screen solve this problem and if so what screen would be needed? I can live without a touchscreen and so can many other people.
Thanks,
Ray
From: Andrew ***@***.***>
Sent: Sunday, March 5, 2023 4:00 AM
To: classicrocker883/MriscocProUI ***@***.***>
Cc: raybonz1 ***@***.***>; Mention ***@***.***>
Subject: Re: [classicrocker883/MriscocProUI] Toolbar is functional but invisible; Settings are not preserved over restart (Issue #12)
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.
—
Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUIYXMNULNUBZOFH6WY75QDW2RIX3ANCNFSM6AAAAAATJE3HTY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
@raybonz1 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. |
|
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. |
Describe the bug
I have built your wonderful repo for my Aquila S2. Now everything is working, I'm experiencing several bugs:
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:
I hope, this is gonna be useful
The text was updated successfully, but these errors were encountered: