Posts made by infiniteloop

@developeralgo222

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.

@developeralgo222

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.

@Tinchus

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.

@T3P3Tony So sad. Miss him, too. RIP Deckingman

@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.

@starworts

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:

• Do you really use the HTTP and Telnet protocols?
• You define the MFM twice: once for ”e0_stop”, then for ”e1_stop”.

@djthuma

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?

@djthuma

… 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.

@fragrama17

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.

@fragrama17

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?

@jay_s_uk

you can get two outputs together as one in M950

Won’t the firmware trigger the gates sequentially, I.e. one after the other? Then, the MOSFET who comes first takes the full load - for just a moment, depending on how close the loop is. So I imagine that, if you couple the gates software-only, one of the MOSFETs has to handle the switch-on current alone. At 24V, 200W, that’s beyond its specs. Or is my assumption off the rails?

@SINTORMAN

Can't I configure them with the same settings and temp probe and they will trigger at the same time?

No, I don't think there is any GCode available to couple two outputs as tightly as required in software.

@SINTORMAN

to power a enclosure heater 24V at 200W, I would like to parallel the smaller heater outputs.

For this to work, you’d have to couple the Gate pins of the MOSFETs, too. Instead, you better use a DC/DC SSR (Solid State Relais) which can be controlled by one of the heater outputs. Please note that the heater outputs control the GND signal, not V+.

May I ask how large your heated enclosure will be? With a size to fit a typical 3D printer, 200W won’t help too much.

@Notepad said in uniform wave artifact on all prints:

doing a test print like this is a really good test to check if the issue is firmware or if its hardware.

Just curious: what hardware issue exactly can you determine (or exclude) by this?

@Inlinebrother

I think that I use all of your advice, but I lack experience, so I can't be as good as you before I get some experience

Holy cow! If you knew how many of my prints I still ruin today, you would speak differently.

Here is the tuning discussion, I used this number for E jerk on purpose
guys are saying that E jerk should be high enough so that it doesn't "cap the X and Y jerk values for a print move"

I am no tuning expert. Despite of my long bowden, I don't even use PA. I'm just printing slowly. But, with respect to your stepper settings, it might be helpful if @Phaedrux could have a quick look. He has a "feeling" (or call it "intuition") for suitable values that I completely lack.

My strategy is "try and fail, but do not stop".

That’s the way! With a caveat: to learn from a fail, you must be able to localise its cause. If you operate too many handles at once, this may be difficult (remember the ”octopussy syndrome“? ).

The thing that I lack about the DWC is git.
It would be great to have a VCS for configs.

