Hi everyone!
Me and my mate are trying to solve an issue we’ve had for a long time with getting the Maslow to run.
We use two Modified Mercedes wiper motors with 55:1 reduction, XBOX360 12A power supply and a couple of encoders we bought from china.
Encoders are 5V, 400 impulses/rev.
Motion control board is the blue smoke herder shield with 3x TLE5206.
After initial setup we get pass on all the motors. When we try to run a g-code or make sled move in any direction with controller arrows or rotate cogs during chain calibration out motors go crazy. Erratic movement and error ie. sled not keeping up or chain lenghts error.
We tried:
*three different designs of control boards
*changing basically every setting
still nothing.
I will try and post a video of what I mean by erratic movement.
Also we run it from win10, on a laptop. First I thought maybe 5v that goes to the encoders is too low current but we connected encoders to 5V externally - same thing.
We extended original encoder cables using similar shielded cable. Shield is grounded but no joy.
At the very beginning few years back this thing worked on these same motors.
Before we modified the motors to attach encoders we had the encoders glued to the “slow/reduced” side of the motor, now after modification they are attached to the fast side. It means that every rev of the sprocket is 22000 (55*400) impulses. My question is then is there a max impulses/rev arduino can handle due to software/MCU clock restrictions?
This is our motor encoder steps per revolution. You can change that value to the encoders you have. Our 8000+ is already high. Are you sure about 22000? I cant tell how much the Arduino can handle. A giggle search should give some clue.
Thanks.
Yes it is 22000, as in original post our encoders give 400 pulses/rev. times 55 rev on reduction. We’ve changed that value during initial setup, also we gave it any other value does not matter for the final; result.
I am aware of cycles per instruction and the fact that whole firmware will reduce the amount of input Arduino can chew through before it starts dropping data, hence my question.
So you’re saying that 8000 plus is already high?
We most probably have to buy new encoders.
If you see how much chain is feed out per revolution, this encoder gives as much more then we actually need. Sorry, we are on the fast side, the chain is on the slower. Still with the ration we are in a good range.
ok so basically no change in behaviour whatsoever.
We looked through everything hardware wise.
*We’re looking at tweaking PID settings. It seems to have some influence on the motor behaviour. (any advise on the settings if you use non standard motor setup?)
*We’ve noticed very high CPU consumption on webcontrol, always above 80% when run on laptops. It’s 25% when controlled from a mobile phone through server.
It sounds like your PID settings are totally off and the should be with the different setup you are using. I had a similar though opposite experience when using a z axis motor with significantly less pulses per rev and the z motor would plunge past the desired setpoint, reverse, retract back beyond the setpoint, and then plunge again and then retract to the final spot. This was caused by the wrong PID.
Based on your description, I would guess that your sled not keeping up has to do with the fact that while the motor is turning, it isn’t turning fast enough to register movement before the system times out. The system has movement safeguards and limits the speed. Have you changed the acceleration, max velocity, and pulses per rev numbers? If so, what are they? Here are the standard ones in the Arduino Mega firmware that may impact your efforts:
to test new settings if you change them, you must disconnect and reconnect to the Mega so it will load them when it reboots.
The general approach to change the settings is to set the Ki and Kd to 0, then send a movement command to the motor. Adjust the Kp value so that the motor moves almost, but not quite the correct distance, then add Ki.
It is an iterative process with many movements and many measurements. There are many resources to read up on how to do this and the mega has a tuning mode you can use without webcontrol, which would probably be a better avenue to pursue. There are others who know much much more about this than I do. I just got an introduction on how to do it and did it recently because it needed to be done. Hopefully you can dial in your system quickly.
Ashamed to say: We’ve been around the problem for a long time but never hit the nail on the head.
Nothing to do with PID as it only regulates the movement but the scale is crucial so pulse/sprocket rotation. Our new encoders do 200 pulses/rev. But on line A and B which gives 400 pulses. I’m wondering if maslow recognizes pulse cycle or a state transition?
Thank you all for your contribution to solving this problem. We used new encoders with 200 pulses which gives us 800 state transitions per rev. That means we get 44000 transitions per sprocket rev. (1:55 reduction) and guess what?
We did not fiddle with the PID but we will at some point after few cuts.
IT’S ALIVE!
BIG UP maslow community!!!
PS. Worth noting is that our original encoders upon disassembly had some weird powder flying around the housing, most likely lack of post production cleaning, this migh also have caused errors.
the stock encoders are only 7ppr. wouldn’t using 200ppr cause data overload? Can the Arduino Mega even handle that much data? Back when we were creating our kit, we were advised to use 3ppr for the z axis motor becasue 7ppr was overkill for the z axis.
