I know it does it for each update. My issue was it would reset it after every power cycle. Did you update to 12.0 or 12.1? It may have been fixed by now.
@BluegrassBlaster Just been looking at the GitHub updates that have been committed for what I think will be the next release and I canāt see one for your problem. Might be worth giving them a prompt.
1.12.1 does have WiFi issues, I just toggle WiFi off and then back on and it continues to work. Others report having to renter password, I donāt have to do that (as I dont reselect the SSID) Just do the toggle. I got annoyed enough to dig out long usb extension cable.
I keep seeing this mentioned. For whatever reason mine has no problem connecting to it automatically. I wonder if itās because of the close proximity it has to my WiFi router. Itās only 30 feet away.
I suspect this is wifi system dependent, i have found many weird issues with embedded controllers and even pi on some systems re-acquiring the station. I am pretty certain there is a bunch of dodgy code out there on many embedded systems - but folks rarely have traced it down. I statically addresses the piās having the issue and the thermostat having the issue I had to use a WRT based router deicated just to it. I am, hoping this is just a simple bug in the FreeRTOS like maybe this one Marvell: fix WiFi reconnect issue by AniruddhaKanhere Ā· Pull Request #3267 Ā· aws/amazon-freertos (github.com) or somesuch.
Out of interest do you use regular DHCP or do you set a reservation on your DHCP server?
@scyto If anything, the security on my router is a whole lot more discriminatory of what it will allow to connect, including custom dhcp. That actually makes me wonder if itās the touchscreen thinking the WiFi isnāt secure, it is an android after all, so it may have embedded security instruction to not connect if it thinks itās not secure. Right after turning it on, it probably tries to connect before all command lines have finished loading that would recognize it as a familiar and safe connection. Similar concept to how Windows shows errors in event viewer because it tried to do something before everything finished loading.
But I also donāt know where the WiFi chip is located, whether itās in the touchscreen or the controller.
My Snapmaker looses the password all the time after 1.12.1 and I now only use Octoprint for printing. It was fine before the last update and itās a right pain for CNC and Laser as I used to just use āfile send toā via Wifi and now have to mess about with USB. The printer is in the garage 5m away from a mesh node, the mesh has 18 other wireless devices connected to it as I type this, They are all over the house and garden and I have no problems with anything other than Snapmaker.
I am hoping the next firmware update will fix this as there has been so much noise about it but as itās a touch screen function and the havenāt published the source code or any changes they are working on itās anybodyās guess.
To verify, youāre saying the WiFi is controlled and memorized by the touchscreen? If so, this reinforces a suspicion I have. I just wasnāt sure if it was controller or touchscreen, I assumed touchscreen but I was too lazy to actually verify for myself.
To clarify, Android devices, specifically phones (the touchscreen is technically a phone configuration) have embedded security instructions to ensure that anything they connect to are to be trusted throughout the entire hardware mesh. I got to thinking about this yesterday as I have never had a single problem with my Snapmaker automatically connecting to my WiFi. No matter what firmware I am on.
It caught my attention because I was asked if I am default settings on my router or not. I have my router set up custom on security including DHCP, my router is far more discriminatory to what it will allow to connect, and I have over 30 devices connected at any given time. Yet my Snapmaker connects every time without fail. This spurred the theory that when booting up the machine, an instruction set is happening before itās supposed to (before fully booted and instruction sets that are supposed to come first havenāt happened yet).
Think along the same lines as when Windows boots up, you go into event viewer and you will always see certain errors. This is by design and it keeps trying until finally those instruction sets load and it tells it ok it can connect now. Microsoft does it intentionally to make sure that security measures are working as intended and if it connects before those sets happen it means security is compromised and Windows defender will actually pop up with a message.
Android has similar security measures, only its embedded in the hardware and makes sure everything is secure before it allows connection to something, including WiFi. It might be that itās getting requests back from my router because of my customized security before it normally would on a default set router.
Unfortunately I cannot confirm this because, as you said, the touchscreen is the one thing they havenāt let us see the source code for.
There are commits in the code base that imply the wifi may actually be an ESP32 microcontroller - but i am not sure as the code profile for an ESP is not present when one digs. So who knows what is actually doing the wifi 
has anyone cracked the lid on the controller to see if there is ESP32 or some other wifi micro controller?
This is a Marlin commit, prior to Snapmakerās modifications: [2.0.x] ESP32 WiFi interface by grownseed Ā· Pull Request #11209 Ā· MarlinFirmware/Marlin Ā· GitHub
@WilliamBosacker is correct: no wifi or bluetooth in the controller: Snapmaker2-Controller/Hardware-Link.md at main Ā· Snapmaker/Snapmaker2-Controller Ā· GitHub
thanks, was wondering that, they seem to have a bunch of redundant marlin stuff hanging around - also makes me assume they have done little to bring common fixes across from marlin once they branched? some of those dates are super oldā¦?
@scyto @brent113 this further backs up my suspicions. I really wish I had an extra touchscreen to dissect. Seeing as I have the proper equipmentā¦
1 Like
They cleaned up a lot of it, but the way Github works, you can see the entire commit history. Youāre looking quite far back. Many of the files that are not needed have been removed from the tree.
100% accurate, no Marlin fixes have been brought in. No new Marlin features either, like inline laser power. Iāve been working on bringing that in.
Does anyone know if the bug with M92 resetting every power cycle has been fixed? It started with v12.0, but I donāt know if it has been fixed yet.
I dont know much about that, but is there a reason you cant put it in your start gcode?
I suppose bug isnāt the right word. I guess feature would be more appropriate. Without it, all the calibration values reset every power cycle. Iām running 11.4 now, because it still provides that. This is specifically what Iām referring to:
Theyāre being saved fine prior to a power cycle. I know an update resets them, however it resets after every power cycle.
Yes I can confirm this seems to be the same on my machine.
I just noticed something odd.
I re-set my xyz esteps with M92 to the value i had used successfully to print an xyz cube last week.
I looked at my M420 V values and they were in the ~6.03 mm to ~7.58 mm as usual.
I then did a calibration of the bed from the touchscreen.
I then looked at the M420 V values and they were in the ~0.48 mm to ~2.06 mm range
I started a print and i noted the nozzle was lowered below the build plate by about maybe 1mm (i hit the power button pretty darn fast before the nozzle got to start temp!)
I think i may have found the methodology that cause head crash last week or so - be careful folks.
This seems to be only an issue if one does calibration AFTER setting xyz esteps.
āupdateā
Given this is a machine damaging issue i filed a github issue
2 Likes