First, congrats on the new baby. Thank you for an in depth explanation of how the software functions. Unfortunately, my programming and coding skills are nearly non existent, but I do think I understand what you are saying for the most part. I think the software GUI layout, and basic functionality of it, is well done. I will just have to accept that it's just not meant for everyone, at every level. Maybe with some more tweaking, it can be though. I thought I seen a post saying rpi wasn't capable of doing WEBGL, but here it is doing it. Maybe it's an experimental software based setting, but it does work! Anyway, here is are 2 files. The roughing file will load with preview and the finishing file crashes the program on my systems. Note that both will load on my beefier desktop setup.
@sharmstr worked through getting webgl working - I have to add it to the documentation still! Thanks for the files, will check when I am back in action!
Just tested and it appears to be working. Thank you for that! I'm going to open up a request on github to maybe change the color of the gear icon on the macro button when you mouse over it. A few times I've clicked just near it when I've wanted to edit the macro and it ran the macro instead
on linux need some kind of permission if try to connect the usb port what ever port get error permisson dennied
is there a known issue with the Feedrate override setting? Sometimes it works, other times it ignores the 20% it is set at and runs at what seems like 100%. Sometimes I will set it to say, 20% then it automagically changes to a different, higher %. Is there a recommended order of operations to always get it to work? FYI I'm using it with a BlackBox
T Drag, and lift. Once you release the mouse it then sends the override commands to adjust the feedrate. gnea/grbl Here's how it works under the bonnet They way Grbl works is we cant tell it "go to 150%" - you have to look at the last reported feedrate override (in Ov: field of '?" response) then calculate the delta to get to the commanded override. Send requested amount of + or - commands to get there... Then wait for FRO to come back in next status message: Update the UI (move slider to actual value so you know what Grbl is doing)
So when I slide it to 20% and it does not change the speed, that is unintended behavior. (bug) It broke an o-flute bit on me yesterday.
Grbl 1.1f? I'll check when I'm in the shop tomorrow but used it over the weekend and it worked. Anyone else?
I've kept out of this one, but since you asked.... I did notice once where I thought the feed rate didnt change. I was cutting a 380mm diameter, in which each trip around is one command. I chalked it up to maybe Control (or grbl) didnt have realtime (mid-command) feed rate adjustment. So when Nick posted the other day, that was going to be my response. However, I stopped myself and decided to do a quick test. I issued a G1 Y1400 F500 command via serial. While it was executing, I changed the feed rate by clicking and by sliding. I couldnt get it to NOT change the feed rate. It worked every time. So, I decided to not respond and let you handle it I know I probably should have tested G3 as opposed to G1, but I was being lazy.
Sidenote, hows Spindle override at 200% gonna work. 100% = max pwm already... Might have to check that with Sonny too. [edit] dropped him a mail [/edit]
if your max feedrate is 2000mm/min and your F word is F1000 then 200% of that is 2000mm/min. no problem there. similarly if F is less than 1000mm/min then 200% is within the valid range. GRBL will have to trim for values that would exceed the max rate. note it is 'feedrate override', so it is not setting the feedrate itself it is adjusting the value set by the last F word.
Not feedrarte, that ones obvious. I said Spindle Sonny replied: "It increases it until it’s at the max PWM. After that it stays at the max PWM." Still makes sense though. If the S value is 50% then 200% override = 100% power (mainly thinking lasers for tool override, spindle = not many users here with spindle under control) . If S is already 100% then it has no effect. Same with feedrate, if a override exceeds configured maximum feedrate the effect is nothing.
One of the things that catches me out on the OB control software is the 0.1 / 10mm / 100mm jog steps. I've been positioning the Z and forgot it was on 10mm! On UGS the Z travel is seperate to the X & Y. This makes sense (to me anyway) as i want to fine tune my Z movements to position and the X and Y i usually need to move in larger increments. Is it on the cards to separate the Jog distances for the Axis?
At this time, no. Mostly because I can't find a way to introduce it in a way thats pretty, and easy. Easy being the key thing. I dislike dropdowns for steps size (;
@sharmstr @Nick W v1.0.150 is out with improved override sliders Please update and check if it works better for you guys now? (Considering it a little beta till I get feedback from more testers hehe)
It is working so far. I have used it for a few days and many projects. It works and now the -% are gone. . thank you, I'll let you know if i run into anything else.
As you've figured out, it doesnt currently support it, but I've opened up a request for you (link below). In my experience with other software/platforms, any time duration/remaining displays are only estimates. Display job duration/remaining time · Issue #67 · OpenBuilds/SW-Machine-Drivers
I appreciate that! Even an estimate would be great. it's better than what I have now. Figured I'd ask, I cannot program unfortunately
If you look at the bottom of the OpenBuilds CONTROL window during a job. There is a green progress bar there that helps at a glance to see the jobs position
