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.

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.

The Duet2 Wifi will still serve you well, @Chriss -- it's not magically bad now that this board has been announced (-:

@dog http://boim.com/DeltaUtil/CalDoc/Calibration.html gives you a nice explanations how different inaccuracies in a delta print affect dimensional accuracy.

@tomasl look here, line 40342, filament specific end gcode

G1 Z33.95 ; Move print head up

So that's where that comes from. And peeking at the HEIGHT comments, 33.95/0.15 = 226

So that's that.

this is either because it's sliced with variable layer heights, or because there is a Z move to move the print head off the print. Z moves that have a comment starting with capital E will be ignored for object height.

@dc42 these fans are for high performance data center servers and have an onboard controller that put them at full speed as long as PWM is not set up, i.e. during boot up. Only a short time on a standalone board, but many seconds in an SBC configuration. I've used an external 5A 24v to 12v step down converter usually used in trucks to drive car appliances made for 12v applications, getting power direct from the PSU. I have not measured their power draw.

There are other versions of the 4028 that draw up to 2A, where I wouldn't recommend hoping it will never draw full current.

@tomf you should be able to attach a buzzer at the 12864 header pins for that, enable the 12864 display and then it should buzz for good.

Alternately, re-use the cable to connect a PanelDue. Making a compatible display case is relatively straightforward.

@fma depends on the way the display connects to the main board. If it is doing serial, it might be possible to port the (last working well with RRF) firmware of the BTT touch screens, if not you may need to do that from scratch /-:

modern magnetic flex Steel print surfaces are easy to shim too. you can even have differently shimmed sets for different target temperatures.

@timsworkshop usually insufficient cooling and/or dwelling time due to low jerk and acceleration times.

Autodesk keeps removing features from the "hobbyist" free version, and just recently even announced they'll remove local simulation (a paid feature) and will in the future only offer cloud based simulation which they charge extra for. It's not even free as in beer, it's more like free as in "the first hit is free, but eventually you'll pay".