OpenBuilds CONTROL Software

Will the laser module disable Z movement during the burn?

Can the replay be left out when going back into cnc mode?

 

Very new to laser engraving, very new on OpenBuilds world, very new in all this stuff..... Just assembled my laser engraver...runned some tests and I have the toolpath and various mark points on the surface. Can anyone help me in how I get rid of it? How can I configure correctly the machine to print only the image on the surface (the surface is a piece of wood - pinus)...tks

 

As I've said, very new on this stuff...problem solved configuring GRBL PARAMETER "LASER MODE ENABLE" as true.
I think it's good to share because of future people struggling with the same problem

 

Hello, I’m trying to complete a rush job this weekend for knife order I got months ago since I now have my MiniMill working with a spring loaded diamond tip bit. Problem is that I paused the machine last night since it is loud until I can make an enclosure. When I just went to go hit the “play” button this morning in OpenBuilds Control, I was unpleasantly surprised that OB Control got disconnected last night for some reason. Now my question is if there is some way to get the machine to line up exactly to the starting point on my drawing and where it needs to be to align perfectly with the half finished engraving on a very expensive hand made knife?
Any help here is very much appreciated!

 

Thanks for the help! I was not able to re-find the zero origin start point for that knife since I had already removed it from the fixture. I should consider making a fixture for each knife design but that would be hard since the MiniMill has a smaller workspace than the size of the blades. I made my fixture so that I can move the length of the blade depending on where the etching is going to be positioned. I'm also using an electro-etching machine made by another knife maker for me. It comes out really good now and the MiniMill with spring loaded diamond tip is helping to eliminate hours of hand work with carbide pens and dental picks that I was using before. All I have to do now is cut the design out with the MiniMill, etch it and cut, and etch a few more times to achieve the heirloom quality engravings I want. I will work on the fixtures as I progress further and share my findings here. Thanks for the advice on how to better save/find the home position for each job. Cheers! PS...If anyone wants to see videos of how I'm etching hardened tool steel then there is a lot of photos and videos on my IG FIST Blades (@fistblades) • Instagram photos and videos

 

Hey Peter, if you get a chance can you look at post #1062? Thanks!

 

With regards to the Z question......This is what the vcarve laser post processor mentions:

"The basic concept is that you set up a tool in V Carve Pro (or other Vectric software) that has the laser parameters to it (the spot size is the drill bit width). Then, you draw in V Carve Pro (or other vectric software) to get the file that you want. When you make your G Code, the post processor will change all of the “retract” portions in the file where the spindle moves up to a laser OFF command. Viola!

Didn't know if using the Lead machine in laser mode would do something similar.


Regarding the replay question....its a typo....should say relay. This question comes from posts #1060 and 1061. I was wondering if I can leave the relay out when going back to cnc mode since its recommended to remove it for laser use.

 

I did read that grbl page a while ago about the laser. Thanks for refreshing my memory!

I have been using Lightburn for my laser. If I'm reading your post correctly when using Lightburn G1 is being written automatically into any Gcode produced though Lightburn?

Sorry, with regards to the relay I'm not understanding what your referring to with the jumper?

 

Again....Thanks Peter for not only taking the time to explain but show where additional information is!

Its people like you that make Openbuilds the place to be!

 

I've been using CNCJS for awhile, and this is so much better. I could drop all other software if I could figure out how to show the current spindle location after I load GCODE. I usually carve onto unique pieces of wood and I have to fit the design by jogging the spindle around to see if design fits. In CNCJS, after I load gcode, I can see where the spindle is in relation to the design. So I jog it over and make sure it's going to "land" on the piece correctly. I see it shows the spindle location while carving, just wish I could see the spindle location all of the time.

Thanks for making awesome software!

 

Thanks. Can it be a preference to turn on and off? The material I'm working with can't be probed as it is unusually shaped. It is not square. The other method I've used is to use the laser to burn a profile line to make sure everything is in alignment. But seeing where the spindle is in relationship to the job is very helpful.
Thanks for considering.

 

So I've been playing with CONTROL lately - half out of long-simmering curiosity about what it's like to work within the OB software/electronics ecosystem (as opposed to just the nuts & bolts), and half - at Mark's urging - as the latest in a series of increasingly desperate flailings to set up a system that I'm confident won't stall on me the minute I glance away.

