You've spent more time avoiding posting useful information than it would have taken to provide. If you had provided them, and no issue would have been found, you would very likely have had your warranty approval by now.
Plenty of warranty claims aren't warranty, they're wiring or other issues that can be found by helpful do-gooders like myself and others. Many hands make light work, That's kind of what the point of these forums and open-source in general.
Aiite, hear me out -
So: Triple Z is the new hotness - Like the excellent Jubilee&Railcore, or my hopefully-pretty-good stablebot, and a few other machine platforms like the voron or similar use plenty of drivers (6-7 drivers) One common thing is that they tend to use nice and big X and Y motors (Jubilee&Stablebot use LDO's 60mm 2A RMS Nema 17, for instance) These pair nicely with the hefty 5160 drivers on the 6HC, but when we drive other motors like the Z axis or extruders, 5160's capabilities are pretty underused and leave alot of cost underutilized. The opposite goes for the D3 mini - the TMC2209s' work great for Z, Extruders, and they're plenty fine for driving motors at moderate currents, but If i'm buying a big old motor, I'd like to be able to chuck the full power at it. Something else that comes to mind is maximum voltage - Everything is more/less 5,12, or 24v locked, and even tho the D3 6HC is rated for more, it leaves the fan/heater/whatever options with pretty clunky/custom options.
Here's my improvement/solution/request:
Make an expansion board for the D3 Mini with 2x TMC5161's.
They're drivable via UART, can chuck plenty of current for even the largest NEMA17's, and use the same codebase to chat as the 5160 (I think). The expansion could use a seperate ground and VMOT from the D3 mini, for a higher voltage PSU (or just activate jumpers to use VMOT from the mini).
It seems like a great "right size" option for these higher-end machines - completely user-selectable (don't want it? don't buy the expansion!) but is plenty capable for what users like me are looking for - 2 high-current drivers for XY, and even allows for "easy" scaling to high-voltage motor driving for even faster maximum speeds. Could be a pretty killer feature that drives sales as well 
Thanks for listening.
So in the inverse, if some EU resellers had gotten V1.1, it would be the EU having preferential treatment?
I don't see any preferential treatment here, other than preferring customers who order parts sooner than later. It happened to be vendors in the US this time, and because of the global chip shortage, its really pronounced.
I bet there are other releases where EU got parts first instead of the US. shrug
Yep - requires another computer to do the kinematics and generate the timings, then sends just raw step pulse information for the MCU to execute. Klipper doesn't use segmentation to calculate moves, instead opting for an iterative solver that uses the final position to calculate back how to get there.
I run toolboards (not the 1LC, but inspired by) over CAN with klipper - basically using CAN to tunnel serial signal through - and it works great and stays in sync with the rest of the motion system.
Apparently klipper only peaks at like 6kb/s usage max for data transfer, which is well within non-FD capabilities. Most of the issues are actually from limited adapters available that behave correctly with the current hack of tunneling serial thru CAN.
The one thing that klipper focuses on is keeping mutliple MCU's in sync from a master. I don't know the ins and outs of how that's accomplished, but considering that they do it over serial or the even more hacky serial-by-can implementation, I'd think that there's something to be learned there.
Related to main topic - I am genuinely appreciative of the bugfixes bringing back steprate performance. I'll be putting a small machine through its paces, and hope to run back-to-back prints between klipper and RRF on a d3 mini to help 1) Get an idea if there's really a difference in print performance and 2) help find ways to improve RRF's performance, especially with future input shaping adventures.
@ccs86 said in Wavy surface problem.:
Klipper
That's my plan for 2 weeks from now - I have a fast corexy that runs klipper on mini5+, and i'll be flopping between klipper and RRF to watch how it changes
@bobby23
The 5160 is the 2160 with a motion controller built in. In both the 3hc and the 6hc, the motion controller is unused, as there is a giant MCU doing the motion controlling, meaning that the identical 2160 is perfectly fine, and comes down to sourcing in the worldwide chip shortage.
I'm finally back up-and-runnning after moving my family across our state and getting started with a new job.
Progress was essentially paused until a little bit ago.
Sorry for the continued delay, life be busy 
Hey - I did a search and I couldn't find some postprocessing scripts that would automagically insert G10 Rnnn Snnn based on the filaments I had chosen, and after having to remember to change them after a while, I figured I'd have some fun and put together a postprocessing script to automatically convert M104 to G10.
This works for Prusaslicer, Superslic3r, all the forks. I personally use superslicer by supermerill
When you execute the completed gcode, it should turn on the Tool but not pick it up, and then put all tools into standby before beginning the print gcode. The standby temp is chosen by a simple subtraction. For toolchangers where you don't want to use all of the tools or commonly swap filaments, its nice to have something that makes the process a little less manual.
To use it in the slicer, all you need to do is remove M104/M109 commands from your start_gcode, and define your "safe word" that tells the script to put all the tools into standby before going into other actions.
Let me know what issues you find.
#!/usr/bin/python
"""
Slic3r post-processing script for RepRap firmware printers which prefer G10, particularily useful on toolchangers/IDEX
{1}
Usage:
Two inputs -
1)delta_temp - The amount of temperature you want to be subtracted from your active temp.
1a) FUTURE WORK - Make this dependent on filament type - more to come
2)end_phrase - this is what you want to use to end your start gcode so the script can "close up" and deselect the tools.
Slic3r automagically puts M104 before any of your starting gcode, so as long as you have your extruders set up, all of this will be performed before any homing or other motion.
Args:
Path: The path parameter will be provided by Slic3r.
Requirements:
{1}
The latest version of Python.
Note that I use this on windows and haven't tried it on any other platform.
{1}
Credit:
{1}
Based on code originally posted by CCS86 on https://forum.duet3d.com/topic/15302/cura-script-to-automatically-probe-only-printed-area?_=1587348242875. - this is mostly just to import the file automagically, Wasn't sure how to immediately run the file based on slic3r's input.
"""
import sys
import re
import math
import os
delta_temp = 20 # amount to subtract from the active temp
end_phrase ="Prantin" # String to search for to end your start gcode and insert the T-1 gcode
def main(fname, delta_temp, end_phrase):
print("BeepBopBoop Scanning...")
try:
_Slic3rFile = open(fname, encoding='utf-8')
except TypeError:
try:
_Slic3rFile = open(fname)
except:
print("Open file exception. Exiting.")
error()
except FileNotFoundError:
print('File not found. Exiting.')
error()
lines = _Slic3rFile.readlines()
_Slic3rFile.close()
linesNew = g10_swap(lines,delta_temp, end_phrase)
_Slic3rFile = open(fname, "r+")
_Slic3rFile.seek(0)
_Slic3rFile.truncate()
for element in linesNew:
_Slic3rFile.write(element)
_Slic3rFile.close()
print("press any key to close")
input()
return
def error():
# remove the next 2 lines to close console automatically
print("Press Enter to close")
input()
sys.exit()
def g10_swap(lines,delta_temp, end_phrase):
# Replace M104 with G10 Gcode
linesNew = []
tools_used = []
start_gcode_ended = False
count=0
for line in lines:
if line.startswith('M104'):
tool=line[(str.find(line,"T")+1)]
#tools_used.append(tool) #stores tools
activetemp=line[(str.find(line,"S")+1):(str.find(line,"S")+4)]
standbytemp=int(activetemp)-delta_temp
linesNew.append(f"G10 P{tool} S{activetemp} R{standbytemp}" + "\n") #actual conversion
if start_gcode_ended==False: #activates tool to get it warmed up - for initial warmups
linesNew.append(f"T{tool} P0" + "\n")
count=count+1 #counts quantity of tools, used in removing m109's
print(f"M104 converted over to G10 T{tool} S{activetemp} R{standbytemp}")
elif line.startswith("M109") and count>0 and start_gcode_ended==True:
count = count-1
continue
else:
if end_phrase in line: # Check for end of start gcode
linesNew.append("T-1 P0" + "\n") #deactivates all tools w/out macros
start_gcode_ended = True
linesNew.append(line)
return linesNew
#main("foo.gcode", delta_temp, end_phrase) #testtesttest
if __name__ == '__main__':
if sys.argv[1]:
fname = sys.argv[1]
main(fname, delta_temp, end_phrase)
else:
print('Error: Proper Slic3r post processing command is python3')
error()
Just merged. Configs to come "soon"
https://github.com/Klipper3d/klipper/pull/5366
Just answering the given question.
Toolspeed doesn't give the entire story. - Volumetric flow (and quality of it) is what the hotend is providing here - 300mm/s is irrevelant, the e3d volcano can do that with .15mm layers using a .5mm nozzle, for ~24mm3/s in flow.
I've heard/read mixed items about it. The owner hasn't had exactly a spotless record of behavior when interacting with the community.
The other reason is that it uses all-custom parts. No compatibility with my library of nozzles or other parts. If i want a new nozzle for the nova, I have to pay their price, and frankly, many of us have decent libraries of e3d/slice compatible nozzles that would be just useless.
Hi There!
I came back to my shop and found that one of my duet boards had its 5v buck that was piped into 5v ext on the duet go to 7.5v, which melted the pi as well.
Anyways, one PI and a proper 5v supply later, and the duet connects back to the pi without issue. I can see temperatures of all of the sensors, but when i try to activate anything, (fan, heater) nothing happens.
All 4 power lights are lit.
I ohmed out the VSSA fuse and its not conductive/connected
I've since jumped out the VSSA fuse but without luck to get any of my outputs to re-enable.
Have i killed my board with a bad 5v buck?
Luke
No problem. Feel free to reach out if you have further questions. I have opinions for days
Luke
@dc42 said in Building an adaptable XL COREXY machine with 2023+ features:
@vectorinnovations said in Building an adaptable XL COREXY machine with 2023+ features:
Because its so large, Iām going to run larger steppers, so external drivers (at least for the Z-Axis).
The Duet 3 6XD and expansion 3HD boards can provide up to 6.3A peak (4.5A RMS) and can use 48V supplies. So it's most unlikely that you will need to use external drivers if you are using stepper motors.
Absolutely agreed here - unless you're stepping up a tier to use FOC servos or something, the duets provide plenty of punch.
For that size I'd heavily recommend against corexy and recommend a "dual markforged" style gantry. It adds 1 motor (XYY) but will provide much more consistent behavior and give better performance in the end.
How many Z motors do you want?
If 3, Can do 6XD, (XYYZZZ) but might have to play it differently if doing quad z (or just add an extra 1XD for the extra motor)
for your toolboards, just run a canbus toolboard from duet. They're excellent. Don't run the SHT/whatever series as the cost savings doens't make sense when you are spending a few $100 on each print at the cheapest in filament.
For large printers, its especially important to have filament sensors. Get all of those per toolhead.
Duet is the best choice for this kind of system, for sure.
@oliof its 100% a debian or bossa bug. Duet has been nothing but awesome in their quest for true open source.
Have you got it working? I've definitely run across that annoying bug 
@Duckers Oh wow, been a long while!
I never got around to this experiment - its gotten to the point where I've switched from a duet mini5+ on klipper to a duet 6hc on klipper - the mini5+ used 2209's, and didn't really notice any changes between the mini and the 6hc, other than speed!
I don't use interpolation on either - experiments with encoders revealed small issues with positioning while using interpolation, but these are also very small!
@sindarius
Thats nice and handy!
I'm printing .2mm layers, but this is with a 400x400 machine on a full plate - I heavily rely on autofan to control cooling - increase with lower layer times, etc.
No cracking here - once I figure out the combination for that material (bed temp, nozzle temp, and % fan needed, (all abs brands I use require fan, especially in enclosed setups) I hit print and go.
A fair portion of the parts printed are larger than my fist, same as the ones that have a narrow aspect ratio - while unenclosed, these can be risky, but i haven't experienced issues with my full-volume prints on my 350x350x300 volume.
No speed benchies here - real production values.
As for the motors - They're 2504AC's - super low inductance while still keeping high torque.
I'll have step-servos by MRRF.
Its advisable to have some cooling - ABS prints in simple enclosed machines like troodon/voron need 50-70% flow from the single 5015 on my machines that use them.
Even my "open air" printer (in reality, the room is ~95deg f) printing ABS at 600mm/s / 15k mm/s/s with a nozzle temp of 280C needs a touch of air for the perimeters to prevent droop on the overhangs, but the infill and bridge features are perfect.
Just merged. Configs to come "soon"
https://github.com/Klipper3d/klipper/pull/5366
