Hi!
Please help with following (I know it is not a MPCNC, but I always appreciated experience and supporting atmospere from here) :
I want to drive a really heavy metal mini mill through Arduino/Ramps/Marlin. I will use it both as mill and -sometimes -printer.
Mechanical side is finalized.
I use on x/y (where my problem resides) Nema17 long motors (0.8Nm, I think); but I made trials also with Nema23. Axis movement is done through 8mm x1.5 pitch lead screws. Calibration is done. Lead screws are moving smooth.
Steppers are driven by external TB6600 /2 micro-steps setting.
I went with movement parameters in Config.h down to 30mm/s default max speed;10mm/sx2 default max acc; 0.4 x/y jerk. Though it does not move satisfactory.
Metered trials I’ve made mostly on Pronterface because I can adjust travel speed.
Main thing which concerns me is:
In homing all axes - I have set Z home position in the middle of bed -. X makes its 0, Y makes its 0, than both axes should start moving simultaneously half bed dimension for Z to search its 0.
Sometimes X/Y don’t move at all (after making their 0 individually), sometimes they barely move milimeters, sometime they fully accelerate but the movement stops randomly on certain point along diagonal to the center of the bed. Immediately Z starts moving to find its 0; no delay, no stall noise - as the x/y axes would have been programmed to stop there.
And sometimes it performs entire sequence, as intended.
Steppers are not getting hot.
Other than that I should be satisfied. I got more than 32Kg push/pull force on bed at homing speed and 1600mm/min max reliable speed (absolute max maybe 1800mm/min) without skipping steps. Nema 23 performed worser with the same parameters; could reach 1500mm/min but with vibrations and easy loosing steps during acceleration or under load??? I don’t get it why, at constant speed (be it that high) the torque /load is lower than Nema 17 steppers. So one reliable speed corresponding to Nema 17’s 1600mm/min should be only 1100-1200mm/min for Nema23.
Anyway the behaviour at “home all” is concerning me as it shows a hidden bug and I question if -instead of reducing more and more speed and acceleration- isn’t something else in Marlin to tweak with better results - maybe in different file?
Most issue seem to be related with starting to move from 0 speed. And further movement (that movement) is simply cancelled.
It’s been a while since I dug into Marlin configuration, but I seem to remember you can set different homing speeds from the normal operating speeds. If your manual testing is going well and you only have issues during homing then I’d look for homing speed options in the Marlin config.h.
Thank you for the answer, Tom.
You are partly right and I have looked a lot for these settings.
The homing speed is only 600 mm/min but I have cut it down to 480mm/min with the same result. The problem is - rarely- issue appears also at the second homing movement, when speed is halved.
As there is no particular behavior , sound etc. I cannot actually detect when it happens, so I cannot say it is specific to homing, certain other command or to certain speeds. Maybe only running a complete job can show there are skipping problems, but as long as I see things are going wrong on a simple sequence like homing all axes, I consider it an issue needing to be solved.
It sounds like you’re worried it is something wrong with the electronics, and not the logic of the homing sequence. Can you replicate what you think homing sequence should be and see if it does the same thing?
G1 X-10 F600
G1 X0 F300
G1 Z-10 F300
You can add in other dimensions at the same time:
G1 X-10 Y-10 F600
G1 X0 Y0 F300
G1 X-10 Y-10 F300
I would also porobably turn off the homing bump for a CNC machine. You don’t want to go crashing into the side anyway, so the first approach should be pretty good.
You said your motors are hot. Keep in mind that the same amount of current will be going through them if they are stationary or moving, and you need to keep well away from their rated current (rated current is in some kind of ideal conditions like liquid cooled, in zero G or something).
I haven’t used those drivers before, so I’m not sure how they work.
Thank you Jeff for the answer!
First, motors are not hot. The setting is 1.5A where maximum for stepper is 1.8 A, as I remember. They stay quite cool (of course, no long job was performed).
Second, I don’t know what to be worried about 
, I suspect everything… from mechanics to Marlin (meaning I don’t know how to tweak it; i’m not thinking to bugs).
I will try the codes you suggested and see how it behaves. I-m not used to work with g-code commands, but everything has a start.
Please define homing bump; I’m not familiar with it. Do you mean give up second slow touch of switch?
I have seen that lately you can select the drivers in Marlin. I have uncommented the lines corresponding X,Y,Z,A and replaced default driver A4988 on these with TB6600. This mod should be enough, isn’t it? I have to say that from my point of view nothing changed with my problem once with this setting.
Gcode isn’t very bad. It looks a lot worse than it is. The trickiest part is that G1 commands can either mean “go to this coordinate” or “move by this much” depending on the last G90/G91 sent. Otherwise, there are no loops, no odd characters, nothing surprising, and I suspect that most CNCers would really benefit from a little understanding.
https://docs.v1engineering.com/learn/gcode/
The home bump is what Marlin calls it when it backs off slowly and comes in for a second measurement. If the homing speed is high, it might get a little bit of error, so it backs off a few mm and tries again at a slower speed. If you’re coming in at a slow enough speed to start, don’t bother with the bump. I think the setting is in the configuration_adv file and you can just set it to 0mm to disable it.
I’m still not really sure what the symptoms are you’re trying to fix. Maybe a video with sound would help?
I think you are right. The film could explain what I mean.
There are some issues claimed by several users of TB6600 with Marlin. Actually they say while printing test cubes they loose steps in a repetitive manner on each layer so that the print results inclined. Their printers are anyway conventional, belt driven, though maybe oversized. So their stepper settings are close to standard ones.
That’s why I mainly connect now my trouble to interfacing TB6600 with Marlin. It was hard to reach to this conclusion as long as I considered it a tuning problem ( speed, acc.) correlated to weight of moving parts. But I went with my dynamic settings as low as possible and problem remains. I will try to make/post a video.
By the way, thank you for V1pi. I have prepared one Pi3 and I’m happy with its performance!
Hi, I’m really happy!
It seems I found a workaround. The owners of printers I have mentioned before (working with TB6600) specified that with v1.1.8 of Marlin printers were working fine. Only with step-up to v1.1.9 problems have appeared.
I have looked on my PC to a previously downloaded custom version of Marlin for CNC Mill.
https://www.youtube.com/watch?v=jlOyqca9AqM
I reccomend you all to take a look at it as it has a custom interface for milling. It really looks worked to fit the purpose.
I loaded it through Arduino.ide -making specific adjustments- and now my machine works as expected - for the moment .
I have rised acceleration to 40mm/s*2 and runs fine!
After all that time lost tweaking (days and days)…it’s a relief.
Thanks for your support.
Grbl is basically marlin for cnc, but it doesn’t support many boards. 1.1.8 supported more than grbl, but not by much.
The board is a standard printer board/ Ramps 1.4 compatible. I only used external stepper drivers TB6600 for their high amps. I knew they were used with Ramps/Marlin since long because some people, complaining about standard driver heating on their printers, made the upgrade.
The drivers are included in the latest Marlins with their particular settings in config_adv.h:
** Minimum delay after setting the stepper DIR (in ns)*
-
-
0 : No delay (Expect at least 10µS since one Stepper ISR must transpire)*
-
-
- 20 : Minimum for TMC2xxx drivers*
-
- 200 : Minimum for A4988 drivers*
-
- 400 : Minimum for A5984 drivers*
-
- 500 : Minimum for LV8729 drivers (guess, no info in datasheet)*
-
- 650 : Minimum for DRV8825 drivers*
-
- 1500 : Minimum for TB6600 drivers (guess, no info in datasheet)*
-
- 15000 : Minimum for TB6560 drivers (guess, no info in datasheet)*
-
- Override the default value based on the driver type set in Configuration.h.*
-
/
#define MINIMUM_STEPPER_DIR_DELAY 1500 -
- Minimum stepper driver pulse width (in µs)*
-
- 0 : Smallest possible width the MCU can produce, compatible with TMC2xxx drivers*
-
- 0 : Minimum 500ns for LV8729, adjusted in stepper.h*
-
- 1 : Minimum for A4988 and A5984 stepper drivers*
-
- 2 : Minimum for DRV8825 stepper drivers*
-
- 3 : Minimum for TB6600 stepper drivers*
-
- 30 : Minimum for TB6560 stepper drivers*
-
- Override the default value based on the driver type set in Configuration.h.*
-
/
#define MINIMUM_STEPPER_PULSE 3 -
- Maximum stepping rate (in Hz) the stepper driver allows*
-
- If undefined, defaults to 1MHz / (2 * MINIMUM_STEPPER_PULSE)*
-
- 500000 : Maximum for A4988 stepper driver*
-
- 400000 : Maximum for TMC2xxx stepper drivers*
-
- 250000 : Maximum for DRV8825 stepper driver*
-
- 200000 : Maximum for LV8729 stepper driver*
-
- 150000 : Maximum for TB6600 stepper driver*
-
- 15000 : Maximum for TB6560 stepper driver*
-
- Override the default value based on the driver type set in Configuration.h.*
-
/
#define MAXIMUM_STEPPER_RATE 150000.
As it seems it is a bug or something like that since Marlin 1.1.9, not completely cleared yet in Marlin 2.0