Posts made by milangupta1

@t3p3tony You got it ! Option b would be my choice and I would definately not make it an error if "end.g" isn't found. That will keep backward compatibility as well as make it optional for anyone to use the end.g macro .. just a feature !

@t3p3tony Of course, I have already hacked it to make it work by adding "M0" to the simplify3D config.

The designer in me, however, is looking for something cleaner and elegant. I am assuming that a clean separation/layering of hardware/firmware/software is still a design principle ? I think it will allow folks who build machines using the duet3D board more flexibility to sell machines vs. machines + tightly coupled slicing software.

Am not picky or debating language symmetry i.e. stop vs end.
start -> stop/end (Although, I instinctively think of stop as "emergency stop").
pause -> cancel/resume

These are all built in with the exception of end. What I cannot figure is why "stop" has the requirement of having M0 in the gcode file when the firmware already knows the file has completed processing.

My recommendation is to just decouple "stop" from M0 or make it config option as a required dependency for trigger. Remember, this recommendation came from inconsistent behavior of slicer programs on what gcode they generate. Simpler would be to just leave "stop" behavior to what it is and introduce "end.g" and trigger it if it exists (in addition).

@milangupta1 Also, where is G92 in homedelta.g ? Shouldn't that be set as the new x and y home positions before you move back to absolute positioning ..

I was trouble shooting a similar issue although on a cartesian printer. Turned out to be the trigger height set incorrectly (-ve instead of +ve).

G31 in config.g. Should this be a positive value ? Also, M666 in bed.cfg ?

@milangupta1
The graph when it is stable .. typically rock solid at 205 degC !

I am having a similar issue .. 2 hrs into the print, I am seeing it trigger a heater fault - temperature out of range. My PID values are (auto-tuned) -

M307 H1
Heater 1 model: gain 739.3, time constant 324.7, dead time 7.1, max PWM 1.00, calibration voltage 24.8, mode PID, inverted no, frequency default
Computed PID parameters for setpoint change: P11.0, I0.230, D54.9
Computed PID parameters for load change: P11.

I am running :
Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.04RC1 (2019-07-14b1)
Duet WiFi Server Version: 1.23

The temp graph :

The print was not going through a heavy period or anything ... just chugging along. This has happened twice now approx 2 hrs into printing ... resetting the heater fault restores temperature stability.

Any ideas on where I should start ? This looks like some kind of oscillation that the PID algorithm isn't able to recover from ..

Please include support for triggering end.g (if it exists) at the end of a job.
Rational :

1. start.g is supported currently
2. allows for cleaner separation of firmware and slicer generated gcode

I am trying to use my slicer (Simplify3d) to generate g-code files and then print them on my duet3d enabled printer (rebuilt Makerbot 2x). I have configured duet3d to be more or less independently operatable (startup/initialization/calibration/homing etc.) from the paneldue or webcontrol. There are still a few kinks although where behavior is dependent on gcode file.

Eg. in the simplest of tasks to play a tune at the end of a job, it requires a M0 command at the end of gcode in order to trigger stop.g currently. In simplify3d, the generated g-code does not include this at the end unless explicitly configured as an "ending script" in simplify3d. I see this as something that should be configured in the machine / firmware vs. the slicing software.

Thanks for considering ..