If the firmware is in lockout, it doesn't respond to our connection "are you there grblHAL!?" requests... Its locked
Technically tech support for CONTROL is for our customer base, so we can't really help with that one as its a 3rd party controller. Maybe check in with BTT on what software they supply for their controller? LCP1768 is quite old (back in the Smoothieboard days isn't it)
I understand. It's a shame though given it's just grblHAL with a different pinout and some other state inversions and whatnot. I ended up getting it to work with gSender (had to select grblHAL as device firmware) so it definitely looks to be a bug with OBC.
I just wired up a new machine and when commissioning it I found a strange problem. I can home no problem. When I move the X axis in a positive direction it works fine but when I try to move back again in the negative direction it goes positive instead. Same with the Y axis. The Z axis works fine both up and down. I loaded a file after homing and then moved in the positive direction to about the centre of the table. I then tried framing the loaded file and it frames correctly moving in a positive direction and a negative direction. I can home (machine home) and then move in a positive direction both X and Y and zero the position. I can then move some more in X and Y positive direction and press the work home button and it will return to the work home position as it should. If I use the negative direction arrows both X and Y only travel positive directions. Have I done something wrong, any other way to test my setup? Windows version 10 Engraver brand and model DIY Grbl version 1.1h LaserGRBL version latest $0=10 $1=25 $2=0 $3=2 $4=0 $5=0 $6=0 $10=19 $11=60.000 $12=0.002 $13=0 $20=0 $21=0 $22=1 $23=3 $24=50 $25=500 $26=250 $27=3.000 $30=1000 $31=0 $32=1 $100=40.000 $101=40.000 $102=80.000 $110=4000 $111=4000 $112=1000.000 $120=800 $121=800 $122=200 $130=840.000 $131=420.000 $132=75.000
The first thing to check is the wiring to the X stepper, looking for one loose connection or faulty wire. An intermittent connection can cause that behaviour. Alex.
Thanks Alex. I actually rewired the steppers with heavier cable and tried it out again. I thought I had got it working as it seemed to work in both directions to start with and then it happened again and played up again as before. I may have a faulty CNC shield or maybe one of the stepper motors or drivers has a problem. I guess I will have to try eliminating each section one at a time and hope that a driver doesn't get fried while doing. I am wondering why it affects the Y and X axis if the problem is only on the X?
check the plugs and sockets on the shield, with the power OFF. dicky connections will probably lead to driver death if you fiddle while they are powered. obviously all solvable with a nice shiny Blackbox (-: much nicer than a shield, but I do understand the financial implications.
Thanks David. I will check all connections again and can swap out the stepper motors and also the boards with spares that I have, to try an eliminate the problem. Seems really strange as it worked okay when I rewired the stepper motor wiring with heavier cable, until I did a machine home, then it wouldn't go in negative directions again. That could be just a coincident and just be a bad connection somewhere.
Okay, I checked all connections and before taking off any stepper motors I thought I would try again. It appears to be a homing problem because I tested several times and the same thing happens each time. If I start the computer and open LaserGRBL and connect and do not make a machine home everything works fine. I have tested this a number of times without any fails. If I do a machine home which seems to work as it should, going in the right direction, touching off and then retouching again, that is when the problem starts. I can from there on only travel in positive directions. If I shut down the computer, disconnect everything and reconnect, fire up LaserGRBL and try everything again, a repeat of the above each time. Everything works until I do a machine home. I guess I have to read up on homing some more, but I don't understand what and why it is happening.
Could be that a cable or connector in the stepper wiring is getting stressed at the home position and losing contact - I'm also in the 'it's a wiring thing' camp
Thanks for your input but I don't think it is wiring. I have checked rechecked and checked again and I have made some tests that are playing out consistent each time. I can do anything that is required if I don't machine home. Everything works fine. As soon as I do a machine home the problem starts. If I work home there is no problem, I have tested both ways probably more than 20 times and it is always the same. It is not a loose connection or anything to do with the wiring, I am sure. It has to be something to do with the program settings in either or the software to do with home cycles.
Alex I have the directions working fine, it is a problem with directions after homing. Funny thing is I just loaded into UGS, same wiring, same settings and it works as it should.
See @Misterg's post above - when you switch on a grbl controller you automatically create a machine home wherever the machine is at power on, so it's not creating a home position that's causing the issue, but could be connected to the physical position of your homing switches. I don't use UGS so can't explain that one. Alex.
That may be so, but there are two homes, one is the wpos home and the other is mpos home. The mpos home is the one that the limits check I believe.
Exactly, although, to avoid confusion, I always refer to MACHINE HOME and workplace ZERO. From what I have read in your post I believe your issue is caused by homing your machine to the limit switches. The homing routine in grbl can't interfere with jogging direction settings which is why we are thinking it must be a wiring problem. We might be wrong, but I can't think of anything else that would do that. Do let us know if you work out what it is. Alex.
How many ways can limit switches be wired? I have only one switch on each axis, the X and Y trigger on negative end ( lower front left) while the Z axis triggers on the positive end (up)? The homing directions are set for those conditions. Exactly the same setup when using UGS which works perfectly.
GRBL has 2 direction settings, one sets the machine directions, which must conform to the cartesian directions for tool motion, X+ is tool right, Y+ is tool away, Z+ is tool up. These will be revealed by jogging. If any one of them is wrong then cutting text will show it up by printing the text backwards or upside down. The second direction setting is for homing, it tells it which way to go to find the switches. With your switches at front left, you will need to invert X and Y so it homes towards the switches. GRBL uses this information for setting up where it thinks machine home is. From your symptoms I'd say you have the machine directions incorrect.
This doesn't sound right to me because the homing direction is correct, it will home towards the switches okay. If I did what you suggest the homing would be away from the switches. When jogging before homing the directions are okay, measurements are okay too. I can set a wpos home and that works okay as well. The problem comes after doing a mpos homing cycle, the directions in the positive direction are okay but in the negative direction are not. All movements are positive. Another thing, everything works perfectly if I use UGS to test, but not when using LaserGRBL.
I just looked back at your grbl settings. The default MACHINE home position is the back, right, up corner - the maximum dimension for each axis. You have put your homing switches at the front,left corner but you haven't inverted the homing direction ($23) so your jogging directions are not correct. You must get the jogging directions right FIRST. X +ve moves the tool right Y +ve moves the tool back Z +ve moves the tool up Once you have those movements correct you can tell your controller where you put your homing switches using $23. See the link below - $2 explains how the direction invert mask works, $3 is the setting to change to get the jogging movements correct. If you are using Openbuilds Control that makes it really easy to change those settings using the grbl settings tab. https://github.com/gnea/grbl/blob/master/doc/markdown/settings.md Alex.
Thanks Alex. I have tried a few times and had no luck. Can you explain how I should go about setting up the directions please. I did some more reading and altered my setting a lot and tried the following: I opened LaserGRBL and connected the machine. I didn't home, I just unlocked with $X I then typed g1x20f500 and it moved in the positive direction ok Then I typed g1x-20f500 and it moved in the negative direction ok I then typed g1y20f500 and it moved in the positive direction ok then I typed g1y-20f500 and it moved back again. Then I did a mpos homing and it homed in the right direction and after finished homing I tried to move with the LaserGRBL arrows X worked pos but negative went in the positive direction Y worked positive but negative went in the positive direction. My new settings are: $0=10 $1=50 $2=2 $3=3 $4=0 $5=0 $6=0 $10=19 $11=60.000 $12=0.002 $13=0 $20=0 $21=1 $22=1 $23=3 $24=50.000 $25=1000.000 $26=250 $27=3.000 $30=255 $31=0 $32=1 $100=80.000 $101=80.000 $102=2560.000 (I am using an 8mm 1.25 thread ratio 1:1 direct drive from a stepper 1/16 micro steps) $110=4000.000 $111=4000.000 $112=500.000 $120=50.000 $121=50.000 $122=50.000 $130=840.000 $131=420.000 I will have to change the accelerations as they are far to slow and I will have to fine tune the steps as well, but they are close.
lets return to this...... so when you run Gcode everything moves correctly, but when you JOG negatives move go positive, right? and this is an Arduino Uno board with external drivers, right? great. your 1/16 stepping it bringing you perilously close to the 30khz GRBL step rate limit. 1/8 would be better Quoting from grblcalc: Z (micro)steps per mm: 2560.000000 which is 0.000390625mm per step Z max steps/s: 21333.333333 4x microsteps woudl give you steps/mm 640.000000 0.0015625mm per step which is still small but quite outside easy measurement, and you can increase Z speed to 2500mm/min without problems in GRBL (hardware may not be able to cope, and for a short Z travel this speed runs out of space really quickly. ) so, why does jogging not go negative, but Gcode does? We have investigated a few things already, now it is time to look closely at the wiring. keep signal wires away from power wires good connections? not just a visual check, tug, move, unplug/replug etc, physical check star ground? ie all DC grounds connect together at one point. and DC ground NOT connected to AC ground. and finally, what drivers are you using? Some require specific timing during direction change which is sometimes achievable by inverting the step and direction pulses. but the correct movement of running Gcode precludes this, most likely.
When I enter pos directions it goes positive and when I enter neg it goes negative, until I mpos home. Then all directions are positive. Arduino Uno, CNC shield v3, DRV8825 I was a bit worried about that, so I will change it to much lower, thanks. Checked the wiring several times and rewired the steppers with heavier shielded cable, all grounded to common point negative DC. DRV8825 What I don't understand is why it all works fine in UGS?
After doing a mpos homing the arrow direction buttons only work in a positive direction. Before homing the machine will work flawlessly. I tested my machine using both LaserGRBL (latest version) and UGS I just tried both softwares and found out that LaserGRBL seems to be the problem. It all works fine in UGS but the problem happens in LaserGRBL so I zoomed out on the work area shown on the computer screen so I could see the cursor that represents the tool. When I have homed and use the direction arrow buttons the cursor moves only in positive directions. So this shows me that it is NOT a hardware error, but a software error, because if it were the reverse the cursor would move in the pos and neg directions when asked.
ok, lasergrbl is the problem then, you will have to talk to the experts about that. https://lasergrbl.com/support/ BTW OpenBuildsCONTROL makes configuring GRBL very easy, especially calibrating steps/mm
