Software bundle 3.4.0beta2 now available

nuroo

I cant wait for the DWC tuning plugin

Did you give any thought to having firmware identify sensor orientation compared to printers axis and config itself accordingly?

CCS86

@nuroo said in Software bundle 3.4.0beta2 now available:

Did you give any thought to having firmware identify sensor orientation compared to printers axis and config itself accordingly?

That sounds like a lot of effort for something that is really easy to configure manually.

dc42

@ccs86 said in Software bundle 3.4.0beta2 now available:

@nuroo said in Software bundle 3.4.0beta2 now available:

Did you give any thought to having firmware identify sensor orientation compared to printers axis and config itself accordingly?

That sounds like a lot of effort for something that is really easy to configure manually.

Exactly. It would be nice to have and we may implement it in the plugin eventually, but it's not a priority.

nuroo

@dc42
no problem.
I appreciate the reponse. Just had a hell of a time picking the right orientation. Ultimately I never did pick the correct orientation and someone here had to help me.

manpowre

I upgraded my duet3d wifi 2 with the 3.4 beta 2 today for my Flsun QQ-S delta. I was excited about a few things, input shaping possibility, the fix for loosing z0 position of bed when homing (if I understood it correctly), and the negative z value fix where it was z0 and didnt go negative z ( I dont have this issue but a friend of mine does).

all working as it should.. I did a test print - flawless. I will try input shaping once I can get hand of a accelerometer.

I had 3.3 beta2 before. (skipped 3.3 release since beta2 was working just fine).

petriheino

Updated from 3.2 to 3.4.0beta2.
Duet 2 Wifi, everything seems work fine or similar to 3.2 (ran 20pcs prints).

Noticed there is some pressure advance bug fixes in the Github (1.8.2021), those were probably included in this beta2 release?

It made a small improvement in cylinder test but doenst still fix retraction related problems.

Are there plans to solving retraction PA effect?

dc42

@petriheino please explain what you mean by "retraction PA effect" - preferably by linking to another thread,

petriheino

@dc42 If PA is enabled, and a retraction (or G10) is performed, the next unretraction (or G11) will cause a defect in the next connected movements (or ring of segments).

From such connected segments, first moves are missing material and the last moves have too much material

Summary of problem:

Settings that affect the amount of PA retraction error:

retraction distance
retraction speed
retraction z hop distance and speed
travel distance between parts
Amount of PA value

This causes random print quality errors in different parts where there is retractions and travel moves and is not possible to correct by setting calibrations or configuration changes.

To be able to print any parts, extremely small retraction distances and speeds has to be used as to minimize error, that are linked to PA value and travel distances between parts (for example for PLA with Pa 0.04):

retraction distance 0.2mm - 0.4mm
retraction speed 900mm/min - 1200mm/min
z hop 0.1mm - 0.4mm
possibly also extra unrectraction distances of 0.03-0.1mm to hide error

Some links:
PA tuning
Enhancing pressure advance
PA tuning Disparencies

dc42

@ccs86 said in Software bundle 3.4.0beta2 now available:

Looking forward to testing the Maestro IS build!

My original plan was to implement the new motion system in integer maths for the Maestro. That turned out to be complicated, so I decided to try using the same floating point code that the other processors use. I was concerned that the maximum step rate would be greatly reduced when using floating point maths in the step ISR on a processor without FPU. However, I managed to almost double the speed of floating point square root calculations on the Maestro, by adapting our own integer square root function to work on floating point values. Consequently, the reduction in maximum step rate is modest, perhaps 10% to 20%.

I have put a preview of RRF with input shaping for the Maestro at https://www.dropbox.com/sh/cq7q3g8coymo9s3/AABtPYEzV1_unETpKEMPInSia?dl=0. Use it with care because it has had very limited testing.

CCS86

@dc42 said in Software bundle 3.4.0beta2 now available:

@ccs86 said in Software bundle 3.4.0beta2 now available:

Looking forward to testing the Maestro IS build!

My original plan was to implement the new motion system in integer maths for the Maestro. That turned out to be complicated, so I decided to try using the same floating point code that the other processors use. I was concerned that the maximum step rate would be greatly reduced when using floating point maths in the step ISR on a processor without FPU. However, I managed to almost double the speed of floating point square root calculations on the Maestro, by adapting our own integer square root function to work on floating point values. Consequently, the reduction in maximum step rate is modest, perhaps 10% to 20%.

I have put a preview of RRF with input shaping for the Maestro at https://www.dropbox.com/sh/cq7q3g8coymo9s3/AABtPYEzV1_unETpKEMPInSia?dl=0. Use it with care because it has had very limited testing.

Well, that is an exciting turn!

I'll give it a try. Let me know if you would like feedback on anything specific.

Thank you for the effort!

that guy E

@dc42 Are there any plans to allow independent X an Y frequencies on a Duet2. I believe I read somewhere that RAM may become an issue.

On my CoreXY I saw ghosting nearly eliminated on the Y axis with the latest Beta, but still present on the X. I used the lower of the 2 values when I initially calculated the frequencies.

dc42

@that-guy-e said in Software bundle 3.4.0beta2 now available:

@dc42 Are there any plans to allow independent X an Y frequencies on a Duet2. I believe I read somewhere that RAM may become an issue.

Yes for Cartesian machines. For CoreXY machines, using separate input shaping for X and Y is a lot more complicated.