@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?
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?
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.
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 really don't know how to qualify or quantify the problem.
Since installing the beta, fast moves literally screech to a halt and don't complete. It sounds like mechanical metal binding.
When tramming the bed, one of the 3 motors grinds for a moment. Hard to tell if it's more than 1, actually. Needless to say, the bed is less level after.
I've reverted back to 3.5.x, the printer was no longer usable on the beta.
@dc42 yes, it is the case. I've used cancellation in the past without issue so I think this is a regression.
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?
@dc42 definitely. My printer never loses steps when used normally.
@gloomyandy It happens after I print a tall print. I have a lot of crash avoidance logic in my gcode that uses the G60 coords to make sure the bed is at a safe height during less determinant situations.
I find that if I print something large or move the bed far out of the way, next time I go to print, my bed will go back alllll the waaaayyy down before coming back up to start printing. I know it's because of the saved positions, but I can't think of anything other than moving to some small offset then manually (or scripted) re-issue G60 just so I store a closer position.
@dc42 Don't know, I'm not doing it because it nearly caused my printer to self destruct.
@dc42 2 switches, filament out sense, and eject button the specs are here, https://www.orbiterprojects.com/orbiter-filament-sensor/