Thanks @sharmstr !!! I got me endstops setup correctly/completely so I could feel comfortable running the home all, in doing so, I realized I would have to revert my override of the default profile to invert x and y as it was homing opposite the endstops. A quick fix, reset, and it homed correctly and now Im going to have to get used to working in negative space as Ive read is common. Thanks for the link, I only had time to skim it, it is exactly what I needed!!! Ill have to take some more time to go through and learn that page proper. Much thanks! -B
Does the machine have homing switches? The behavior you describe indicates that it does not. When there are no homing switches GRBL sets machine home to wherever it turns on or resets. It also defaults G28 to 0,0,0 unless you change it (and it remembers the change). So it looks like your are turning on (connecting the software will also do a reset) with the router in the middle of the machine. While this can work there is a better way. We fake the home position! Industry convention is that home is at the positive ends of travel, so if we put the router at X+ Y+ and Z+ we can call this home. Just push it there (if belts) or jog it there (if screws) and then reset the controller. Now GRBL regards this as machine 0,0,0. Now we have a bunch of advantages: G28 offsets will always be in the same place on the machine, I use this as a place for tool changes. Work offsets (WCS like G54) are remembered correctly through power outs. Thus if you are busy on a cut and the power fails or you have to Estop for some reason, the work 0,0,0 is remembered in the correct place. (I always check Z height after this, and especially after a tool break the Z offset will change) We can easily position a fixture and cut many items in the fixture over many days without having to reset WCS offsets, even with turning off everything and turning on again the next day. But how to ensure that this always works? All we have to do is always switch off in the home position. I use macro for this G53 G0 z0 G53 X0 Y0 If power fails, we only have to push or jog to that position and reset and we have our work coordinates back and can continue. you cannot enable homing until all the switches work. If homing is enabled, you HAVE TO home before doing any work. (G28 is not a homing command, G28 is only a remembered position that can be used for toll change or material change etc. It is an offset from the home position so without a good home G28 is useless)
'Homing' means setting the machine coordinates to 0,0,0 in a defined position. You can set up a macro to reset the work coordinates but really you already have buttons for that. ^ those buttons there set work coordinates to 0 at the current position. So if you want it to be the same as machine 0 then either press 'gotozero XYZ' if you have home switches or give commands G53 G0 Z0 ; safely raise z G53 G0 X0 Y0 ; go to home and then press the 'setZero XYZ' button
After I click on the "Home" button (picture of house), the machine goes to the home position but the coordinates are not 0,0,0. This happens after I turn on the machine and computer. I almost ruined a job after I forgot to click on the "SetZero XYZ" button.
setting work coordinates is a normal part of every CNC job. you have do it every time. this is not what home is for. home is so the machine knows about itself. work coordinates are so the machine knows about your workpiece.
@Peter Van Der Walt We got a problem. I cant reproduce, but I have a screenshot for you. The other day, @Blake Barr contacted me asking why the Z probe wizard would switch to inches per min on the feed rate. I told him he was crazy and to quit drinking in the shop. .180 had just came out so I tested both .179 and .180 and couldnt reproduce. I explained to him again that he was crazy. Today I was setting up a new job. I manually set x and y 0 using the set buttons (something he had done as well). Then I used the Probe Z wizard. I have never changed my feed rate in the wizard so its set to 100mm per min. I clicked the probe button and my bit slammed into my probe plate. In the screen shot you can see that it used my jog feed rate, not the feed rate in the wizard. Then when I retracted it slammed into my Z limit switch (which is a good 40+mm from where Z0 is after probing) as you can see below. I've since run it again like 4 times without issue. Good luck You're going to say its emi
Would it be possible to add a cancel or way to close the new pen modal that pops up when you mistakenly press the new buttons that are next to the Z jog buttons?
I've been using GRBL Panel since I started working with the Openbuild platform as I found it to be the best available. The issue is that it is starting to become outdated and is no longer supported. I'd say PAnel and OBCS are on par with each other at the moment, but there are a few things that would tip the scale to OBCS. One nice feature from Panel was the ability to change jog distances. It was mentioned once already, but the response was to use continuous jogging which makes it impossible to move a set distance. Convenient jog distances are all based on machine size and tolerance range. For instance, I used 0.05mm, 1mm, 10mm, and 50mm. That was for a 300mm x 300mm machine purposed for aluminum. Someone with a 1000mm x 1000mm travel for wood working may want the preset values. The second feature that I enjoyed was adjustable jog speed. Just like the distance, there were four click boxes with adjustable values. If we're talking convenience, clicking a box definitely beats getting to the keyboard and typing new values. The third would be WCS (G54-G59). You can type in which ever work coordinate you want, and the current zero coordinates will appear. One of the drop down menus on the side in Panel would let you select which WCS you were working in. This is a minor compared to the jog functions, but I figured I'd mention it.
As always, feedback is welcome but, some counterpointing is in order (as there are goals behind the scenes thats not always apparent) and Up for a challenge? @Kevon Ritter It doesnt come up often enough as a problem, just from users thats kinda used to some other application's way. There is a large todo of more important issues but let's throw down a challenge: Show me something soooo good it can convince the whole team: I've setup a Boilerplate here: https://codepen.io/petervanderwalt/pen/ymaeBK - fork it, and build a Better jog panel! If someone comes up with one thats not only more efficient, but also looks better, and makes things even easier (; Well - then i'll be sold See below though, must do all that without needing the user to configure anything (so no dialog to setup your preferred jog distances etc) - (bonus points for something that is unique and not just doing the same thing all the CNC/3D printing apps does) Wouldnt jogging at maximum speed, with properly tuned acceleration do fine? I've not seen a need myself, except if you are using jog for manual machining? The big thing about this is to absolutely hide all the WCS stuff as all it does is confuse beginners (which CONTROL is actually made for - for years the entry learning curve was steep, the idea with CONTROL was not to just add another host, but to add an Easier to use host...). Thats the overshadowing mission at the bottom of any decision. That and it should "just work without needing any configuration" - ie it sets itself up as far as possible
@sharmstr I had this happen to me a couple of times, and after some head scratching I figured out what had happened. I had ran a g-code file that was in inches (g20 sent at the beginning of the file), my machine remained in inch mode after the file completed. Later when I used the Z-probe my machine tried to move 25 in. at 100 ipm. . Since then I send a g21 from the console before I use the Z-probe. I don't know if you had the same situation, just thought I would throw this out there.
Thanks for the feedback. I am on leave today, but will test on Monday. If its reproducible consistently, its easier to fix.
ah now...... I normally use bCNC but last night I swapped to OBCS for a job precisely because it has continuous jog AND a settable jog speed. This means I was able to quickly reduce an extra bit of material by 2mm just by jogging around at a 'feedrate' without having to do any drawing or use a wizard to create gcode. and I really liked Candle because of the same continuous jog but ditched it because it never sets G54 offsets instead always using G92. This means it forgets your work offset everytime it resets.
Exactly why i am keeping the input (we all do a bit of manual machining sometimes right) , but it remembers last value and stays that way. For actual jogging i dont see a need to vary the feedrate all the time as suggested
Understand. But my gcode files are in mm. The Fusion post I use doesnt use imperial at all. It will error out if you try to. If you look at my screen shot, you'll see the G21 commands. However, when trying to figure out what happened, I did think it odd that Peter isnt specifying G21 in the initial probe command. I will say that earlier in the day I did mistakenly press "inch-mode" when trying to load a file. I immediately switched back to mm, opened the file and ran the job. But even when you switch to inch-mode in Control, all move commands sent are converted to mm. (1" move in x+ sends G91G21X24.4). In other words, I dont think a G20 command has ever been sent to my machine. Ever. I appreciate your input though.
That is a conundrum indeed! Always hardest to get the reproducible pattern. Any chance either of you (adding @WJC) are playing with none G54 coordinate space before probing? (just asking on a hunch)
I had just changed bits between jobs, so no. For my own education, what are all the $J=G9121X-10F4978 that are issued after I pressed the probe button (in my screen shot)? I could understand why they would be there before I probe since I do jog the bit down close to the plate before probing.
nm. I was reading it wrong. I thought you were using G28 commands and that those jog lines were happening during the probe routine.
so I have now ruined another bit because of Probe Z. Probe Z has now cost me nearly $75 dollars and put me even further behind on getting projects completed. Getting pissed about this problem is now becoming a search for better software. And this is NOT an EMI problem. here is the gcode: X0, Y0 were set manually prior to probe Z. Yesterday I did this same thing and the first time it probed, had the same problem. retracted and ran probe again and it worked as it should. I did not look at the console to see if when it retracted it set coding to G21 but I bet you it did which is why probe Z worked the 2nd time. Notice G20 yet it set Z to 19.72mm (my touch plate thickness). I read and operate in inches and it probed (or attempted) 19.72" at 100ipm. Z callout was set to 19.72" (not the mm counterpart) after it broke the bit and completed the command. Why is this a difficult fix? Seeing G20 there sticks out like a sore thumb. Since your probing featuring are set to run in metric regardless whether you operate the software in inches, why cant you just change the code for probing to always be set to G21? Am I missing something here or why does this sound like a really simple fix? Or just dont let people use inches if you know its a problem. EDIT: Now that im not so pissed, i am looking this over and i am going to explain in depth what i am doing: I am manually setting X0, Y0 and then manually inputting half the cutting diameter into X and Y, then setting that position to 0 to get true zero. that is where G20 is coming from. then i jog 5ish inches in X+ and Y+ to get into position for the probe. You can see G21 in the jogging commands but it makes me wonder if G20 is still overriding G21 since its a callout for a G21 jog to position vs a solid G20 or G21 command like at the top of the Gcode i have listed. [ G0 X.03125 ] ok [13:02:49] [ G20 ] ok [13:02:49] [ G0 Y0.03125 ] ok [13:02:52] [ G10 P1 L20 Y0 ] ok [13:02:52] [ G10 P1 L20 X0 ] ok [13:02:58] [ $J=G91G21Y25.4F5000 ] ok [13:02:59] [ $J=G91G21Y25.4F5000 ] ok [13:03:00] [ $J=G91G21Y25.4F5000 ] ok [13:03:01] [ $J=G91G21Y25.4F5000 ] ok [13:03:03] [ $J=G91G21Y25.4F5000 ] ok [13:03:05] [ $J=G91G21X25.4F5000 ] ok [13:03:06] [ $J=G91G21X25.4F5000 ] ok [13:03:07] [ $J=G91G21X25.4F5000 ] ok [13:03:08] [ $J=G91G21X25.4F5000 ] ok [13:03:09] [ $J=G91G21X25.4F5000 ] ok [13:03:18] [ $J=G91G21Z2.54F5000 ] ok [13:03:20] [ $J=G91G21Z2.54F5000 ] ok [13:03:21] [ $J=G91G21Z2.54F5000 ] ok [13:03:22] [ $J=G91G21Z2.54F5000 ] ok [13:03:49] [ G10 P1 L20 Z0 ] ok [13:03:50] [ [ PROBE ] ] Probe Completed. Setting Z to 19.72mm [13:03:50] [ G38.2 Z-25 F100 ] [PRB:128.301,-533.370,-4.628:1]
As you know its broken, do not use it! Jog Z down manually, click Setzero. Not too hard, and surely cheaper and less frustrating. When the bug is fixed you'll see a notice in the Changelog on the troubleshooting tab, or also hosted here: OpenBuilds/OpenBuilds-CONTROL See OpenBuilds CONTROL Software and the other related ones around it - we don't say its EMI. We were still discussing the root cause a) there is a long todo list: Build software better, together is just the CONTROL/CAM one - and priorities just like any other organisation b) So far I've had two users reporting the issue, you'd be the third. Relatively low priority for a bug thats not really reproducable yet (up to the last discussion at least, sounds like you have a pattern of how to make it fail, so can now try again) and c) it was first reported on 20 July. Just 11 days ago - so hold your horses Well, thats putting a bandaid on it but sure, checkout v1.0.183 (compiling now - test it later) . There's a quick way, and a right way. The right way will be when I have the probing wizard switch to Inch too when the user is in inches (; - of course thats more work too so will stay on the todo for now Of course, @sharmstr works exclusively in mm mode and had it happen to her too So... still up for debate if G21 fixes it
Is there a difference in the background between a standalone G20/G21 code (like the G20 listed at the top of the code i posted) vs a G21 Jog code? Does the G21 jog code reset the coding to G21 or is that jog code in G21 remain only for jogging?
@Blake Barr : OpenBuilds/OpenBuilds-CONTROL v1.0.183 is up (adds G21 before probing as you wanted to test with)
As per Grbl Wiki > Jogging gnea/grbl : We do use the override, which is active just for the jog command then
OHHHHHH. Sorry for the wrong info Blake. I wasnt aware of that. Normally, as I mentioned in our chat its modal. But as I also said in our chat, I'll take Peters word over anything I say. LOL Peter, just to let you know, since Blake (and from the looks of it WJC) have run into this problem several times, I've suggested that he create a macro for Z0 probe that calls out a G21. I understand that it may be a bandaid, but would be interesting to see if in doing that the random problem goes away or happens again.
I will keep you updated. I made sure to make g20 active prior to probing and adding g21 prior to probe Z appears to have solved the problem.
Good idea, but note that v1.0.183 will do: addQToEnd('G21'); addQToEnd('G10 P1 L20 Z0'); addQToEnd('G38.2 Z-' + data.dist + ' F' + data.feedrate);
