Best posts made by gnydick

If you need to make cables for the CAN-FD connections and don't want to solder or crimp ZH connections, I found that JST has an alternative for the cable end. They're the ZR connector.

https://www.jst-mfg.com/product/pdf/eng/eZR.pdf

These allow you to insert all of the wires at once without having to strip the insulation. Just insert and crimp, and all of the connections are made via IDC connection.

I've not known what this connector type was called, but after googling, I found it.

Digi-Key has them in the US, I'm sure they're readily available elsewhere..

Over 100mm/sec for the entire print, even the 3mm circle. I have video of it to. Crazy to watch.

I know it's a simple print, but I've been battling crappy mechanicals, only to finally make it awesome. Was getting oval holes and bumpy round corners. Now, it's a workhorse!

@bearer I know. I've been a bit crispy. My apologies to everyone. I'll post it when I get a chance.

It's common for me to home, tram, tram, maybe tram again, then home-Z. I wanted a simple way to do it, so I started designing an electromechanical control panel. For now I just have added a handheld microswitch connected to io1 on the 6HC to accomplish all 3 of those tasks.

P.S. my switch is NC, but I have it inverted so my check value is zero instead of one.

• tap - Home All
• tap, tap-hold x 1sec - Tram
• tap, tap-hold x 2sec - Home-Z

var button_pressed = sensors.gpIn[22].value


M581 P-1 T22


G4 P500
var button_still_pressed = sensors.gpIn[22].value


if { var.button_still_pressed == 0 }
    G4 S1
    set var.button_still_pressed = sensors.gpIn[22].value
    if { var.button_still_pressed == 0 }
        G28 Z
        G4 S1
        M581 T22 P22
    else        
        G32    
        G4 S1
        M581 T22 P22
else
    G28
    G4 S1
    M581 T22 P22

I've been posting for quite a long time, at least years, about the same question, coming at it from different angles, trying to figure out if my problem was caused by different things each time.

What was my problem? Some call it ringing, some call it ghosting, but it didn't follow either behavior.

I was getting ripple artifacts, but they were slightly different. Sometimes it looked like the extruder was pulsing too hard, sometimes it looked like pressure advance was wrong, or I had loose belts, or too much vibration in my system. The list can go on and on.

Among other things over the years, I recently converted my Railcore to a tool changer with direct drive tools and expanded the frame to accommodate the extra hardware. This is when the print quality got really out of hand.

I basically built a new printer.

Well, the actual problem was that my XY motors were too weak. I threw on some beefier ones and my prints come out super tidy again. Can't tell the difference with prints from my Voron v0.1.

Hope that helps someone else.

It was actually really easy. Going to post a series of videos on the design and how to do it.

@gnydick NM, brain fart

@Kolbi click "Select All" check mark on list of files. Right-click, choose download.

It's not one step for all, but at least it's one step for each area.

Honestly, I feel the new version is worse in almost every way.

• There are even less buttons that can be clicked by using the space bar
• The buttons are much slower to respond, for example, clicking baby-step repeatedly is torture, you have to wait for the flash animation to finish before you can click it again
• It's clunkier, even though it looks prettier; more clicks to do the same thing
• The pop-up messages take you to the g-code console when you dismiss them

I'm being brutally honest here, this is the perfect example of form over function. I tried explaining what was needed in the RFC and warned about this kind of stuff.

The web interface should be fast, instant in response as possible given the web host, predictable, and impossible to click the wrong thing at the wrong time. It should have every single button clickable via the space bar as well as every clickable item tab-indexed.

I predicted this would be a passion project about learning a new front end library, and I was right.

Honestly, I suggest going back to square one.

Start by creating a control interfaces like this was a manufacturing machine. Oh, wait, it is!

Forget fancy menus. What do we do a lot of?

Well, when tuning and tweaking

• I want to have a g-code console and the config editor side-by-side
• give me a small mechanical control there as well
• a drop down with macros is enough, they don't need to be listed out
  • if you want to repeatedly run macros, then make a screen for that

What we don't need

• Graphs are pretty, but really, there's no reason for them to take up so much space
• The status pane is also way too big. It would work just as well as a single line along the bottom or top

I could go on and on, but I'm honestly so mad that I warned this would happen. Since updating to the latest firmware, I can't even revert to Web Control 1. Can I just re-upload it or will I have to clean up files on the SD Card?

In reality, my suggestion a long time ago was to make each of these panes a widget you can drag 'n drop and resize to make your own screens. THAT would please everyone.

As a hobbyist, I never minded slightly buggy things. It was exciting helping out projects to become better. But, I am no longer a hobbyist and use my printers professionally.

I don't want to install any more RC's just to have fixes, because almost invariably, something else is broken.

Can you please have a stable branch that is blessed and receives hot-fixes along the way? While the RC's are on a separate track for being actual Release Candidates and not things you have to install to get fixes?

This would be very beneficial to Duet customers as I'm sure they don't all want to dog-food, especially when the food is slightly spoiled 90% of the time.

As a commercial product, it just makes sense to have this release process. Frankly, it's this reason that I'm hesitant to recommend Duet products.

@samlogan87 to be fair, I've brought up the improper release practices, but to no avail. That is specifically, he won't back port fixes. It's always "oh, yeah, that's fixed in the current beta/RC." And often it's not like they're trivial breakages. Show stoppers need to be back ported to the stable branch.

