I’d vote for .95 release be with 3.10.
I’d like for it to also have some other advances that have not been merged yet, but we are still waiting on a firmware binary to bundle with it if we opt for that.
I can see python 3.11-dev, 3.11.1, 3.12.0a3, 3.12-dev… I tried your latest commit with 3.10.5. no dice… left info on github issue comment.
I had failed to update the client side socket.io library to match the python server side updates.
But the bigger issue looking into that is that there’s no package manager in use for the client side JS libraries. So I’m following through on that.
I’ll keep making commits to that :pr: as I make progress and let you know when it’s ready for a proper review.
2 Likes
Looking at this as you go, I’m leaving comments on what isn’t working for my setup. I am not sure if that is helpful. I can see you have made large structural changes in the main.py and split it out into the app folder, which makes a lot of sense. I’m thinking it will be a pain to put back in all the changes I made, but it will be a better code set to do it that way.
Thanks for your efforts to improve this! Your professional background shows and I think this will be a much-needed improvement.
I am seriously thinking about unwinding some of my changes to make code review easier.
Apart from using a package manager for the JS libraries, the other big change I’m making is shifting all the JS to modules - you can see type="module" in the various <script tags. Shifting to modules means that everything declared in a particular JS file is private (i.e. local) to that file. This makes everything a lot easier to reason about because you don’t have to know the whole code base, with everything that’s global, just to understand one file.
@Orob Just pushed a new commit to that PR I’ve been working on. This does not get things working again, but I was able to establish that the problem lay with changes to how Bootstrap’s modals are wired up
2 Likes
@Orob I’ve just pushed several more commits that got the Bootstrap modals working again, and cleared most of the initial errors that show up in the browser console.
I doubt that this is ‘fixed’, but it should be much closer to ‘reviewable’.
I’m thinking seriously about a :pr: that is just some of the code cleanup that I did, nothing related to the dependency updates.
@Orob Here’s a little :pr: I broke out of the other work - this does not fix the socket.io incompatibility presently in the master branch. It just does a lot better job of logging things.
Logging improvements for the Python code by md8n · Pull Request #196 · WebControlCNC/WebControl (github.com)
I’ll test on the Linux setup this evening. I got lost trying to get this to work as is on windows and in wsl. Socketio and Jinja2 roadblock the the dependency installation because of a need to use visual studio c++ compiler version 14 to pip install these components.
I’m digging through the holey firmware documenting the code changes trying to get the tb boards and original Maslow boards to work right. I think one issue is an eeprom save setting assignment made for the z axis limit position.
I’m also using WSL on Windows, hosting Ubuntu 18.04.
You shouldn’t need VS c++ for the pip install. I’d recommend creating a new Python virtual environment, and starting again. I rewrote part of the README to cover what I did to get things up and running
20.04 LTS is in wsl and I just started setting it up for webcontrol python. Still trying to get it to work as it is without restarting the setup. I do have python 3.9 currently and that may be part of it, but the linux laptop has python 3.10 on it and seems to have loaded dependencies ok now, but the program doesn’t run. too bad there isn’t a way to move an environment from one machine to another…
it is the windows virtual environment that needs the C++
Below is the latest holey calibration hex file. it is in the 291 test branch of the orob-maslow repo. PR will be submitted to webcontrolcnc/Firmware HoleyRelease after it is tested. This post is a request for testers. Of particular interest is verifying the eastbay shield and the other open TB6643 users.
New features of note (not comprehensive list):
-
spindle speed control. Set max and min speeds. gcode S command sets spindle speed as you go, turn off with M3, turn on with m4 or M5 you calibrate and tell the controller what the max and min really are and it will set with gcode. spindle speed control pwm is pin 45 often, but not always labeled aux 7.
-
supports Gcode R radius command for curve cutting
-
supports boards 1.8, 1.10, 1.12 that I have tested in addition to the fact that it should support boards 1.0-1.5b thanks to copy/paste. Need verificiation here
-
soft z axis limits. you can set them by position with your router. move it to the far reaches and set or just clear them from wiithin the webcontrol window. access from the actions menu and then “z axis limits”
(not yet tested the current WC release version- you will need WC version .957+ that needs a build release as well for this to work… working on that)
The hope is to get some feedback that it works and then PR it into the holey release branch of the webcontrolcnc/firmware repo, not just my private repo. I have included it here so you can test it if you like. Please screenshot and respond with any errors you find.
EDIT 2:
This works fine on the bench now:
Holey-51.291.hex (185.4 KB)
1 Like
Orob you have been busy! Nice work!
Ahh… so the problem will be then that certain libraries have not yet been built for Windows and a specific version of Python. In which case I’d recommend going back to earlier versions of Python until you get to one that doesn’t need the C++ compiler, in other words there are pre-built binaries for a given library, for Windows and for a specific version of Python
I’ve been loading libraries with pip install --use-pep517 so it compiles most of them, but it is hung up on needing that right now. My focus at the moment is getting the firmware to respond correctly and every time I post a version, I find a problem. Most of the issues are specific to my custom shield, so nobody else cares, but I really want it to work now. need to cut some stuff today before the sun goes down.
I have another prerelease candidate 51.292 on github if you want to test, pull here:
Again, my intent is not to take over this, but to use this avenue as a sandbox to contribute back hopefully without destroying what is already there until it is tested.
I’ve run into various walls with trying to get the full set of updated dependencies to work. So I’m intended parking the most recent :pr: of mine, and even introducing another :pr: to roll back the previous one that I did that got merged in prematurely.
As best as I can tell there’s just too much technical debt there for me to resolve what’s going on across the multiple threads.
With saying that I would NOT recommend that this code base be used as the starting part for any new project such as the Maslow v4. The way to move forward is to literally start a completely new project and gradually reintroduce various dependencies and bits and pieces of the old code base making sure that each part works before moving on to the next
1 Like
Thanks for all of you efforts and time.
Not at all. From my perspective it was well worth the effort - it’s just sometimes things don’t work out, that happens.
With this, I would have to say that I’m not a fan of Flask, I don’t ‘hate’ it, I just don’t think that it is really fit for our purposes. Also the Python multithreading … The organisation I work for is ‘all-in’ on Python (with Django), but we do any multithreading with anything except Python.
In terms of something that non-professional developers could get into, I would recommend going all node.js (for the backend) - so Javascript / TypeScript all the way. But if we want maximum ‘works on everythang’ then it’s got to be .net based (so C#), for which I’d recommend starting with Uno Framework for the frontend, which means you can target Mac, Windows, iOS, Android, Linux, WASM, Raspberry Pi, etc. right from the start
Good evening. .. I have just been reading through this post and following with interest especially when it mentioned potential updates to WebControl . There have certainly been a lot of twists and turns . I am relatively new to the Maslow but have a Jumpstart Maslow, with built Z axis built and working Web control (one of the older 2020 versions) using a Pi4 to control the arduino 2560. As an aside I also fitted it with a spindle rather than a router and was originally looking at if it would have been possible to control my VFD from WebControl..but thats astep too far at the moment. So far I am fairly impressed with what I can do with the Maslow and it works!!. Anyway you all seem to have been working incredibly hard at trying to provide improvements to the WebControl firmware.. and right at the end I pop up and ask the dumb question .. was it ever concluded and do you have an improved version running ? .. and I suppose more importantly (and rather selfishly) are there any plan for a prebuilt Pi image ? to allow us folks a quick and simple update where we dont have your incredible software develpoment knowledge . Many thanks to you all for your hard work and perseverance.