Is this the center point deviation that is still using the old calculations in
this release (that I have a PR submitted for)?
David Lang
1 Like
Yeah, that change will be in the next release. I need to test it still.
@bar some code clean up, that was annoying the 
out of me.
Standardize error_code and alertdlg by md8n · Pull Request #54 · BarbourSmith/ESP3D-WEBUI
I’m pretty happy that it is OK and ‘good to go’, but running a test with it is still probably a good idea as it touches several files that are probably more than a little bit crufty.
This is a sorta precursor for the other clean up that I’m doing that I think @dlang wants out of the way before his stuff gets merged in.
1 Like
1-2mm of innacuracy is a lot as it adds on top of general machine accuracy.
then, @bar it seems it could be avoided by having the small increment alignment jogs treated differently than the large jog movements
1 Like
It just dips a tad when the jog is finished and the arms slack a bit, when you move it again or start a cut it tightens up and returns to where it was.
1 Like
But the dip makes it impossible to jog and rezero on features inside of 1-2mm range then thats something foundational and worth solving IMO. for example we could have a jog mode modifier that keep belts tight with microjogs.
2 Likes
Teied getting 0.85 to work all day but no dice. It had various crazy issues.
- could calibrate but gave position errors any time trying to cut a job and crashed
- failed to start calibrating (center point deviation)
- failed calibration very early, with excessive belt tension (0.1 fitness)
- failed calibration late (0.42 fitness)
The issues were sensitive to the machine size parameter, but with careful measuring and re-measuring of anchor point location I could not resolve this.
I also tried re-sinking my anchors using a laser to get as square as possible (1"/4 x delta, 1"/8 y delta was the best I could manage).
However, the machine calibrates happily enough with 0.84 and runs, albeit with some reliability issues at the extremes of a 4x8’ sheet.
1 Like
Michael Barrow wrote:
Teied getting 0.85 to work all day but no dice. It had various crazy issues.
- could calibrate but gave position errors any time trying to cut a job and crashed
- failed to start calibrating (center point deviation)
- failed calibration very early, with excessive belt tension (0.1 fitness)
- failed calibration late (0.42 fitness)
The issues were sensitive to the machine size parameter, but with careful measuring and re-measuring of anchor point location I could not resolve this.
I also tried re-sinking my anchors using a laser to get as square as possible (1"/4 x delta, 1"/8 y delta was the best I could manage).
However, the machine calibrates happily enough with 0.84 and runs, albeit with some reliability issues at the extremes of a 4x8’ sheet.
what is your frame size?
David Lang
This sounds to me like it could be a magnet issue?
If you do extend all followed immediately by a retract all what numbers do you get printed out?
@md8n @bar there is a bug in the naming cleanup
it defines nvs as a string = ‘maslow’ (Maslow.h line 31) which is a duplicate definition of the name nvs
I tried changing the name in case it was duplicating something that was included from nvs.h but didn’t find it, so I created a PR to back out that portion of the change
1 Like
That’s probably a result of a bad merge.
I’m pretty sure that I moved that declaration, so after a later merge it probably got reincluded back at its original location.
1 Like
heads up that I have started a major cleanup effort on the code that changes from varnameTL/TR/BL/BR to varname[0-4]
eventually, a lot of functions will collapse together (instead of four computeXX() functions, there will be one, that takes the arm as a parameter)
I have the PR marked as draft, but it should be safe to merge at any point as the commits are all supposed to do a single thing and not change any external interfaces. Reviewing the entire PR as one diff will be very difficult, but each commit should make sense and be straightforward on it’s own (even if it changes a lot of lines, it should be a pretty mechanical change)
I’ve got enough up to make it worth starting to review
1 Like
@bar as I am going through this, there are for axisXXHomed variables that get initialized and set to false, but as far as I can tell are never used. There is also a axis_homed array that looks like it may be intended to replace these separate variables. Can you see if there is someplace that these four variables are used that I’m missing?
1 Like
@bar another code question, retractALL(), extendALL() and retractXX() functions are defined, but I do not see anywhere that they are used. am I missing something? or are they dead code from before axisxx.retract() was being used?
found the calls in …/ProcessSettings.cpp
1 Like
@bar another code question:
void Maslow_::setTargets(float xTarget, float yTarget, float zTarget, bool tl, bool tr, bool bl, bool br) {
this appears to only every be called with x/y/z targets, never with any of the per-arm flags set. what is the reason for having them (and then testing for them inside the function)??
1 Like
I am not sure, that was a change that @RomanG made pretty early on and it’s probably safe to take those out at this point if they aren’t used. Great clean up!
Sorry it took me so long to respond, somehow I missed this thread being unread 
I figured it was just such a massive set of changes that you weren’t getting to it yet 
you’ve picked the first two of the 14 commits that I’ve submitted. hopefully I kept each individual commit straighforward enough to review.
1 Like
It was a problem with the JST based hardware. I downgraded to the original hardware and had no issue with the same set of everything (just swapped over the encoder boards with the same magnets, arms, etc.).
I guess this is good and bad news since I had hoped the JST encoder boards would have no reliabilty problems but at least I know where the problem is
Might be an obvious question, but did you put the heatsinks on the new board?
Hi @ian_ab, thanks for responding!
Yea, I did move the heat sinks over between the two motherboards.
The glue is still hanging on in there even after putting them back on the original release PCB.
Michael