This was my very first thought when I updated my printer with a Duet and converted to RRF. In fact, I grabbed some config.g for my type of printer from the Web. To start with, it didn’t even match my RRF version. In the end, I had to spell every single line of it (by the help of the GCode dictionary - that’s how I learnt GCode the hard way. Most of the template’s entries were either idiotic or faulty. It took me three months until I had a functional machine again. TBH, I’m still working on that project - after years. The fun never stops, my journey continues.

In my eyes, it is better to use the RepRapFirmware Configuration Tool as a starting point - see: Configuring RepRapFirmware for your machine. It has some flaws (see your Z values), but IMO it’s arguably better than some template ”from hearsay” which could easily turn out to be ”from hell”.

that is also how the generator creates a config today

I’m perfectly fine with separate entries for axes and extruders, I just noted that it is different from my settings.

@Inlinebrother

The config I posted is for the left print

So start your journey from here.

The fact is that low jerk and acceleration settings helped achieve a good result

I agree. A second thing to have in mind is print speeds. Most of the basic settings can be better explored at moderate speeds. At high speed, you introduce a whole zoo of mechanical effects from your printer’s hardware to the equation. Everybody want’s to print fast, but I feel more comfortable with the idea to take this challenge in a second step.

@Inlinebrother
Mains power switch:

At first, before I grounded the board, I witnessed the board shutdown and turn off wifi. The lights near 5v switch were blinking with no pattern. But the 24v power LEDs didn't show any signs of trouble.

Got it.

RRF vs Cura:

I think that the [Cura’s] Printer Settings plugin makes things a bit more difficult.

You nail it. But it depends on your personal preferences. For my part, I feel uncomfortable with the idea of having crucial firmware settings embodied in every print object - when I improve my configuration over time, I’d have to re-slice every single design, I.e. all over the place, instead of doing it once and for all. And, of course, I am nailed to one slicer, can’t switch to another one or even run .gcode files from other sources.

There’s already a lot of settings in the .gcode files: print speeds, temperatures, layer heights… BUT: except of the layer heights, I can adjust all of this in DWC on the fly. With this approach, I could already save numerous prints, while my older designs automatically inherit all benefits from tuning measures I made over time - in RRF, that is.

@Inlinebrother OK. Just to be clear about today’s topic: It’s your config.g, motor section.

Firstly, an admission: For me, GCodes are hard to decipher, I can neither read nor spell GCodes by heart, I have to look them up here. Sure, I’ve prominently bookmarked the GCode dictionary, but even to understand my own config.g, I have to go through it line by line. Chaps like @Phaedrux (that’s the one who wrote the tuning macros) and @droftarts (the one who contributed most of the valuable hints to your thread) eat GCodes for breakfast (Sorry guys, didn’t want to trigger you - but if you are willing to scan @inlinebrother’s config,g, you’re welcome: I won’t catch everything).

M566 X60 Y60 Z12 ; set maximum instantaneous speed changes (mm/min)

These values are an order of magnitude off. To understand what you do, PLEASE look up M566 in the dictionary. The example depicts conservative values, start with these for X, Y and Z. Note that E is missing from your line: That’s because your setup follows a different pattern, it provides a second M566 in the ”Extruders” section.

Let’s take a break and look at the details: Comparing the values for X/Y/Z to E, the difference is stunning. All units are mm/min, so why should Z be limited to 12 mm per minute(!), whereas E can take 12000 mm in the same time? Sincerely: 1000 times more than the 12 on Z? This pattern stinks, it is illogical. Well, that’s a good reason for yet another break: Where do these figures come from?

My claim: Oral tradition (or a digital variant of that). Someone had these numbers in his config, some values were lost in translation, someone ignored the decimal point, another one omitted a trailing zero, and finally, you have to observe the units to deal with: RRF uses millimetres per minute, other firmwares (and slicers like Cura) prefer to use millimetres per second - what a difference!

Sorry for the rant. My point is just this:

1. Always have a close look at the units involved
2. Never copy the templates from others blindly, better think twice
3. Analyse every line of GCode, use the dictionary (and your brain)

OK, three points. But you get the idea. Anybody on this forum cries for templates of a config for his specific printer. If you followed me up to here, you now understand why that’s a questionable idea - too much can go wrong (and has almost certainly gone wrong with your config).

———

Next: M203. This line carries no comment, it defines the max. speed per axis, again, in mm/min. Add a comment to make its meaning explicit. Again, the extruder has it’s own M203. Comparing your settings to those for my poor old bedslinger, there is some room for optimization. But, first things first: cross-check your RRF settings with what you command in Cura: M203 imposes absolute limits, regardless of what you tell your slicer. And always remember: RRF is mm/min, Cura is mm/sec.

———

Finally, M201 (Accellerations). Again, you have separate entries for axes and extruders. IMO, the values are leaning to the conservative side, so there’s a potential for optimization. Keep this in mind, add the topic to your list of items to be tuned.

@Inlinebrother

The left print is a good start, but how can you explain the failure on the right? Which parameters or settings were wrong? And please, don’t simply guess what might have gone wrong.

What I intend to say: You must be in control of the printing conditions all the time. Furthermore, remote observers need to know what exactly you intended to test, and, which parameters you changed in order to cause such a poor quality output as on the right. At least, you should remember the settings for the left print: it’s a good start, revert to them.

@Inlinebrother
Leakage circuit breaker installed?:

I guess so

Let's leave it at that as long as the PSU issues seem to have vanished.

Mains power switch:

It is the Flashforge Creator Pro and it has a button behind it to turn off the power that goes to the PSU

But didn't you tell me that the PSU never turns off? Or did I misunderstand something? In this context, you also mentioned some LEDs never going off …

Config, print quality, tuning:

I found macros for tuning the speeds, jerk and acceleration here

These are really great. But, before you start tuning the printer, you should take two separate steps:

1. Go through your config.g, some motor settings are off the rails. I'll get back to this in a separate post.
2. Learn where to draw the line between RRF and Cura: Some print (and printer) parameters can both be defined in Cura and RRF, some settings will be overridden by values from the other side of the fence. I tend to lean more towards the RRF side, because the various slicers are difficult to manage due to a plethoria of settings, but in the end, you must simply know what GCodes your slicer generates in his start section - and, which of these might interfere with your definitions in config.g and the Macro start.g (on the RRF side of the fence).

Generally, stick to the same rules as for hardware debugging: One step at a time. So, don't change multiple parameters in either Cura or RRF (and never in both of them in the same test cycle). If you don't know what you do, learn it. To understand the effect of a certain setting to the print result you get, you must be able to identify the culprit. If you are faced with multiple suspects, chances are high that the real culprit stays unidentified.

Enough said. In the meantime, I have to take care of my dog and some other stuff, but then, we'll deal with your config.g. CU