Estlcam has a GRBL post processor so it should work fine with an Xpro 4. I use it on my Arduino based controller which uses GRBL. I am curious if it specifically says somewhere that the Xpro 4 in incompatible? I could not find it.
Sorry, brainfart I had when mentioning that Xpro 4 is not compatible with using estlcam as crontoller. V4 works as v3 , but not with the Bluetooth bluelink. Only with usb cable. I had issue with interference on my V3 and ordered a V4 with the bluelink and unfortunately that did not work. Unable to flash the V4 board when the bluelink is plugged in. Spoke with Christian about it and he said he will not add it. Now I use Estlcam to generate the gcode and Openbuild Control to send the gcode to my cnc. Sorry for posing misleading info.
Vaguely related (although probably on the opposite side of the safety issue), I noticed that the prohibition on movement or GCode input while paused also makes it impossible to toggle (ie, stop) the spindle or coolant. Oooo... that's kinda exciting! Although... ...this is sort of what I'd gotten in the habit of doing on Mach 3 (even though it does support toolchanges). With my first machine I discovered that I had such lousy luck with getting anything to turn out the way I hoped (or the machine remaining in one piece) on the first try that I was much better off with large projects broken into pieces anyhow. Once I finally moved on to a more reliable machine, I discovered half the problems were the moron operator's fault, and stuck with the practice anyhow. For all my whining about what CONTROL doesn't do, this was by far the easiest limitation to adapt to This is actually close to an entirely different feature I'd love to see - and that's restarting a toolpath from an arbitrary line number. There's nothing worse than being 3/4 of the way through a long program and suddenly hearing a stepper stall - or having a housemate plug in their blowdryer and cause a blackout... or discovering that hole it's about to plunge into will be a half inch in the wrong direction (which would never happen to a careful bat like me) and you need to hammer the E-stop & lose position entirely. It's often possible to re-align the machine reasonably close (at least if you were careful to zero on a reasonably repeatable feature and aren't working to especially tight tolerances), but even if you're patience enough to wait for it all over again, running over the same path (minus a few thou to the left) doesn't always come out so well. Of course, it would be even easier to recover on arbitrary features if the spindle were rendered while jogging, and... Oh. Right. That's why I'd always held off on begging for restart-from-anywhere... it's a bit of a rabbit hole of other features I want. Um... maybe forget I said anything. -Bats (I'm... err... just gonna go back to VFD-shopping now. I think that'd be best...)
Noooo! Frequent updates are gooood! ...just as long as we can tell them to piss off and go wait in the hall because we're busy and/or convinced they'll try to sit on the nice furniture or knock over something breakable -Bats (besides, with any less updates, how would we fix the damage the previous updates did?)
Not to reply to myself, but... ...I just reminded myself of something I've been meaning to ask for a while, Peter: If you look at CONTROL's Troubleshooting tab, The BlackBox's DOOR input triggers HOLD:ON/OFF, rather than the (possibly more intuitive) Door Sensor. Is this intentional? This may (or may not!) be a slightly bigger issue than it seems at first glance, too, as HOLD is just a momentary trigger for Feed Hold. Pressing & holding HOLD will pause the current program, but won't do anything to keep it from being restarted, while I assume (and this may be a bit much of an assumption on my part) that Door Sensor would act as an interlock, and blocks anything from happening as long as it's engaged. It's not a big deal the way I've got it wired up to an "Oh !" button, but if someone's actually using it for a door switch on an enclosure, it's not likely to behave quite the way they're expecting. -Bats (wait... didn't I promise I was going to shut up and go back to shopping?) (but... I hate shopping!)
Well, the one on my CNC is hanging overhead where it's a little hard to see (like any self-respecting bat), but here's the "Oh !" button on my lathe: On the off chance you were actually serious, it was one like this (although you can find a wide variety of formats & prices by searching for Emergency Stop Mushroom Button). I sure as wouldn't trust it with the rated 660V / 10A, but I've got a signal-level interlock on both the lathe's VFD and on the Gecko G540 I was previously using for my CNC. I doubt OSHA would approve, but it works pretty nicely for me. - s (OH BATS!)
So I just did the update and lost connection in the middle of my cut, now it will not let me connect to USB. I assume this is related to the updates? Is there any way I can go back and download an older version?
Some additional information: -USB port still works on the computer -Tried plugging into a different USB port -Switched out to the cable provided with the machine -Restarted computer and PSU -Tried going back to version 1.0.179 because that's the last one I found in my downloaded files, still wont connect to USB -Does not seem to be recognizing a USB device is even plugged in as it is greyed out and says "waiting for USB" This is on a lead 1010 with blackbox btw Have ran tons of programs with zero issues and all of a sudden I download the latest update and now my machine is a paperweight. Maybe its not related to the update...seems unlikely though.
Yes, haven't you notice almost everything we do is intentional (; The DOOR input only works as a door sensor on Grbl with the door interlock compile time option enabled. On regular Grbl that pin is the FEED HOLD input pin (and can be used as such if you prefer): Refer https://github.com/gnea/grbl/blob/master/grbl/config.h#L171-L180 Our main use the door input (enclosure door sensor, stops machine when door opens) - we don't recommend wiring feedhold/cyclestart etc buttons as it a) is planned to be dropped in future version of Grbl, b) can interfere with the software states, etc
The log output what be useful, what exactly does it say? (Serial log tab) Doubt strongly it is update related (otherwise a thousand users would already have also had the same issue) Most likely reasons for unsuccesful connection: - Selecting the wrong port in the dropdown - Incorrect wiring shorting controller (test with everything except USB unplugged)
Yes, but only almost everything *glares at the pushy update process lurking in the corner* Ahhhh... I see. I'd thus far remained blissfully ignorant of the recompilation habits of grbls. So the Door (as opposed to Hold) signal is being dropped, or the whole Door/Hold/DOOR/(dormouse?) deal is being ditched? I'm trying to figure out what I safely can or can't do with my E-stop. Aside from, you know, actually wiring it as a proper E-stop that kills the power. Because I really don't know if I trust it with that much power. Or that much authority, really. But mostly I'm not convinced it won't melt if I hook it up to the mains. -Bats ( the next step is rigging the button to scream YOU WILL RESPECT MAH AUTHORITAH! every time it's pressed)
Take the lazy way out, make a killswitch extension (old video of mine, sorry) E-Stop should cut power, because you never know what will be on fire... It could even be the chinese power strip itself so wire this before any power strip, or other extension or whatever, and make sure switch is "on the way out" so you can hit it when you run too Less of a drop and more of a re-engineer when Gnea finally comes out - got to go look for the old chat with Sonny, can't remember the specifics, but basically that was why we didn't just include those buttons on BlackBox - future proofed edit: Extract from a longer, and sadly private email re pin allocations: " I will likely remove the control input pins and push those to a SPI port, so there are be an infinite number of them."
Looks like you're using the same button I've been afraid to trust on mains voltage (even before reading reviews about how they melted). You're either a braver man than I, or bought yours before they'd resorted to making the innards out of ultra-low density translucent green polycrapolene from half-empty soda bottles and fermented algae. It could even be the Chinese E-stop button itself! (in all seriousness, I've had the power strips apart - they're almost entirely metal and they have very little to burn. The button I'd have genuine concerns about - especially hung from on a wooden loft full of nice, dry, flammable old Christmas garbage) If I need something on the way out, it'll already be too late. If I can't stand & fight it, I won't be able to outrun the all-too-nearby shelf of solvents and aerosols. I really need to make another push for getting all that crap shoved elsewhere - preferably in a proper flammables cabinet - so I can stop babysitting everything so closely. And yes, I really should have a system-wide E-stop for the whole shop... but I currently don't. What I have are, as recently mentioned somewhere, is an Oh ****! button in easy reach of each of the big tools, that can be hammered to bring it to a screeching halt when the circumstances call for it. I neither know how pronounce it, what it stands for, what species of rodent it's meant to resemble, nor quite what it's supposed to be, aside from a Mega-targeted grbl spinoff that's been in the works for at least six years but doesn't seem to talk about itself much by name. Also, it sounds more like a type of gnu than a gerbil. I like the sound of infinite control inputs, but I'm fuzzy on how that would work with the BlackBox. I can't imagine you'd future-proof for future changes that you couldn't support anyhow (that whole "intentional" thing, after all... so would a (theoretically futuristical) gnearbl flash end up taking over the internal "ISCP" header for control inputs? Also, shouldn't that be an "ICSP" header? Or is that a secret message about its possible future applications? -Bats (In-Serial Circuit Programming? In-System Cereal Programming? InSensitive Cultural Prognostication?)
That particular one was from RS if I recall, i think it was a brand name one too and was closer to $30-40 than the $5 alibaba style you refer to. Its been solid for many years now, even comes with the removable switch module at the back Gnea is the "next version" of Grbl, with a HAL, and chip-agnostic (though seems to be targetting the ATSAMD51 as main candidate) Future proof: BlackBox runs an Atmega so, whenever Gnea is real (as you say, 6 years on) someday and we do something with that there'll be a whole new board. I rather meant the psycology, not get users accustomed to something that might go away anyway
Hello, I have run into my first problem with the control software. I am connected, everything jogs fine, nothing seems amiss until I go to run a job. I have my gcode file opened, I see the 3d view, i reviewed it to make sure it wasn't expecting a tool change, but as soon as I hit Run Job nothing happens. The alarm is not on, so I don't know what else it could be. Thanks for your insight in advance.
G90 G21 (Toolpath 2) M05 M0 ;T301 M03S18000 G0X40.77Y21.60Z2.54 G1Z-1.27F304.8 X40.74Y20.63F1143.0 X40.66Y19.65 X40.38Y17.77 X39.91Y15.94 X39.27Y14.20 X38.47Y12.53 X37.50Y10.94 X36.40Y9.46 X35.12Y8.06 X33.80Y6.87 X32.33Y5.76 X30.73Y4.79 X29.01Y3.97 X27.32Y3.36 X25.51Y2.89 X23.59Y2.60 X22.62Y2.52 X21.60Y2.50 X19.67Y2.60 X17.77Y2.89 X15.94Y3.36 X14.25Y3.97 X12.54Y4.79 X10.94Y5.76 X9.46Y6.87 X8.10Y8.10 X6.87Y9.46 X5.76Y10.94 X4.81Y12.52 X4.00Y14.19 X3.36Y15.94 X2.89Y17.77 X2.60Y19.67 X2.52Y20.65 X2.50Y21.66 X2.60Y23.59 X2.89Y25.51 X3.36Y27.32 X4.00Y29.08 X4.81Y30.75 X5.76Y32.33 X6.87Y33.80 X8.14Y35.20 X9.46Y36.40 X10.94Y37.50 X12.51Y38.46 X14.20Y39.27 X15.94Y39.91 X17.77Y40.38 X19.65Y40.66 X20.63Y40.74 X21.66Y40.77 X22.63Y40.74 X23.61Y40.66 X25.51Y40.37 X27.32Y39.91 X29.07Y39.27 X30.75Y38.46 X32.33Y37.50 X33.80Y36.40 X35.20Y35.12 X36.40Y33.80 X37.50Y32.33 X38.46Y30.75 X39.27Y29.07 X39.91Y27.32 X40.37Y25.51 X40.66Y23.61 X40.74Y22.63 X40.77Y21.60 Z2.54 G0 G1Z-2.50F304.8 X40.74Y20.63F1143.0 X40.66Y19.65 X40.38Y17.77 X39.91Y15.94 X39.27Y14.20 X38.47Y12.53 X37.50Y10.94 X36.40Y9.46 X35.12Y8.06 X33.80Y6.87 X32.33Y5.76 X30.73Y4.79 X29.01Y3.97 X27.32Y3.36 X25.51Y2.89 X23.59Y2.60 X22.62Y2.52 X21.60Y2.50 X19.67Y2.60 X17.77Y2.89 X15.94Y3.36 X14.25Y3.97 X12.54Y4.79 X10.94Y5.76 X9.46Y6.87 X8.10Y8.10 X6.87Y9.46 X5.76Y10.94 X4.81Y12.52 X4.00Y14.19 X3.36Y15.94 X2.89Y17.77 X2.60Y19.67 X2.52Y20.65 X2.50Y21.66 X2.60Y23.59 X2.89Y25.51 X3.36Y27.32 X4.00Y29.08 X4.81Y30.75 X5.76Y32.33 X6.87Y33.80 X8.14Y35.20 X9.46Y36.40 X10.94Y37.50 X12.51Y38.46 X14.20Y39.27 X15.94Y39.91 X17.77Y40.38 X19.65Y40.66 X20.63Y40.74 X21.66Y40.77 X22.63Y40.74 X23.61Y40.66 X25.51Y40.37 X27.32Y39.91 X29.07Y39.27 X30.75Y38.46 X32.33Y37.50 X33.80Y36.40 X35.20Y35.12 X36.40Y33.80 X37.50Y32.33 X38.46Y30.75 X39.27Y29.07 X39.91Y27.32 X40.37Y25.51 X40.66Y23.61 X40.74Y22.63 X40.77Y21.60 Z2.54 M05 M02
Use a Grbl compatible CAM/Post Processor M0 is a Pause - not sure why thats in there, but seems to be accompanied by a Toolchange, Grbl doesn't support Toolchanges. Refer M Codes
What it looks like is the T was intended to be commented out with the semicolon (I don't whether it was an attempt to edit it out, or if it was just inserted by the post as a reminder of which tool was intended). I don't know which posts use semicolons for comments, although I know I've seen them before (apparently at least Siemens uses them) - never mind a mix of semicolons and parentheses - but that could definitely cause some confusion. Either grbl barfs on the toolchange, or it randomly pauses on the M0 when the user has no reason to expect that they'll have to unpaause. Probably best to just drop the whole line, since there's not much point to a pause that early in a program anyhow. You might want to offer a little more of a warning with that link, seeing as it is the linuxCNC reference, not a grbl-specific one, and happens to include a lot of functionality (say, for example, toolchanges) that grbl lacks. Speaking of pausing, Peter, I haven't noticed any options for controlling it in CONTROL, but does grbl/BlackBox support M1 optional pauses? I really liked being able to throw them in as toggleable breakpoints on troublesome or risky toolpaths in Mach 3. -Bats (Sure, I could go and try it... but using a machine I can't cut with depresses me. Just ask my poor mill.)
Not specifically, but tag a note onto Toolchanges · Issue #26 · OpenBuilds/OpenBuilds-CONTROL - catching it will be about the same as catching M6 except don't launch the toolchange UI
v1.0.223 released, another nice big release - New XYZ Probe Plus and Custom XYZ Probe wizards - New Probe Button on Main toolbar - Added support for custom Keyboard shortcuts to Macros (Issue #78 partially) - Added Keyboard shortcut for GotoZero (Issue #115) - Added Keyboard shortcuts for switching between Incremental/Continuous jogging (Issue #121) - Fixed File Association Opening bug (Bug #119 ) - Added loaded Filename to titlebar (Issue #116) - Added shortcut key F6 to jump to console (Issue #112) - Changed Keybinding for Devtools to ctrl+shift+i Also checkout:
I have my own touch plate and currently use the exterior edges. I have attempted to create a macro to use the hole and eliminate the need to use a specific diameter bit. Looks like you've added the interior probe capability and solved the problem I was working on. Is the probe hole a particular diameter or does the probe software routine accommodate various diameters.
Not sure if anyone else had this issue but just updated and all of my macros disappeared. Not a huge deal since most were all probing macros anyway. Are these stored anywhere?? I've actually found 1 issues now: 1: It doesn't appear that I can add new macros. If I find anything else, I'll update this post.
Will see if anyone else reports similar, it shouldn't and didnt in testing. Maybe something in a macro that tripped it. Ctrl+shift+i > Console for clues while adding macro?
just tested with my probe, works fine. If you need an algorithm using the hole that does require known bit size, let me know. I couldn't get GRBL macro to store values and do simple math.
