Some of you may remember I reserved a kinematics type number back in August 2019.

And some of you remember I wanted to take a break from 3d printers.

Well, I failed either so far. But as of today, I have a prototype machine built that I can implement for. Luckily, someone did it for Smoothieware (the same person whose prototype build I copied, with his blessing and help).

Here is a first photo:

And here is a short video of me abusing delta mode and absolute tower moves to show that it's only mostly dead:

https://photos.app.goo.gl/c4ptuJajXeWNc8di9

Still missing are endstops, belt tension, anything on the effector to do useful stuff, a surface to do stuff on ... but for implementing the kinematics this should be sufficient. Let's see if I can get to there in less than nine months (-:

Hi,
as requested, I am reposting this as a firmware wishlist item.

If possible, I would like to see

job.lastFileAborted
job.lastFileCancelled
job.lastFileSimulated

to be made available in standalone mode.

Hi,
The 1LC format is nice to mount on a Hemera, but people use other extrusion systems as well ...

it would be great to see other toolboard form factors like the pancake board to fit on the back of one of the currently popular mini extruders with round nema14s ... sadly I lack the time and skills to adopt the 1LC toolboard myself, but if anyone feels inspired, let me know (-:

PS: Yes, I know, chip shortage makes this hard.

For closure, the MKSTHR36 2040 based toolboard fills this gap in the product line-up. I will be able to report how it works probably end of next week.

I recently ran across a concept from 2014 that seems to have been implemented in LinuxCNC and MachineKit, but none of the main printer firmwares around: Velocity based extrusion.

In short, the extruder is not an axis controlled by the GCode directly, but the firmware is instructed about target line width and height and controls extrusion speed according to nozzle movement. This is similar to volumetric extrusion but different (extruder is still an axis) and should basically result in pressure equalization similar to Pressure Advance, but based on nozzle movement velocity rather than as a heuristic adjusting the extruder movement.

Further reading:
https://basdebruijn.com/2014/05/machinekit-and-additive-manufacturing/
https://basdebruijn.com/2014/09/velocity-extruding-revisited/
Post processing script for slic3r:
https://github.com/machinekoder/Machinekit-Slic3r-postprocess/blob/master/velocity-extrusion.py

Tom Sanlanderer has designed and published a cheap diameter sensing setup (see https://www.youmagine.com/designs/infidel-inline-filament-diameter-estimator-lowcost-10-24) -- it would be great to see that included in a future filament sensor design -- and to add a feature to adjust extrusion rate with the sensed diameter of course for those of us that like the last tiny bit of precision.

@natthapol-vanasrivilai I would suggest before you start with software development 101 you look up the developers background who you are trying to lecture here. @dc42 is also behind eschertech.com, which has a formal C++ verifier in its product portfolio. If you do more than a glancing view on the github repo, you see that the code is at times adjusted to allow for the verifier to run.

Formal verification may not be a common way to ensure software quality, but it's an approach that can cover a lot of issues that unit testing and integration testing cannot, or can only do at very high cost.

You should also consider that automotive control systems usually apply to systems that have a (mostly) fixed configuration, while RepRapFirmware does allow free-form reconfiguration of the system. I posit that no amount of unit and integration testing will be able to catch all errors in such a system. They also have hundreds of millions of monetary units in development budget which allows for large and cumbersome software development processes to be run.

As such, the release of beta and release candidate systems -- which by definition aren't supported deemed production ready releases are another way to gather more input about new changes, their performance, bugs, unintended side effects, etc. One of the reasons that 3.4 is still not in release is exactly that there are known issues that need to be analysed, the root cause found, fixed, tested, integrated, and released.

PS: I've seen "reasonably sized" software with unit tests and a code coverage quotient well beyond 90% in my 20+ years career in IT that simply didn't work in practice. So I completely disagree with you that the existence or absence of unit tests allows any guess about the quality of the software under test.

https://youtu.be/OUEUayf1yt0

really excited about this and I spotted a PanelDue in the video (-;

Hi,
I would like to document what I needed to do to compile RepRapFirmware and DuetWiFiSocketServer on a Debian Buster system (similar to a previous report on doing the same on Linux Arch).

First off, do not waste time trying to install the build chain from debian packages. They are sorely outdated and will not work.

The Build Instructions are a decent baseline, but to get everything going, I had to close some gaps.

Build Tools

1. Eclipse IDE for C++ downloaded from upstream. This requires a JRE to run, but openjdk is sufficient.
2. arm GNU toolchain downloaded from upstream. The Debian packages are massively outdated and builds will fail.
3. xtensa architecture toolchain from upstream is needed for DuetWifiSocketServer. As with the arm-gcc cross compiler, the Buster packages are outdated and won't build the project.
4. ESPtool because the esptool.py included in the xtensa architecture toolchain has different command line switches and the build will fail without the binary
5. eboot.elf from the Arduino ESP libraries

Additional Dependencies

In addition to the repositories listed in the build instructions, you need LwipESP8266 and CoreESP8266 as prerequisites to build DuetWiFiSocketServer.

More Project Variables and Paths

1. For LwipESP8266, set GccPath to the bin dir of the xtensa-lx106-elf compiler suite
2. For CoreESP8266, set GccPath to the bin dir of the xtensa-lx106-elf compiler suite
3. For DuetWifiSocketServer, set

• EspBootFile to the path to a valid eboot.bin
• EspToolPath to the esptool binary (NB esptool.py does not work because it has another call signature)
• GCCPath to the bin dir of the xtensa-lx106-compiler suite

From the default settings on the checked out projects it looks like you can find those when you added ESP8266 support to a local arduino installation, but when I set this up I was tired and couldn't remember how to set up board support on Arduino so it was more straightforward for me to download and build everything from source. It also made it possible for me to ensure that I really got the latest versions of everything.

With all this in place, I was able to build CoreNG, FreeRTOS, RRFLibraries, LwipEsp8266, CoreEsp8266, DuetWifiSocketServer and finally RepRapFirmware without a hitch.

The last ten days I kept myself busy with a V-Core Pro Corexy kit. It sports a 750W AC heater, three independent z steppers, MGN15 linear rails, 9mm Gates belts, a Duet3 with a Raspberry Pi4, hall effect endstops, a polypropylene print plate, paracord-sleeved cabling, a 450W Meanwell PSU (overpowered without running a heater, but that hopefully means it will rarely switch on it's fans). Print volume is 300x300x300 -- but since I use integrated leadscrew steppers, Z is likely close to 330.

The kit is super chonky for lack of a better word. The belt runs are super clean and parallel to everything, and the belt tensioner is integrated in the X carriage requiring a single screw per belt to tension.

I am almost ready to do a first print, but am missing mounts for the endstops and Z calibration. After that, everything will be cleanup and incremental improvements.

and if possible a sample gcode file that causes this issue.

@dc42 3.5b4, no? Also, how would one update the firmware in existing sensors at home?

@JoergS5 you are allowed to be opinionated in your implementation and just pick one of the two kinematics solutions. It moght be interesting to do a "shortest path" kind of heuristic later (-;

@Luke-sLaboratory I havent tried, I just like to be on the up and up (-:

@apak is that captured in a bug on the klipper side? I worry that the conspiracy theorists talk about Duet3D "locking" the board.

@apak what does semibrick mean, and do you know how to recover?

@infiniteloop some people turn the board fan on based on the hotend temp taking it as a proxy for "machine will get load". So thats not necesarily wrong.

@droftarts said in Duet2 Eth Klipper Firmware issues:

I'm also not sure about using /dev/serial/by-id/ as the port.

Thats normal under klipper because /dev/ttyACM* is not reliable to be stable across boots (USB enumeration can change with kernel and/or klipper formware updates), and you may have multiple boards (displays, toolboards, multiple control boards for larger numbers of drivers or additional IO). Configuring by id gives you a stable identifier.

@re_tour said in My printer stops extruding randomly, what am I missing?:

The cooling fan is a noctua 10x10 fan with a step down converter, which I don't think is an issue(but I've been wrong before sooo...)

I would not rely on a Noctua 40x10 for hotend cooling. A 40x20 may work if there is free airflow "behind" the hotend. Its quiet because it has almost no air pressure.

@CCS86 I strongly disagree, too easy to accidentally overwrite what I don't want to. This safeguard saved my bacon already a couple times.