Poor print quality with RRF3 - especially 3.2.2.

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!