Open TypQxQ opened 2 years ago
It is automatically added only if G10 commands are not specified in your custom start g-code.
You can add for example:
G10 S{first_layer_temperature[initial_tool]} P[initial_tool] ; set temperature
Thank you! G10 is the old way and M568 is the new way: https://duet3d.dozuki.com/Wiki/G10
We recently switched from M104 to G10 for RepRap firmware, should we now switch to M568?
We recently switched from M104 to G10 for RepRap firmware, should we now switch to M568?
No no no no!
RepRap version 2.05 does not support the new m568. Many users still use RRF 2 because Rrf3 is basically still beta -- "stable" release aside. I prefer 2.05.1 (last release of rrf2)
The documentation for rrf says that new versions of rrf will support g10 for quite a while.
It would be awkward to allow the user to choose which gcode they want to use... so I don't know how to handle this.
I don't know why rrf made that change. I'm not a user of the new 3.0 firmware because I prefer the "long term stability" of 2.05.1
This is a long way of saying please don't change anything right now. There is time to make this decision.
@bubnikv as a stop gap, until G10
is fully deprecated, IMO, PS should emit only G10
but detect both G10
and M568
as valid.
And while M104
is deprecated in RRF 3.x, it is still supported and functions properly.
And while
M104
is deprecated in RRF 3.x, it is still supported and functions properly.
Yes this is true. I think it is the case, but we should confirm, that M104 is properly detected by PS when in RRF flavor.
All versions of RRF understand M104. All versions of RRF understand G10 (I believe the change was made a long time ago in a galaxy far far away). Only versions RRF 3.3-beta2 and up understand M568.
While most bleeding-edge users have moved to RRF3+, I think many OEMs prefer to deploy RRF2 for the time being.
Also, the M568 command used to have a different meaning in older versions of RRF, so it is problematic to emit without knowing the version number. G10 is safe to emit to all versions.
Yes this is true. I think it is the case, but we should confirm, that M104 is properly detected by PS when in RRF flavor.
It does - here's a snippet from GCODE I just sliced with rc2
...
...
...
M107
;TYPE:Custom
; Railcore 300ZL start code - 20 May 2021
M140 S75 ; Raise bed temp to profile requested bed temp
M190 S75 ; Wait for bed temp to rise
G28 ; home all axes
G32 ; Autocalibrate bed
G32 ; Autocalibrate bed a second time
G28 Z ; Home Z after bed leveling
;
;
G1 Z20 F600 ; Move bed down 20
M104 S255 T0 ; Raise hot-end temp to profile requested hot-end layer 1 temp
M109 S255 T0 ; Wait for hot-end temp to rise to profile requested hot-end layer 1 temp
Can you please check this in 2.6.0-alpha2 and provide some feedback? Thanks.
Version
PrusaSlicer 2.4.0-rc2+win64
Operating system type + version
Windows 10
3D printer brand / version + firmware version (if known)
Custom Toolchanger, RRF 3.4 beta 7
Behavior
When slicing for RepRap firmware a print where 2 tools are used, all 3 tools are heated up between the custom Start G-code and the custom Tool change G-code:
Project File (.3MF) where problem occurs
Christmas_Tree_Window.zip