Lowrider resetting during cut

Hi all,
I’ve been having trouble with my lowrider 2 that I’ve finished building recently. I’ve been trying to cut out these large molds that take a few hours to do each. Every time I do the roughing phase, the cnc seems to reset itself at random. Some times it can work perfectly for a few hours before resetting. Sometimes it just resets a few passes into the job. This also seems to only happen for the roughing phase and never the finishing phase.

Extra Info:
I have a lowrider 2 and it has dual end stops and can home in all its axis.
I use estlcam v11 to generate the gcode.
I have tried cutting through repetier host and through the lcd screen, the problem still arises.
I have a Rambo board
Almost all the pieces were bought through the v1 shop, except the 3d printed parts.

Now I don’t know if it can be considered series or parallel wiring. But I wired up the steppers so that each one has its own slot. And modified the firmware in the advanced config, by commenting out the X_DUAL_STEPPER_DRIVERS, and setting NUM_Z_STEPPER_DRIVERS equal to 2. I did modify the series cables that came in the kit and made them into individual cables.

I’m also cutting mdf, (the home depot type) at a feed rate of 7 mm/s in x an y and 2 mm/s in z. (5mm step down, 50% step over, 1/4 ‘’ two flute end mill) I’ve also tried slowing down the feed rate when it cuts through repetier host and the lcd screen. The temperature of the motors also doesn’t seem to matter that much, I’ve cut with them being at around 50 C and also at 30-40 C, it still resets.

I can also see when during the cutting the reset happens, because the cnc just stops in its tracks and stays there for a few seconds and then z axis collapses and plunges the bit into the stock material (if I don’t catch it in time).

I’ve ran the gcode in mid air cutting nothing and it has no problem with it, but when it has to cut the mdf it will always resets in a random spot.

At this point I’m running out of ideas, I’m wondering if you guys have any ideas?

Below is a picture of my setup and the command log from repetier host.

20:37:48.960 : N1341 M117 ETE 5h 09m 20s15
20:37:48.960 : N1342 G1 Y196.7 Z-25 F420
20:37:48.960 : N1343 G1 Y1069.2 F42038
20:37:48.960 : N1344 G1 X136.7 F420
20:37:48.976 : N1345 G1 Y196.8 F42026
20:37:48.976 : N1346 G1 Y188.2 Z-20.0494 F420
20:37:50.397 : N1347 M117 ETE 5h 04m 47s5
20:37:50.882 : N1348 M105
20:37:52.304 : N1349 M10524
20:37:52.304 : N1350 G1 X139.9 F420
20:39:57.951 : N1351 M10517
20:39:57.951 : N1352 M117 ETE 5h 04m 47s
20:39:57.951 : N1353 G1 Z-20.0522 F42050
20:39:58.419 : N1354 M117 ETE 5h 04m 47s
20:39:58.419 : N1355 M10521
20:39:58.419 : N1356 G1 Y196.8 Z-25 F420
20:41:55.301 : Error:!! KILL caused by too much inactive time - current command: G1 Z-20.0522 F420
20:41:55.364 : Error:Printer halted. kill() called!
20:41:56.551 : Printer reset detected - initializing
20:41:56.551 : start
20:41:56.551 : echo:Marlin 421D bugfix-2.0.x
20:41:56.551 : N1 M10538
20:41:56.551 : N2 M117 ETE 5h 04m 45s
20:41:56.551 : N3 M140 S0102
20:41:56.551 : echo: Last Updated: 2020-03-06 | Author: (V1 Engineering, Ryan, 421D)
20:41:56.551 : echo:Compiled: Jun 23 2020
20:41:56.551 : echo: Free Memory: 3405 PlannerBufferBytes: 1488
20:41:56.738 : N1 M110
20:41:56.738 : N2 M11536
20:41:56.738 : N3 M105
20:41:56.738 : N4 M11435
20:41:56.738 : N5 M111 S6
20:42:04.300 : echo:SD init fail
20:42:04.316 : echo:V76 stored settings retrieved (623 bytes; crc 38721)
20:42:04.316 : echo: G21 ; Units in mm (mm)
20:42:04.316 : echo: M149 C ; Units in Celsius
20:42:04.316 : echo:; Steps per unit:
20:42:04.316 : echo: M92 X100.00 Y100.00 Z400.00 E100.00
20:42:04.316 : echo:; Maximum feedrates (units/s):
20:42:04.316 : echo: M203 X50.00 Y50.00 Z15.00 E25.00
20:42:04.316 : echo:; Maximum Acceleration (units/s2):
20:42:04.316 : echo: M201 X180.00 Y180.00 Z80.00 E180.00
20:42:04.332 : echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
20:42:04.332 : echo: M204 P180.00 R3000.00 T180.00
20:42:04.332 : echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
20:42:04.332 : echo: M205 B20000.00 S0.00 T0.00 J0.04
20:42:04.332 : echo:; Home offset:
20:42:04.332 : echo: M206 X0.00 Y0.00 Z0.00
20:42:04.332 : echo:; Endstop adjustment:
20:42:04.332 : echo: M666 Y0.00
20:42:04.332 : Z0.00
20:42:04.582 : N6 T060
20:42:04.582 : N7 M20
20:42:04.597 : echo:Unknown command: “M140 S0”
20:42:04.597 : N8 M8019
20:42:04.597 : FIRMWARE_NAME:Marlin 421D bugfix-2.0.x (GitHub) SOURCE_CODE_URL:https:/github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:V1 CNC EXTRUDER_COUNT:0 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
20:42:04.597 : Cap:SERIAL_XON_XOFF:0
20:42:04.597 : N9 M220 S100
20:42:04.597 : N10 M221 S10081
20:42:04.613 : Cap:BINARY_FILE_TRANSFER:0
20:42:04.613 : Cap:EEPROM:1
20:42:04.613 : Cap:VOLUMETRIC:0
20:42:04.613 : Cap:AUTOREPORT_TEMP:0
20:42:04.613 : Cap:PROGRESS:0
20:42:04.613 : Cap:PRINT_JOB:1
20:42:04.613 : Cap:AUTOLEVEL:0
20:42:04.613 : Cap:Z_PROBE:0
20:42:04.613 : Cap:LEVELING_DATA:0
20:42:04.613 : Cap:BUILD_PERCENT:0
20:42:04.613 : Cap:SOFTWARE_POWER:0
20:42:04.613 : Cap:TOGGLE_LIGHTS:0
20:42:04.613 : Cap:CASE_LIGHT_BRIGHTNESS:0
20:42:04.613 : Cap:EMERGENCY_PARSER:0
20:42:04.613 : Cap:PROMPT_SUPPORT:0
20:42:04.613 : Cap:AUTOREPORT_SD_STATUS:0
20:42:04.613 : Cap:THERMAL_PROTECTION:1
20:42:04.613 : Cap:MOTION_MODES:1
20:42:04.613 : Cap:CHAMBER_TEMPERATURE:0
20:42:04.613 : N11 M111 S6
20:42:04.613 : N12 T0*9
20:42:04.628 : X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
20:42:04.628 : Count X:0 Y:0 Z:0
20:42:04.628 : echo:DEBUG:INFO,ERRORS
20:42:04.628 : Begin file list
20:42:04.628 : End file list
20:42:04.628 : echo:Unknown command: “M80”
20:42:04.628 : echo:Unknown command: “M221 S100”
20:42:04.628 : echo:DEBUG:INFO,ERRORS

