Steps/mm at correct setting causes stepper drive error

[neomadic]

There's a chance that this could be a bCNC issue but I thought I'd see if anyone here has any ideas.

In the last few months, I've built two cnc control systems with raspberry pi3/Protoneer boards/grbl1.1 and I'm trying to get one of them tuned to the machine, but not having much luck. This system is for a 5'x10' "lightning cnc" plasma table at a friend's business.

I'm ready to install the computer and all I need to finish is motor tuning. I'm having an issue with the necessarily low steps/mm settings though. When the steps/mm is set correctly, the motors barely move, then stop randomly and grbl seems to give up, or think the job is done. Then it needs reset a few times before it responds again.

The x axis steppers have 15t, 4mm pitch rack and pinion setups. At 1/4 microstepping, 200 steps per revolution, and 60mm per revolution, my x axis steps per mm setting should be 13.333. I've checked this a bunch of times and am 99% sure it's right. I somehow hope that I'm wrong though.

When I set the steps/mm to what it needs to be, no matter what I set the acceleration and max travel speeds to, the motors barely move, and give up way before reaching their requested destination, but grbl doesn't throw any errors and just acts like it accomplished the goal. I also find that trying to jog it hangs up grbl randomly, requiring a soft reset to regain responsiveness. If I put the steps per mm up in the 300+ range, I get smooth running motors but still can't get over 500mm/min rapids, regardless of max travel settings. (The steppers aren't installed on the machine btw. I'm tracking RPM, time, and calculating position.) I also tried changing feed rates in g01 commands in addition to jogging at different multipliers.

The maximum performance I can find seems to be around 500mm/minute, with the external driver step settings set to 1/8 microstepping, steps/mm at 1500, max rate at 500, and accel at 20mm/s^2.

The correct setting in Mach 3 on the old controller, in inches, was 3392.3966 steps per inch, which I arrived at using an online calculator, comparing requested travel to actual travel, then adjusting by putting the actual travel back into the calculator. It was spot on whether I asked it to move an inch or ten feet, like within a few thousandths. If I divide this by 25.4 to convert to steps/mm, I get 133.6. This setting also results in slow/locking up motors and unresponsive max travel settings.

I have the checkbox for inches checked in tools in bcnc and have set setting $13(I think) to report in inches. Does this mean that I need to use steps per inch in config instead of steps per mm? I tried the settings that worked perfectly in Mach3 and the motors sound nice but waaay overshoot the intended destination and still can't get near reaching the 70ipm, or 1778mm/min that I need to cut 1/4" steel plate smoothly.

I should add that the table was easily capable of 200 inches per minute rapids using the Gecko G540 and Mach3 so I'm either dealing with a software issue or a hardware compatibility issue between the Protoneer shield and the TB6600 external drivers. The steppers had no problem throwing the gantry around.

Any input would be greatly appreciated!

[chamnit]

Please post your Grbl $$ settings, $I build info output, and any other customizations you’ve made to the firmware.

[neomadic]

These are the most recent settings. I know they're not correct for the machine because I've been playing with the values just to get the motors to run. If I leave them as is and change the x and y steps/mm to 13.333, without changing any other settings, the motors just gitter.

I'll go through it all again tonight and post what I think the optimum grbl settings should be to make the machine run quickly and accurately.

I really appreciate your help.

$I [VER:1.1e.20170114:] [OPT:V]

$$ $0=10 $1=255 $2=4 $3=4 $4=0 $5=0 $6=0 $10=1 $11=0.010 $12=0.002 $13=1 $20=0 $21=0 $22=0 $23=4 $24=25.000 $25=1000.000 $26=250 $27=2.000 $30=1000 $31=0 $32=0 $100=100.000 $101=13.333 $102=400.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=2686.000 $131=1336.000 $132=114.300 ok $G [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0.0 S0]

[neomadic]

I forgot to mention that the grbl build is stock. I couldn't get the IDE to recognize the folder to add to the library when I wanted to try to update it. That's another issue I need to figure out.

[chamnit]

@neomadic : Please try using the most recent version and re-test. If it still does it, then post the exact steps and g-code commands to help me reproduce the problem here.

[neomadic]

The most recent grbl-master.zip file that's posted on github isn't recognized when I try to add it to the IDE library. I updated IDE and followed four different tutorials step by step. IDE's not having issues with other sketches and libraries. Not sure where to go from here.

[chamnit]

Are you selecting the grbl folder inside the unzipped archive?

[neomadic]

Yes. I've tried renaming grbl-master to grbl, directly installing the main folder and subfolder individually and together into the arduino 1.8 libraries folder, tried changing permissions on files. Tried moving the grbl folder to different folders like desktop and downloads and direcing the IDE program to install he libraries from there. A more linux savy friend even spent an hour poking around in terminal and is stumped. I just reflashed the sd card for the raspberry pi and am going to try and reload the version of grbl that the maker of my breakout board built into the image.

The next step is firing up my other system, wiring the motors to it and seeing if the problem replicates. They're nearly identical setups.

[chamnit]

It looks like you have a Protoneer Rasbpberry Pi board for Grbl. I’m unsure if the IDE installation method will work for this. I recall that there is a special procedure for that board, which was stated somewhere on the manufacturers wiki pages. It’s primarily due to how it communicates with Grbl through the RPi IO pins. This may confuse the Arduino IDE. If I recall right, you have to flash it manually with a precompiled hex file.

[neomadic]

I reflashed the r-pi sd card with the protoneer supplied image and repeated the IDE library loading thing the exact same way a few times and it eventually worked.
It's running build: [VER:1.1f.20170801] [OPT:V,15,128]

