Poor print quality with RRF3 - especially 3.2.2.

[o_lampe]

@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?

[deckingman]

@o_lampe

@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 Beta

Now can we shut up about the AB gantry and the drivers which have nothing connected to them? It's all irrelevant.

[dc42]

@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.

[CCS86]

@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.

[deckingman]

@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?

[deckingman]

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.

[CCS86]

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.

[keyz182]

@CCS86

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.

[zapta]

@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.

[deckingman]

@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.

[CCS86]

@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.

[Phaedrux]

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.

[deckingman]

@Phaedrux You can lock it for me.

[hackinistrator]

@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.00

i 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 visible

what 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 visible

so now there is (r) and (c) , so (c) is indication for rotational axis?
is this a bug ?

[dc42]

@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).

[hackinistrator]

@dc42 no S1 used , i copied deckingman's m584 , which includes r0 without s1. and ab both flagged(r).
so a bug then ?

[dc42]

@hackinistrator said in Poor print quality with RRF3 - especially 3.2.2.:

@dc42 no S1 used , i copied deckingman's m584 , which includes r0 without s1. and ab both flagged(r).
so a bug then ?

It sounds like it. I will see if I can reproduce that behaviour.

[deckingman]

A quick update for anyone who is/was following this thread. The repairs to the printer after the crash (RRF 3.3.beta1+1) were all completed within a couples of days. We don't really know the cause but @dc42 thinks it may have been due to something called a "race condition". Anyway, long story short but I've done lots of test prints and I'm now running 3.3.beta2. With that, I got three good repeats of the part I was printing before - not perfect prints (mostly due to a lack of retraction) but they were consistent so I finally had a baseline to work with. The problems I had with pressure advance seem to have gone away so I've re-enabled that. I've moved on to printing other things (because I really don't want to make any more of that same part) and have just completed 3 collet holders which take a tad under 7 hours each. They are quite respectable prints with no significant variations in print quality between all 3.
So confidence has gone up a couple of notches..........

[jens55]

Good to hear that you are making progress!