@dc42 said in hierarchy of control over gcodes, machine vs filament vs slicer:

The printer speed and acceleration limits should always be set no higher than the printer can reliably achieve. Otherwise you may end up with the slicer commanding the printer to move faster than it can manage, especially if you use the speed factor control in DWC or PanelDue to increase speed. You can of course set lower speeds and accelerations in the slicer settings.

That's something I have wondered in the past. If the slicer says to move at 100mm/s, and RRF has the speed limit set to 150mm/s, I would expect the printer to move at 100mm/s. If the speed factor control is then set to 200% in DWC, what happens? How fast does RRF drive the printer? 150 or 200mm/s?

I mention speeds, but presumably this applies to accelerations just the same?

I did look in the DWC manual for the speed factor control but it wasn't clear to me what limits were still imposed, if any.

This also had me wondering the other day as I was adjusting pressure advance as well as input shaping. In particular if pressure advance could result in extruder feed rates outside the limits that I had specified in RRF, and if some sort of clipping might occur if hard limits were enforced resulting in some obscure printing artefact. Same with input shaping and how the actual moves sent to move the head might look after going through a 'shaper filter' and whether they too were being 'clipped'. ... I have a background in audio design where clipping is just about the worst thing imaginable for a poor audiophile. 🙂

Now that I'm running two linear delta machines, where the amount the effector moves is not nicely related to the rotation of a single stepper but some combination of all three depending where on the print bed you are, it really starts to do my head in. Plus that's without considering bed mesh correction, tapering, skew adjustment, or others I don't even know about. 🙂

A user submitted a pull request to PrusaSlicer some time ago to fetch the printer speed and acceleration limits from the RRF object model and to modify the print time calculation to better reflect RRF when RRF is the selected firmware type; but unfortunately it wasn't actioned. See https://github.com/prusa3d/PrusaSlicer/pull/8087.

Oh, that's a shame, I for one would have found it useful.

@apak
Thank you for the solution. ❤

PS - I've just discovered that LinuxCNC supports an extended version of G10 in which P0 is allowed and means use the current coordinate system. That's not currently supported by RRF, but I can add it in the next 3.4 beta release.

@fcwilt

This is very convenient, thank you for the tip.

I had a few succesful print since I made the Z-offset correctly.

@erfreuterstudent
that's a premier for me too, but we'll try.
With a toolchanger you could poll the diameter of the current tool in tpost#.g by using M118 S2 P"toolnumber"
Now the arduino reads this message and sends the aquired data, but here it get's shady for me. It is easy to receive messages and display them on DWC, but reading data into a global variable is unknown to me. I tried it over I2Cport, but fell into the same dark hole...
Maybe @dc42 has a solution now?

There's a series of guides on converting the Ender 3 over. In the end it's quite similar to the ender 5. It may help clarify some things.

https://duet3d.dozuki.com/Guide/Ender+3+Pro+and+Duet+Maestro+Guide+Part+1:+Wiring/37

Part 5, for calibration may be what you're after right now.

https://duet3d.dozuki.com/Guide/Ender+3+Pro+and+Duet+3+Mini+5++Guide+Part+1:+Wiring/87

The second link is for a more recent guide using RRF3, which is still in progress.

@dc42 thank you. This is very helpful. I will give it a try. It seems the assistant you have asks the user to adjust per a given thread pitch. I do like the craftbot method of just continuously probing and letting the use make micro adjustments to see how close they are getting to the desired positions.

Perhaps once we have SBC capability on the Duet2 we can make more elaborate wizards and guided assistants.

I'm noob in programming but i will check it, thank you all.

Hi,

The only thing that exists in the slicer related to starting/ending a print are calls to macros

print_begin.g print_end.g ; ----- print_begin.g ----- ; ; must occur after... ; - all axes have been homed M106 P2 S255 ; lights on M106 P6 S255 ; lights on M106 P7 S255 ; lights on G90 ; absolute moves G1 Z75 F1200 ; position for cleaning G1 X0 Y-145 F6000 ; position for cleaning T0 ; select tool 0 so extruder commands below will work M703 ; configure selected filament (sets temp set points) M291 R"Waiting on heaters to reach set points..." T0 M116 ; wait for temps to reach set points M291 R"Priming extruder..." T0 G92 E0 ; reset the extruder logical position M83 ; extruder relative mode G1 E10 F120 ; prime the extruder G92 E0 ; reset the extruder logical position M400 ; wait for extruding to finish M291 R"Clean Nozzle and Bed" P"Click OK when ready to print" S3 M98 P"configprobe.g" ; configure Z probe M98 P"probeZ.g" ; set Z=0 datum G29 S1 ; load height map M291 R"Starting to print..." T1

@dc42 Thank you for clarifying this. Its a silly simple thing but i couldn't find the answer anywhere.

sorry i just realized how the setup is one.

are the switches NO or NC?

i would try to wire them in parallel and use M558 P5

they will need to be connected to the z probe port.

but a construct would allow the printhead to move. this would not be beneficial for the print quality.

@dc42 Is this still on the to-do list or has it been implemented?

https://www.dropbox.com/s/xlzhcwm6c8qfyar/benchy_not working.gcode?dl=0
https://www.dropbox.com/s/2kg1cpzdxq78m8h/benchy_working.gcode?dl=0

That's correct, create a new axis (e.g. U or C, it doesn't matter which as long as you are consistent) for the extruder angle control using the M584 command. If you need to home it, connect the homing switch to the E0 endstop input.

You don't need to alter the Z steps/mm, you can use M579.

@botanic2000 said in G92 not working for E axis:

Has run into same issue with E-axis today. Was trying to set up print resuming after power loss and found out that RRF is ignoring G92 command in the "resurrect.g" file.
Basically, what happens is when I resume printing after power down the print head goes over the print and then it starts extruding all the way from 0 to the value that has been stored in "resurrect.g".

What am I doing wrong here?

Firmware Version: 2.01(RTOS) (2018-07-26b2)

1_1537273182573_resurrect-prologue.g 0_1537273182573_resurrect.g

Please post the ResTest.gcode file too, or put it on a file sharing site so that I can download it.