If you want to roll your own Desktop on Jessie-lite/headless system take a look at this guide on the raspberry pi forum.
Definitely worth thinking through. In my view though I think there are plenty of similar failure cases with GroundControl too where you wouldn’t be able to jog the sled if something went wrong (laptop runs out of battery, hard crashes, etc). Overall I feel like I have more redundancy in being able to use any device I happen to have nearby to control the Maslow. My ultimate emergency plan is to just pull the plug that powers the router, pi, and arduino
Etched @johnboiles image to sd card, added ssh and wpa supplicant file, loaded for first run in pi 3 and this is where I am.
Asking for username password. Doesnt seem like it took long enough to auto download webcontrol as noted in the in the installation notes. Tried opening my ip with .5001 added in browser, but no luck.
Went on and signed into the rpi with user: pi
pswd: raspberry and showed message that I need to sign in under pi and change password by typing pswd. Any suggestions?
It takes 10-15 mins on first boot to download and run the webmcp docker container. Maybe just wait a bit and try port 5001 again (pro-tip: avahi daemon is installed and advertises the pi as maslowpi so you can open http://maslowpi.local:5001). If that doesn’t work the output of
sudo systemctl status webmcp would be helpful
We don’t have anything set up to output to the screen by default (I only run mine headless). The screenshot you posted is what I would expect.
Great!! The neat thing about WebMCP is that you can use it to update Webcontrol with the ‘Update’ button. WebMCP will also update itself at every boot (though it probably won’t change as much)
Haha. That is my e-stop, too. It is not elegant, but it works.
I think this is a topic worth discussing. Since it is easy to update WebControl (and the Firmware, possibly), it could be possible to do both good and bad things. For example, if a calibration needs to change, in order to compensate for changes in the software, it would be important for the User to know that.
I would like to understand how to configure the network. For example, I would be connecting through a router. I am guessing I will have to configure the router. Is that correct? Are there any other things I would need to know?
Here is another question. Do we have a mechanism to seamlessly transition between WebControl and GC? It would be nice to be able to directly transition without having to re-calibrate chain-lengths and all that.
Are you trying to reach the RPi through a router (i.e. from the WAN side) or just trying to reach it from the LAN side? Either way, I’d set the RPi for a static IP address and that’s probably all you need to do if trying to reach it from the LAN side of the router. If trying to reach it through the WAN side, then you would have to configure the router for port forwarding (likely).
You can import your ground control.ini file in to webcontrol from the actions menu. I spent a lot of time troubleshooting that part and honestly it’s one of the parts id like to get more feedback on.
I am not trying to do either, currently. I am just trying to gain some understanding of how this is done, so that at a future time, I could give it a try.
This may not be what you’re asking but I just want to make it clear: I highly advise you not to expose your webcontrol instance to the public internet by making it available to the WAN interface through your main router. There’s no login mechanism (unless you set up your own with something like HAProxy). If you want to access webcontrol outside of your network, set up a VPN (this is what I do).
If you just want it available in your internal network the normal raspberry pi networking tutorials apply – you can set a static IP if you want (I think the best way is editing /etc/network/interfaces – but i’d google to see if there’s a simpler way now), or configure your router’s DHCP to always assign the same IP (only available on some routers – this is what I do). You can also discover the IP automagically using bonjour/mdns by simply going to http://maslowpi.local:5001 (though I’m unsure if that works on windows). As a backup you can also do what @clintloggins did and hook up a monitor and see what IP it says on the screen and just navigate to http://x.x.x.x:5001 (replacing x.x.x.x with the IP you see from the bootup logs).
It really doesn’t matter if the device is connecting over wifi or not, if the network that you are using has wifi access turned on, all of these exploits still apply (and it probably does, unless your phone has an ethernet cord as well) - It’s even worse if that network has internet access, as then with the right exploits, someone could control your maslow from over the internet. but of course first they would need to bother to access your network, and let’s face it, they probably have bigger targets to go after than your cnc.
Worth noting that this is also true for GroundControl if your computer running GroundControl is connected to the internet and becomes compromised through a virus, malware or an OS exploit. With either GroundControl or WebControl, I wouldn’t recommend leaving your Maslow plugged in and unattended, especially if you have a way to power up/down the spindle automatically.
Grid knife guide
About hackers having bigger targets than go after your CNC…
Nowadays exploit bots are automated tools crawling everywhere they find an opening, and using extensive lists of computer vulnerabilities listed in public databases like this one.
Altough bots might recognize a specific software listed on Github, they are more likely to setup standard malwares to spy on the network, fool other computers into thinking they are the DNS server, setup attacks as a middle man to collect and exfiltrate banking info, crypto currencies credentials, setup ransomware, steel social media credentials, or become remote command centers to lauch further attacks on the Web… and on the neighbour WiFi LANs.
Now WiFi can be used to access the LAN, bypassing the home router protections used for connection to the Internet. This efffectively increases the attack surface. So the Raspberry Pi is one more machine to monitor, and one more side entry point if WiFi is used.
And yes it is possible to find vulnerabilities that can be used to attack Linux machines like the PI.
So like @johnboiles says,
With either GroundControl or WebControl, I wouldn’t recommend leaving your Maslow plugged in and unattended, especially if you have a way to power up/down the spindle automatically.
@madgrizzle and @johnboiles I cant thank y’all enough for the the amazing job on this project!! I have cut 2 projects with Web Control and now this will be how I control my Maslow, hopefully, indefinitely. My laptop is going in the house!!!
I think I may try to figure out a kill switch just in case I have a network problem while running code or my phone screen goes to sleep.
Glad to hear it! It’s def been a game changer for my use of the Maslow. @madgrizzle takes most of the credit. I just made the pi image and did some dockerfile magic.
For the kill switch are you thinking just something that stops the gcode or something that cuts the power. The former could be cool since it would be less likely to lose chain positions. We could possibly hook something up to a pi GPIO. Or maybe if there’s some kind of off the shelf usb connected button that might be simpler for folks
There’s an area that I still need to spend some time addressing and that’s switching units to/from metric and imperial. Most of the time it works, but in certain situations the client can get out of sync with webcontrol, mostly when you have multiple browsers running (i.e., phone and desktop both connected to webcontrol) and one of the goes to sleep. For instance, you have have a browser on your phone connected, but your phone goes to sleep and you change units on the desktop, the phone may miss that unit change command and when you wake the phone up, it will still be using the old units (i.e., it doesn’t refresh the webpage). I’m working on tweaking that so, but not sure exactly how to handle it.
Generally, I recommend sticking with one unit or another.
Feel free to ask for any improvements or additions you can think of… I’m pretty open to doing most anything I’m capable of … insofar as I have the time to do it…
Yeah I’ve experienced that once or twice.
I ran webcontrol on a pi 3 and used the built-in browser. It worked fine, but was somewhat lagging. Now I use a Chromebook to access the server and it’s very responsive. Running on a pi3b+ might make it more useable if the pi is also hosting the browser.
I found a way to slim down the python install for Windows 10 to run WebControl. By using the Conda package manager for Python to install the requirements, you will not have to do separate downloads from Microsoft for the VisualStudio C++ libraries. the compiled modules can be downloaded directly from the Anaconda servers. You could install Anaconda Python to do this, but it will install a lot of extras (Juypter Notebook, Spyder IDE, etc.), which maybe of interest if you code or are in the science or math fields. I chose to just download the Conda package manager with Python.
Download Miniconda Python 3.7, from here
Install it and you should now have an Anaconda Prompt in your Windows start menu. After I had all the dependencies downloaded and WebControl working, I made a copy of my working environment. The environment.yml (459 Bytes) can be copied to your unzipped WebControl folder or cut and paste the text below into text editor and save it. The YAML file is used to clone the python build on your PC.
name: webcontrol channels: - defaults dependencies: - Python=3.7.2 - Click=7.0 - Flask=1.0.2 - Flask-SocketIO=3.0.2 - gevent=1.3.7 - greenlet=0.4.15 - itsdangerous=0.24 - Jinja2=2.10 - MarkupSafe=1.0 - numpy=1.15.2 - pyserial=3.4 - python-engineio=2.3.2 - python-socketio=2.0.0 - six=1.11.0 - Werkzeug=0.14.1 - pip: - flask-mobility==0.1.1 - opencv-python==188.8.131.52 - schedule==0.5.0
Once you’ve copied the environment.yml file to the WebControl-master directory, launch the Anaconda Prompt from the Windows start. This will open up a command prompt for Python. CD to the WebControl-master directory and run the following commands to create and activate the python environment.
conda env create -f environment.yml conda activate webcontrol
You should now be in the virtual python environment with all the dependencies.
In the 64-bit Anaconda for Windows I had trouble with 3 packages not installing from PIP inside the environment.yml file that need to be installed manually as shown below.
pip install flask-mobility==0.1.1 pip install opencv-python==184.108.40.206 pip install schedule==0.5.0
Note - With the 32-bit Miniconda installation in Windows 10 and in Linux I did not have this problem. All package dependencies were resolved when running
conda env create.
With all dependencies taken care of just start up WebControl with
and open your browser to http://localhost:5000/
Is this easier than installing VisualStudio C++ libraries and python.org on a Windows 10 PC?
Will this be helpful to someone who can’t meet the graphics requirements to run kivy and GroundControl?