While I think I've found a few bugs, definitely accumulated a long wishlist of additions, and found myself swearing over a few features I feel absolutely crippled without (scaled-rate analog stick jogging on a gamepad, .000/.0000" DROs in inch mode, and @Tony Barnhill 's request for a live display of spindle position while jogging are all high on the list), I've been trying to keep my mouth shut until I can sort out how many are actually software issues (or actually useful additions) and how many are plain ol' PEBKAC issues... but this one has me afraid to go any farther - or, indeed, to try doing much of anything with the software - without addressing it.

The problem is the continuous jog (or at least I haven't noticed it on incremental yet). It would seem that under certain circumstances it takes the "continuous" bit just a little too literally, and keeps on going after the button is released (until either the full 1270mm movement is completed, or another jog signal or abort is received). Needless to say, this is not exactly a Good Thing.

It looks like it can be triggered on X or Z (but not Y, which is curious) by clicking/pressing & holding jog for a second, then (very) rapidly release-press-(re)release the same button/key. I've been seeing a lot of it, since the LMB on my CNC box's trackball has been getting a bit fluttery lately, but it seems to be more than just a debounce issue (and, for what it's worth, it happens both on Win7 & Debian Stretch, although I haven't tried playing with the Android jog app yet) .

The log when that press [hold] release-press-release happens looks something like this:

Code:

[22:46:47] [ $J=G91 G21 X-1000 F1270.00 ] ok
[22:46:48] [ ] ok

...while normally a series of X- jogs would all just look like this:

Code:

[22:50:36] [ $J=G91 G21 X-1000 F1270.00 ] ok
[22:50:37] [ $J=G91 G21 X-1000 F1270.00 ] ok
[22:50:38] [ $J=G91 G21 X-1000 F1270.00 ] ok
[22:50:39] [ $J=G91 G21 X-1000 F1270.00 ] ok
[22:50:40] [ $J=G91 G21 X-1000 F1270.00 ] ok

Based on my (thin) understanding of grbl & CONTROL's jogging mechanism, it executes a 50" jog (sorry, "1270mm" - still not clear on why it stubbornly sticks to G21s for these instead of using G20 when everything else is set to/operating in inch mode) when the button is pressed, and then sends a 0x85 jog cancel (which doesn't appear in the console) as soon as the button is released. In this case it looks like the [jogA], [cancelA], [jogB], [cancelB] that's input somehow gets munged into just [jogA] and... whatever produces the "[ ] ok", while smothering the two cancels and dumping their corpses down a an abandoned ground wire somewhere to bitrot.

