I'm new to grbl. I need a basic two axis setup with two motors per axis. I'm not sure if grbl even allows it as its a 3 axis only solution as per my understanding and search. I was able to clone X axis by using the jumpers on the shield shown here. This works great. For Y axis I could not find any help googling. So I shorted Y.STEP/DIR pins with Z.STEP/DIR pins respectively. This kind of works... but the Y motor and Z motors run at different speeds. Below are my parameters: Code: >>> $$ $0 = 10 (step pulse, usec) $1 = 25 (step idle delay, msec) $2 = 0 (step port invert mask:00000000) $3 = 0 (dir port invert mask:00000000) $4 = 0 (step enable invert, bool) $5 = 0 (limit pins invert, bool) $6 = 0 (probe pin invert, bool) $10 = 3 (status report mask:00000011) $11 = 0.010 (junction deviation, mm) $12 = 0.002 (arc tolerance, mm) $13 = 0 (report inches, bool) $20 = 0 (soft limits, bool) $21 = 0 (hard limits, bool) $22 = 0 (homing cycle, bool) $23 = 0 (homing dir invert mask:00000000) $24 = 25.000 (homing feed, mm/min) $25 = 500.000 (homing seek, mm/min) $26 = 250 (homing debounce, msec) $27 = 1.000 (homing pull-off, mm) $100 = 250.000 (x, step/mm) $101 = 250.000 (y, step/mm) $102 = 250.000 (z, step/mm) $110 = 500.000 (x max rate, mm/min) $111 = 500.000 (y max rate, mm/min) $112 = 500.000 (z max rate, mm/min) $120 = 10.000 (x accel, mm/sec^2) $121 = 10.000 (y accel, mm/sec^2) $122 = 10.000 (z accel, mm/sec^2) $130 = 200.000 (x max travel, mm) $131 = 200.000 (y max travel, mm) $132 = 200.000 (z max travel, mm) ok Not sure why it is happening... I mean if both Y and Z motors are getting same signals then both shall run at same speed.... I'm sure I am missing something here Any help would be great !!!
Grbl 0.9 is from 2016 - checkout Grbl 1.1 the Wiki has a section on 2 axes machines too. Cloning an axis is purely electrical (connect signals from microcontroller to stepper drivers in parallel)
how about doing it in the Gcode? if you have G1 Y16 Z16 then both Y and Z will move together to position 16. whether Y and Z are parallel to each other or not won't matter, GRBL does not care. The downside is that all arcs will have to be linearized since GRBL does still believe Z is at right angles to Y.
Thx Peter n David... As you pointed I had issues with the cabling I had don. So now things are fine. I moved to grbl v1.1h also I'm using UGS for configuring the machine as below: ^Y | | | | | | | | | |--------------------------->X origin At this point I did step calibration and did not enable limit switches and homing. I created a small text in netscape and generated gcode, loaded it in UGS, move the motors manually close to origin->Reset zero-> run gcode. Things worked as expected. Next, I started enabling limit switches and homing. Since grbl wiki says that : "By default, Grbl assumes your homing limit switches are in the positive direction". Match that I had to reverse my motor settings to : Code: >>> $3=0 ok >>> $3=1 ok ISSUE: Next I enabled the limit switches. I've placed two limit switches for X and Y axis. I wired them to be NC and inverted in UGS: I Tried homing and it worked fine !!!! But now after homing when I tried to run the same gcode as was tried before enabling switches, I Immediately get this error: Code: >>> G03X38.7887Y53.0736Z-0.125I-13.5493J12.1126 [Error] An error was detected while sending 'G03X36.4844Y49.8471Z-0.125I-3.9093J8.4457': (ALARM:1) Hard limit has been triggered. Machine position is likely lost due to sudden halt. Re-homing is highly recommended. Streaming has been paused. [Error] Error while processing response <An error was detected while sending 'G03X36.4844Y49.8471Z-0.125I-3.9093J8.4457': (ALARM:1) Hard limit has been triggered. Machine position is likely lost due to sudden halt. Re-homing is highly recommended. Streaming has been paused.> >>> G03X40.5412Y57.0847Z-0.125I-19.3235J10.831 [MSG:Reset to continue] The gcode generated by inkscape is trying to move X and Y in +ve direction, which is towards the limit switches. But I am already at my homing position !!! How to get past this ? Is there any settings I need to change .... Pls suggest
Where are your limit switches? +Y goes away form you, +X goes to the right. then the switches are away and right. if your switches are close an dleft, you need to reverse only the homing directions, not the directions of the axes themselves. Now you jog to where you want to start and then use the 'set zero' buttons to set work zero at that point. The Gcode runs relative to WORK zero, not machine zero (which is set by homing)
Hi David, in the meantime I experimented with the settings whole night, checking the thread multiple times I got it somewhat working but still the logic I could only understand from your comment.... So is that a thumb rule for 2 axis mcs : Considering one corner as origin my +X goes to right and +Y goes away, so thats correct. My both limit switches are on the origin. Both limit switches are NC. I've inverted them in UGS $5=1. In Enable homing settings I'm using $23=7. One other thing not sure if that affects, I have connected the Limit switches to X- and Y- on arduino shield... Is that correct ? My sequence is -> home -> Reset zero -> run gcode this seem to work but only without soft limits.... no matter what I set soft limits to my gcode always fails with : Code: [Error] An error was detected while sending 'G00Z5': (ALARM:2) Soft limit alarm. G-code motion target exceeds machine travel. Machine position retained. Alarm may be safely unlocked. Streaming has been paused. [Error] Error while processing response <An error was detected while sending 'G00Z5': (ALARM:2) Soft limit alarm. G-code motion target exceeds machine travel. Machine position retained. Alarm may be safely unlocked. Streaming has been paused.> [MSG:Reset to continue] Attached are my gcode settings and gcode. i'm just starting with cnc, so not good at analysing directly gcode. I'm sure I'll get better with time
not a "rule of thumb", a pretty hard law of cnc machines all over the world, axis directions obey the 'right hand rule'. on the rare machine where this absolutely has to be broken you would need lots of operator training and even more hardware and software safety interlocks. so, for a flat bed router type machine X is side to side , + on the right Y is front to back, + at the back (note this is tool movement, if the bed moves it appears to be reversed, but the TOOL still moves + to the rear and right) Z is up and down, + is up (this makes any negative Z movement a 'cut'). so the limit switches are at front left? (maybe a picture will make all this clear to us?) if they work, then yes (-: that is trying to move Z up by 5mm, but as I understand it your machine does not have a Z axis. Your Gcode should not have Z moves in it at all. You can work around it by moving Z down before starting the cut, just jog down 'far enough' and then 'setzeroZ'. Now it thinks Z has space to move up from the WCS 0. So in this case if you move down 6mm, it has room to move up 5mm and 1mm spare space, without triggering any alarms. To avoid having Z moves you probably need to use a laser toolpath.
It's a hot wire cutter... I m using 4 motors... X and A are cloned... Y and Z are electrically shorted on the grbl shield... Pics attached... Excuse me for messy workspace So I guess workaround will not work for me as y and z are shorted. All motors are driven by seperate drivers. Not sure why inkspace is generating z movements for a plain 2 d image though.
But are they really? Blending the Y and Z signals and potentially inducing backfeed into the Y channel? If I was looking to create a clone signal I’d be pulling the step and dir pins from the Z driver and wiring the holes back to the matching pins on the Y driver, reducing the Z socket to power only but theoretically turning the driver into a Y2. May not work as I don’t know jack about electronics but logically seems the best place to start. (I would also probably try it on a push-in proto board before I went to snipping any pins)
Thx for the pointer David.... I removed all Z axis movements from the gcode and now it works as expected and also triggers the soft limits correctly !!! Hurray So my first learnings just to summarize : - While selecting the motor wiring/ direction, "right hand thumb rule" is the deciding factor not the direction motor rotates. X+ towards your right, Y+ away from you(find that corner of your m/c) - The Gcode runs relative to WORK zero, not machine zero (later is set by homing while former by Reset Zero cmd) - Homing does not depend on the X/Y axis direction, but on where you place limit switches. In case, you plan to set homing in -X and -Y direction, you just reverse the homing directions not the actual axis direction. e.g. if you have X axis limit switch on left(-X direction) and Y axis on away from you(+Y) then for homing correctly, you must use $23 =1 or 5(for 2 axis machines). - In case using NC switches, Invert the switches by setting $5=1, Irrespective whether you are using them on -ve axis direction or + direction. I guess grbl internally wants NO switches... Correct ? Can we have combination one NO and one NC ? But $5 is only one variable.... this I'll remember forever : thanks for helping me out.
Rick... I think STEP and DIR signals are digital logic so shall not be a problem. Although I too am not an expert on this. looking for some expert comment from community... in that case I may go with your suggestion.
cool little cutter you have there. when the day comes that you want to make tapered things, @rcKeith has some excellent resources. You already have almost everything, just a RAMPS1.4 or MKS controller and you will be able to cut almost anything. https://rckeith.co.uk/
