Belts you can buy a 5m roll, thats not the issue. 5’x16’ thats correct. Im crazy to start processing large sheets they are a pain to work by hand.
Ive read that post but lol, having a router its a little different than a pen, for that size. Im currently looking into a proper steel build cnc but at that size i dont have enough arms and legs
2 Likes
I started a thread on the discord here
It sounds like maybe there is a fix in the works
So, I’m not at a point still where I can run my machine for a few weeks, so I’m trying to get some clarification on the net effect of the changes of this commit
What I gathered from the previous posts is that it seems the changes maybe caused the refresh to not work in some scenarios where it previously did. Is this the case or did I misunderstand?
Is the cut down UI appearing in places where it didn’t before, when the machine is not actually moving, like during a tool change (M0 pause)?
If so, if someone can post some details, I’d like to try to pass that feedback on while this is a topic of discussion/development.
2 Likes
I’m a bit confused by that too. I never saw that basic screen until after that change. Supposedly it was doing it before? Maybe I just wasn’t reloading the UI during a job? I haven’t run a real job in awhile (new workshop under construction).
so it looks like there was some rewriting of the index.html.gz files. Does that also affect webui3
no. That’s WebUI 2.
Okay, reading that last little bit really starts to show me how little I know about this stuff. It also sounds like some of teh codebase might be getting a little simplified, that is great to hear. I love elegant improvements. At least in CAD I know if something takes less operations to achieve, it is the better way to do it.
2 Likes
Yea, all that stuff about what memory it’s using for what purposes where is over my head.
2 Likes
Over your head as well?!? Crud, I never stand a chance at learning this stuff. Sounds amazing though. Kinda like magic.
1 Like
I’m used to coding for a computer in C# where I don’t have to care about memory management outside of wrapping some things in a using statement to ensure memory gets released.
I’ve written some basic stuff for Arduinos/ESPs in C/C++ but FluidNC is on a completely different level than something that can operate my garage door opener.
3 Likes
So, here’s a decent explanation I found…
This is from a thread here:
"The ESP32 is based on a harvard architecture which means that there are two buses … one for instructions and one for data. Loosely, address space south of 0x4000 0000 is taken from the data bus while address space (if I remember correctly) from 0x4000 0000 to 0x4FFF FFFF is from the instruction bus.
Now imagine a 64K page of RAM. Unlike in other environments where that page of RAM “just exists” at a fixed address space location, on the ESP32 we have MMU (Memory Mapping Unit) which can make that 64K page of real RAM be mapped to distinct address locations. This means that we can have RAM that can be read from the data bus or have RAM read from the instruction bus.
That then begs the question, what would you put in RAM that can be read from the instruction bus? The answer is (if I understand correctly) … instructions (executable code).
When we compile a C source file we end up with an object file that is then linked to produce an executable. During compilation, the different “sections” of the compiled C are placed in different “sections” of the object file. For example, code goes into the “.text” section and initialized data goes into the “.data” section. By flagging a piece of code with the “IRAM_ATTR” we are declaring that the compiled code will be placed in a section called “.dram.text” (I’m making that up as I don’t have a reference to hand). What this means is that instead of an executable having just “.text” and “.data” sections, there are additional sections. The ESP32 bootloader, upon startup, will copy those “.dram.text” sections into real RAM at startup before giving control to your application. The RAM is then mapped into the instruction area address space (> 0x4000 0000). This means that control can be passed to this code (as normal) from within your running app and it will “work” because the code lives in the instruction bus address space.
What now remains is “why” you would want to do this? The answer is to consider the alternative. If the code you want to run is NOT in RAM, then where else could it be? The answer is “flash” … if it is in flash, then when a request to execute that code is received, the code has to be executed from there. Flash on the ESP32 is much slower than RAM access … so there is a memory cache which can be used to resolve some of that … however we can’t be assured that when we branch to a piece of code that it will be present in cache and hence may need a slow load from flash.
And now we come to the kicker … if the code we want to run is an interrupt service routine (ISR), we invariably want to get in and out of it as quickly as possible. If we had to “wait” within an ISR for a load from flash, things would go horribly wrong. By flagging a function as existing in RAM we are effectively sacrificing valuable RAM for the knowledge that its access will be optimal and of constant time."
“- The ‘cache error’ actually is from the flash cache. This is a bit of memory that is used while accessing the flash: if that bit of memory doesn’t have the info you are trying to read, it’ll try to update itself from flash so it can give the processor the data it needs. However, if flash is disabled it cannot do that, hence the error.”
Which brings us to the FluidNC case…
From Mitch:
" In both cases, the crash is occurring during an interrupt handler. In this case, it is happening in Machine::Motor::step() at the line _driver->step() . In 1322 it is Machine::Axes::unstep() at the line m->_driver->unstep(); . In both cases it is a Cache disabled error, with the target address of a call instruction in A8 whose value is 0xbad00bad. We expect the cache to be disabled during interrupt handlers, but we do not expect an attempt to access FLASH then."
This, at least, assuming the way I read all of that is correct, gives a little insight into what the problem is…
Tracking that down in FluidNC…well, that’s a complicated issue, and part of why I somewhat defend the developers sometimes. This stuff is complicated, and difficult to debug.
I am a total beginner in this area, and just try to follow along with it and learn a bit as I go.
5 Likes
Also, FYI, the author of that post has a book on ESP32…if anyone wants to dig deep into it…
5 Likes
Yeah, it looks like there are multiple intracies at play.
Having to read flash during an ISR is a really bad idea and I’m sure they will need to make that not happen.
There’s also discusison about IRAM with similar limitations.
It goes all the way back to what Jamie observed that there are low level architectural design details that may need to be reeconsidered to avoid the instability and crashing that is happening.
From my total “noob” perspective, it sounds like it needs to disable access to whatever interface elements would cause an issue. I’d much prefer being told, “That option is not available during an active job” and then leave me right where I was, in the job.
It’s a bit more complicated than that…
FluidNC, up until very recently, did not even have the notion of “job”.
Also, it’s not just during a “job”, and is limited to certain types of functions being executed, which happens to be what controls the motion.
There is already a default setting for “Block during Motion”, however Mitch commented that he thought it wasn’t handling all of the cases correctly. After the latest changes, though, it maybe is handling too many cases, but I haven’t gotten confirmation of that yet.
Also of note, the firmware and the interface are 2 completely different projects. So while FluidNC can block FLASH access when it deems it dangerous, it does not control what the UI does.
3 Likes
This. It occurred to me that some of these issues could be prevented by the UI, but using the WebUI we are, it’s limited how much we would want to make custom. Especially, for Mike to keep the FluidNC fork up to date.
2 Likes
Here is the relevant information in the espressif docs… to help understand what Mitch is talking about 
1 Like
I was able to get a few minutes to confirm that at least with the older version I’m running, which should be in the 3.7.12-3.7.14 area, that when a M0 is hit, the machine is in a “Hold” state, and I had no problem hitting Reload on the page 2 or 3 times without seeing the cut down screen.
I probably have the $HTTP?BlockDuringMotion setting as false as well.
If someone has a chance to test this with the latest version, please let me know what you find.
Mitch just put out a pre-release version for testing these fixes.
I guess it was supposed to be a 3.8.4 and not a 3.9.4.
From Discord:
https://github.com/bdring/FluidNC/pull/1349 purports to fix the crashes that have been plaguing recent versions. I have tested that it fixes the crashes, but there are a lot of configurations that I haven’t had time to test, so it would be great if lots of people could give it a try.
In particular, these things need to be tested:
** Systems that use RMT stepping*
** Homing*
** Limits*
** Various spindle types including lasers*
** Well, actually, pretty much everything*
Without this fix, it was possible to induce a crash readily by going to the local filesystem page in WebUI2 and refresing the file list while motors were moving.
I am preparing a prerelease to make it easier for people to test this.
5 Likes
I’ll put this on my JL1 laser sometime this weekend and do some testing there.
2 Likes
I can’t get this pre-release to work and I’m questioning my brain on a Friday after a crazy week. Anyone else get this to work?
Didn’t work from the web installer, so I installed it locally with PlatformIO.
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400e9bab PS : 0x00060530 A0 : 0x800e9c70 A1 : 0x3ffb2160
A2 : 0x3ffd5310 A3 : 0x00000000 A4 : 0x701a74ed A5 : 0x00000000
A6 : 0x3ffb4280 A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3ffb2130
A10 : 0x00000000 A11 : 0x00000001 A12 : 0x00000000 A13 : 0x00000000
A14 : 0x3ffc54f8 A15 : 0x00000064 SAR : 0x00000019 EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000 LBEG : 0x4008bf40 LEND : 0x4008bf4b LCOUNT : 0x00000000
Backtrace: 0x400e9ba8:0x3ffb2160 0x400e9c6d:0x3ffb2180 0x400ed205:0x3ffb21a0 0x400e84fb:0x3ffb21c0 0x400e7f65:0x3ffb2200 0x400ee177:0x3ffb2240 0x40128ea2:0x3ffb2290
#0 0x400e9ba8 in Machine::LimitPin::update(bool) at FluidNC/src/Machine/LimitPin.cpp:73
#1 0x400e9c6d in Machine::LimitPin::init() at FluidNC/src/Machine/LimitPin.cpp:53
#2 0x400ed205 in Machine::Motor::init() at FluidNC/src/Machine/Motor.cpp:38 (discriminator 2)
#3 0x400e84fb in Machine::Axis::init() at FluidNC/src/Machine/Axis.cpp:41 (discriminator 2)
#4 0x400e7f65 in Machine::Axes::init() at FluidNC/src/Machine/Axes.cpp:53 (discriminator 2)
#5 0x400ee177 in setup() at FluidNC/src/Main.cpp:101
#6 0x40128ea2 in loopTask(void*) at C:/Users/jeyea/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:42
2 Likes