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,
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 Duet2 Wifi will still serve you well, @Chriss -- it's not magically bad now that this board has been announced (-:

I like the JoKo Engineering FreeCAD tutorials and demos on YouTube (and I usually hate YouTube tutorials). He does a couple comparison between various tools as well, but for everyone that doubts FreeCADs capability, the demo where he builds something out of a Solidworks certification in FreeCAD, then exports it as step file and checks the result in Solidworks for full compliance is pretty amazing.

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.

Because someone on the 3d Printers discord asked for help with his V-Core Pro, I finally got my act together and got mine up and running again (with the notable exception of part cooling).

Beauty shot:

Hemera and the toolboard are a real good combination, but it gets in the way of my preferred hemera part cooler. The mini IR probe works well on the mamorubot PP plate, and the Duet3 board was good with the Zesty Nimble, but I decided to use the Hemera here now, which means the tool board got some more work to do.

Next steps are

• fixing up the CAN cable (and power cable)
• possibly adding a drag chain to avoid dangling cables
• fixing the heater block rotation (it's "wrong")
• replacing the cheap noname SSR that came with the bed heater with a zero crossing one to avoid flicker when it keeps set temperatures.
• possibly adding the magnetic filament sensor
• part cooling. Because the front of the head is already pretty crowded, I am thinking of borrowing the cooling setup from the Medusa switching hotend: 5015 in the back and a flexible cooling hose to the front
• adding some panels for passively heated chamber for more fun with ASA and ABS

This machine is a Duet Baby: Duet3 board, tool distribution board, tool board, mini IR probe, PanelDue .... (hence it would be a nice touch to finally add the filament sensor somewhere).

@Phaedrux behold:

Finally got this going, thanks to @PCR s PCB -- very nice. Accidentally invented the sandwich design where the ESP32 sits between the PCB and the display -- makes for a sleek setup. I'll look into making a case for this (-:

I think I need to do two or three things to the code to make this cover my use case -- babystepping during printing, ordering of macros (at least show the numbered macros first like on PanelDue), and maybe one or two other things (-:

For people looking for a nice, configurable 12864 display, I cannot recommend the BTT TFT2.4 (or other sizes) well enough. While it's nominally an MKS-like touch screen, it also has an 12864 emulation mode that works perfectly fine with the Duet Maestro (including external SD card support), except for annoyingly not drawing the initial screen nicely.

So far I had to fiddle around with the screen (go to a sub menu, back out) to fix this display corruption, but today dealing with other things on my DICE I figured that the display comes up nicely after a reset initiated when the config file is updated. So there must be a better way than physically twiddling buttons I thought.

The solution is fairly simple: Patience. And this is how you introduce patience (at the end of your config.g):

M918 P1 E4 ;-- initialize screen 
G4 P500    ;-- wait half a second
M918 P1 E4 ;-- initialize again

People smarter than me may figure out how to teach the touch screen to talk PanelDue, other than the MKS one the BTT one is fully open source with all files available.

And here is a beauty shot:

@Kolbi in 3.1.1, daemon.g is being called every second, maybe that already gives you enough leeway for your cyclic running of commands?

How many macros do you have? There is a fixed limit.

Slicers assume the origin (0,0) is either in the front left or center of the print volume.

For now people "cheat" by defining virtual axes and setting arbitrary positions on them as makeshift variables.

I see "similar" behavior for the U hotend cooling fan on my IDEX (currently running RRF2.0.5.1), with the U hotend cooling fan being connected to fan3 on the Duex board. I found this to be a good thing, but I can see that it might be undesirable for lasers and stuff.

someone once linked a two-in-one setup with two bowden feeders and a direct feeder here on the forum, which is one application where I see this could be beneficial: decent control of the retracted filament that's not used, and nice short retracts on the print head.

RepPanel uses LVGL.

Hey Frederick,
thanks for the insight on the second motor -- offsetting the racking forces that way is pretty smart (at least smarter than whatever I would have come up with).

I also believe that a solution that works with the parts at hand is a good solution, common best practice be damned. Innovation doesn't usually come from sticking to what "everybody knows to be best").

I hadn't heard of MoI before (or if I did, I promptly forgot about it). Don't worry about the files, I am in practice not going to build another printer before finishing off the two-and-a-half I am currently working on...

Yeah, it's a markforged as @fcwilt pointed out in the initial post, but the one setup I am aware of can do X and Y with two motors. So I wonder if this is dual Y to take care of the extra weight of the full X axis moving in Y, or something else...

That looks nifty! What's the third stepper on the top for?

CAD renders are usually super clean without filament spools, cables, etc.; I like to see stuff like cable runs and so on

Not that I'd say no to CAD files or STLs either (-: