I’ve been working on firmware to get holey to work with eastbay 1.5 boards within webcontrol. I have found or created a bug somehow and I’m not sure how to fix it and looking for some insight:
Scenario 1: calibration. first hole is located. router plunges and doesn’t retract and drags a slot across the entire board.
Scenario 2: made a 6" square with 4 plunged corners (Gcode below). Sled moves to lower left hole, plunges and then doesn’t retract all the way back to home. Once at home, it does not retract. When the home button is clicked, it retracts to its normal position and motors hum and it believes it is home. Using single z axis movements, the motor works fine. I have a metal maslow high speed z axis motor.
Has anyone else seen this? The motors don’t go crazy running until you turn them off, so this is progress with this shield, but in triangular calibration mode with this board, the z axis won’t plunge to cut the calibration pattern. In holey calibration mode, it doesn’t retract as it should. I’m unsure if it is the z axis motor and accompanying encoder setup or if it is the firmware not making the z move when it should for some reason.
Here are the z axis motor settings in webcontrol:
pitch: 31
steps per rev: 4200
kp position z axis: 1300
ki position z axis: 0
kd position z axis: 34
kp velocity z axis: 5
ki velocity z axis: 0
kd velocity z axis: .28
The 1.5 board works with WebControl as it should. Either with our 1.26b firmware or the Maslow master firmware. There is no reason why it wouldn’t work with your firmware version, the holey calibration does not change the way the shield connects to the motors, the pinout remains the same.
When i was helping you to include the 1.5 into your firmware i did a lot of testing and everything was working right.
Try installing the 1.26b firmware (maslow or master) and test with Ground control or WebControl just to rule out possible issues with your z motor settings, then go from there.
Here is a tread of users mentioning similar issues with the metalmaslow motor settings
Looking at your Z-axis settings, 31mm pitch seems excessive for a lead screw, this setting needs to match what your actual screw pitch is or you will be making the firmware believe it moves more (or less) per rotation than it actually is.
If you want to speed up the Z-axis i would bump up the maxZRPM = 12.60; in settings.cpp instead of changing the pitch and having to compensate with higher ppr for the offset.
Will do a bit of testing today and see if i can replicate your issues.
This sounds very very much like a bug that I have seen other folks reporting. I’m not sure that there is a concrete solution, yet or a reason that it is happening sometimes.
Great point. Thanks for offering the suggestion. I wonder if the error for sled not keeping up being where I set it at 20 is too high so the z axis settings fall within that limit… I’ll dig back through the settings and get the correct numbers in place and try that.
with the encoder set at 600 steps per rev and the pitch at about 2, the square gcode file actually shows the motor move up and down at each corner, so this is progress. It is slow and the motor is chattering like the PID settings need to be tuned the entire time the system is activated. to speed it up, I changed the encoder to 1200 and the pitch to 3 and it still works, but the motor tends to wander upward as the sled moves, also an indication of the PID settings needing some tuning. I’ll post more when I have it stable. setting the max z axis speed to 10x what it was (126 vs 12.6 with $18=126) didn’t seem to make much difference in the movement speed.
This seems pretty concerning to me like maybe it isn’t reading from that encoder for some reason? Or maybe the z-axis is disabled between moves but the output isn’t actually being set to stop the motor?
I the the Kp Ki and Kd values are so far off that it is hunting because it is activated. The same pid values are unlikely to work with the stock motor at 7000 steps per rev and the motor I have at about 700 steps per rev. I’ll try tuning it and see if I can get it to calm down a bit. I had similar issues when I got it working with makerverse and tuned it to work fine, but that was with the due controller, so a different ballgame. Maybe I’ll start with those PID values and see what happens.
Ah gotcha I was misunderstanding how different the steps per rev were. That makes sense that the PID values would need to be adjusted. Starting from the ones which worked on a different controller makes sense to me.
so the motor should be set at 600 steps per rev and it moves inconsistently at best. I swapped the pulleys to be 3:1 movement, so for distance, the 600 steps has a pitch of 24. If I put it at 1200 steps, it actually moves consistently, the pitch has to be 48. I’m unsure whether to start with the velocity PID settings or the position PID settings, so I set them all to 0 and it actually works with the minimal oscillations. I reviewed how to do manual PID tuning (from stack exchange):
Set all gains to zero.
Increase the P gain until the response to a disturbance is steady oscillation.
Increase the D gain until the the oscillations go away (i.e. it’s critically damped).
Repeat steps 2 and 3 until increasing the D gain does not stop the oscillations.
Set P and D to the last stable values.
Increase the I gain until it brings you to the setpoint with the number of oscillations desired (normally zero but a quicker response can be had if you don’t mind a couple oscillations of overshoot)
in case anyone else wants to try to do it. I have not found reasonable values yet and I’m not very happy with this motor setup at the moment, but I did successfully cut a couple things, but I won’t be doing any pocket cuts until this gets sorted out.
FWIW, ive always tuned PID’s by opening them up and start with the P like you did. but i would then tune the I and then bring in the D.
Not sure if the order makes any difference. maybe its just my process. The majority of industrial controllers I tune are PI only so the D is always an afterthought.
With all the gains set to zero I wouldn’t expect it to work at all
That is pretty much the technique that I used for tuning too, but I found that it was somewhat of a magical process where things didn’t always work the way I would have expected.
So GREAT NEWS!! I just did a 2 pass holey calibration with an Eastbay 1.5b board and got 4 mm precision: it is not the greatest precision, but better than the 8 mm it gave on the first pass. (sloppiness due to frame flex and user laziness in measurement accuracy)
The bad news: I need my garage back…
EDIT: I’ll be submitting a PR for 51.29 that supports 1.5b board as well as 1.8 and a few other mods. Here it is if you want to try it: holey-51.29.hex (182.2 KB)
