um, no..... a G0 move should move at 10000mm/min according to your $110-$112 settings. a G1 move will move at whatever is set by the F word, G0 always uses the maximum rate settings. According to this calculator GRBL settings calculator 10000mm/min at 200steps/mm will exceed a 30khz step rate, which GRBL simply cannot do properly, behavior will be 'odd' at step rates over 30khz. Set your max rates to 8500mm/min and test....
See the Acceleration calculator on RepRap Calculator - Prusa Printers Acceleration and deceleration is a fact of life - you cannot entirely beat physics Compensation would be something like 1min20/1min * 1000mm/min. But for actual lasering the burn result is more relevant than the precise speed - do some Calibration burns
Can someone help me understand why a jog move after a probe doesnt go the programmed 5mm distance? Here's log of what I'm doing. Code: [09:14:30] [ ? ] <Idle|MPos:-100.001,-100.001,-100.000|FS:0,0> // Here you can see that the starting point of the probe is Z-100 in mcs [09:14:38] [ G21 G17 G91 ] ok [09:14:40] [ [ PROBE ] ] Probe Completed. [09:14:40] [ G38.2 Z-25 F100 ] [PRB:-100.001,-100.001,-103.526:1] // Probe triggered at Z-103.526 [09:14:40] [ G38.2 Z-25 F100 ] ok [09:14:40] [ G4 P0.4 ] ok [09:14:40] [ $J=G91G21Z5F1000 ] ok // Now jog up 5mm [09:14:40] [ G90 G21 ] ok [09:15:22] [ ? ] <Idle|MPos:-100.001,-100.001,-98.619|FS:0,0|WCO:-100.000,-100.000,-100.000> //Machine coordinates now show Z-98.619. Expecting -98.526 There's a difference of .093mm.
According to grbl when I get the machine position (MPos) via ? FYI - I'm not using G10 to set anything. I'm merely probing down and then moving back up 5mm. See the log above and you'll see that it found the probe at -103.526 and then moved up 5mm. I would expect that ? would tell me the machine is now at -98.526 but its saying -98.619.
Ahh i see it there yes. Nope, got me stumped Guess attempt 1: after hitting the probe, Grbl decelerated for a little bit before coming to a stop, resulting in minor diff between probe hit point and point it stopped moving? See if probing at F50 vs F100 halves the error too?
I'll try it it but I'm doing it from my desk. No machine. Just an Arduino with a probe switch attached. I was just curiously really and trying to know more about how this stuff actually works. The difference isnt enough to make a real difference.
Noted, but the deceleration i am referring to = firmware Probe interrupt triggers, maybe (just a wild theory) Grbl's code takes a couple more steps / cpu cycles / polling cycles of some kind to come to actually come rest?
You're probably on to something there. Lowering the feed rate to 10 dropped the average difference to in the .030mm.
yep, acceleration time. that is why you always probe twice, 2nd time much slower. with my Z probe I have found that if I always probe at the same speed I can rely on the trigger point to be accurate as calibrated. go faster or slower and the trigger point will move a bit, so there is definitely some internal difference between the trigger point and the processing of the trigger point. polled not interrupt? don't fee like delving in the source now.
Not really worth looking into. Was just making sure it wasnt my code or something else happening in control. I suppose instead of specifying a 5mm move, one could get prb and do a calculation to come up with exactly 5mm. But I'm just using it to move off the probe. It did get me to thinking about how this would effect the efficiency of collecting cloud point data but that's for another day. Thanks, guys!
Q3HB64MA drivers hey ive picked up an old laser cutter for free but it had an old Leetro controller and as it didnt come with the usb dongle i cant use the software so until im ready to buy a ruida controller i was going to setup GRBL on an uno however i am lost as to how and if i can connect the stepper drivers that are in the machine to the uno as they dont have an enable pin and they have pulse and direction + and - pins is it posible to drive these with Grbl this is the driver i have 71.0US $ |3phase hybrid stepper motor driver Q3HB64MA|driver stepper motor|motor monitordriver - AliExpress
which just means they are enabled all the time.. but they do have it called 'motor free signal' in the docs connect all the - pins together and to signal ground on the Uno (NOT motor power supply ground!) connect the + pins to the relevant step and direction pins on the Uno This is the same connection scheme as for DQ542 drivers which have been described before in these forums and elsewhere 3 phase motors, cool, but hard to replace as they are not often stocked
Hi, guys, I have a couple issues. I'm using GRBL to operate our CNC mill and will list my settings below. Up until now, we've used our mills for a long time with issues I've usually been able to solve with tinkering and minor adjustments. My first issue is that I am experiencing random stalls on my X-Axis right away when I initiate an NC file. I can manually tell the X axis to move and it runs great, but within the first 2-3 seconds of a file, the X axis will halt even though GRBL shows it as still moving (no error code and the mill continues to run). This has happened in the past and usually cleaning the machine and restarting it a couple times "fixed" it. The next issue is that when it does run, it has lately been naturally stopping and I've been presented with the following windows error: "See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt) at System.Convert.ToDecimal(String value) at GrblPanel.GrblGui.showGrblPositions(String data) at GrblPanel.GrblIF.raiseAppSerialDataEvent(String data) at GrblPanel.GrblIF.VB$StateMachine_40__client_ComReadData.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.8.4420.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- GrblPanel Assembly Version: 1.0.9.18 Win32 Version: 1.0.9.18 CodeBase: file:///C:/Users/millright/Downloads/GrblPanel-Release-1.0.9.18A/GrblPanel.exe ---------------------------------------- Microsoft.VisualBasic Assembly Version: 10.0.0.0 Win32 Version: 14.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.8.4360.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.8.4455.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.8.4400.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.8.4390.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.8.4190.0 built by: NET48REL1LAST_B CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- RepeatButton Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///C:/Users/millright/Downloads/GrblPanel-Release-1.0.9.18A/RepeatButton.DLL ---------------------------------------- Accessibility Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- System.Data Assembly Version: 4.0.0.0 Win32 Version: 4.8.4455.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll ---------------------------------------- System.Numerics Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box." At first I thought to blame the file itself and had my people double check it and resubmit, however the issue persisted and was replicated on other files that have previously worked. It should be noted that while it stops every time, the error message only appears 50% of the time. Here are my GRBL settings: imgur.com Any help would be vastly appreciated as a lot of responsibility has fallen onto me to solve this despite never having worked on a CNC mill until just a few months ago. I was just thrown into this and left to my own devices.
Sorry I can't help with your grbl panel problem, but have you tried a different control programme such as Openbuilds Control? docs:software:openbuilds-control [OpenBuilds Documentation] Alex
that error Smells like USB corruption to me. Use a high quality SHORT USB cable and keep it away from power cables (AC and motor power). The X stopping is possibly a stepper driver overheat. What drivers are you using? Could also be that your rapid speed is right on the edge of stalling and the slightest increase in resistance in the leadscrew makes it stall. Reducing max rate and acceleration will prove this. Keep in mind that the faster a stepper motor turns the less torque it has. You have limit switches, therefore EMI is possible, but you should see a related error message. I don't know if GRBLpanel knows how to display that properly though, not updated in 3 years.
Thank you so much. I reduced the max rate accel. by about 30% and this fixed the stalling issue. Crossing my fingers that cleaning the USB ports and switching USB cables solved the other problem.
I am missing the boat on jogging and working with a new origin. Let's say I want to jog 300 in some direction and work from that new offset. I select G54 and even reset it to X/Y/Z=0 with a G10 L2 Px. I also issue a G90. My subsequent G1 moves will still reference the machine coordinates, not the G54. I must be making it harder than it is - how is something like this done? Do I issue a G91? Send only relative moves? Thanks!
No, stick to absolute moves. G10 L20 will set current wcs zero at the current location. G1 (or any movements) can only reference the MACHINE co-ordinate system if there is a G53 at the beginning of the line, so I suspect something is wrong with your setting the wcs zero. What was the full command line you entered with G10? Alex.
Thanks Alex, It's not working for me, but hear is what I'm trying today: $J=G91 G20 F50.0 X100 - issue this 3 or 4 times to get to where I want to start a job G90 'g92 x0 y0 z0 - not sure this works to zero WCS G10 P1 L20 X0 Y0 Z0 - seen this both ways, tried both G10 P1 L2 X0 Y0 Z0 - they do appear to zero G54 WCS G54 F100 G1 X100 Y0 - draw a little box, but G1 X100 Y100 - backs up to machine 0-0-0 G1 X0 Y100 - when I'm trying to place the job G1 X0 Y0 - to my jogged position Something is out of order somewhere or I'm missing something!
Thanks Peter, if you look, yes, that does seem to zero the G54 WCS. But, my subsequent G1 moves revert to the G53 machine coords regardless. If you can tell me how to jog to a position, zero the G54, and then work in G54 I'd appreciate. It is possible I'm going something else wrong, or somehow putting it back into G53.
Only "G53 G1" can move in G53. G53 is nonmodal, only applies to lines it starts with. G54-59 is modal (applies since being set until set to something else) Jog where you want to be. G10 L20 P0 X0Y0 (assuming you only want to zero XY and keep Z tool length). Done Or just use OpenBuilds-CONTROL it has a SETZERO button, Coordinate system indicators, etc (;
You can't "put it into G53" unless you put G53 at the beginning of the line - G53 is non-modal - it only applies to the line it is on. You can't accidentally drop into G53 co-ordinates - that's impossible. Just to clarify - for your experiments - are you homing the machine first, then jogging to the middle of the bed so you definitely have enough room around your wcs zero position for the G1 moves? I notice your jog moves were only in X - if you were at the MACHINE co-ordinates zero when you started (X right, Y back) and then issued a G1 Y positive move you would be moving beyond limits. And a thought occurs to me as I type this - can you confirm that when you jog X+ve moves right and Y+ve moves back? Alex. PS - send G54 first - then you know everything you are doing is in that wcs.
Have I lost my mind? Or has page 47 of this thread disappeared? I can't find any of the helpful information from @Peter Van Der Walt Thanks!
Moved our ongoing discussion to a new thread as it got a little long and on point to your specific implementation. You should have a Notification under the flag icon in top right corner:
Does anyone have an idea of what could cause me to need to adjust my Y offset by ~120 out nowhere? Nothing has changed today, but everything I've tried running just runs... low.
Yep, everything goes right home when told to and no other issues. After I shifted the offsets (ended up being about 90-100 difference), you wouldn't be able to tell anything changed.
