I will admit, I’m still setting up my Maslow CNC and I am using Web Control on it’s own to prevent getting used to software that may not work when Python 2.7 goes into the abyss. I am having a problem calibrating the machine using it’s own stuff. I’ve used a tape measure to the best of my ability, but I have a feeling I’m going to end up with a system that can’t cut straight. Can you put some resources into developing the calibration functions that are in ground control? An example, I can’t find where I can cause one motor to extend by a particular amount. I can get the tooth to go straight up for each motor. Maybe on that page, add the extend/ retract features for each motor too, as well as the measure the distance between motors feature.
Or…someone please reply to me with specific instructions how to do this operation in Web Control 1.27.
After you set sprockets vertical, you press ‘Define Zero’. This tells the controller that the chains are at zero length. Then the ‘Extend Left to xxxx mm’ and ‘Extend Right to xxxx mm’ will enable and you can press them to extend the chains the particular amount. xxxx is the value that is in Advanced Settings->Extend Chain Distance. Default is 1651 mm for a 10-foot beam. I use 2032 mm for a 12-foot beam. I’m thinking I need to include something in webcontrol to determine this value automatically.
As for measure distance between motors, I’m not a fan of that process. Besides leading to an enormous amount of confusion during the guided calibration process in ground control, its been my experience that the distance measured is not as accurate as the distance measured by hand.
I can certainly understand the frustration. I do not plan to mimic ground control’s guided calibration process. My hope is that documenting the process clearing would be sufficient. And yes, the documentation is lacking… it’s not hard to put together documentation, just time consuming.
Please note that I’m in no way affiliated with Maslow CNC and this project is completely open-sourced.
This started as a project to allow me to use a phone to control ground control in order to set sprockets vertical (I got tired of going back and forth between computer and sprockets). It evolved into what you see today… a complete alternative to ground control. Besides some help early on from @johnboiles, webcontrol has been a one-man development show. Please don’t take these comments the wrong way, I greatly appreciate people testing it, using it, finding bugs, and providing feedback (such as your post). Just realize that it’s an entirely voluntary project.
Thanks for your help @madgrizzle. I do think Webcontrol will be much more convenient than using Ground Control and I appreciate the work you are putting into it. I hit the define zero and that made it so I could extend the chains. Now that I understand the difference, I’m going to continue with the build.
The RPI Zero W works with webcontrol single directory release. It is distinctly slower than the RPI 3B+ when it comes to file operations. Uploading and opening gcode files (which does a lot of processing) is longer. But it seems to work fine after that. I used a 6-year old microSD card I had lying around, so not sure if the speed of the card was a factor.
… and I loaded buster on the RPI Zero W so webcontrol is apparently compatibility with the latest OS. I don’t have a Pi 4 to test, but I assume it will work just as well. There’s nothing special going on that I think wouldn’t work on a 4.
is there a new Pi image to use (as opposed to the old docker based one), or is it just take a stock raspian image and install the webcontrol app on it?
No new pi image. I’ve only started looking into how @johnboiles created the one for docker. I suspect downloading the image, burning it, and doing a wget for the release you want is all that’s needed.
I’d still like to come up with a good solution to get an rpi connected to the internet in a headless environment. I’m thinking maybe making an image with it defaulting to ap mode, then connecting to it using your phone, and entering the ssid and password might be the simplest.
Before figuring out how to generate a new image, I need to figure out how to update the pyinstalled files.
It looks like, in webcontrol, I can call a script to run using subprocess.Popen and then exit webcontrol and the script will continue to run. So I’m thinking the process would be:
Within webcontrol:
a) Check to see if upgrade file exists (maybe do this every hour or something)
b) Notify user of upgrade availability (maybe do this as a badge to Actions menu)
c) Give user option to download and update via a new Action
d) Download file and verify checksum
e) Call subprocess.Popen to execute an upgrade script while passing the filename of the new file and type of file (single directory or single file)
f) Exit webcontrol
Within the upgrade script:
a) Wait a few seconds (to give time for webcontrol to shutdown)
b) upgrade/replace files as appropriate for the file type
c) Restart webcontrol
Well, it will be user initiated to upgrade. I’m not proposing automatic upgrade.
To fix an installation I think would be relatively easy assuming someone has console/ssh or gui access. I’d like to make it foolproof, but I don’t know how.
Basically, when the RPI is not in range of a wireless network, it becomes an access point that you can connect to. The advantages of this approach is that 1) you don’t have to pre-configure your RPI to connect to your wireless network prior to its first boot as it will boot in AP mode and then through a web page (to be developed) allow you to enter in your wireless network details, and 2) you can disconnect your RPI from the controller, take it in your house so it connects to your wireless LAN, perform update(s) as needed, and take it back to your shop and reconnect it to the controller.
you don’t need to have internet (other than to install the software on the Pi),
you do need a network, but it can just be local to the shop.
The best way to do this is to have the Pi be in AP mode (takes a bit of
configuration, but as work is done to make a Pi image to run, this should be
easy to do as it will be the default way to configure the Pi)
Basically, when the RPI is not in range of a wireless network, it becomes an access point that you can connect to. The advantages of this approach is that 1) you don’t have to pre-configure your RPI to connect to your wireless network prior to its first boot as it will boot in AP mode and then through a web page (to be developed) allow you to enter in your wireless network details, and 2) you can disconnect your RPI from the controller, take it in your house so it connects to your wireless LAN, perform update(s) as needed, and take it back to your shop and reconnect it to the controller.
try to have an option to make the swich manual (I can imagine a situation where
the connectivity to a known wireless network is marginal, just enough for the pi
to see it, but not good enough to connect reliably, and so the pi keeps trying
to connect and doesn’t give you a local connection)
I would even consider using a gpio that you could just put a jumper on to make
the config change.
Thanks for that info @dlang! I might give this a go then! I have a spare HDMI monitor, a RPi 3b+ and tons of SD cards. Would be cool to have my system built right onto the maslow!
errors during the build, hanging mid-build, then running out of drive space… I’ve created a new free tier AWS EC2 to try it out on… this one hopefully is distro is lean enough to give me the space needed.
You could also just pick up a real, real cheap access point/router (or even an old one that you might have lying around… go to goodwill?) and put it in the shop. You don’t need it connected to the internet. Would be easier than trying to set the RPI into AP mode.
I thought about saying that, but to support that, you still need to do a bunch
of configuration (either on the AP, which is going to be different per AP, or on
the Pi) to make it work well, and if you’re going to that much trouble, just
using the pi simplifies things a lot.
