let’s ask copilot to see if it can identify what went wrong.
David Lang
let’s ask copilot to see if it can identify what went wrong.
David Lang
Here is the March 20th Interstitial release for testing ![]()
firmware.bin (1.9 MB)
index.html.gz (134.3 KB)
Hi all, ive been away for a bit with life things. Catching up on the work and seeing interesting things in the code.
I’m thinking about traditional CNC machines that have dedicated controls and physical buttons and dedicated displays. We are sharing some of the functions between the esp and our client device.
I wonder if introducing a dedicated proxy “controller” might resolve some issues, but adding more complexity. I’m thinking something like a raspberrypi that would proxy host the webpage instead of our device. It would be dual networked to maslow direct and then our personal wifi. It would be physically closer to maslow for reliability.
More of a brainstorming post.
Dano
Makes me think of the Klipper project in 3D printing…the machine firmware for that is pared way down, and the remaining functionality is hosted on a Raspberry Pi. A configuration file determines the specific printer and the Klipper software does all the high-level stuff.
I’m not thinking to move major functions as the software is well developed and far along. I was thinking of a possible solution to add some reliability without significant efforts.
Dano
Dano wrote:
I’m not thinking to move major functions as the software is well developed and
far along. I was thinking of a possible solution to add some reliability
without significant efforts.
How would moving the functionality off of the current chip help?
It’s really only calibration that uses the browser for any calculations,
the current setup is that the fluidNC firmware running on the esp32 makes a web
interface that the browser can connect to. It also hosts a html page that tells
the browser all the fun things to show
There really isn’t much that a second computer like a Pi could do unless you
were to ditch fluidNC for something different.
one thing to keep in mind is that the controllers for the traditional CNC
machines are EXTREMELY limited, but the ESP32 is a dual core chip running at
something like 300MHz, a pretty beefy chip, so it can do a lot more than
traditional controllers.
David Lang
Thanks for the thoughtful response. You know much better the details of the architecture.
A couple of the recent issues appears to be wifi connectivity related. As i understand it disconnects from our browser are causing maslow to hang and proceed in some unplanned path.
I was thinking having a paired browser ie rpi that would connect both to maslow ap and our Wi-Fi to proxy the browser might reduce wifi challenges.
Dano
Dano wrote:
A couple of the recent issues appears to be wifi connectivity related. As i understand it disconnects from our browser are causing maslow to hang and proceed in some unplanned path.
I was thinking having a paired browser ie rpi that would connect both to maslow ap and our Wi-Fi to proxy the browser might reduce wifi challenges.
we would need to figure out the cause of the disconnects (and why disconnecting
causes the problems), and once we do that, we can probably fix things.
If the problem is the wifi disconnecting, it would disconnect the pi as well
there is also a lot of state in the connection between the browser and the
firmware. the process of making the nice UI that shows progress requires a lot
of communication. Once that communication channel is broken (or even if it were
to be lost and then reconnected via a proxy) there will be messages lost that
can cause grief.
It would be nice if there was a simple fix, but the reality is far more complex.
David Lang
I’ve thought about that too and it’s a pretty compelling idea in a lot of ways. One of the big wild cards is that everyone’s computer is different and having a dedicated controller option could remove some variables.
The issue that I keep running into with it is that it would be hard to do without the controller ending up costing as much as the machine which seems like a tough value prop
Designed to give explanation of Red LED errors.
This is experimental, use with caution. I haven’t found any problems, but that doesn’t mean there aren’t any. Built on next release.
firmware.bin (1.9 MB)
index.html.gz (134.3 KB)
Disconnecting encoder cable caused alarm (status Extended). Reconnecting and Taking Slack got it back into operation, did not need to do retract etc. Dropping WiFi caused disconnection while running a file, on reconnection web page showed XYZ movements and I was able to pause, resume and stop (with delay). Graphic was not displayed. Not sure how to force any other errors. I’m going to put it up for testing by any brave souls.
I suggest this is ready for release now, before adding any more changes.
Each time we get to version which appears useful, it is put here for testing. When we are reasonably confident that it is not going to have adverse impact, we release it as a new version. Any improvements can then be added to the new base, followed by another release here. Repeat.
Excellent! I will get 1.12 out today.
I hope you mean v1.20, not v1.12 ![]()
David Lang
Haha yes ![]()