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.

@droftarts, yes, exactly. I couldn't even get the strands in a ferrule that would fit.

Originally, I tried just reducing the conductor count but that caused the wires to get hot to the touch and the toolboard's mcu was over 100deg C.

So I ended up making a step-down connector that reduces the diameter. basically additional high temp heater cord spliced in and fit in the ferrule.

It's working better now. The MCU is only 64 deg and nothing is hot to the touch.

@gloomyandy it's the 80w heater that can be ordered from Luke's Lab for the Chube hot end. I'm running the air cooled so it uses the 6x20 cartridge, not the super volcano length.

What I'm asking is, is that normal? If it's that large for 80w, how could a 120w ever fit, etc.

looking at the docs for the toolboard 1LC, it says the heater can sustain up to 5A. Figuring 24V and 5A would yield 120w. I want to hook up an 80w heater I have but the wire guage is much too large. What am I missing here?

@dc42 ripples were 2mm apart and set it to 30Hz

@dc42 thanks. Now that you say it's in "G", I knew that, I'm a little embarrassed I forgot that at the time of writing. My last reply.

I measured the wavelength and used that alone as the frequency for input shaping and it seemed to have a little bit of an improvement.

The most improvement is from reducing maximum jerk.

Based on the design, RailCore, X movements have much more inertia to overcome than Y, given I have the e3d tool changer on it.

The input shaping graphs reliably show the difference.

My confusion is how can the amplitude be on the order 10^-4 to 10^-3 and still have such visible artifacts on the print?

@dc42

I'll do the measuring soon for you.

In the mean time, what are the expectations for how IS works? What is the unit of the amplitude?

@gnydick @dc42 bump.

I've tried many different acceleration settings. Tightening belts, super, duper squared and exactly equal belt lengths, etc.

the numbers in the Input Shaping plugin are in the range 10^-4 to 10^-3. How are these values even useful? Wouldn't these amplitudes be imperceptible?

@o_lampe thanks

Yeah, the whole idea came from wanting a big STOP button, then thought about having a physical panel with all of the different typical jog maneuvers, homing, tramming, and I started to worry I may not have enough pins for every function I wanted a button for. So I figured this was a really common use case of mine it would be a good one to start with to reduce the number of pins used.

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

@dc42

axis_limits.g config-override.g config.g config-user.g tools.g