I think I ruled out anything mechanical. I even fortified my z axis further with additional brackets. Z slides very smooth and holds position. I appreciate all your help in troubleshooting the matter. Is an EPROMM wipe something I should try?
As i said, my list was an attempt to capture all potential causes. including the ones that were easily or previously ruled out. i think part of the problem is that not everyone is up to speed on previous findings and what has been attempted so far. theres a lot of posts to go through.
ill make a note of what you have done mechanically to rule out the binding.
i think a wipe might be in order. however, it would require you to essentially set up your machine from scratch.
when you bought your machine, what set up did you do with it. Dis you do a complete wipe and set up or did you just start running it from ehe software and firmware the previous owner had used?
1 Like
I didn’t wipe anything, I installed holey firmware from the webcontrol button. Then ran the calibration. I’m think the previous owner used groundcontrol and the waste board only had markings that correspond with triangular Cal.
I think this might be a good place to start. From what I udnerstand the first thing you did when you purchased the machine was switch to WC and update the firmware from it. This would have meant you would have needed to import the Ground Control settings file into Web Control as well. It may be that something went hinky with the settings file import or the firmare upgrade.
There is honestly no way of knowing what the previous owner has done or what if any problems they encountered. If it was me I would start fresh, from scratch. If for any other reason than to eliminate this from the potential causes and to start out wiht a known installaion. I believe when you “Wipe EPROM” it will erase everything on the Arduino. All of your calibration data and machine settings will be lost. It will be as if your machine was being set up for the first time. It’s a lot of work though and I would like someone else to chime in on wether a wipe and re-install is a wise move.
this would cause the actual position to be wrong (cuts are bad), but it would
not cause the position that the system thinks it is at to vary
(trivial, not quite accurate version, if pulses are missed, it will just move
things further until it thinks it’s at the right place, that won’t cause it to
think it’s at the wrong place)
David Lang
Im not following. What were you referring to?
sorry, I thought I quoted it, the line about electrical noise in the encoder
lines.
This could cause errors in the pysical location, but not in the logical position
(which is what’s being reported_
David Lang
I wiped controller settings, wiped controller position and settings and wiped controller EEPROM. When I wiped the EEPROM I get an alarm connection failed or invalid firmware. I take it that it worked then?
Wiped everything, deleted webcontrol did a fresh install. Still having the same issue.
1 Like
Ok, I see now. Isn’t he seeing both though? A differnetial in the gcode command and the position feedback being reproted in WC as well as inconsistent depth of cuts in the pockets? I may be mistaken.
EDIT:
A bad encoder reading for things other than noise (defective disk, readh head, etc…) would have the same effect right? The controller would just keep trying to close the difference which would result in a Z position not physicaly being where it is supposed to be.
Ok, this actualy eliminates a few things. It was a lot of extra work but we can rule out something in the initial set up causing the problem. I’ll update the list.
1 Like
yes, an electrical error would result in moving the wrong distance.
I think we need to look into this in two steps
-
address the issue of the Z axis not moving all the way to where it’s told to
move as far as the controller knows (especially if we can trigger the problem by
just repeating the same movement cycle to increase the error) -
once we have the machine thinking that it’s moving correctly, see if we still
have a problem with the physical movement not being what’s expected.
chasing the physical error while the system is telling us that it’s not moving
where we tell it to move seems hopelss to me.
David Lang
1 Like
My bet is on one of these two. A lose cable could be giving inconsistent feedback to the system, but I would expect that to result in gradual position creep over time, rather than it just being a bit off consistently.
I think it’s a PID settings issue. Why other people with the same setup aren’t seeing it I’m not sure, but it would make sense for the z-axis PID settings to be different for this motor than for the original one. I would try increasing the P value in the PID settings a little bit at a time and see if it helps. If it starts to oscillate you’ve gone too far.
@TimS reported that he has the Maker Made Classic Z-Axis motor. Does anyone know what the default PID settings are for that motor and is that what his machine is currently configured for?
The key here is consistency. His error is very consistent. Intermittent faults wouldnt be this repeatable.
The thing is he is seeing actual discrepencies in his depth of cuts. Which supports the PID tuning idea. If the PID needds tuning, wouldn’t the controller be constantly trying to close the delta? if so, shouldnt he be hearing the Z motor constantly buzzing rather than just moving to a position and stop?
1 Like
Well, I’m lost. Order a new motor?
Or
Drink more beer, so I can’t see the numbers?
1 Like
@TimS , we seem to be circling around this being a PID settings issue. You’ve ruled out physical binding, you completely wiped and reset you controller which rules out a corrupted set up. You were using a version of WC that many others have used yet not reported this problem. It’s also unlikely to be an encoder feedback issue.
You mentioned that this is Maker Made classic kit. I’d be curious to see if @MakerMadeCNC can offer up the recommended PID settings for this motor. Can you confirm the PID settings (Kp, Ki, Kd) that you are currently using?
1 Like
the default pid settings should be correct for this motor in Webcontrol… I think that is part of the radio silence.
1 Like
it’s not time to order a new motor (at least not yet)
we need to fix the software problem that’s causing it to not try hard enough to
move to the right location first. Once we make it so that it thinks it’s doing
the right thing, then we can look at the mechanical/electrical side of things to
figure out why it’s not doing what it thinks it is, but first we need to get it
to where it thinks it’s doing the right thing.
so the Z axis pid tuning seems to be where we need to start (either that or we
need to figure out a change to the firmware to get it to report what it thinks
is happening better to be able to track this down)
(comments to everyone else)
I think that some sort of debug flag for webcontrol and/or the firmware that
would let us log where it thinks it should be and where it thinks it is on a
periodic basis (say every second or so) so that we can see the difference
between the sled and the gcode in the logs rather than just in video of the
display would be a useful thing to have in the long term.
how exactly does webcontrol know where it is to display the numbers that are
alarming Tim? is this just calculated? is it sending a B code to the firmware to
get a position report? (if the latter, then we should be able to make a gcode
file that excercises the Z axis and then issues the B code to get the position
report in the log file, right???)
the new webcontrol has something to test/set the Z pid values, is that ready for
Tim to try?
David Lang
I tried the z PID positional tuning and changed the default kpPZ from 1300 to 900 thru 2500 in intervals, ran a gcode at each interval and nothing changed.
1 Like
when the gcode you run sends the Z to a depth, it travels to that depth and holds there. when its holding, do you hear the Z motor continuing to buzz or does it stop until the next Z axis move? im more interested in the answer to this when the position demand mismatch exists but also in general too.