Yes, you are right. Auto-reporting, FluidNC sends reports to the UI with the UI not asking. Polling means the UI makes individual requests for each report.
I think auto-reporting is probably slightly more efficient, but if the UI hangs a bit, the reports keep coming and jam up the web socket and maybe buffering blows the memory. With polling, if the UI hangs a bit, it is somewhat self-correcting because the requests stop coming.
Which branches/repos are you using? Sorry if this was shared already.
I am running directly from main which at the moment matches release 3.7.5.
I have a couple of local hacks for instrumentation but nothing that I think would alter the behavior.
Congrats on finding some bugs! Super excited to see how this works out.
Sort of sounds like we might just be using one core for everything right now?
Has anyone configured a Z proble on FluidNC?
I’m trying to set the Delta Z accoridng to the doc, but I think the gcodes are note supported
- The way I have started to do this is Home and probe twice on each side. So G28 Z0, G38.2 Z0, M114, G28 Z0, G38.2 Z0, M114, Then move over G0 X1250, G28 Z0, G38.2 Z0, M114, G28 Z0, G38.2 Z0, M114. From there subtract the average of both sides, M666 Z0.5, M500. Then test again. G28 Z0, G38.2 Z0, M114, G28 Z0, G38.2 Z0, M114, Then move over G0 X1250, G28 Z0, G38.2 Z0, M114, G28 Z0, G38.2 Z0, M114.
M114 will return
ERROR:20
Unsupported or invalid g-code command found in block.
And M66 Z0.5612 will return
ERROR:23
G-code command in block requires an integer value.
For Y axis, I used the little screws to mecanichally adjust the squareness, but I can’t do this on the Z axis because the switch won’t hit the little screws, had to print and install Doug’s boots to make contact
Was that supposed to be M666 Z0.512
M66 is a “Wait on input” command.
M666 is an endstop adjustment code. Initially intended for Delta printer homing, I think, but works for dual endstop squaring.
Sorry about that, that was a typo, I used M666 indeed, same result
The offsets are set in the config section or file and you can save it with the macro I made.
“mpos_mm: 0” or “pulloff_mm: 5.000” I forgot and need to test it again.
Config Homing and Limit Switches | Wiki.js it is pulloff_mm: 5.000 setting different values for each stepper will square it up.
Logical once you know it!
Thanks!
Yeah everything is just a little different. Luckily the wiki is really good and the search has saved me a bunch. It is good enough I am actually enjoying learning it, I don’t have to go to a bunch of sites to figure things out.
Update: it looks like adding a second UART, which is required for my pendant, is a significant contributor and explains why my setup is getting so many more crashes than others.
I had expected another UART to be “trivial” and this was a mistake on my part to make that assumption.
Now at least I know why the FluidNC devs are not running around in a panic over FluidNC crashing so easily: it crashes slightly less easily for everyone else without the extra UART.
So when do you sleep? or dont you. I saw your timestamps over on discord!!
Also, I saw the pre-emption note, I think there may be more there, just that the increased resources uncovered it. The memory thing has been there quite a while!
Okay I have another update on the USB-c versions. I got in another batch and they work fine, So I messed with the old ones that do not work and I caught an error message I had not seen before. A second flash and they work fine!! That is awesome. That means I have a bunch of esp32’s now and a whole bunch of Jackpot Boards in process. Heck yeah, We are going to have inventory soon!!
That’s awesome! Always good when you can make the others usable!!
Always curious… what was that other error?
No idea, ahahahahah.
“[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
./components/esp_littlefs/src/littlefs/lfs.c:1229:error: Corrupted dir pair at {0x0, 0x1}”
I never saw it because it scrolled off the screen. For some reason, I saw it before it got away. Happens on every one I tested, I have even flashed several of them multiple times including an erase and it was still there. Odd. Mitch has some of them, and I showed him the error. Not sure if there is anything they can do or maybe if they can add a pause if that error pops up or something.
I just know flashing that part twice in a row fixes it. I will do some more testing on them next week. I am taking a little 2 day break this weekend.
Yeah right, last time you said that you were in here each day, LOL
Hope you truly do get away!
I always check in over coffee at least, but I won’t have any of my toys to do any testing.