I was brainstorming on ways to reduce or eliminate the need for wifi to be in the equation at all for maslow4 given it, at least for me, can get disconnected so easily. Since fluidnc (which is what M4 is built upon) is GRBL compatible, could you connect to the Maslow’s USB port and use it like any other GRBL device? I’m thinking about another ESP32, raspberry pi or other more powerful device like a laptop connected directly to the port and not even need to use wifi for normal operations. Then you could use openbuilds control or gcode sender to drive the device…
I’m thinking too that this would open up other user interface possibilities outside the super-constrained ESP32 environment to drive the machine.
Yes!!! 100% excited to hear this suggestion. It solves connection issue and opens the door to the feature rich and free openbuilds control. Openbuilds control will easily allow us to jog the Maslow via wireless joystick or mobile phone. And all of those plugins like JobSizer are soooo nice!
Macros for Maslow specific commands like retract all etc can be added by simple macro, as they are just gcode commands right?
Yes!!! 100% excited to hear this suggestion. It solves connection issue and opens the door to the feature rich and free openbuilds control.
Openbuilds control will easily allow us to jog the Maslow via wireless
joystick or mobile phone. And all of those plugins like JobSizer are soooo
nice!
you can already jog from a mobile phone
due to the fluidnc support, you can connect other devices to the system like a
joystick.
One of the reasons the maslow 4 has wifi and the built-in esp32 based UI is the
problems that we had with the prior versions of the maslow. This is a very
electrically noisy environment, enough that with the controller mounted to the
top of the frame, the interference was making USB connections unrealiable for
many people.
There was also the problem of supporting the Ground Control UI on many different
operating systems (which is why WebControl based on a pi was a very strong
suggestion.
We need to figure out what is going wrong with the wifi connection. Is it on the
ESP side or on the browser side? Are you having problems connecting to the
maslow directly? or going through your home wifi?
Also, since FluidNC is grbl compatible, this should not be affecting cutting.
And at the same time, all the desktop tools that know how to talk to FluidNC
(and grbl) should ‘just work’ if you connect them. The maslow UI is just one
more tab added to the stock FluidNC GUI
Macros for Maslow specific commands like retract all etc can be added by
simple macro, as they are just gcode commands right?
non-standard stuff, not gcode (and possibly not all available by the command
line, currently) the older maslow had B commands for the maslow-specific things,
I think this has a lot of potential, but let me share a few details on how some of this works. So, Maslow-specific commands are not G-code commands, but “FluidNC user commands”.
So, if you connect through USB and open a COM-port, you can run those commands, by sending $ALL for retracting, $EXT for extending and $CAL for running calibration, for instance, and it will run those. However, things like calibration calculator are written in javascript and integrated into webUI. The script that updates the config file after the calibration is there too, as well as probably a few other things.
Understood. I have seen and mostly understand what is in the UI code. In fact @Ethan and I did port over just the calibration functions to a standalone tool (using @Bar’s calibration simulation as a guide) so that we could copy/paste and try the functions with different inputs to visualize what was happening there by taking points out of the calculation, etc. I understand why that might be the best place for them right now, but these functions could also be ported to something standalone that just talks to maslow over a hard wired connection in the same way.
What I’m suggesting maybe starts with more of a hybrid where we can use the connection to run the machine day to day with really any gcode sender (openbuilds, universal g-code sender etc) and only use the maslow’s ESP32 ui to do the calibration or maybe a specialized program to do the calibration and produce a yaml file. I think most senders have “macros” you can use that would allow you to (for instance) set up retract all, extend all, take slack, etc buttons / features.
I also think that going down the path of having the software and hardware somewhat self-contained is understandable and can leverage a connected browser for computing power, but when that connection is over wifi, and the machine needs it to stay alive or report errors, that seems fragile to me.
Also, having it be “just a web browser” means people can use any sort of device to talk to it, but some (like a phone) are maybe not appropriate for all the things. My initial temptation was to use a really old tablet I have but the calibration took ages to run on that so I had my computer inside the house connected and the tablet to kick off the calibration. I “shot myself in the foot” with this, not thinking about the fact that both UIs would be talking to maslow.
My home wifi is not bad, though my garage is near as far as I’d want to go away from my base. I could buy an extender closer to the garage if needed. The bigger issue in my mind is with not having a “dedicated” device driving or monitoring the maslow. Also, the other g-code senders out there have great features we can eventually have / write into ESP32UI (maybe, if the ESP32 memory will hold them!)
So mostly “interruption of connection”. for instance, switching away from the browser to take a phone call, going back and its no longer talking to the maslow.
As you mention, this should be possible without too much trouble, so maybe I’ll just try it and see how it works!
What I’m suggesting maybe starts with more of a hybrid where we can use the
connection to run the machine day to day with really any gcode sender
(openbuilds, universal g-code sender etc) and only use the maslow’s ESP32 ui
to do the calibration or maybe a specialized program to do the calibration and
produce a yaml file. I think most senders have “macros” you can use that would
allow you to (for instance) set up retract all, extend all, take slack, etc
buttons / features.
you should be able to do this already. In the UI the original FluidNC tabs are
still there
I also think that going down the path of having the software and hardware
somewhat self-contained is understandable and can leverage a connected browser
for computing power, but when that connection is over wifi, and the machine
needs it to stay alive or report errors, that seems fragile to me.
I don’t think that cutting a file uses the procesing power of the browser, I
think that’s only for the calibration
I’d be interested to see someone upload a file to a calibrated maslow 4 and then
use the fluidNC interface to cut it instead of the maslow interface. Does that
have the same problem with the browser going away? Given that fluidNC has been
around a bit, I would be surprised.
This would also impact wifi I’d think, right? I think with an adequately shielded usb cable it should be mostly ok.
possibly, but the wifi has a lot of stuff in the protocol to make it resistant
to interference that you don’t have on USB
yes, having a shielded cable will help, but with webcontrol we found the most
effective thing was to make the cable from the pi to the controller short.
My home wifi is not bad, though my garage is near as far as I’d want to go away from my base. I could buy an extender closer to the garage if needed. The bigger issue in my mind is with not having a “dedicated” device driving or monitoring the maslow. Also, the other g-code senders out there have great features we can eventually have / write into ESP32UI (maybe, if the ESP32 memory will hold them!)
So mostly “interruption of connection”. for instance, switching away from the browser to take a phone call, going back and its no longer talking to the maslow.
As you mention, this should be possible without too much trouble, so maybe I’ll just try it and see how it works!
I’m just trying to debug the problem, if you are near max range for your home
network, you may have more communications problems than going direct.
but it’s still a problem for a connection interruption to stop the machine (as I
noted elsewhere)
So I gave it a try. I connected a usb to my laptop and the maslow then used openbuilds to try to connect. It connected, sent the command to see what it was, and failed to detec. I think the constant heartbeat messages are getting in the way, as I eventually retried a few times and it detected grbl. I tried a jog and the maslow just complied all 4 belts for a bit and the machine sank down 100mm or so.
So it definitely sees the serial and can talk to it, but some of the messaging in there might mess it up. I can try other less complex gcode senders and see if I gain traction. I don’t really have a Pi to spare right now, but I may order an orangepi or something and attach a small screen… eventually that is. I’d really like to get some cuts working with what I have first then go after this.
I actually tested using UGS to control the machine via USB a while back and it worked then, but I think that was before I added the heartbeat. I wouldn’t expect that to prevent it from working though because it’s just once a second.
In theory driving it over USB should work at the moment
I actually tested using UGS to control the machine via USB a while back and it
worked then, but I think that was before I added the heartbeat. I wouldn¢t
expect that to prevent it from working though because it¢s just once a second.
If the heartbeat does cause grief, then we should just need to reformat the
heartbeat message so that it matches the grbl status messages that don’t confuse
UGS and similar.
