Poor print quality with RRF3 - especially 3.2.2.

fcwilt

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

That's a force cancelling/load balancing gantry that is completely separate to the XY and UV gantries. It simply carries a container with lumps of lead. It's just another CoreXY mechanism that sits at the very top of the machine and is in no way connected to the hot end or the extruders. The motor directions are reversed so it does the exact opposite of the XY gantry to stop the printer rocking around when I throw my heavy hot end around at high speed.

That is most interesting. Where did you hear about that idea or was it something you devised on your own?

Thanks.

Frederick

hackinistrator

Forget about the AB gantry. That's a force cancelling/load balancing gantry that is completely separate to the XY and UV gantries.

i think in your case its important .
x is related to a , and y is related to b .

so i would expect these relations to stay the same during print . your reports shows otherwise (at least i think so)

deckingman

@fcwilt It was my own idea - another world first that has since been copied. I did a write up of it on my blog. I'm using my phone right now so can't easily provide a link but there is a link to my blog in my signature.

deckingman

@hackinistrator I can't say that I noticed, but yes A should always be the same as X and B should always be the same as Y. The X and Y motors are on expansion board 3 and the A and B motors are on the main board. That might be a clue.....

o_lampe

@deckingman
about the XYUVAB axis':
I read in the Wiki that you have to use definitions of the extra axis in a certain order. E.g. you can't define V-axis without having a U-axis. If you still do, the FW automatically defines a virtual axis.
I believe, that you have to define UVW before using ABC or you have an unknown W-axis in your system, which might do spooky things.
Your printer is running for a long time with this axis', but maybe a newer FW treats theses ghosts different?

deckingman

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

@deckingman
about the XYUVAB axis':
I read in the Wiki that you have to use definitions of the extra axis in a certain order. E.g. you can't define V-axis without having a U-axis. If you still do, the FW automatically defines a virtual axis.
I believe, that you have to define UVW before using ABC or you have an unknown W-axis in your system, which might do spooky things.
Your printer is running for a long time with this axis', but maybe a newer FW treats theses ghosts different?

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;

I'm fairly sure using those matrix values should sort out any ghost axes but I'll leave it to @dc42 - he's best placed to know.

deckingman

@fcwilt Here is a link to the first post I did with the load balancing gantry
https://somei3deas.wordpress.com/2018/10/04/dynamic-force-cancellationload-balancing/. Not that it was later discovered that this has no effect on print quality. That is to say, even when the entire printer rocked from side to side, the actual print was fine. So eliminating the rocking was largely a solution to a problem that doesn't exist.

fcwilt

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

@fcwilt It was my own idea - another world first that has since been copied. I did a write up of it on my blog. I'm using my phone right now so can't easily provide a link but there is a link to my blog in my signature.

Thanks. That was quite educational.

But I think I've found the source of ALL of your printer problems.

It is not big enough.

Frederick

deckingman

@fcwilt The trouble is, I can't make it much taller because I'm not tall enough. I have to stand on a step to see they very top of it as it is now. I did mention to my wife that if we did away with the freezer in the garage, I could make it wider. But for some reason, she prefers to have that second freezer. Strange creatures women - always have the wrong priorities

hackinistrator

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

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

@deckingman
about the XYUVAB axis':
I read in the Wiki that you have to use definitions of the extra axis in a certain order. E.g. you can't define V-axis without having a U-axis. If you still do, the FW automatically defines a virtual axis.
I believe, that you have to define UVW before using ABC or you have an unknown W-axis in your system, which might do spooky things.
Your printer is running for a long time with this axis', but maybe a newer FW treats theses ghosts different?

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;

I'm fairly sure using those matrix values should sort out any ghost axes but I'll leave it to @dc42 - he's best placed to know.

did you copy and paste m669 from your config.g , are you sure its not a mistake?

in m584 a and b defined as driver 2 and 3 .
in m669 you are setting a and b to move with drives 5 and 6 ? there is no drive 6 on main board .
i dont know whats going on here .

also in m584 you define x as driver 2 on 3hc(b3) and y as driver 1 ? any reason for that ? usually x comes before y .

this is your motor location per you dump files :
3hc #3
Driver 0: position -1182960 z axis
Driver 1: position 3200 y axis
Driver 2: position -145076 x axis

main board
Driver 0: position 31360 u axis
Driver 1: position 6604 v axis
Driver 2: position 16320 a axis
Driver 3: position 31840 b axis
Driver 4: position 4756 ?
Driver 5: position 31360 ?

when you paused the print , a and b (if they are configured right , not sure anymore) should be :
a around 200mm from its end stop
b around 400mm from its end stop
is this logical ?
i dont know how much steps/mm your xy has . if its same as ab (80steps/mm) your x should be around 1.8meters from end stop . i dont thik your printer is that big
so maybe you're using different steps/mm for xy , but anyways i think their relation to ab is way off .
can you send M669 command and post the report ?

edit :
almost forgot , drives 5,6 on main board not defined , but i still see changing position on them , whats going on ?

deckingman

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

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.

o_lampe

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

deckingman

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

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.