I've run into this multiple times. I've resolved myself to having to just grin and bear it and stick with broken "stable" releases because I'd rather align myself with the devil I know rather than the devil I don't.

Same thing goes for baby stepping. It's woefully implemented. It's overly complicated and only works under assumed conditions. If you're running a work in progress printer with manual tweaking and tuning needed while operating, baby steps will F you up quite well. Search for my posts on the matter.

@phaedrux

What you described is paradoxical. I can't stay on the stable branch AND get hot fixes.

A couple months ago when 2.01 came out, that's the stable release.

Now, if I want fixes, I want them applied to 2.01, i.e. 2.01.1 for the first hot fix release.

I don't want to install 2.02-RCs because they're buggy. By definition, they are not hot fixes, they are beta releases.

I've found a few key things that needed fixing on my printer that has made a huge difference, so now pressure advance and input shaping have to start over.

1. my CoreXY belts were not equal length. While I could square the gantry, the belts were never the same tension. Now they are.
2. My motors were set to X16 Y16 I1 microstepping. Made lots of harsh vibrations at many different speeds. I was tired of the noise so I started playing with the microstepping and ended up with X64 Y64 I0 and it's sooo much better. I did also try different driver settings like stealthChop, but that didn't make a difference. Maybe it will now that the vibrations are gone.
3. Last but not least, my X rails weren't equally spaced. They were parallel, but I overtightened some screws and it made the rail wavy on a small scale. I loosened all of the screws between the ends and re-torqued them all to just-barely-firm and that seems to have fixed it. Now my gantry just sounds like recirculating ball bearings.

I made a new print and it's quite literally perfect. Old print on the left, new print on the right.

For example, if I get inputs[], is inputs[0] guaranteed to be HTTP forever? Other objects, like fans[] will always be based on whatever I, the users, deemed fan 0, 1, etc. Wouldn't things that must maintain over time make more sense as dictionaries, like inputs['http'] make more sense?

@chrishamm

the baby-step button wasn't slow because it was waiting, it was slow because it was animating, right?

I have to disagree with your assessment of the rest, which is why it's going to take forever for DWC to be useable.

I have built entire content management systems in a week long before all of these fancy libraries were around.

It sounds like you're relying on frameworks to be silver bullets. The notion that it is a PWA is misguided. Yes, we all want it on both desktop and mobile browsers, but going along with PWA methodology is a recipe for bloat and over complication.

I downloaded DWC1 source, added one JS library, and was able to turn it into a drag-n-drop re-arrange-able site in less than an hour.

I honestly think you're working too hard on it and not realizing that at it's essence, it's a ridiculously simple web site. It doesn't need anything fancy to be awesome.

This doesn't need to be a PWA, it needs to be control plane that can be layed out on desktop and mobile.

I guarantee you, based on your experience with the system, if you were to start from scratch, you could have something awesome in less than a week's time if you adopt the notion that you're building control panels for a machine, not a Progressive Web App. The site is only going to do so many things, and that so many, is very few. There are only a small handful of technical hurdles when it comes to working with the duet web-host, once those are knocked out, which you can do instantly, because you've done it before, it would take no time at all.

So, I've got the Promega, now I've pretty much rebuilt it. Linear rails for Z optical z end stop, plus much more. It's fantastically precise now in the Z axis.

There are oddities though. There are inconsistencies in the behavior.

If I disable all compensation, I can go from home to Z0 and it's perfect. If I enable mesh compensation, same story, works just right. Seems like the compensation isn't in use when manually sending g-code.

Now, I've manually mesh probed many times, but it never seems to work right.

When printing, the mesh surface seems to be calculated correctly in terms of shape and following the contour of the bed. The problem is, it's always too high. After the print starts, I have to baby step it down anywhere from .6 to 1+mm. Once I do that, like I said, it prints nicely.

Now, I cancel the print. I should mention, I modified the stop and cancel macros so nothing is disabled and the motors aren't turned off, etc., so I don't have to re-home. I print again, and the nozzle is too high again by the same amount. So I baby step it more. Now the baby steps are twice as much. Repeat, repeat, repeat and the baby step offset is now triple, quadruple, pentuple.

So, while trying to debug all of these bizarre behaviors, it's not obvious when different features are enabled. It seems like the baby steps are forgotten, why is my probing always too high, etc.?

I feel like there's a state machine with a sense of humour in there.

What are the rules for when compensation effects the Z, ... again for when baby steps are taken into account? How are they used? Other printers have "live Z tuning" which is a permanent offset dialed in, but it really seems like that's not the case with baby steps.

It's all so very conflating and obfuscating when trying to debug.

What are the rules/state machine exactly?

@dc42, bump

@brunofporto I have one too, 600W. The fan isn't able to be controlled by law to reduce risk. I personally wouldn't assume I know better to think that an overheating PSU can be recovered by turning on a fan. Just my unsolicited $0.02.

thanks for the pointers, @oliof

You can handle power failures gracefully. There's a resurrect function you can configure by filling in the resurrect-prologue.g file.

@johnocfii the reason why it's happening, I'm theorizing, is because the wipe happens at travel speed, so there's a negative extrusion while moving fast, so it thinks it's an extrusion move that needs to be smoothed.