RepRapFirmware 3.2 planned improvements

dc42

@gtj0 said in RepRapFirmware 3.02 planned improvements:

So the value at which speed decreases will be configurable via M558?

The idea is to allow fast-then-slow probing with G30, without having to use M558 to change the probing speed. I haven't decided on the exact mechanism yet.

garyd9

Several months ago, it was discussed (and demonstrated) that RRF on a duet2 was no longer able to handle higher speed movements. Even 150mm/sec movements on a delta machine could cause hiccups on a duet2 board. Around that time, you did do some optimizations, but said you'd re-visit it after 3.01 went out the door (and/or redo timing tests?)

bot

@garyd9 On that list is to improve step pulse generation, and re-introduce multi-stepping. This should help achieve faster speeds on prints which are not limited by the gcode queue, but by step pulse generation.

arhi

This post is deleted!

zapta

Any plans to support slicer's (e.g. Prusaslicer) time markers for more accurate time-left display?

Or is it already implemented on RRF? I am still on 2.x.

dc42

@zapta said in RepRapFirmware 3.02 planned improvements:

Any plans to support slicer's (e.g. Prusaslicer) time markers for more accurate time-left display?

Do you mean the M73 command?

CCS86

Any chance of revisiting this topic?

https://forum.duet3d.com/topic/4802/6th-order-jerk-controlled-motion-planning

dc42

It's on the list for implementation, but IMO it's pointless as long as jerk or junction deviation is needed at corners. The first-order motion components need to be made continuous before or at the same time as worrying about third and high order components.

Nuramori

This post is deleted!

bot

@dc42 Is there anything that a slicer could output to make improved motion planning easier for the firmware?

I've been playing around with IceSL, which requires a LUA script to process the sliced model and generate gcode output. And therefore, we have an opportunity to use the raw, non-truncated, slice geometry data before it is turned to gcode and calculate anything we wish and format it alongside the gcode in any way we wish.

Unfortunately, the underlying slicer does not generate curves. But, we can calculate angles, segment lengths, extrusion rates, etc. in the slicer and offload that from the FW.

I'm currently making a RRF-specific printer profile for IceSL, which is basically just implementing all the features duet users expect, and producing gcode compatible with RRF.

Long story short, we have the possibility now to do high-precision pre-processing of the gcode at the same time that we slice it.

Bipotronic

Implementation of Variables of GCode Meta Comments would be useful. Or is this function already implemented?

zapta

@dc42 said in RepRapFirmware 3.02 planned improvements:

Do you mean the M73 command?

Yes, M73. This is what I got from in a 22minutes (estimated) gcode file:

M73 P0 R22
M73 P0 R22
M73 P4 R21
M73 P9 R20
M73 P13 R19
M73 P18 R18
M73 P22 R17
M73 P27 R16
M73 P31 R15
M73 P36 R14
M73 P40 R13
M73 P45 R12
M73 P49 R11
M73 P54 R10
M73 P58 R9
M73 P63 R8
M73 P67 R7
M73 P72 R6
M73 P76 R5
M73 P81 R4
M73 P85 R3
M73 P90 R2
M73 P94 R1
M73 P99 R0
M73 P100 R0

In the early phases of the print probably the remaining time R is more useful for the estimation and in later phase probably the percentage P and actual time so far will give a better estimation.

The markers seem to be in (estimated) 1 minute intervals.

dc42

I've added M73 to the list for consideration.

zapta

@dc42 said in RepRapFirmware 3.02 planned improvements:

I've added M73 to the list for consideration.

Thanks.

CCS86

@dc42 said in RepRapFirmware 3.02 planned improvements:

It's on the list for implementation, but IMO it's pointless as long as jerk or junction deviation is needed at corners. The first-order motion components need to be made continuous before or at the same time as worrying about third and high order components.

What is causing that dependance?

zapta

@dc42, FYI, I run a small experiment correlating the M73 markers with actual prints (replaced them with G10 and M140 that propagated the values to standby fields in the json). Results look very good, both for linearity and absolute time values.

My slicer has default setting, without any calibration for the max speed, acceleration and jerk of my printer.

You can probably run tests much faster using simulator mode.

copystring

Please add inverted M80/M81 for meanwell PSUs.
I know. I'm inpatient. Is it a lot of work to implement this?

SpoonUnit

Could the option be added to set the min limit for behaviours similar to that controlled my M190. A default of 41 seems fine, but ultimately arbitrary, and having the option to hand control of this value to the operator would be nice. M143 sets max limits, perhaps it could be overloaded to support specifying min limits also?

droftarts

@dc42 really looking forward to playing with G5 Bezier curves!

Ian

dc42

@copystring said in RepRapFirmware 3.02 planned improvements:

Please add inverted M80/M81 for meanwell PSUs.
I know. I'm inpatient. Is it a lot of work to implement this?

This is included in the planned work to make the PS_ON pin configurable.