Poor print quality with RRF3 - especially 3.2.2.
-
@hackinistrator Dunno. Driver position (as reported by M122) is fairly new so I've never looked at it before. Maybe there is something odd about the way they are reported - maybe something different for expansion boards and the main board?
Don't forget this is CoreXY kinematics, not Cartesian. So both motors contribute to movement. That's why I prefer to call them Alpha and Beta but for configuration purposes, they have to be called X and Y (or U and V or A and B). Also, the A and B motor directions are reversed. Oh and the axes lengths are a bit longer than the XY.
I can confirm that they all use the same belt and pulley pitch and all motors are 0.9 degree, so the steps per mm are the same for all axes (80). I can also confirm that it all works as it should.
No idea why Drivers 4 and 5 report anything - as you say, they aren't configured and physically, don't have any motors connected. You'll have to ask @dc42.
-
On the expansion boards, the driver positions are the net number of microsteps moved since the board was powered up or reset. Therefore, for a drive used to move an axis, the position is where the axis is now compared to where it was at power up. However, if after homing it you move the axis to a particular position and record the corresponding driver position, then when you next move the axis back to that position, the driver position should read the same.
For the main board, if drivers 4 and 5 have never been configured, I would expect the positions to read back as zero.
-
@hackinistrator said in Poor print quality with RRF3 - especially 3.2.2.:
main board
Driver 0: position 31360 u axis
...
Driver 5: position 31360 ?Both the same! Coincidence or another ghost axis in the machine?
-
We have another data point. I don't think it's particularly relevant to the issues at hand, but here goes.............
At Davids' request, I've run a test with the belts removed from the motors. So the machine is as configured but obviously the carriages don't move. So no damage will result if there are any sudden wild excursions away from the commanded XY position. I've also unloaded the filament. So the only difference between this and a real print, is that the motors won't have the same load.
Soon after the test is started, I pause the print. My pause.g moves all 3 gantries (XY, UV and AB) to a fixed position away from the part. At this time I run M122 on all boards. Then I resume the print, pause it again at about 98% complete, and repeat the M122s. So the individual driver positions each time the print is paused should be the same (because the gantries are moving to the same position in space).
For the important motors (the X and Y) which are on an expansion board, this is the case. It also true of the UV motors which are on the main board. And it is true for the B motor on the main board. However, there is a difference when looking at the "A" motor. This reports a position of 8480 after the first pause, but 55520 after the second pause. I don't think this "real" because I did not remove the belts from the AB gantry (because it is de-coupled from anything else and I don't care if it crashes because I'll be taking it off when I get around to it). That gantry looked like it was in about the right position throughout the print and I'm pretty sure I'd have spotted such a huge difference in reported position if it was "real".
I don't really want to get hung up about this AB gantry because essentially, it doesn't do anything except move lumps of lead around. If it crashed or did something unexpected, it would have no effect on the print (even it bent the frame that it's on because that is de-coupled from the main printer frame).
I also don't really want to get hung up about the drivers that have nothing connected to them, because it's just a distraction from the real issues at hand.
But for info, driver 4 (unassigned) reports the same position as driver 1 (the "V" motor). That is the case for both pauses. Driver 5 (also unassigned) reports the same position as drivers 0 ("U" motor) and 3 ("B" motor). And yes drivers 0 ( U) and 3 (B) report exactly the same position, which seems to be somewhat implausible although not impossible.
In summary, there might be something odd about reported driver positions for the AB gantry that does nothing more than move lumps of lead around, and for the drivers that have nothing connected to them. But the critical thing is that the XYU and V drivers show repeatable values when the machine is moved to the same, fixed, position.
I'll be running more tests today to try and capture that X shift that I experienced before...............
-
@deckingman said in Poor print quality with RRF3 - especially 3.2.2.:
I have this
M584 X3.2 Y3.1 Z3.0 U0.0 V0.1 A0.2 B0.3 E1.0:1.1:1.2:2.0:2.1:2.2 R0 P7;
and
M669 K8 A0:0:0:0:0:1:1 B0:0:0:0:0:1:-1;@hackinistrator already quoted these and mentioned AB weren't mapped right.
Shouldn't it be A0:1:1 and B0:1:-1, since you use the second and third driver of the first board?You answered, you like to call your axis Alpha and Beta, but I still don't get it, what's what?
-
@hackinistrator already quoted these and mentioned AB weren't mapped right.
Shouldn't it be A0:1:1 and B0:1:-1, since you use the second and third driver of the first board?The matrix values and kinematics are as advised by Manuel who is part of the Duet team. I tend to believe what the Duet team tell me is the correct way to do things, rather than what a forum user who joined less that 3 months ago tells me.
I'm not sure why people keep saying I've got it wrong when I repeatedly say that it it works just fine and has been doing for years. It has been working long before the people who tell me it's wrong even joined this forum. The AB gantry homes to the far right corner (because the motors are reversed) when the XY and UV gantries home to the front left corner. Once homed, the AB gantry faithfully replicates whatever moves the XY gantry does but in the opposite direction.
What I'm saying is that the AB gantry works exactly as it is intended to work. So can people please stop telling me that I, (and the Duet team) have got the configuration of it wrong.
It is entirely possible that the matrix values which suffix the "K8" parameter are the cause of driver positions being reported for drivers 4 and 5. But who cares? It has nothing to do with the issues at hand because nothing is connected to those drivers.
You answered, you like to call your axis Alpha and Beta, but I still don't get it, what's what?
I don't call axes Alpha and Beta. If you read what I wrote again (and if you knew anything about CoreXY kinematics) you'd see this - quote " So both motors contribute to movement. That's why I prefer to call them Alpha and Beta............" It's motors that are better described as Alpha and Beta because either pure X or pure Y movement involves both motors turning. In one case, they both move in the same direction. In the other case, they move in opposite directions. If just the Alpha motor (X) turns, then movement is at 45 degrees so you can't really call it the X motor because when it turns on its own, it produces both X and Y movement. Likewise the Beta motor (Y) also produces both Y and X movement. So you can't really call the motors X and Y in the same sense that a Cartesian would be. Hence the better terminology is to use Alpha and Beta when talking about CoreXY kinematics.
Here is how the motors are described in my config.g file
M569 P3.2 S0 ; Drive 0 goes backwards - Lower left XY Alpha M569 P3.1 S0 ; Drive 1 goes backwards - Lower Right XY Beta M569 P3.0 S1 ; Drive 2 goes forwards - Z M569 P0.0 S0 ; Drive 3 goes backwards - Middle left UV Alpha M569 P0.1 S0 ; Drive 4 goes backwards - Middle right UV Beta M569 P0.2 S1 ; Drive 6 goes forwards - Upper Left AB Alpha M569 P0.3 S1 ; Drive 7 goes forwards - Upper Right AB BetaNow can we shut up about the AB gantry and the drivers which have nothing connected to them? It's all irrelevant.
-
@o_lampe said in Poor print quality with RRF3 - especially 3.2.2.:
@hackinistrator said in Poor print quality with RRF3 - especially 3.2.2.:
main board
Driver 0: position 31360 u axis
...
Driver 5: position 31360 ?Both the same! Coincidence or another ghost axis in the machine?
The reason is that the "position" reported against each driver is not really the driver position, it is the position of the axis with the same number. So the figures against drivers 4 and 5 are the positions of the A and B axes. In RRF 3.3beta3 I will either fix this or remove the driver positions from the report.
-
@deckingman said in Poor print quality with RRF3 - especially 3.2.2.:
The matrix values and kinematics are as advised by Manuel who is part of the Duet team. I tend to believe what the Duet team tell me is the correct way to do things, rather than what a forum user who joined less that 3 months ago tells me.
I'm not sure why people keep saying I've got it wrong when I repeatedly say that it it works just fine and has been doing for years. It has been working long before the people who tell me it's wrong even joined this forum.
Now can we shut up about the AB gantry and the drivers which have nothing connected to them? It's all irrelevant.
What does forum join date have to do with anything?
Your air of superiority and defensiveness aren't helping you solve this issue, or encourage people to spend their time to help you.
-
@CCS86 said in Poor print quality with RRF3 - especially 3.2.2.:
What does forum join date have to do with anything?
Well when you have two pieces of advice which differ, and of those one is from a long standing member of the Duet team who actually write the firmware, and the other is from a user with only 3 months experience, which one would you take?
The persons' join date becomes relevant when you have conflicting advice. One needs to evaluate that advice somehow and one way to do it is to make a judgement about the experience and knowledge of the persons giving the advice.
Your air of superiority and defensiveness aren't helping you solve this issue, or encourage people to spend their time to help you.
You are of course entitled to your opinion. I'm trying to resolve an issue related to print to print variability. If people want to tell me that they think my load balancing gantry which has been working flawlessly for 2 years (and which is decoupled from the machine and has no effect one way or the other) is configured incorrectly (despite the fact that this is how the firmware authors have told me to configure it) then I'm afraid they'll get short shrift.
If that come across as being superior or defensive then tough sh*t. If it discourages people who can't come up with any practical advice for the issues at hand, then good. They won't waste their time writing.
Thanks for taking the time to make a personal dig at me - that was helpful too - now can we get back to the issues at hand?
-
Or another way of looking at it is this. I was the first person to put extruders on a separate gantry. The Duet guys implemented the firmware for me that enabled those two gantries to be homed independently. So that's how the first CoreXYUV was invented. Then later on, I added the AB load balancing gantry. That was another world first which has since been copied. But AFAIK, it is the only CoreXYUVAB in existence - certainly the only one with a 6 input mixing hot end. So as regards to this machine, me being the person who designed and built it from the ground up, means that I do have more knowledge of how it works than anyone else.
One could even say that I have superior knowledge of it. So if people find that simple fact offensive, then there isn't much I can do about it. -
Since you are convinced that everything you are doing is above being questioned, why did you even post on the user forum to solicit opinions from inferior beings?
Just talk to the Duet engineers directly and spare everyone else from your dog and pony show.
-
As requested, I'm starting a new thread. Not sure if this is the correct section. If not, feel free to move it.
@deckingman was specifically asked by the Duet engineers to post here
For anyone watching this thread, and for those who have contributed, I just want to say that the Duet team and I have opened up the communication medium that we used at the very start (when Gen 3 was still at the pre-production stage), in order to work together to resolve these issues. That's nothing personal - just that these forums are maybe not the best way to post messages rapidly back and forth between us.
They have now opened up more direct channels.
Just talk to the Duet engineers directly and spare everyone else from your dog and pony show.
No-one is forcing you to click on this thread, so consider yourself spared.
-
@keyz182 said in Poor print quality with RRF3 - especially 3.2.2.:
They have now opened up more direct channels.
Harmony was restored on the kingdom island.
-
@CCS86 said in Poor print quality with RRF3 - especially 3.2.2.:
............... why did you even post on the user forum to solicit opinions from inferior beings?
Quite simply because at the outset, the only way to report issues is via these forums. If you take a look at dc42s signature, it specifically states not to contact him by other means. So prior to opening up an alternative channel for me to contact them directly, starting a new thread on these forums was the only way to highlight the problem to the Duet team.
I'm sorry about your inferiority complex - there is nothing I can do about that either.
-
@deckingman said in Poor print quality with RRF3 - especially 3.2.2.:
I'm sorry about your inferiority complex - there is nothing I can do about that either.
I have no need to prove my qualification to you. But, no, self esteem is not something I struggle with. I am just observant enough to see you treating people like crap. A fact you are oblivious to. Just consider for a moment, that you could tell people why you think their suggestions are wrong, without being rude and arrogant. As a mechanical engineer, I can appreciate your build. But, I can also see false assumptions you are making in this diagnostic process.
-
Let's all take a deep breath and relax a bit, shall we?
I'd rather not have to lock this thread, but maybe a cool down is needed?
I expect the utmost civility from all involved, nothing less.
-
@Phaedrux You can lock it for me.
-
@deckingman said
The matrix values and kinematics are as advised by Manuel who is part of the Duet team. I tend to believe what the Duet team tell me is the correct way to do things, rather than what a forum user who joined less that 3 months ago tells me.
relax . i did't say your matrix is wrong , i just stated that "I dont know whats going on here"
also i never suggested you to use different matrix or anything . just tried to help .your matrix is correct .
documentation for M669 command is very poor and lacking.i didn't realize at first that in axis matrix all extruder drives are ignored when counting the drivers .
i tested your matrix , this is the actual drive mapping :
m669 Kinematics is modified CoreXYUV, matrix: 1.00 1.00 0 0 0 0 0 1.00 -1.00 0 0 0 0 0 0 0 1.00 0 0 0 0 0 0 0 1.00 1.00 0 0 0 0 0 1.00 -1.00 0 0 0 0 0 0 0 1.00 1.00 0 0 0 0 0 1.00 -1.00i think drive assignment(m584) in RRF is pretty flawed also . it works , but it could be better .
for example when you assign drives for axis , you assign single drive for axis , while actually you move 2 motors (in case of corexy) so both X and Y should be assigned with same 2 motors .@dc42 when i send M584 for corexyzuvab i get this
m584 Driver assignments: X3.2 Y3.1 Z3.0 U0.0 V0.1 (r)A0.2 (r)B0.3 E1.0:1.1:1.2:2.0:2.1:2.2, 7 axes visiblewhat is the (r) on AB axis?
at first i thought its rotational axis indication , but i set R0 in m584 , so i set it to rotational axis intentionally and this is what i get :
m584 Driver assignments: X3.2 Y3.1 Z3.0 U0.0 V0.1 (r)(c)A0.2 (r)(c)B0.3 E1.0:1.1:1.2:2.0:2.1:2.2, 7 axes visibleso now there is (r) and (c) , so (c) is indication for rotational axis?
is this a bug ? -
@hackinistrator said in Poor print quality with RRF3 - especially 3.2.2.:
so now there is (r) and (c) , so (c) is indication for rotational axis?
(r) means NIST rotational, and (c) means continuous rotation (which isn't fully implemented yet). If you use R0 when creating axes and you do not also use S1, then the new axes should not be flagged (r).
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 no S1 used , i copied deckingman's m584 , which includes r0 without s1. and ab both flagged(r).
so a bug then ?
