@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? 
i can't seem to get a good voltage divider to purchase that can handle 6 outlets.
I’m not aware of a commercial product either. Just mount 12 resistors on a perfboard - that’s it.
i need high accuracy and robust reliability , that's why i used a Voltage Level Shifter
The level shifter you want to use is inappropriate for the task: as @gloomyandy says, the TXS0108E translates logical (i.e. ”binary”) signals from one voltage level to another one. Please study the data sheet to understand what this device is intended to do. On page 17, they say explicitly what they do to your analog signal:
When transmitting data from A-ports to B-ports, during a rising edge the one-shot circuit (OS3) turns on the PMOS transistor (P2) for a short-duration which reduces the low-to-high transition time. Similarly, during a falling edge, when transmitting data from A to B, the one-shot circuit (OS4) turns on the N-channel MOSFET transistor (N2) for a short-duration which speeds up the high-to-low transition.
So, they don’t shift an analog voltage to another level, instead, they try to detect flanks and sharpen these for better digital signal quality. For your use case, that’s the opposite of ”high accuracy”.
A simple voltage divider is what you need. Using high-quality resistors, these are very accurate and highly reliable. I really have no clue why you disqualify them as ”simple but not robust”. The contrary is true. Towards @gloomyandy, you mention three alternative solutions: ”Zener Diode Clamp” and ”Opto-isolator”. Both are counter-productive: With a Z-diode, you can clip (or limit) a voltage, an opto-isolator is highly non-linear. Your preferred solution, a ”Bi-directional Logic Level Shifter”, falls in the same category.
If you don’t like voltage dividers at all, there is an alternative: Op-Amps. But designing a circuit with several discrete components is a major task and not worth the effort: any added accuracy is easily ruined by the subsequent A/D conversion on the Duet controller or by temperature shifts along all components in the signal path.
Just make sure (…) your filament is in the proper state (dry) and you are done.
What if the ”filament” isn’t dry but more or less ”foamy”? From the OP:
We have a bit specific printing material (kind of a foam), which flow rate we cannot really control well.
@fragrama17 Just my two cents: to reduce reaction times on flow rate measurements, you could perhaps try to shorten the movement queue length (see M595) or disable it completely with M555 ( M555 P6 - set nanoDLP compatibility mode). However, this can cause the printing movements to be a bit bumpy - sorry, never tried that myself, so this idea might not even be worth a penny.
@droftarts said in FilamentMonitor Short and fast errors:
I don't think that's an error
Well yes, but on my part. Thanks for putting it right.
HTTP tends to be required!
Does the OP run a SBC configuration? Was not aware of that.
Pounding my head against the wall
don’t. 
I find that the filament senor is triggering during a lot of successive short and fast movements.
Usually occurring during infill or small parts with a decent amount of retractions.
The MFM is set to check extruding moves every 3.0 mm. Shorter moves, combined with retractions, may not be properly registered. In your M591 command, you can either try to set the E parameter to a higher value (in order to not report minor ”hiccups”), or you can lower the Raa parameter (in order to ignore false ”under-extrusion” events). @droftarts recommends a third alternative: try that first.
Please tell us which firmware version you are running and which Duet board you use.
To your config.g:
I was referring to this page on the documentation.
So we are on the same page 
Can you share the version of your Duet board?
Do we talk about a genuine BLTouch or a lookalike (CR-Touch, BTT Microprobe, …)?
Which version is the BLTouch?
… when it says "First, you need to allocate an unused heater expansion channel…"
Suppose you got this from a forum post? Better follow the Duet3D Documentation. For your BL-Touch (and similar Z-probes), read this: Connecting a Z probe - BLTouch. If questions remain, you're welcome to return to this thread.
seems like you guys don't really like Microsoft ecosystem
I’m not ”you guys”: as a simple 3D printing individual, I just speak for myself. TBH, in a strict sense, I’m not even a Linux guy, I prefer Macs. But on this forum, that doesn’t matter: I’m here as a longtime DUET user, convinced of Duet3D’s Open Source policy as well as of their approach to hard- and software integration. When the Duet team introduced their SBC solution, using Linux on this was the obvious choice.
I didn’t want to hurt your feelings - not even your pro-Micro$oft ones 
. Instead, I propagate a more 'agnostic' view: Instead of engaging in long-lost battles in the OS wars, go with the least common denominator. That’s what Duet3D has rightly done.
The dotnet platform provides really good abstractions for multiple purposes
Same does Linux, which nowadays has become the gold standard for server applications, even at Cupertino and Redmond.
deciding to not take advantage of these is like deciding to kind of re-inventing the wheel.
Micro$oft has ”re-invented” numerous wheels, mostly to keep its dominant position, not for the good intent. Strictly taken, logging mechanisms have been covered to an exhaust by Unix ages ago, so why should I use .Net just because they bolted a fifth wheel to the M$ waggon?