@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? 
@jimakron said in G93 not working:
Why was G93 supported, but now it isn't?
Does any mode support it?
From the GCode dictionary, G93: Feed Rate Mode (Inverse Time Mode):
CNC specific. Supported from firmware version 3.5
@theolodian You can use a macro like this:
var nDriver = 3 ; <<< tell number of axes
; iterate through the axes:
while {var.nDriver > 0}
set var.nDriver = var.nDriver - 1
if {! move.axes[var.nDriver].homed} ; if an axis is not homed ...
M99 ; ... we abort this macro
; if all axes are homed, we arrive here:
M300 S1000 P2000 ; beep (do whatever you want)
Insert the axes count in line 1 and replace the beep in line 10 with any command you want.
@adamfilip As an addition to the wise words of @deckingman: if you follow his advice, you can use the thermistor built into the heater to limit its maximum temperature with M143. Adapt the first example given there to your own requirements:
M143 H1 P0 S275 A2 ; switch off heater 1 temporarily if it exceeds 275°C
@brian In DWC, extrude/retract are by default disabled if the hotend is cold and the tool is not active (i.e. not selected). If your case is different, please provide some more details.
The axes are disabled, because the Duet does not "know" where the print head actually is as long as the axes have not been homed - this is a measure of precaution so you can’t inadvertently ram the head into the bed or override limits.
It is however no problem to override that limitation: With M564 S0 H0, you unlimit the axes. Simply put this gCode into a macro, then you can easily access it if needed.
@highfreq said in Axis temperature compensation:
if i can change it continuosly or just once at beginning of the print
If you compute axis compensation in start.g, this is for the whole print - which makes sense. If you want, however, monitor the chamber's temperature all the time (and adjust the compensation accordingly), put your code in daemon.g where it will be called every 10 seconds. Personally, I think the latter approach is questionable, as you counter one "global" variable (the axis elongation) which affects the whole print with a measure which affects single layers - that's difficult to balance properly. Better you keep the conditions stable during a print.
@jay_s_uk That sounds great, and at a viscat softening temp. of 97°C, it’s much better than PETG. Thanks for the hint, I’ll have to try that with my printer, too.
@kmoore If your firmware is at least RRF 3.3, you can put your code into the system macro daemon.g which is called every ten seconds.
As a prerequisite, you might want to initialise a global variable in your start.g macro with the state of job.file.filament[0] which tells the filament consumption of extruder drive 0 in mm. For an overview how to access the printer's object model, read this.
Within daemon.g (insufficient details can be found here), you monitor the state of job.file.filament[0], until the value is 1000 larger than stored in your global var. That’s the time to trigger the compressor.
After that, update your global var with the current state of job.file.filament[0] to prepare the next iteration.
With G4 S3, you then wait 3 seconds until it’s time to switch the compressor off.
Please note that this is just an outline of the steps to take - many details remain to be solved. One problem may be the timing: is it sufficient to look at filament progress every 10 seconds? What other edge conditions must be considered? Pellets under- or overflow, perhaps?
I will be able to supply you with some gCodes, but before that, you should get an idea of the process, because: if something goes wrong, it's your printer who suffers. By the way: what the hell of a beast is that? Sounds interesting …
some people turn the board fan on based on the hotend temp taking it as a proxy for "machine will get load".
Interesting approach. I could not find hints to this in the config of the OP, but at least for the tool fan, this would be good news
@nightowl999
What’s the difference…
There’s none. The only thing to observe is that some .g files are either mandatory (config, homing, …) or required for a desired functionality (event notifications, tool changing etc.).
@adistr said in Stepper motor jog:
Let make it more simple please.
If I want to run the X-axis motor non-stop.
Simply put: don't use a stepper. LOL