@o_lampe said in Fun Fact .. you can use GPT Chat For:
The next logical thing to do: Remove the config-tool and add a link to GPT instead
Why stop there? What about a Duet controller with AI and natural language IO? Reportedly, @DC42 already has a working prototype of the Duet AI5 on his desk - the last hurdle being a mysterious error message: „I’m sorry Dave. I’m afraid I can’t do that“
@paolozampini1973 said in DUEX 5 V0.8 TO DUEX 5 V0.11:
I am an electronic and IT TECHNICIAN for 29 years
If you are as experienced as you constantly tell us, you should not only be able to study the Duet docs and schematics - they are all publicly available. You also should be able to understand them. Instead, you cry out for "authorities" and write endless rants against everyone who tries to help you. With all the anger you spread, you better go chopping wood, just to cool down a bit 
@paolozampini1973
Maybe your 29 years of experience have outlasted too long? I’ve started with electronic circuits about 50 years ago, and at that time, they all ran at 5 volt, or even combined with negative voltages - think of RS-232. In the meantime, 3.3v are common, and as you should know as an expert, many CPU’s are internally operated at levels just above levels of 1.1 volts.
The Duet originates from the (then revolutionary) Arduino Due (an Italian project, I think) - that was the first Arduino with 3.3 V (and a 32-bit ARM core). With this knowledge in mind, you should’t complain, you better should wonder why there are any 5V logic levels left.
So no: we have to deal with both logical levels, the ancient 5V and the 3.3V of modern times. Feel lucky not to have experienced the -12 V of RS-232 (not to forget the additional +12V the hard drives required at that time). For God’s sake, it’s irrelevant what you would „never ever put on the market“ or not: until now, my venerable Duet 2 is the best companion of my printer I can think of.
Not to mention the fantastic community: this forum is a collection of profound knowledge and experience - paired with (very british and quite incredible) politeness and patience of the contributors. I always found a solution for all of the problems I faced, without ever having to ask a single question: I just had to search and to read a lot.
That’s what I recommend to you, too: read before you write, think before you shout. By the way: Do you have a problem with authorities? Why else do you insist on a face-to-face with „the engineer“? Sounds to me like a bad Italo-western movie plot 
If you are looking for a solution, ask. This community does the best to help you with whatever technical problem you face. However, if you are looking for a shootdown: forget it! Or, to put it in @oliof’s words: „that does not make for a good Saturday afternoon experience“.
@o_lampe said in "Define Area for Mesh Grid Compensation" not saving!:
I can't reference specific gcodes anymore? In the old gcode wiki was a link I could copy/paste....
This works for me: Move the mouse to the upper right corner of the Gcode entry - a "¶" character should appear. With the right mouse button, call the context menu and "open link in a new tab". From there, you get the link URL.
@daoust said in Error gcode file too long:
I got this message: error, gcode file too long.
It’s not the file is too long, the error message states: GCode command too long. Reading the complete message tells us that in line 995655 of the file "CFFFP_700w heater2.gcode", the G1 command fails at character position 256. Now, please look up that line in the file and show what it contains. In addition, tell us the Cura version you are using.
@paolozampini1973 Stop your Suada. I’ve better things to do than to read the garbage of a man who thinks he’s perfect. Have a nice day and go your ways.
@mrdui said in Input Shaping makes no difference whatsoever:
It seems to me, according to the noise my Z axis makes during the print, that it compensates during the whole print, which, in my mind doesn't really makes sense because it would report the bed planeity errors over the whole print, so every face of it is being very slightly deformed.
I think you are looking for M376.
@mrdui said in Input Shaping makes no difference whatsoever:
Didn't want to edit config.g mid print
A wise decision: in order to apply changes from the config, you have to run config.g - a bad idea while printing. For modifications "on the fly", you simply send gCodes from the console.
Where did you find that in the documentation?
In GCode Meta Commands under Binary infix operators - there, the caret is the last entry in the table.
I have a dumb question
Not so dumb at all…
Does the printer have to re-home?
That depends…
What kind of power failure do we expect? On a sharp power cut, the idea is that all movements stop immediately, then, with the remaining power in the capacitors (of PSU and Duet boards), the positions of all axes are written to the SD card. However, there are other types of power failures such as „brownouts“ or intermittent outages due to a lightning hitting the line - at least in theory, the mechanical position may then be out of sync with the latest stored coordinates. Luckily, we can ignore this case as we can’t do anything to prevent it.
Assuming a clear power cut: will the printer mechanics stop on the spot, or will inertia and/or gravity cause further movement of an axis? If, for instance, a heavy bed tends to give way down due to its own weight, the final Z-position differs from the Z coordinate stored in resurrect.g. Obviously, any axis which is suspected to not hold its exact position after a power loss will need to be re-homed.
Which precision per axis is required to continue a print? In the event of a power loss, stepper motors tend to skip microsteps, I.e. they like to snap into some full-step position. Same thing may happen when they are re-powered. In the worst case, these effects may add-up to a misalignment of two full steps - depending on your printer’s steps/mm, layer height and line thickness, this can be either tolerable or ruin your print. In case of the latter, the relevant axes have to be re-homed.
To conclude: In most cases, re-homing of X and Y is possible without interfering with a print on the bed, so simply do it.
how do you home Z when there's a partial print on the bed?
Good question. I can think of three different solutions:
Using a probe (such like a BLTouch), you can possibly probe your bed along one or more edges or in some corner - given that the printable area is smaller than the bed’s physical dimensions and the head or gantry are guarantied to not collide with the print object. However, if your printer has multiple Z drives (which is good for tramming or even bed levelling), probing just one corner can result in a bed not being well levelled.
Using (additional) high-end switches on all Z-drives, you can re-home Z with these. This may be a bit less precise than using a probe, but could be good enough to resume the current print job.
Trust in god and simply continue to print. Small inconsistencies can be corrected on the fly by adjusting the microsteps via DWC. If, however, your printer tends to not hold its Z-height when left without power, this method is unsafe.
To conclude: as a general solution, #2 is the way to go, but often, #3 does surprisingly well (depending on the mechanics of your printer).
Finally, you can prevent the thread of a power loss by providing some kind of UPS: admittedly, a full-fledged UPS powerful enough to keep a bed heater alive is costly, but in most real-world scenarios, a low-voltage (e.g. 24V) battery bank feeding just the steppers, nozzle heaters and controllers, will save your day. See @deckingman's post above, he has the expertise.
@gnydick Better ask Why. Spoiler: maybe you over-estimate your charming appearance? 
Or could it be due to electrical noise from nearby signal or motor cables?
IMHO, that’s the most plausible scenario. To test, take another cable of similar length and route it as far away from any steppers and wiring harnesses as possible.
When I perform a homing operation, the axis moves but stops before reaching the X endstop.
Would be good to know whether the move stops due to the endstop being triggered…
Context (please confirm):
You are running a 6HC + 1XD in a SBC setup?
Your config.g is still this here?
; Configuration file for Duet 3 (firmware version 3.5.1)
; executed by the firmware on start-up
;
; SBC Config
M291 P"Applying persistent configuration options" R"Please wait" S1 T60 ; show that persistent settings are being configured
while exists(sbc) && plugins.DuetPiManagementPlugin.pid < 0 && iterations < 30
G4 S2 ; wait for DuetPiManagementPlugin to become available
G4 S2 ; wait another moment
M929 S2 ; start logging events to the SD Card
M550 P"MD" ; set persistent hostname for printer
;M551 P"mdrapid" ; set password
M586 P0 S1 C"*" ; configure HTTP & enable CORS
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet
M292 ; hide message box again upon completion
; General Preferences
G21 ; Work in millimetres
G90 ; absolute coordinates
M83 ; relative extruder moves
; Drives
M569 P41.0 S1 R1 T2.5:2.5:5:5 ; physical drive 0.0 goes forwards with active high enable config pulses intervals (x)
M569 P42.0 S1 R1 T2.5:2.5:5:5 ; physical drive 0.0 goes forwards with active high enable config pulses intervals (y)
M569 P43.0 S1 R1 T2.5:2.5:5:5 ; physical drive 0.0 goes forwards with active high enable config pulses intervals (z)
M584 X41.0 Y42.0 Z43.0 ; set drive mapping
M92 X83.50 Y83.50 Z320.00 ; set steps per mm
M566 X600.00 Y600.00 Z60.00 ; set maximum instantaneous speed changes (mm/min)
M203 X3000.00 Y3000.00 Z1800.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 ; set accelerations (mm/s^2)
; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X2000 Y4000 Z320 S0 ; set axis maxima
; Endstops
M574 X1 S1 P"io2.in" ; configure switch-type (e.g. microswitch) endstop for low end on X via pin io2.in
M574 Y1 S1 P"io3.in" ; configure switch-type (e.g. microswitch) endstop for low end on Y via pin io3.in
; Z-Probe
M558 P5 C"io5.in" H10 F900 T3000 ; set Z probe type to switch and the dive height + speeds
G31 P500 X0 Y0 Z8 ; set Z probe trigger value, offset and trigger height
M557 X0:1250 Y0:2400 S200 ; define mesh grid
; PE320 Extruder
M569 P40.0 S1 R1 T0:0:0:0 ; external drive CAN address 40 goes forward, active high enable
M584 E40.0 ; set drive mapping - map extruder to CAN address 40
M350 E1 I0 ; configure extruder with NO microstepping
M92 E301.6485 ; set steps per mm - extruder E-steps/mm (resolution of 1:48) or 166.7 steps/rev
M566 E3000 ; set maximum instantaneous speed changes (mm/min)
M203 E3000 ; set maximum speeds (mm/min)
M201 E20000 ; set accelerations (mm/s^2)
; Temp sensor parameters
M308 S0 P"2.spi.cs0" Y"rtd-max31865" A"Top"
M308 S1 P"2.spi.cs1" Y"rtd-max31865" A"Middle"
M308 S2 P"2.spi.cs2" Y"rtd-max31865" A"Bottom"
M308 S3 P"2.spi.cs3" Y"rtd-max31865" A"Nozzle"
; Create heaters
M950 H0 C"out0" T0 ; create Top heater output on out0 and map it to sensor 0
M950 H1 C"out1" T1 ; create Middle heater output on out1 and map it to sensor 1
M950 H2 C"out2" T2 ; create Bottom heater output on out2 and map it to sensor 2
M950 H3 C"out3" T3 ; create Nozzle heater output on out3 and map it to sensor 3
; Set PID heater parameters
M307 H0 R1.319 K0.319:0.000 D25.28 E1.35 S1.00 B0
M307 H1 R0.650 K0.120:0.000 D35.30 E1.35 S1.00 B0
M307 H2 R0.636 K0.188:0.000 D41.46 E1.35 S1.00 B0
M307 H3 R0.500 K0.137:0.000 D21.29 E1.35 S1.00 B0
; Maximum extruder heater temperature
M143 H0 S400 ; set temperature limit for heater 0 to 400C
M143 H1 S400 ; set temperature limit for heater 0 to 400C
M143 H2 S400 ; set temperature limit for heater 0 to 400C
M143 H3 S400 ; set temperature limit for heater 0 to 400C
; Extruder heater fault detection
M570 H0 P60 T30 ; An anomaly on heaters 0 must persist for 60 seconds, and must be greater or less than 30C from the setpoint, to raise a heater fault.
M570 H1 P60 T30 ; An anomaly on heaters 1 must persist for 60 seconds, and must be greater or less than 30C from the setpoint, to raise a heater fault.
M570 H2 P60 T30 ; An anomaly on heaters 2 must persist for 60 seconds, and must be greater or less than 30C from the setpoint, to raise a heater fault.
M570 H3 P60 T30 ; An anomaly on heaters 3 must persist for 60 seconds, and must be greater or less than 30C from the setpoint, to raise a heater fault.
; Define Heaters as Tools
M563 P0 H0 S"Top"
M563 P1 H1 S"Middle"
M563 P2 H2 S"Bottom"
M563 P3 D0 H3 S"Nozzle"
; Heater Cooling Fans
M950 F0 C"2.out0+io1.in" Q100 A"Heat Break Fan" ; Heat Break Fan -- 4-wire PWM 12V fan so invert it, 100Hz PWM, NO tacho
M950 F1 C"!2.out3+out3.tach" Q100 A"Top Fan" ; Top Fan -- 4-wire PWM 12V fan so invert it, 100Hz PWM, tacho connected
M950 F2 C"!2.out4+out4.tach" Q100 A"Middle Fan" ; Middle Fan -- 4-wire 12V PWM fan so invert it, 100Hz PWM, tacho connected
M950 F3 C"!2.out5+out5.tach" Q100 A"Bottom Fan" ; Bottom Fan -- 4-wire 12V PWM fan so invert it, 100Hz PWM, tacho connected
M106 P0 S1 T40 H0:1:2:3 ; Turn on Heat Break Fans when heaters 0-3 are above 40 deg
M106 P1 S0.5 ; Run at 20% speed at 2200rpm (max 11000rpm)
M106 P2 S0.5 ; Run at 20% speed at 2200rpm (max 11000rpm)
M106 P3 S0.5 ; Run at 20% speed at 2200rpm (max 11000rpm)
; Bed Heaters
;M308 S4 P"1.temp0" Y"thermistor" A"Bed" T100000 B4725 C7.06e-8 ; configure bed thermistor at 1.temp0
;M308 S5 P"1.temp1" Y"thermistor" A"Bed" T100000 B4725 C7.06e-8 ; configure bed thermistor at 1.temp1
;M308 S6 P"1.temp2" Y"thermistor" A"Bed" T100000 B4725 C7.06e-8 ; configure bed thermistor at 1.temp2
;M308 S7 P"temp0" Y"thermistor" A"Bed" T100000 B4725 C7.06e-8 ; configure bed thermistor at temp0
;M950 H4 C"1.out0" T4 Q10 ; create bed heater output on 1.out0 and map it to temp sensor 4
;M950 H5 C"1.out1" T5 Q10 ; create bed heater output on 1.out1 and map it to temp sensor 5
;M950 H6 C"1.out2" T6 Q10 ; create bed heater output on 1.out2 and map it to temp sensor 6
;M950 H7 C"1.out3" T7 Q10 ; create bed heater output on 1.out3 and map it to temp sensor 7
;M307 H4 R0.421 K0.321:0.000 D5.73 E1.35 S1.00 B0 ; Bed PID tuning parameters
;M140 P0 H4 ; map heater 4 to heated bed 0
;M140 P1 H5 ; map heater 5 to heated bed 1
;M140 P2 H6 ; map heater 6 to heated bed 2
;M140 P3 H7 ; map heater 7 to heated bed 3
;M143 H4 S120 ; max temp -- 120 deg C
;M143 H5 S120 ; max temp -- 120 deg C
;M143 H6 S120 ; max temp -- 120 deg C
;M143 H7 S120 ; max temp -- 120 deg C
;M570 H4 P60 T15 ; An anomaly on heaters 4 must persist for 60 seconds, and must be greater or less than 15C from the setpoint, to raise a heater fault.
;M570 H5 P60 T15 ; An anomaly on heaters 4 must persist for 60 seconds, and must be greater or less than 15C from the setpoint, to raise a heater fault.
;M570 H6 P60 T15 ; An anomaly on heaters 4 must persist for 60 seconds, and must be greater or less than 15C from the setpoint, to raise a heater fault.
;M570 H7 P60 T15 ; An anomaly on heaters 4 must persist for 60 seconds, and must be greater or less than 15C from the setpoint, to raise a heater fault.
; Define Bed Heaters as Tools
;M563 P4 H4 S"Bed 0"
;M563 P5 H5 S"Bed 1"
;M563 P6 H6 S"Bed 2"
;M563 P7 H7 S"Bed 3"
; Define Inputs
M950 J0 C"io0.in" ; Relay 12 - Estop
M950 J1 C"io1.in" ; Relay 13 - Reset
;M950 J2 C"io2.in" ; Relay 14 - X-Endstop
;M950 J3 C"io3.in" ; Relay 15 - Y-Endstop
;M950 J4 C"io4.in" ; Relay 16 - Z-Endstop
;M950 J5 C"io5.in" ; Relay 17 - Z-Probe
M950 J6 C"io6.in" ; Relay 18 - FREE
M950 J7 C"io7.in" ; Relay 19 - FREE
M950 J8 C"io8.in" ; Relay 20 - FREE
M950 J9 C"1.io0.in" ; Relay 21 - FREE
M950 J10 C"1.io1.in" ; Relay 22 - FREE
M950 J11 C"2.io0.in" ; Smart Wiring Loom - Material sensor LEFT
M950 J12 C"2.io2.in" ; Smart Wiring Loom - Material sensor RIGHT
M950 J13 C"40.io0.in" ; 1XD board - Servo Drive Fault
; Configure Input Triggers
M581 P1 T2 S1 R0 ; Relay 13 - trigger 2 (Reset) activates on falling edge when Estop button is pressed
M581 P13 T3 S1 R0 ; Trigger 3 (Servo Drive Fault) activates on falling edge when servo fault detected
; Define Ouputs
M950 P0 C"out4" ; Relay 1 - Pellet Material Feed Solenoid
M950 P1 C"out5" ; Relay 2 - Part Cooling Solenoid
M950 P2 C"out6" ; Relay 3 - FREE
M950 P3 C"out7" ; Relay 4 - FREE
M950 P4 C"out8" ; Relay 5 - FREE
M950 P5 C"out9" ; Relay 6 - FREE
M950 P6 C"1.out1" ; Relay 7 - FREE
M950 P7 C"1.out2" ; Relay 8 - FREE
M950 P8 C"1.out3" ; Relay 9 - FREE
M950 P9 C"1.out4" ; Relay 10 - FREE
M950 P10 C"1.out5" ; Relay 11 - FREE
M950 P11 C"40.io0.out" ; 1XD board - Clear Servo Drive Faults
; Set Outputs
M42 P0 S0 ; Output OFF
M42 P1 S0 ; Output OFF
M42 P2 S0 ; Output OFF
M42 P3 S0 ; Output OFF
M42 P4 S0 ; Output OFF
M42 P5 S0 ; Output OFF
M42 P6 S0 ; Output OFF
M42 P7 S0 ; Output OFF
M42 P8 S0 ; Output OFF
M42 P9 S0 ; Output OFF
M42 P10 S0 ; Output OFF
M42 P11 S0 ; Output OFF
; Select Tool
T3 ; select nozzle heater with PE320 extruder
M568 P3 A0 ; set nozzle heater to off
; Custom settings
echo >"/sys/coef.g" "set global.coef = {global.coef}"
Extending on what @dc42 stated above, it’s fine to permanently store a variable like this, but it comes at a cost. You only need the file storage for some parameters to survive a reboot, reset or shutdown. During runtime, global variables do the job.
Now, if you have two macros, one to store a set of globals, and one to restore these from disk (SD card), you just have to spot some events who potentially lead to a reset/shutdown, such as pause or end of print, and call the ”store” macro on these events.
The ”restore” macro has to be called only once, either at the end of your config.g or when you start a print - whatever suits your needs.
Essentially, you just have to write the ”store” macro, as it creates (by using ”echo”) an executable file which then IS the ”restore” macro. If you need some sample code on how to compose complex expressions, just drop a note.
I completely missed having a G4 P1 executing at EVERY loop iteration.
Well, that’s just a millisecond. However note the usage of G4 at this line in your daemon.g:
G4 P{var.dt} ; loop delay, 500ms, P = [ms], S = [s]
This one is essential for granting time to parallel processes. For details, look up the ”daemon” sections from the links in my previous post.
If a macro has to wait for the completion of some code in the printing queue or from another macro, don’t use a delay, use M400 instead.
have read somewhere that without [the while loop] the daemon.g executes slower, like every several seconds or so.
As a self-assigned expert for infinite loops, I can confirm that 
. But it is always better to study the documentation. For daemon.g, see the respective sections in Macros and GCode meta commands.
With M226, the Notes state:
Use M25 when a pause is required from a different source of GCodes (such as the web interface console, PanelDue or a Macro).
Which, in your case, is true. Looking up M25, however, it says:
Note that if a pause is commanded while a macro is being executed, the pause will be deferred until the macro has completed.
… which puzzles me a bit, because your macro - the daemon - will never run up to completion. So, the only advice I can give on this one is to test both variants. Then use whichever of them works for you.
Talking of tests: In order to spot the code lines where the daemon spends most of its time, you might want to comment-out single statements (or blocks of statements) temporarily. Then look whether the response times improve significantly.
Some of your code can certainly be optimised, but the M98 calls are my primary suspect: Every time a macro is invoked, it has to be fetched from the SD card (Note:.on every iteration of the loop!). You can either unravel the macro code into daemon.g or try a fresh, high quality (e.g. very fast) SD card.
the motor keeps stalling after 15-20 minutes of printing when coming from a cold start and sooner on later prints.
Looks like a classical heat creep. Initially, this might have happened at high temperatures when printing ABS. Then, with PLA, remainders of the ABS can partially block the filament path so that the melt zone expands upwards…
Have fought with that before, cleaning the filament path had only a temporary effect. In the end, I had to swap both the nozzle and heat barrier. Finally, I improved the cooling (of the cold end of my hot end ), which was the root cause of my problem.
the wave function collapses and the cat is definitely dead.
Common wisdom: Never bet on a cat, they always know better…
@droftarts Good hint, THX. @OwenD's code is in fact a joy to read.
I normally read all of any new commands but I was already familiar (so I thought) with G91 that has no arguments so didn’t dig in to the details. My bad.
No excuses required. The sheer mass of documentation has become an invitation to some quite interesting hide-and-seek sessions.
I make a change through DWC and then walk over to the room with the printer to visually observe and use the LCD interface for further commands…
Well, that can sum-up to some miles to go. I prefer to test my code in isolation, i.e. with all potentially harmful GCodes commented out (as far and as long as possible), so that I can stay in front of DWC most of the time. Often, some echos can do the job.
@jltx Here's some brain food. Wanted to figure out the persistence of a calculated value when passing this as a parameter to a second macro. You have to create the files "test1" and "test2" (did this in the /sys directory).
test1:
; Test macro with optional parameter B
; calls the macro test2 which requires an S parameter
var temp_1 = 100
if exists(param.B)
set var.temp_1 = {param.B}
var temp_2 = {var.temp_1 - 10}
M98 P"test2 " ^ S{var.temp_2}
echo var.temp_2
test2:
; Macro test2, requires an S parameter (defaults to 0)
var my_s = 0
if exists(param.S)
set var.my_s = param.S
echo var.my_s
Call this from the command prompt with
M98 P"test1"
or
M98 P"test1" B<your number here>
Hope this helps.
this is eye opening
Better risk a second look, for instance at the G91 GCode. In the Notes section, it states:
The flag state is saved when a macro starts and is restored when a macro ends.
If every macro had to preserve the complete machine state when called, the Duet would run out of steam memory very fast.
The GCode meta commands are an essential reading and an indispensable reference for macro coders as well. In the GCode Dictionary, look up the details of any G-, M- and T-Codes you are interested in. For the third source, @dc42 already mentioned the object model which you can most easily access by means of the DWC plugin.
However, even an excessive documentation will not cover all and every detail, not to talk of unknown side effects. That's why macros (sometimes even single code lines) have to be tested. When I write a macro, I often carry one or more temporary macros with me, using them as a test bed for code snippets or to check the persistence of vars across a call chain. Last but not least, there's always this incredible forum to help you out 
Edit: I've contributed some sample code to your second thread. To put down these few code lines, I had to run several tests. To get rid of the error messages and warnings, I consulted the "GCode meta commands" multiple times. BTW, over time, that has become kind of a misnomer for this document, I call it the "RRF Macro Programmer's Reference".