@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? 
rather than counting executions and adding delay times, in my daemon.g I am just having global 'next trigger time' variables - which I am checking against the upTime in every daemon.g execution
Good hint, that’s neat.
I don't have any g4's or loops in the daemon.g
Then, it is called every 10 seconds - which, depending on your needs, may be fine. From the GCode meta commands, section ”daemon.g”:
It is recommended to use a while loop inside the daemon.g file if you are using it to prevent the firmware having to open it every 10 seconds.
So, re-opening of the daemon.g file every 10 secs comes at a cost.
If you are using echo's to determine when things are running I have also found that sometimes echo's seem to get ignored
…not to mention the execution time of the echo command itself which has an impact on all measurements.
Is there a mechanism for the Duet3 to monitor things on a separate process than the gcode execution?
Daemon.g IS a separate process. However, all processes share a single resource, the MCU, which can become a bottleneck.
This does not mean that you have to count every single millisecond, just try to keep your code in daemon.g tight.
Now, your case is quite special, you intend to substitute the feeder logic built into RRF with your own control mechanism. Using a scripting language, execution times are calculated in seconds, that’s several orders of magnitude slower than the C++ code of RRF. IMHO you have three options:
Set up a minimal (but functional) prototype variant using daemon.g, run realistic test prints with it to see if the print runs smoothly. If it stutters or becomes jerky, take one of the other options.
Modify the firmware. That’s quite a significant effort, but you certainly get kind of realtime behaviour, even for complex tasks.
Use a separate controller (Arduino, ESP or such) as a loosely coupled sub-system. Here, interfacing the hardware (fans, feeder, pressure sensor etc.) is the tricky part, the software is - relatively - trivial to write.
the dt = 2000ms is not great
Keep it at 500ms as proposed in the documentation.
i was expecting someone from sales that knows the product inside and out to reach out to me.
In order to configure a complex machinery out of unspecified mechanics and controllers (consisting of both hard- and software), you can’t simply ask a salesman to fill your shopping cart with some of his products. To be able to make a serious offer, the guys at DUET3D need to understand your product idea to a considerable technical depth.
Your request reminds me of students who are tasked with a purely hypothetical project by their tutor - as there is no real ”beef”, they have no idea of neither mechanics nor electronics. No specs, no knowledge, no „thing“ to talk about. So what you ask for is some unspecified electronics which can interact with - technically spoken - a ”nothing” or ”void”.
If you have a business idea, you either know a lot of details - that’s what the DUET3D sales department needs to know to give good advice on their products. Or you need someone who can develop the idea up to the point where it can materialise in the head of your counterpart on the Duet side of the counter.
@XYZMechanical If you were serious, you would have to dig through specifications in order to get an understanding of how components (part number here) play their roles in a complex technical system (part number here). Your ”projects” (oh well, not just one) are pure fantasy, you don’t even invest own thoughts (part numbers unknown), for an obvious reason: it’s more convenient to use our brains instead. Before you ever ”assemble this said kit” and ”trouble shoot” the ”motion system”, look for your own ”sub assemblies” and see if you can make them to work like any human around here. And no, I’m too polite to tell you where to put your part numbers.
@samlevy0515 That's rare. Does this insight come from chatGPT?
@Timothee-Leblond
No way, but…
PAUSE is not added to the command queue, it acts - as you rightly say - on the beginning of the next move.
To shorten lengthy moves, you can enable segmentation. For details, see the S parameter in M669: Set kinematics type and kinematics parameters.
there are exciting opportunities for further development and collaboration in leveraging AI
That’s from the marketing department. Throw in some blockchains, that’s even better 
I would be very interested to learn more about your work and perspectives on these integrations. [Optional: Briefly mention your own relevant background or interest, e.g., "As a researcher in AI applications," or "As a professional in additive manufacturing,"]
First you feed us some buzzwords, now you’re looking for employees to bring them to life. Ah ok, you call it ”knowledge exchange”. Nice try.
Edit: Next time, you better remove the stage directions given by your bs-generator (did I say "AI"?):
I have been following developments in areas such as [Mention something specific you found in your research about their work or the general field, e.g., AI-powered design tools, smart manufacturing processes].
The endstop wires are routed separately from the extruder motor cables, so they don't share the same path.
Just for clarity - how exactly have you wired the X endstop? From my understanding, there are two lines:
Am I right with this assumption? Or do you supply 5V instead of GND? If so, where do you pick it up? Are any pull-up or pull-down resistors involved?
I managed to try a fresh 0.4 nozzle and replaced the original extruder cooling fan with an slightly bigger one, still not working.
So you didn’t touch the heat break? From you photos, I cant’t get a clue. Could you describe the setup? I mean, is it all-metal, has it a PTFE tube all down to the nozzle …
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.