ZPID tuning for velocity gives me an error code no matter the numbers I put in. Position just doesn’t do anything when I test, but I don’t know what those values mean so I just put in some numbers.
The additional macros I set up to turn router on and off then changed them to move z axis , but they seemed stuck on router on.
When starting an aircut. It first pauses per code and when I resume it does resume but gives me and error code.
The next raspberry pi update will be for raspberry pi os x64 since I just imaged my development system to start with a fresh python 3.10 version because I crippled my other one. This may or may not be an issue for those running 32 bit. I suspect it will, but I can only do this on one machine at at time and the 64 bit is the way of the future.
Fully support that. It would be great to support both, but it’s better to focus your development efforts on the future and not try to juggle too many balls at once.
We should make it clear where the last 32 bit version is for anyone who wants to use it. It’s already quite good so for anyone who is stuck on 32 bit it’s still a fantastic option.
Anyone who has a 64 bit capable Pi is probably going to want to be running it at 64 bit. Especially since the RasPi foundation has finally released the OS out of beta.
What WC needed was someone to grab it and point it in a new direction. Having it move to a 64 bit RasPi only application is probably the most logical choice from a development standpoint.
0.94, the first release of the new webcontrolcnc/webcontrol is the last 32 bit version official release.
All 0.95 beta from version C and on are 64 bit raspberry pi os and 64 bit linux. Once this comes out of beta, it will go the official webcontrolcnc repo.
64 bit linux and 64 bit rpi both make sense to me since that is what I’m using. The Ubuntu linux version came with python 3.8 and is working fine. Raspberry pi os bullseye is using 3.9. I fought with pushing them to 3.10, but without clear instructions on how to do it or previously knowing how to comfortably do it, it is a huge waste of time, which is why I went to bullseye x64 as a fresh start. There is a new release on my github now with Webcontrol-0.95c for both linux and raspberry pi single folder versions for python 3.8 and python 3.9 respectively.
My apologies, I took your previous statement to mean you were only working with 64 bit RasPi going forward. The fact that you are also producing a seperate Linux version is a bonus.
Tested it this morning.
The additional macros still cannot be changed from what I initially set them as. Even when I delete the gcode for them.
I get that error code on resume still.
Most of the time it loads with the “V:NaN/NaN” shown in picture. When it loaded like this the gcode and sled positions don’t change although the maslow seems to be moving and following the program correctly.
Gcodeclean seems to work but overwrites the original file.
Sometimes I lose the com port and have to restart to gain it back, refresh screen or going into settings for the com refresh didn’t work to regain.
In the action menu. Shutdown webcontrol is no longer there. And the sudo system to disable webcontrol doesn’t work to shut it down. I have to restart comp to bring up the working version of webcontrol.
Macro resave function will be looked at.
EDIT: webcontrol has to restart to reload the setngs when the buttons are changed, but they will change. not sure we want to force a restart of webcontrol if the settings are changed… if you just change your z axis pitch, maybe not, but if you change the buttons, then yes.
I’m unclear on the V: code in the window. V:NaN/NaN is “not a number” code so it is getting text.
Edit: can you share your gcode that you are getting this error from?
gcodeclean: If gcodeclean is not installed separately then the file is unchanged, not overwritten. When it works it will append -gcc to the file. Perhaps there is a way to capture its nonfunction…
No idea on the com port loss. I have not touched the serial port code.
The webcontrol restart button in the action menu was removed because it used webmcp, but can be put it back if it was working for you.
In a pinch to kill webcontrol, you can open a terminal window, run
htop
and select the webcontrol branch then press F9 and then 9 to kill it. And it will stop… If you have it running as a service with auto restart then it will respawn immediately and effectively restart.
Then you will need to:
sudo systemctl stop webcontrol
Funny thing: I find on my Linux machine when running webcontrol and the browser auto launches, more than half of the time it isn’t functional yet and has to be reloaded to be fully functional.
I really appreciate your patience as we work through these items.
Reloaded and restarted still stuck. I am able to switch macro settings without reload on the current WC
This was appearing on start up before loading any gcode. Weird thing was that it was affecting the current WC and had to delete the .webcontrol file to fix it. Don’t know if one overwrote the other or what. Good thing I had all the settings written down.
Oh I saw it in the menu and thought it was implemented. If I have to download it separately, do I have to put it in a certain folder so it works from your webcontrol menu.
That would be nice it’s easier than opening up the terminal and doing from there, especially since im such a novice in Linux.
gcodeclean is here (may need to click on releases on right column and download there. It needs to be placed unzipped/untar’d in a folder next to webcontrol. There is a version 0.95d that has the restart button. I’ll look again at the macro buttons to see if there is a script that is missing to reload them. EDIT: simply refreshing the web page will change the macro buttons…
There’s no way that should happen (from the perspective of GCodeClean, because it always creates a new file with a new filename based on the original filename). What was the name of your file that got overwritten, and I’ll see if there’s been some regression.
New GCodeClean released: v0.9.6 - Release FileNotFoundException & Tweak Tolerances · md8n/GCodeClean
FileNotFoundException is now returned as Exit code 2 (Exit code 0 means success).
The default or user supplied tolerances are now tweaked into more limited ranges of ‘sensibleness’ based on the units in use in the GCode (mm / inch)
And a little update to the README
webcontrol now puts out an internal server error if the folder is not found and the terminal output trace gets a message that says “GcodeClean folder not found.” if it isn’t there, so it won’t run errorless to the user when it isn’t doing anything.
No need to worry. I didn’t understand how it was implemented in Orob’s WC. I thought it was self contained and tried it through the menu (I didn’t have it downloaded separately). There was no error with it and I thought the file overwritten since the date/time next to the file was changed to the time I tried it. I will download gcodeclean and see how it works through webcontrol after work sometime this week.
Did you change something or is it working for you? I must have some wonky conflicts going on or somekind of cache that’s not allowing it to work. When having two versions installed is the only folder I have to rename/isolate the .webcontrol one?
The macro buttons are fine. I changed the frontpage.html file and the post response to them in main.py and I didn’t think it made a difference, but it works with a refresh. Maybe hold shift and refresh. I’m running this on Ubuntu 20.04 I believe … whatever the latest .04 (long term release) is as of March in firefox browser. Multiple webcontrol folders will share the same .webcontrol folder and that is fine. if the webcontrol.json file is missing the settings a newer one needs, it will add them and the others won’t look for the new settings, so they won’t change them either. I have 3 or 4 instances running on the same machine for various things I was messing with and it works ok.
Like most things I “fix” I have to break them to figure it out. This one took a while to get back on track, but it is working. Attempting to merge with the main branch broke the web page. It was several days running in circles chasing dependencies. The LED features I started with were from a much older branch and the merge was needed for lower case gcode, software z limits, radius (R) gcode and a couple other things.
0.954 is now available for testing. ( got rid of the letters and d was the letter it was on which translates to 4 pretty easily)
Done:
macros (shown above - if title is change, page refresh will show new title on the button)
gcodeclean (if installed correctly - it is not bundled)
rpi contextual menus (gpio/led/power off, etc… don’t work unless you are running a raspberry pi)
vs
triangular calibration: looks different now (thanks to @hangtentex)
action menu also looks different (thanks to @hangtentex)
Remaining to do:
Please test out this version and let me know if there are issues. I’m not likely going to have a chunk of time to spend on it for a while, so we will need to list out the issues and verify the functionality of the things I have messed with to ensure something else didn’t break.
just a few minor changes…… he says. im only going to tweak a couple of things… he says.
Yeah, im not an expert by any stretch but im just going to throw this out there and say that this was a lot of work Rob. Thank you.
Let hope it still all works like it should. I couldn’t use my Maslow yesterday because of this software issue, but hopefully it will be useful to someone.
I’d like to get the log file fixed and the zPID working for the official pull request.
Anybody familiar with B13, B14 functions in the firmware? Is there a B15?
