Forgive my ignorance, but is that different than
" The integrated SPI flash is connected to GPIO6, GPIO7, GPIO8, GPIO9, GPIO10 and GPIO11. These six pins cannot be used as regular GPIOs."
listed for the current board we use?
Edit: I see…nvmd. I didn’t realize that was the FluidNC wiki. Disregard that question…I’ll read some more
I have no idea what the differences are. I used what I was told (other than genuine). I assume that means it uses those plus some more to access even more memory, like a computer???
We do not use those pins on the jackpot.
I am really most interested in exactly what is triggering your issues and how to replicate them.
I have zero clue what is going on in those boards. I just learned i2s is even a thing, making the jackpot. I am electronics self-taught. If I have to learn something I can but that takes time.
We are probably a few over 100 jackpots out there and I am not hearing memory issues from anyone (but you two, both using STA). If you are having them I really want to figure out how to trigger it and see if it happens with a new board. We really might be fighting a dud board. Making everyone from here on out pay an extra $7-$10 per jackpot because you have a board with bad memory is not a good idea. I really want a test.
If we have a test, I can test every board before it leaves or make the switch to genuine or fund the fluid guys to get a board with more memory.
I don’t have memory issues anymore after switching to STA. It was only in AP mode. But I also have only used the machine sparingly.
Either way. Do you have a test procedure I can follow to replicate it in AP mode. If that doesn’t work let me send you another board. The last test you had me run did not cause an error on my end, does it still cause an error on your end? If so that sounds like an esp issue.
I am really not interested in testing STA mode, I do not plan on offering my support for that mode and never have. I can not account for home networks, I do not know enough about that. I feel my time is best spent elsewhere.
(Sorry, I got a phone call and got pulled away)
Maybe let’s back up. I’m going to try to clarify some things, but I don’t want it to come off the wrong way, as I think it tends to do when you can’t actually speak to someone.
My test procedure was nothing but turn on the board, wait for it to boot, connect, then run a job. In AP mode, I was consistently getting low memory warnings. It got a little better after upgrading to 3.7.8. And then it got a little better changing to the newer config file.
Then it went away moving away from Auto Poll in AP mode.
But in STA mode, my preferred mode of operation, I have not had any issues even with AutoPoll on. Since this is the way that the FluidNC guys suggest to run it, I think it’s best for me to go that route.
I honestly don’t know enough about it to know why mine immediately got low memory warnings and yours didn’t running my file.
I honestly only took an interest in looking into it because I saw there was such a big issue with memory in the beginning.
You are wanting to tell everyone to remain in AP mode, which the FluidNC guys say not to because it causes memory problems. From my standpoint, I felt like if we(as a group I’ll include myself as I intend to be around for as long as I’m welcome) are going to be hearing from people having low memory and job crashing problems due to AP mode (according to FluidNC developers), then it might be worth the effort to do a test to see if it was possible to get a board with more memory to alleviate the potential issue that the FluidNC guys say exist.
I was going to do this test myself for my own knowledge as well.
The only issue I see with that is that you may be doing a lot of fighting to get the exact optimal specs to run under and you don’t get low memory warnings, but if one thing changes, then what? What if FluidNC becomes slightly less efficient in a future release and now all of the AP modes have memory problems and none of the STAs do?
The $7 was to go from knockoff to genuine, which I think is probably a good idea if there’s a high failure rate or people are struggling to get connected etc., but not necessarily purely for memory.
I was looking more at the standpoint of increasing the memory so that there was less of a chance of an issue even if you stay using AP mode, which the FluidNC guys recommend against because of memory issues. If getting the same quality board you have now with 8MB instead 4MB of PSRAM was a matter of say $0.50-$1, then it seems to me it would be worth it if it meant you didn’t have to be running the most optimal config to not have warnings, or at least to give some potential room for growth.
If you are staying with knockoff, then there may be a pretty small increase for that memory. I don’t really know. I was just curiously looking and trying to understand the differences between all of the boards.
I’m not trying to cause you to do anymore work or complaining about a problem with my own Jackpot. I work in software and deal with a very memory sensitive application, so it piqued my interest to dig into why this software(firmware) was dealing with low memory on this board, and what the actual limiting factor was.
I’m aware Bart had a similar board so was just curious to see what he was using vs. what we are using, and whether people have the same issue with his or not.
I’m happy to do any tests with my board if you are just curious to figure something out, but as far as my current use, I have no complaints.
I’m sorry if I wasted your time or frustrated you in any way, that wasn’t my intent. I just was a bit curious and I like to learn things and fix things.
I hear you, I promise. You have said yourself you are no longer having issues in either mode. If anything changes I will look deeper into it.
That is my point is now it no longer happens to either of us. I have made adjustments to the configs and new firmware. I am not worried about it anymore until we see new reports on current configs.
I am wondering this exact thing. If we have a test or a debug mode to prove numbers, I am sure it would get a lot of eyes. Until we can cause an issue repeatably, there is no way to even test if anything we do makes an improvement. No use throwing time or money at something we can not test. Yours booting up into a memory issue is not normal and I am concerned you are basing all this off that. Even though yours now works as expected in both modes that first taste has made you hypersensitive to it.
It is not a waste and I appreciate your concern and expertise.
I think I remember the FluidNC guys recommendation to stay away from AP mode was not empirical but was based on the logic that the AP mode is “doing more work” in hosting the access point and watching for clients etc. But AP mode doesn’t run SSDP. I found SSDP causes a large momentary drop in RAM every 60 seconds which is the worst kind of memory consumption. SSDP is only in STA mode.
Previously it was always-on, now there is an option to turn it off.
So even though AP mode is theoretically “doing more work”, STA has its own baggage and I wouldn’t have high confidence that AP mode is actually worse like the FluidNC guys say.
I wish there were a deterministic stress test that could determine the amount of headroom in different configurations. It’s really hard when everything is anecdotal and even my own crashes when I’m stressing the system are not conclusive.
There are esp functions to measure free memory. One for all time (since boot) min free memory (high water mark)…one for instantaneous free memory.
I use these in my esphome devices. They publish these stats and I can graph them!
Maybe you can add that to publish in a special message to the serial port, or just add a gcode to make it query it and print it back out on serial.
This is one of those things that can affect the results. Just adding this capability can reduce your free memory. And you will only see the instantaneous free heap while it is querying it. So you won’t ever catch the max.
I was just looking into the same thing.
I’m not set up to debug this yet, but I may order a spare ESP32 to test with.
They already report this when the memory is low. So it seems maybe on some interval just reporting the free memory regardless if it’s low or not should give some rough stats on how things change after boot with different settings.
The FluidNC guys, as far I could tell, were basing their recommendation on saying they had evidence of a memory leak in the AP mode wifi stack. It’s repeated by them quite often across github and discord.
Sorry I have a note to add this to the docs. keep getting busy. Does this make it harder to find in STA mode? Should it always be off in the configs or yaml and someone only enable it if they need?
Heck just to see an at idle number should help right. Just get a moving average over half an hour or some number and compare the two? Or some other baseline. I will see if I can figure out how to make it happen.
It’s required true if you want to access it using http://fluidnc.local/
If you are using the IP address to connect, it’s unnecessary. Setting to false means IP address is the only way to connect in the browser.
I really see no reason for it unless you are also using DHCP.
That is good to know, Last time I tried that I needed to add bonjour I think for it to work, so I never bothered to use that either (fluidnc.local).
I am hesitant to try and take it away in the setting then. If someone reads the fluidnc wiki they might expect it. I guess it is just best to add a note to our instructions about the memory hit and suggest not using it.
For as much as they complain about not having enough time to document things properly, I actually find the FluidNC wiki to be pretty good about explaining all of the settings, etc.
A note was added about it when Jamie added the option (I presume by him)
I didn’t add it to the docs. Cool that they are keeping on top of it!
Their wiki is on point, I think Bart might even edit them before he merges a PR. I aspire to be even half that thorough.
Just FYI, I was digging through the FluidNC code and came across this function.
You can issue this at any time and it will show the current free memory as well the lowest it got.
$heap
[MSG:INFO: Heap free: 70532 min: 51064]
This should make it easy enough for anyone to test config changes and how they affect memory usage even without custom firmware
$Heap
[MSG:INFO: Heap free: 35988 min: 14504]
Hmm… Mines a little lower than yours LOL
That was just FluidNC running on a spare ESP32 with default config
Nice find, I am very interested to check that out.