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've made a Script in python using a new method I added to Danal's (RIP) DuetWebAPI to automatically upload files to duet 3's (with SBC? not sure, all I have is w/ SBC)
Should be slicer-agnostic, just add it to your post processing scripts with the following command (or run it in a terminal, doesn't matter)
python3 {pathtoyourscript}/Upload.py "[output_filepath]" {DuetIP}
Its in my slicertools repo where I have two other tools like mesh-resizing (I combined S3D and SS from this link into a single script, and added a probeSpacing variable that can be called from the command line) and G10 conversion for conventional slicers (particularily convenient for toolchangers!
https://github.com/lukeslaboratory/SlicerTools
I know the code is probably pretty scuffed, and I'm more than happy to learn!
Hopefully this helps someone else!
Got mine today, SUPER excited. Amazing Stuff!
Luke
No, I agree!
The accelerometer on the frame was to see what is extra about the head shaking on systems that are damped and allowed to freely wobble - IE, in the context of the toolhead to the rest of the room, it will be shaking alot more if its on a damped ball or a soft foam than if it was rigidly affixed to the floor, but by using the damping, it will be vibrating alot less in the context of toolhead to the bed - The extra accelerometer on the frame was merely to subtract out the total machine shaking and to isolate only the undesirable vibrations that affect actual print quality
If you do come up with a result, I'd be curious to see what the MTTF is for a similar board, the Odrid C2, which can upgrade to using EMMC modules instead of sd cards.
I think what you've hit here is discovering the natural frequency of your machine, or at least some loose components that are vibrating on your machine at the frequency.
There are a few options you can use to address it -
Hi there!
Per the release notes, the default behavior for LED's is to expect that they are Neopixel, not Dotstar.
https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md
Please provide images of the setup, wire paths, link towhere you got your extra MOSFET board, and the config.g file you used.
Thank you!
Alright - I've made an improvement to the script, I have an extra-large machine and depending on how much of the bed I'm using at any given point, I can exceed the points-per-axis limitations of duet firmware (currently 21:21). It now will run the calculations, and if there are more than 21 points required, it converts over to using the P parameter instead of the S parameter, trying to honor the original requested spacing.
#!/usr/bin/python
"""
Slic3r post-processing script for RepRap firmware printers which dynamically defines the mesh grid dimensions (M557) based on the print dimensions.
{1}
Usage:
{1}
Slic3r Settings:
In Print Settings > Output Options
1. turn no "Verbose G-code"
2. in "Post-processing scripts" type the full path to python and the full path to this script
e.g. <Python Path>\python.exe <Script Path>\meshcalc.py;
{1}
In Printer Settings > Custom G-code > Start G-code
Make sure the start g-code contains the M557 command, and that you probe the bed and load the compensation map, e.g.
M557 X10:290 Y10:290 S20 ; Setup default grid
G29 ; Mesh bed probe
G29 S1 ; Load compensation map
Script Settings
probeSpacing = 20 - change this to the preferred probe point spacing in M557
Note: The minimum X and Y of the probed area is limited to 2 times the probeSpacing.
This is so that prints with a small footprint will have a minimum 3x3 probe mesh
{1}
Args:
{1}
Path: The path parameter will be provided by Slic3r.
{1}
Requirements:
{1}
The latest version of Python.
Note that I use this on windows and haven't tried it on any other platform.
Also this script assumes that the bed origin (0,0) is NOT the centre of the bed. Go ahead and modify this script as required.
{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.
and maybe 90% or more is code posted by MWOLTER on the same thread.
Thank you both.
"""
import sys
import re
import math
import os
probeSpacing = 20 # set your required probe point spacing for M557
def main(fname):
print("Starting Mesh Calculations")
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 = calcBed(lines)
_Slic3rFile = open(fname, "r+")
_Slic3rFile.seek(0)
_Slic3rFile.truncate()
for element in linesNew:
_Slic3rFile.write(element)
_Slic3rFile.close()
return
def error():
# remove the next 2 lines to close console automatically
print("Press Enter to close")
input()
sys.exit()
def calcBed(lines):
bounds = findBounds(lines)
bed = findBed()
for axis in bounds:
if bounds[axis]['max'] - bounds[axis]['min'] < bed[axis]:
print(f'Success: {axis} mesh is smaller than bed')
else:
print('Error: Mesh is larger than bed. Exiting.')
error()
for limit in bounds[axis]:
if limit == 'min':
if (bed[axis]) - bounds[axis][limit] > 0:
print(f'Success: {axis} {limit} coordinate is on the bed.')
else:
print(f'Error: {axis} {limit} coordinate is off the bed. Exiting.')
error()
if limit == 'max':
if (bed[axis]) - bounds[axis][limit] > 0:
print(f'Success: {axis} {limit} coordinate is on the bed.')
else:
print(f'Error: {axis} {limit} coordinate is off the bed. Exiting.')
error()
return fillGrid(bounds, lines)
def findBed():
bed = {
'X': 0,
'Y': 0,
}
bedCorners = os.environ.get("SLIC3R_BED_SHAPE")
maxXY = bedCorners.split(',')[2].split('x')
bed['X'] = int(maxXY[0])
bed['Y'] = int(maxXY[1])
print(bed)
return bed
def findBounds(lines):
bounds = {
'X': {'min': 9999, 'max': 0},
'Y': {'min': 9999, 'max': 0},
}
parsing = False
for line in lines:
if "move to next layer (0)" in line:
parsing = True
continue
elif "move to next layer (1)" in line:
break
if parsing:
# Get coordinates on this line
for match in re.findall(r'([YX])([\d.]+)\s', line):
# Get axis letter
axis = match[0]
# Skip axes we don't care about
if axis not in bounds:
continue
# Parse parameter value
value = float(match[1])
# Update bounds
bounds[axis]['min'] = math.floor(min(bounds[axis]['min'], value))
bounds[axis]['max'] = math.ceil(max(bounds[axis]['max'], value))
# make sure the bounds are at least 2 x Probe Point Spacing, for small prints.
# also, make sure that the maximum amount of points isn't exceeded.
if parsing:
global probeSpacing
for axis in bounds:
spacing = (bounds[axis]['max'] - bounds[axis]['min'])/2
if spacing < probeSpacing:
probeSpacing = spacing
print("Bounds are: " + str(bounds))
return bounds
def fillGrid(bounds, lines):
#Check the quantity of points - cannot exceed 21points per axis, otherwise will throw error and ruin print by not running a mesh
X_points=(bounds['X']['max']-bounds['X']['min'])/probeSpacing
Y_points=(bounds['Y']['max']-bounds['Y']['min'])/probeSpacing
if X_points>21 or Y_points>21:
Points=True
#basically, if its over 21, just use 21, if not, round up, keeping roughly the same spacing for the non-affected axis
if X_points>21: X_points = 21
else: X_points = math.ceil(X_points)
if Y_points>21: Y_points=21
else:Y_points = math.ceil(Y_points)
print('With your required print footprint, you\'ll exceed 21 points on either axis, changing to point based. Your new point grid is {}:{} points'.format(X_points,Y_points))
else:
Points=False
if Points == True:
# Fill in the level command template
gridNew = 'M557 X{}:{} Y{}:{} P{}:{}'.format(bounds['X']['min'], bounds['X']['max'],bounds['Y']['min'], bounds['Y']['max'], X_points, Y_points)
else:
# Fill in the level command template
gridNew = 'M557 X{}:{} Y{}:{} S{}'.format(bounds['X']['min'], bounds['X']['max'],bounds['Y']['min'], bounds['Y']['max'], probeSpacing)
# Replace M557 command in GCODE
linesNew = []
for line in lines:
if line.startswith('M557'):
linesNew.append(re.sub(r'^M557 X\d+:\d+ Y\d+:\d+ S\d+', gridNew, line, flags=re.MULTILINE))
print('New M557: ' + linesNew[-1])
else:
linesNew.append(line)
return linesNew
if __name__ == '__main__':
if sys.argv[1]:
main(fname = sys.argv[1])
else:
print('Error: Proper Slic3r post processing command is python3')
error()