Ability to change movement/feedrate button increments, please

I work with a 8x8x6 meter concrete printer...... 100mm is not very long to move, and 6000mm/sec is just slow af....

Kulitorum

@Kulitorum here.

I tried to use G2 and G3 but they are not interpolated very nice in current firmware and pausing during a G2 or G3 messes up and the printhead moves in random directions. I talked to dc42 about this, but I guess the current use of G2 and G3 is too low for him to spend time with it.

So I use very short lines of a max of 5 mm. With good jerk and acceleration parameters, that moves smoothly and allows me to pause a print at any time within 25mm, in regards to 4-5 commands being buffered in firmware.

Your slicer should keep an eye on overflow (crossing 360 degrees) and if needed "rewind" the rotation back to 0 to untangle your wires.

Now watching thread, if you need more help. Unfortunatly I can't share my code.

Kulitorum

This is the printer:

@dc42 Hello again.

We setup a test where we ran the same gcode with the nozzle rotation configured for the U axis and for the A Axis.

Thinking that the shaking would be clear, I mounted a gopro on the printhead - looking down - and put some gloves on the floor for reference. The most obvious result is that the whole print happens a lot faster when the nozzle is running as the A-axis, but looking at the printer in real life, you also notice some shaking and hard accelerations on the U-axis version.

I have uploaded an (unlisted) video here: https://youtu.be/abVquTFmLH8

I will mail the config files and gcode files (only the first layer) to you.

My conclusion is that the axies cannot be running the same code, something is not right.

Please have a look.

Michael

750w servo motor on the x-axis.

https://www.youtube.com/watch?v=nMCpMZPh6Ds

I hope to print at this speed, but I have set the expected speed at 300mm/sec. We'll see what the concrete pumps can do.

Kulitorum

@t3p3tony Yes, I did that already, so that you can pause the machine quickly if there's a minor issue. I'm cutting all moves into 5mm sections.

@phaedrux I mailed it to DC42

How did you get a Duet to be this noisy?

The design is wasting a lot of space on the XY plane, and not gaining much from it. And you move a lot of weight around for no real reason.

The couplers have to be 100% centered, and I doubt these are, as they are tightened from one side.

At least put the motors "outside" the moving area, so they "stick out" of the frame. This will increase your printable area around 10cm on both axes.

Lots of design issues IMHO

Xa Xb Xc, Ya, Yb, Yc ?
D,H,I,J,K,L,M ?

@dc42 Cool, it works now - dont know why it didnt before, but now it does. Thank you for the help.

@dc42 On most machines we are running Release 3.3 - never machines are 3.4.1

@dc42 Agreed, it just does not seem to make any difference on site. That being said, the printer is in Saudi Arabia and I'm in Denmark, so I do not have hands on myself. We already have people on site and are sending another guy down there to help debug it.

Thank you for the input.

I build concrete printers that are run by a Duet3.

As a sales and information tool I created an app that allows you to configure your concrete printer - https://cobod.com/configurator

I now made a VR version where you can walk around the machine and play with it and I want to add the Duet GUI to the VR version so we can use it for training. To make it as realistic as possible my idea is to include RRF in the code and present the user with the actual webpage (on a handheld device in VR) so you can simulate basically everything.

So to do this I need to compile the core parts of RRF without all the driver and wifi stuff (and probably more) under windows. My hope is to have everything running and feeding XYZE values to my printer simulator setup so you can have the machine running as real life.

But compiling anything eludes me - I have spend two days and gotten nowhere.

Does anybody have something like this running that I can use as a starting point? - RRF compiling on windows for win32 in any capacity?

Any help or ideas are very welcome.

I'd even pay someone to make it for me

@infiniteloop X-2 of cause

@infiniteloop Thanks for the help - yes, I read it all.

You think the P parameter is explained? - Pnnn means what? Is P2 an option?

Yes, it's 23mm over 4900mm I will fix the frame, but right now I have half a house printed and the printer no longer aligns with the print for some unknown reason

It gets better with M556 S100 X-1 P1 and even better with X-1.9 but X-2 throws it way off. I don't get it.

Also the documentation only referes to using the printed test piece, which really does not apply for 12x20m long houses - it does not really explain how it works.

I hope @DC42 will try to explain tomorrow, and maybe update the documentation for others to read later.

Thank again.

What are the parameters for M556? - I can only find one description and I fail to understand it.

I have a machine that's skewed. If I move 4900mm on the X-Axis, the Y is off by 23mm.

So I tried M556 S4900 X23 P1 ( to make it compensate on the Y-axis? - the P parameter is really never explained)

But it does not go as expected - no real difference.

Some documentation says that the X parameter is in Tangent, others in mm (maybe)

Can you help me understand the parameters?

Thank you.

@phaedrux I mailed it to DC42

@dc42 Hello again.

We setup a test where we ran the same gcode with the nozzle rotation configured for the U axis and for the A Axis.

Thinking that the shaking would be clear, I mounted a gopro on the printhead - looking down - and put some gloves on the floor for reference. The most obvious result is that the whole print happens a lot faster when the nozzle is running as the A-axis, but looking at the printer in real life, you also notice some shaking and hard accelerations on the U-axis version.

I have uploaded an (unlisted) video here: https://youtu.be/abVquTFmLH8

I will mail the config files and gcode files (only the first layer) to you.

My conclusion is that the axies cannot be running the same code, something is not right.

Please have a look.

Michael

@dc42 We are updating the firmware today, but this is not a new thing, it has been the case since forever. (4 years) - so I doubt updating will make any difference.

We spend 3 days trying to figure out why we have these uneven movements, and changing the axis "name" to A fixed it.

We will examine further, but it does feel like the Axies are somehow running different code.