I am an instructor at University of Missouri. I have been given the task of building and calibrating the Maslow my department bought for our Building Technology Lab.
I built the default frame, installed all hardware and electronics, and everything seemed great. I ran the calibration, and I got through all steps except the test cut.
I am receiving the error - “Sled is not keeping up with its expected position. Make a note of the line number”
This only seems to happen when the right motor is engaged fully.
I have tried a solution I found on the forums to set the max speed to 500. It seemed to help when adjusting chain length. Once I have the chain length set, I use “Test motors” function on the Action screen. The motors test fine and all lines say “Pass”
However, if I try to cut the Triangular test pattern through the Advanced screen (I also tried the test pattern at the end of the full calibration, and suffered the same results), it gives the error and the motors stop. I try stopping and recutting the test pattern, and receive the same result.
If I use the Home command, the motors will move. If I use vertical move commands, the motors move. When I use a lateral command (left or right), the right motor moves a little, stops, and then gives the error.
I am running GC 1.12 and firmware 1.12. Quadrilateral config. The only thing I am unsure of is which PCB I am running. How do I find this info? Apologies if that’s a newbie question. The project was just dropped in my lap a week ago and I am trying to learn everything from the ground up.
The easiest way to find the PCB number is to check in Ground Control as soon as the machine connects, it will be printed in the text on the right hand side:
Detecting the sled position is a pretty new feature and it hasn’t been tested very thoroughly with the quadrilateral setup. For the sake of just getting you up and running ASAP I would say just turning it off wouldn’t be a bad idea. You can essentially turn it off by entering a large number in the setting here:
I think I’m getting a simillar error. I actually reinstalled version 1.11.
What happens is that mostly when the sled is moving in diagonal towards the upper rigth corner (bigger load on the right motor), the motor stalls, jumps or works slower. Also the right motor heat sink is always hotter than the left one.
With version 1.11 there is no error message but the white cross keeps moving while the red cross stays behind.
Then sometimes the right motor starts running at high speed and recovers the position.
I’ve swaped the cables and the problem stays with the right motor.
Everything looks like the motor has an overload and doesn’t have enough torque.
Could the motor be damaged?
Could it be the shield?
Can you post the .nc file where this happens, and info about which line(s) show the issue? I’d like to hook up some test equipment here and look for the cause.
Here it is. This file uses the lower half of the board. I have another file that was supposed to cut on the upper half of the board but the problem was buch worse (bigger load?), so I didn’t even try to cut with that one.
I think that the issue is that those motors look like they are probably not strong enough to power the machine. The warning is correct that the sled is not keeping up, but it’s not keeping up because of the the motors are much smaller than the ones in the kit. We use a similar motor to that for the z-axis where much less force is needed.
To test that the issues is with the motors not having enough power I would try to remove weight from the sled by taking the router off and see if lowering the weight solves the issue. If so you could either use a smaller router or a dremel type tool with those motors, or you would need to find larger motors with more power.
Got it! I think that other motor is an excellent choice for the z-axis.
Those look very similar to the motors in the kit. They are about 30% faster in theory but, that will give them 30% less torque than the stock motor which could still be the issue.
Your guess that the the number of pulses could be the issue is also a good one. An easy way is to ask the machine to move six inches and check that it actually moves six inches. If it does the CPR is ok
Thanks for sharing the file. The gcode looks good, many short straight movements to define the arcs, easy for the Maslow to do. As the cuts run clockwise around the paths there aren’t many places that involve movement diagonally toward the right motor. Where does the problem happen? It’s a big file and will take a while to run, if I can concentrate on a smaller part that would help.
The cut lives within a square about 500mm wide by 575mm high. Were you running it in the center of the lower half of the work area? If so, it’s cutting within the best part of the workarea, which should help avoid the problem.
It looks to be cutting 6mm deep at 500mm/min feed rate. You could dial one of those back, either cutting in two 3mm passes or at a slightly lower (450? 400?) feed rate. The higher encoder pulse rate might reduce the upper limit of feedrate that works reliably.
The power supply for the motors is another variable - as you noted, the issue happens when the load on the right motor is highest. There isn’t an easy way to check the voltage reaching the motor, but if you have a way to try a bigger power supply that would be interesting.
The on-screen arrows move the sled at the maximum feed rate as set in the Advanced Settings. You can use them to test movement in different parts of the workarea at different max feedrates. If everything is working properly, the sled should make a straight line movement. If the movement ‘hooks’ at the end as you described above, you’ve found an easy way to test things like changes to the feed rate or the power supply, without cutting valuable plywood
“Your guess that the the number of pulses could be the issue is also a good one. An easy way is to ask the machine to move six inches and check that it actually moves six inches. If it does the CPR is ok”
After calibration I made vertical movements of 200 mm with the arrows and it moved correctly. Only moving up, there was a difference of less than 1 mm in the end of the 200 mm. Every other movment didn’t show visible error (measuring with tape).
In fact the error I mention never happens with the arrows.
First part to be cut is the third from top. It happened in the initial arc going from the left end to the center. Second and third to be cut are in the middle. The problem occurred again only in the top of the contour, again when it goes right and up.
4th and 5th parts are the ones on top and they came out OK.
6th part is the one in the bottom which came out almost good but but with a deformation on the right “horn”. Sled then recovered and the rest of the countour was ok. It usually recovers going down.
Here it is:
Yes, it’s a 600x1200x5 sheet of plywood, vertical and centered in the working area. I prepared two gcode files, one for the top half and one for the lower half. I run some blank tests without cutting bit. The problem was much worse on the top half. After a successful blank run on the bottom I decided to make real cutting but the problem occurred again. The thing is it also happens with no cutting load.
Correct
I’m not sure about cutting load causing the problem. Could the feed rate and the fact that these motors have 13 pulses per rev be the cause?
I actually started with a 4 Amp power supply. I then changed to a 5 Amp which needed modification of the connector, but the result was the same. I will try to find a bigger PS.
I never saw the problem using the arrows, but then I only made this kind of movement around the center of the work area.
I’ll test this also in more critical areas.
I think so, yes. That’s what I’ve found testing out a couple different z motors. The accuracy reduces at higher motor speeds.
I’ve run the file with a pen, and the areas you list as having trouble look proper.
That horn might indicate a problem with the left chain on the motor sprocket, pulling the sled farther left than wanted. How many teeth on the sprockets? Is the chain parallel to the workarea across the whole width and height (sled attachment height or bowed plywood)? Check that the motor hasn’t gotten pulled to a slight angle from true by the tension of calibrations.
The shapes in the .nc file are very interesting, I hope you will post a picture of the project once the issues are solved.
Sprockets have 13 teeth.
The horn does have a strange shape. Not the one one would expect with just the right motor stalling.
I ran some more tests and the behavior is now more random. I started with a 200 mm up movement and the problem immediately happened. Then, as It sometimes looks like an intermittent connection, I shaked cables and connectors but nothing seems to be consistent with the erratic behavior of the motor. I also tried reducing the feed rate to 400 mm/min and the problem still happens.
Always the right motor and easier to reproduce on the top right corner (moving to it).
Chains seem to be quite parallel.
It seems to be something on the hardware side. In fact right motor makes much more noise than the left one. So I also opened the gearbox. No blockage there just noisy gears.
I don’t know but I’m considering ordering a new motor.
Not sure how difficult it would be, but physically swapping the two motors to see whether the problem moves with the motor would be interesting. Look carefully at the motor brackets for displacement when you do. I had a left bracket skew slightly because of where I put the screws holding it - that caused the chain to climb up on the sprocket teeth very occasionally.
Watching the left motor for the chain climbing up on the teeth during the problem would be instructive. That would cause the sled to err above the desired path while a speed issue with the right motor would probably cause the sled to drop below the path. During the left-chain problem, the black and red cursors on the screen should be together because the encoders don’t reveal chain problems. During the right motor possibility, I think the red cursor will move away from the black one as the encoders signal that the motion does not match the command.
I made some more tests today. I swapped the motors. Initially the problem seemed to be still on the right side but then also on the left side. In fact it would alternate: either the left motor stalled and the right one would run or the right one would stall and the left one would run.
It was quite obvious there was not enough power for both motors at the same time.
I took 2 kg out of the sled and it seems to follow the path very well. I couldn’t test under cutting load. Didn’t have the time today.
Power supply doesn’t even get warm so I think this power limitation must be somewhere else. Maybe in the chips?
Is this a situation where the TLE5206 PowerControl Board would be advisable?
If you’ve already tried a power supply that is rated for more than 6 Amps at 12 VDC, then the TLE5206 board would be another thing to try. The stock Maslow board can supply up to 2Amps per motor, the TLE5206 5Amps, but in either case the power supply must provide the desired power. What is the rating for your power supply?
If I were you I would try a more powerful supply. If instead you have a meter that will read %PWM then you could differentiate between a power problem and trouble with the encoder pulse rate. Monitoring voltage will not be as useful as PWM because of the pulsed nature of the power to the motors.
The motors are rarely run at 100%PWM in normal use. The PID loops only ask for enough power to move the motors at the desired speed. Watching across the M+/M- leads with the meter during various movements will give you a feeling for how hard a motor is working. If you see it maxed out at 100%PWM, then more power is the answer.
The motors you’re using may need more than 2Amps to run at high speed. If that’s so then the TLE5206 could safely deliver the higher current. Don’t make this measurement using the Maslow board to supply the current - the power control chips could be damaged during the reading if the current is high.
If the motors run well below the maximum PWM, then the higher pulse rate of the encoders could be causing the Mega to lose pulses. Running at a lower maximum feed rate would be one solution for that. You’ve tested at 400mm/minute, how about trying 350mor 300?