Looks like your board is timing out.
If you start your code with M84 S0 it will disable the timeout.

Yes Pok… it looks like there was a 2 minute gap between instructions being passed to the controller board - so it timed out. Perhaps disabling the timeout will work but perhaps the problem lies with why there was a 2 minute gap?..this looks to me like a comms issue between the computer and the controller, if you are using a laptop ensure you have disabled the usb timeout on the laptop ( google it ), try a different, high quality USB cable, try to separate the data cables from the power cables to minimise the chance of electrical noise upsetting the controller as it appears the problem only happens when the spindle is under load, keep the spindle power cable well away from the stepper motor wires… and look into the possibility of adding some shielding to the controller if possible. they would be my first actions.

That doesn’t quite seem right. M84 is for disabling the stepper timeout, but this looks like the board reset. It doesn’t do that on inactivity that I’m aware of. So I am suspicious of repetier host mucking with things and reconnecting. It will reset on a reconnect.

Was the router on when you did that? Maybe it is interfering?

A really long USB cable and a laptop is maybe not the best long term solution. Most low riders use the SD card in an LCD to run jobs, or they hook up a v1pi to run octoprint or cncjs.

Ok, so here’s an update.

I tried the M84 S0 thing and it looked promising at first, was able to cut for 3 hrs. But then it reset.

I didn’t do that the first time so, I ran it again with the router on, cutting only air. It did not reset at all.

Also when I ran the m84 s0 and air cutting test I was just using the SD in the LCD.

So maybe there is interference when there’s tool load. I’m going to separate the router cable and shield the controller, maybe that will help.

Are there any other things that would cause a printer reset?

Possibly power problems to the board itself? Your power supply might be overheating, or you’ve got a bad connection to the board. However, I doubt this, as it seems to not be losing communication completely- repetier would be requesting board information on a reconnect, I believe?

I think jeffe is on the money with the router interference. I think you’ll find much better results shielding the controller, using a shorter USB, and moving the router power cord- possibly to a different circuit altogether?

Other things you can try is the M85 command, similar to the M84. But that’s only treating the symptom, not the cause.

To be honest I’m surprised this problem doesn’t come up more often- Running inductive loads alongside poorly shielded and suppressed microprocessors should by all rights cause mayhem!

This sounds a lot like a reset problem I had with my Lowrider.

I determined that static from the dust collection system would induce resets.

I grounded a wire on a outlet mounting screw and ran it inside the dust hose. This has been 100% successful. The wire I used is insulated (it was what I had on hand) and I only stripped 2-3 inches at the end near the router, but that has proven adequate.