I've got a fresh version of bcnc installed too and with the step/mm settings under 50, it still won't run the motors other than gittering. I figured that the less microstepping I use, the easier it would be on the arduino to process it but it acts like it's the opposite.

I'll fire up the other box tomorrow and see if they both do it.

Thanks again for taking a look at this!

[neomadic]

I think I figured it out.

If I click on g54 in the control screen in bCNC, set feed to 2500, set units to inches, make sure $13=1, check the inches check box under the Tools screen, and type G01 X100 Y100 Z10 F2500, the machine runs at almost exactly 100 inches per minute and is accurate with regards to position. I guess that no matter what the settings are at, the feed rate needs to be input in mm/min instead of ipm.

I'll verify this on the machine tomorrow and post up my results.

[swarfer]

just because you clicked 'inches' does not mean that GRBL is working in inches, it means that bCNC is working in inches. you have to send a G20 to GRBL to tell it to expect inches in all following commands.

AND don't forget that any file you send MUST have it's own G20 or G21 at the top to set the mode it needs AND after a metric file runs the GUI might try to send inch measurements for jogs etc and you will need to click the inch/metric button to reset it or send a G20 yourself to make sure it is set the way you want it.

[neomadic]

Thanks for the input. I realized this morning that setting the feed rate in g54 doesn't seem to affect anything. There's definitely something forcing things back to metric when I open/close bCNC, but it only affects the feed rate, not the motor speed, displayed position, or actual position.

I'm trying to figure out what setting sets this line in GRBL, or in bCNC if that's where it lives: [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0.0 S0]

So far for testing, I haven't even been loading gcode files. I've just been manually entering commands and measuring how far/fast they travel. I really think I have things dialed at 1/8 microstepping and am getting a little over 100ipm travel speeds.

There's definitely something not right with the way the system handles low steps/mm rates but it seems that the system has the ability to run at the speeds I need at higher microstepping rates so the low rate gittering thing is no longer an issue for me.

I think the whole issue here was the confusion involved with setting the system up to use imperial measurements. The negative coordinate workspace thing is really counter intuitive too but I think I finally figured it out.

I promise that as soon as I'm cutting parts and have verified that I definitely know what I'm doing, I'll make a very specific tutorial video for using bCNC with GRBL to use Inches and positive workspace coordinates.

Unless there are people out there that need to drive their steppers with tall gearing and no microstepping, I think that this issue can be closed.

Thanks again to everyone that's working on this stuff! Even with the tricky learning curve, I still don't miss windows/mach3!

[chamnit]

The negative coordinates is definitely weird to a lot of people but it's common on production CNC mills. At least the ones I've seen. Here's an explaination. Given the amount of push back I've gotten over the years on this, I'll allow the machine coordinate frame to be set anywhere in the next ARM version. It wasn't installed on the 328p due to space constraints and its low priority.

[neomadic]

That's really strange. I've read the explanation a few times and just can't wrap my head around it. Ran it by a few machinist friends and they're all baffled too. Ever since taking an autocad course back in college twenty years ago, the industry standard, in the US at least, has been to set the origin of the drawing in the left lower corner and dimension the drawing all in positive space. It's no big deal and should be easy to work around, just kind of a head scratcher.

Now that I've figured out how to recompile, I'll try changing the force set origin setting in config.h.

"the next arm version"??? That will be awesome!

[chamnit]

Work coordinate frames are usually in the bottom left corner. Machine coordinate frames are in the top right for Grbl. This also serves as a way to force the operator to use work coordinate systems as they should be doing.

[neomadic]

This really deeply confuses me, and I'm almost sure that it's just me over thinking things, or having forgotten or misunderstood a definition...

The way bCNC is displaying the work area just doesn't make sense or work right when it's in negative space, regardless of wcs settings, unless I redo all of my drawings and g-code, or maybe just hack my sheetcam post processor a little more.

I like my machine park position, wcs origin, and machine zero to be the same on plasma tables just to simplify things and minimize unnecessary motion/wasted time during homing and material loading. I also like the display and keyboard keys to correspond directionally with the view of the table. On this particular machine, due to the position of the control station and where the machine is in the shop, the home position needs to be in the lower left corner. If I'm having trouble wrapping my head around this, the guys that will be running the machine are going to have a hard time too so I just need to get it all setup so operation is as simplified as possible and write up a little instruction/workflow process manual for them

I'm doing the learning curve thing on seven systems at once right now, linux, freecad, sheetcam, raspberrypi, arduino, bCNC, and Grbl. I am definitely making progress but am also a little overwhelmed. I'm five months in and feel like I'm close to having a usable machine but I definitely have more research and poking around to do before I tell the robot to fire the torch!

Thanks again for your help and time. Hopefully I can become proficient enough at this to help contribute to future development efforts. I see more axes in my future. ;)

[chamnit]

2D CNC cutters/laser/plamsa have origins at the bottom-left. 3D printers as well. 3D CNC mills are upper-top-right.

[chamnit]

@neomadic : Also please try to remember that CNC is pretty old and a lot of things about it don't make a lot of sense. Particularly g-codes. They are not standardized and vary a little to a lot between machines and machine types.

[neomadic]

I can see how the negative coords would make sense on a fixed spindle machine.

Not making sense actually makes a little bit of sense to me these days. :)

[neomadic]

Quick update.

I cut metal on the machine yesterday. Motion control is perfect!

I only have one little thing to figure out. I'm finding it impossible to open gcode and have the origin of the plotted display line up with the orange dashed machine table display lines. It seems to cut fine anyway because I disabled soft limits but It would be nice to figure out how to display the part within the machine work area display. I wouldn't be surprised at all if I'm missing something stupid again here.

[neomadic]

Confirming operator error in case anyone else has the same issue. After homing the machine, everything lines up.