It’s a puzzle that ‘sometimes’ you can run at least a part of a file. We had min. 1 report of a loose encoder. Maybe removing the black cap and inspecting the encoders could give a hint.
Also check that the screws of the sprockets are sitting tight on the flat part of the motor shaft!
It’s strange that you pass the test motors without sled but not with it.
The circle gcode has issues. The lower left 3rd consists of 4 commands where only 1 would be needed.
Motors have been changed so encoder should be fine. I replaced motors with a new set and the gears were removed from old and installed on mew. Original and new set up are tightly connected and contact the flat of the motor shaft. I will do this check on my old motors before I reinstall them (Need to return other borrowed motors).
The circle program I have been testing with is very simple. Two cuts around diameter (~5") at .0125 cut depth. No tabs. Again program was run without bit installed. My speeds I set to 20ipm (X-Y movement and Z axis move).
The lines of code you are referencing looks to be for a tab.
Panels and piecesZZ.nc
Tabs at full material thickness and the blue line is 4 gcode commands.
Edit: Not saying it has something to do with what you are seeing. Just sharing my findings.
We did recently have a ‘strange behaviour’ report that had similar 100th of an inch moves in the g-code.
Do you know the setting to truncate digits in GC? I want to remove this as a possible source of the problem.
When problems first showed up, I was in the middle of cutting the arc of one of the circles, not the tab. At the time, I had already cut ~50% of all the holes in the program. The sled stopped near top center of the work area where the machine is generally most accurate. Once this cut stopped, I have not been able to cut anything properly since.
I had thought that maybe the program was the issues initially. I closed GC, re-opened it and cleared the existing G code. I made a new G code to again try to cut the circle that failed and all remaining circles. It stopped in almost the same location when I ran the new program.
I then wrote a new program with just the single circle that failed (full thickness tabs). This also failed in near the same location on the sheet. I tested the motors at this time and started getting the sled not keeping up errors consistently.
Is also in the ‘advanced settings’ called ‘truncate floating point numbers’ and is set to ‘off’ as default.
Could be an indication of an overheated chip or a weak power supply.
Something might have smoked at the top middle where both motors are pulling against each other.
Can you move the sled around with the arrow keys? A series of straight lines near the top could give a clue.
I can the sled without any issue sing the arrow keys, unless I first perform a motor test. After the motor test, any movement (X, Y or Z) causes the sled not keeping up error.
I ran calibration and the cuts were good (Top to bottom axial measurements within 1/32"). I can run a simple program to simulate cuts along the top. I will do this tonight and see if it fails.
Overheated chip in Maslow board? I replaced this and still have errors.
My power supply was already replaced on time. Is there a way to test this? I tested the output from the power supply (connection to Maslow) and it’s voltage and amps were fine.
You could have discovered a bug that could be the reason the ‘sled not keeping up’ is showing up in troubleshoot far to often.
Looking at the log, I could connect the warning message to the 2 tiny moves in the g-code. (bCNC pic)
The middle 2 of the 4 lines marked above have triggered the warning in the log.
Looks like something can not handle tiny moves like:
G01 X43.95153 Y32.30964
G01 X43.95227 Y32.36223
In the log the POS-error jumps after this lines:
<Idle,MPos:4.59,10.71,-0.12,WPos:0.000,0.000,0.000>
[PE:0.38,0.55,127]
ok
Sent: G01 X0.84153 Y10.799640
G01 X0.84153 Y10.799640
ok
Sent: G01 X0.84227 Y10.852230
G01 X0.84227 Y10.852230
<Idle,MPos:0.84,10.84,-0.12,WPos:0.000,0.000,0.000>
[PE:84.92,-80.22,127]
ALARM: The sled is not keeping up with its expected position and has halted. Click the ‘Stop’ button to clear the alarm. More information at: Keeping Up · MaslowCNC/Firmware Wiki · GitHub
[Forward Calculating Position]
position loaded at:
113.25
271.65
<Idle,MPos:4.46,10.70,-0.12,WPos:0.000,0.000,0.000>
[PE:0.05,-0.01,127]
If it’s a bug, would it show up if running #fakeservo? I ran the code on webcontrol and didn’t have any issues.
It does not show up on my fake-servo. We had something similar issue with a code made in CamBam i think. Can’t find the post to see if there is a connection.
@madgrizzle 1 more thing that kept me wondering tonight is the quote above.
Was curious and tested what the FakeServo does with the test. As expected all motors fai, but the position indicator was not expected. https://youtu.be/oYVs0217mmw
The build up on the PE in the log file during the motor test above is making me want to dig deeper. Not goint to happen tonight. 22 days is one of the worst support we had in my history here 
Also If I hit the cancel button in GC after the motor test the sled movements would not give me the sled errors.
What version of GC and firmware do you have right now?
There was a bug in v1.24 which affected G1 and G2 commands. I was able to calibrate with v1.24, but my first cutting job was a disaster. Currently running v1.25 and all is good.
Newest 1.25.
Verified it is set to default (off). I also ran a simple test cut (straight line 24" long about 6" from top of sheet) and it ran no problem.
After the program was finished running, I ran the motor test and it failed for the L motor direction 1 only.
I cleared error and was able to move sled around.
I re-ran the motor test two times back to back and it passed for all.
I played around and it looks like my system gets stuck going into and coming out of the motor test.
What I mean by that is, if I move the sled around and do not hit the red cancel button before doing the motor test, the test will fail in the direction I was previously moving the sled using key pad arrows.
If I try to use the z axis controls after a motor test without hitting the red stop button I get the sled not keeping up message. This message is not supposed to happen in the newest versions of software I have been told. It is almost like we need to put a reset (automatic hit of the red stop button) that loads the sled position before and after the motor test.
For the moment I would suggest to do nothing then the cut what you want with clean g-code.
Changing settings brings strange things without a restart and a disconnection and reconnect of the arduino and the motor test I would avoid also without restarting and reconnecting every thing.
My Maslow is disassembled, otherwise I would try to replicate what you are seeing.
Running the simple program was no issue. I think that the old motors I had have problems and the motor test and error message issues are two separate issues.
I will set up and run a full (sheet) program that I have run before without problems (no tool bit) tomorrow night.
Just to see if it does OK or not. If it does OK, I will assume that my motors needed replacing (would like new cables also). And the other problems I have had were more software bugs and/or symptoms of my failing motors.
Since updating my Maslow with the Z -axis I have had similar problems. I think the motor controller board needs replacing in my system as I damaged the arduino board when installing the z-axis motor. The motor I purchased had different wiring setup and because I am new the Maslow CNC it took a while to figure the correct way to wire up the motor. During this this process I most likely damaged the Maslow board. It worked fine for a couple of days then the z-axis statred to play up and I have not been able to make it work since.
I have tried everything you have, but I have not had any success. My next step is replacing the z-axis motor if that fails then the Maslow motor controller board.