The one other "this can't possibly be safe" issue that's had me on edge is the ability of "Enter" to start running a loaded program with no safeguards. I'm having trouble repro'ing it today, but several times when I've thought the console textbox had focus (maybe I forgot that I'd done something since typing my last command, or maybe that little ">_" icon just subconsciously convinced me it was a waiting cursor), I've entered a grbl command (say, a simple "$$") without looking & hit enter, only to watch the machine suddenly & quite unexpectedly launch into whatever toolpath was in the editor instead. While too many confirmation popups often just get annoying (like all those **** "lost steps are likely" alarms every time I have to stop something I probably shouldn't have started in the first place - any chance of muting those, redirecting errors to the console, or at least getting the option to clear them with a keystroke?), this is somewhere one would probably make sense (not for "run job" in general, mind you - just if it's being executed from Enter rather than an explicit click).

Conversely, a hotkey to jump straight to the console input line would also be quite welcome... As would a long list of other things that I seem to vaguely remember promising I wouldn't start going on about.


[edit: After writing all this and (briefly) entertaining the notion of poking around in the source, I found the git repository... which already has this listed as Keyboard Jog Bug #73. Although the fact that it's a six month old "Urgent" bug is a little worrying - is this a more tangled issue than it seems? Or is Mark just not paying you enough because he's a stingy ba "differently prioritizing key developmental resources"?]


-Bats
(Fun Fact: "This can't possibly be safe" is my middle name. Batscraven Thiscantpossiblybesafe von Rotwang the Third.)

 

I think it's either the return spring or the microswitch under the button that's on the fritz & causing clicks to flutter or multiply (the price of using a vintage (wired) MS Trackball Optical), but unfortunately that's not the root of the problem - just causing the problem to manifest a little more frequently. An operator second-guessing themselves with an overcaffeinated finger on the keyboard can do it too.


-Bats
(err... not that I'd ever have cause to second guess myself while twitching in a caffeine haze)

 

That's sort of what I was afraid of. I had similar problems with a probe script in Mach 3 that would tend to miss the brief contact of a probe-and-retract. A couple dozen lines ballooned to a couple hundred before I had it mostly working (or at least restricted to non-destructive failure modes).

I'm in the middle of changing software platforms & completely rewiring my machine, and haven't written a full line of code in years... but I may get frustrated enough to take a crack at it before I'm done - Javascript definitely lowers the bar to entry... although... yeah... catching those quick events...

I'd assumed it was open source, but I didn't mange to find that source until I'd already written most of this. Any chance of mentioning/linking to the repo either in the UI (maybe an About page?) and/or on the software.openbuilds page? (yeah, yeah, I know... "log it on github" )

For the most part, though, I've been trying (not entirely successfully, but trying) to keep my mouth shut until I've sorted out which are real problems, and which I just haven't wrapped my brain around yet - especially since I'm transitioning to new software, new electronics, and a new OS (no XP support? how could you?? ) all at once. Case in point: My *nix is extremely rusty, and I think this is the first time I've used Debian since the 90s, so I was all up in arms about the apparent lack of support for SMB shares when loading files in the linux version... until it occurred to me that they had to already be mounted, and, after that, that wherever or however Debian's Thunar file manager was mounting them for its own use just wasn't standard enough for CONTROL to see. Manually mounting them at /media/xxx (which is presumably my fileserver full of pornographic G-code) solved the problem, and saved me a terribly embarrassing bug report.

I tend to lean towards enduser clarity over excessive code economy (at least when dealing with high-level/low-efficiency scripty languages), and having the system operating with a mix of units at any given point in time just seems like a recipe for confusion. Especially since it seems like some parts aren't quite clear on what unit other parts are operating with.

A related discovery (or collection of discoveries) made late last night:

• Loading a program with unspecified units will render in the 3D view (and, by default, cut) as if it were metric, regardless of which unit (inch/mm) mode the UI is operating in. This isn't a major problem in itself, but...
  
• Switching from metric to inches with a G20 in the console (hitting "Update 3D View" optional), will then cause the machine to move in inches, while still displaying the mm-scale render (ie, a tiny render with spindle travel way beyond the bounds). Simulating, on the other hand, will occur at the rendered scale.
  
• Oddly enough, ending the program with a G20 will cause it to render in inches, while beginning the program with a G20 and ending with a return to G21 will render and simulate at mm-scale (the opposite of expected behavior) while cutting based on the G20/G21 mode set in the console. The renderer appears to use the last-detected G20/21 as the render & sim scale for the entire program.
• Getting into slightly silly territory, alternating between G20 & G21 statements in a program causes all sorts of confusion when it comes time to run - drastic speed changes (F100 means very different things depending on whether you interpret it as in/m or mm/m), and after a couple changes the spindle display gives up and disappears completely (while the DROs show continued movement). Hopefully the number of edge cases who actually try to switch units back and forth within a single program will be extraordinarily few, though (most of the scenarios I can think of involve hand-written code & canned cycles), so this is probably the least hazardous manifestation of the problem.

So a safe & gentle "G91 G1 Z-10 F200" turns from slowly inching (sorry... cm'ing?) the Z downwards in G21, to burying the tool chuck-deep in the spoilboard as fast as it'll go (and, after hitting bottom, continuing to dig) in G20, with the preview giving no hint of what's about to happen.

While this probably(?) won't bite a user who steers clear of the console and runs only programmatically-generated G-code (at least from software that doesn't do anything too strange), the potential disaster for a user just starting to experiment with their own G-code is troubling - especially since it won't be revealed in the simulation. Handling units globally in a unified way might not have done anything to avoid this bug (I haven't even glanced at the code), but it's the sort of thing I always worry about when I notice a program operating in different units than I expected.

(and, yeah, I'll try to post this over on github a bit later)

Nope - I hadn't touched - or even looked closely at any of the default assignments, but that's pretty scary in itself (try typing "G1 X.01 F10" when you think the cursor's in the textbox ). Not to mention the number of times Mach 3 beeped at me yelling "Nothing to feed hold" when I'd hit the spacebar while leaning over the keyboard to fiddle with the machine or workpiece, which suggests sticking with the default is going to land me in the hospital about ten minutes after I finally get spindle control wired in.

One other scenario I've found is that after clicking the Open G-CODE button, it's possible to hit Tab (shifting the focus - with no visual indication - to Run Job) and then Enter will start a job, but the one I was running into before hadn't involved Tab - somehow I'd created a situation where it was possible to start in the console textbox, hit Esc, and then have the

Binding Run & Pause to different keys will be going on my wishlist, too - one being potentially dangerous if it'***** [edit: if. it. is. hit.] accidentally, the other being nice to have on a big, easy-to-hit target for when you're flailing at the keyboard in a panic as things start going sideways (or, well, going some direction other than sideways, I guess, depending on what you were expecting).

The problem isn't the alarms themselves - they're there for a reason (well, usually), and passing them along to the user definitely makes sense. My gripe was that they can be (and - at least in my mad arghwhywontitwork flailing - are very frequently) triggered by hitting Esc, but then require picking up the mouse to click away the dialog. A toast/notification-style popup (or even catching a standard Enter/Esc or Y/N to clear the dialog), or blinking the console tab could convey the same information with less interference.

Of course, I since discovered that they could (sometimes) be cleared by Tab then Enter, or (reliably) with End, or whatever else is bound to Unlock Alarm

Well there's your problem. You're using the wrong users! Hasn't someone forked a better version yet?

I'm more of an "F5" kinda bat myself, but will do. I'll add the to-do list to my to-do list, if that doesn't cause me to implode into a recursive ball of Yo Dawgery.

Sounds about the way I thought it was working (or not-working), and you just saved me some time digging for the handler. Thanks - I'll try to take a look & see if anything comes to mind.

Not that I expect I'll somehow magically produce a brilliant solution to a problem that you've gone half the year without cracking... but there's something sorta zen about staring vacantly at someone else's code.

But even if I'm not managing anything else useful, I'll see if I can at least get a few of the more concrete issues plugged in on the tracker tonight.


-Bats
(and by "zen" I mean "feels like you're doing something really significant, but doesn't actually accomplish much")

 

I'll enthusiastically second the request. I find that it helps immensely when I'm laying out/mounting workpieces - especially with irregular or scrap stock (ie, most of the time), or to judge how certain features of a toolpath align with patterns in burls or other heavily figured woods. It's also been a lifesaver on more than one occasion when trying to recover (or at least partially salvage) a toolpath that died midway through a long run.

Of course, I'm of the "there should be options for everything and more" school of thought (with, optionally, even more options to turn those options on and off in case you don't like them), which I understand is more or less antithetical to OB's sans settings vision for CONTROL.


-Bats
(and another page of options to set the color & alpha levels of the options that toggle the options!)

 

Hey all,


Last night I had a situation occur that caused the Z to smash into my work piece and bust my bit. I’m not sure if this was an issue I caused or not that’s why I would like to post this to get a solution so it doesn’t happen again.


Here is what happened: (which has never happened before in over a year of using the Lead and blackbox)


I homed my machine and then used the Triquetra to zero work home. I made sure I hit Zero XYZ and started my job……..something didn’t look/feel right (not related to this problem) so I paused and then stopped the job. I wanted to return to work zero so I could check something out so I hit the return to work zero and that’s when the Z smashed into the work piece and the X and Y began to move and snapped my bit. I hit the oh s*$t button and stopped everything.


After saying a few choice words and sometime later I air ran the job without a bit to see what happen. Everything looked good when I paused but when I hit stop the XY and Z values all changed and I don’t know why. I have done this several times in the past with no issues. The machine always returned back to work zero after stopping a job.


Does anyone know what may be causing this? Is this an issue with the latest version of the control?


Thanks,


Ben

 

Not sure if it matters but I didn't hit abort until it slammed into the work piece.

When I thought something was wrong during the carve I hit "pause" then "stop" job. The router turned off like I would expect and then I hit Go To Zero and that when the problem happened. Apparently "Stop job" has that same effect as the abort button in making grbl lose its coordinates?

 

"Pause Job" remembers the coordinates. I think that "Stop Job" doesn't remember the coordinates. You'll get a message saying that homing the machine is recommended.

 

I could have swore in the past that I have hit "stop job" and then returned the machine to work zero by hitting the "go to zero" command.