In short, I'm attempting to operate a thermoform "onto" the print bed once the print is done. So once a print is done the print head moves out of the way and a heater heats up a thermoplastic sheet held by a carriage that moves parallel to the Z-Axis, via belt connected steppers, so the sheet can be pulled over the bed. Then the vacuum turns on. So in summary:
As far as the controller & firmware etc., everything you want to do can be done just with correct configuration and adding a macro to run the extra mechanics; or add the full code to the slicer end code, either way.
Rotating the head away while still maintaining full accuracy seems difficult though; using a larger frame so the axes can move clear of the required area is likely cheaper.
The only high-accuracy possibility I can think of could be to use an E3D toolchanger system, with a hinge and servo added above the tool attachment point so when the tool is unclamped it can be swivelled up over the carriage, rather than left in a static carrier.
Still complex and expensive, possibly more so than just longer axis rails to move a normal head clear.
All the other motions are straightforward and controllable, with pretty much off-the-shelf mechanical parts.
12/31/2020, 10:26:56 PM m997 b1
Error: M997: Response timeout: CAN addr 1, req type 6024, RID=0
12/31/2020, 10:26:56 PM Connection to Duet established
12/31/2020, 10:26:55 PM Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)
@pgoellner in your screenshot you use reprapFirmware 3.2Beta4.1, but for 3.1.1 you need a different version. Go to github, go to tags, download the zip of tag version 3.1.1. This version will fit to the 3.1.0 libraries. DuetWifiSocketServer is not needed for compilation.
If you want to use the newest beta build instead, I would choose a version which is tagged for RRF and all libraries. CoreNG is replaced by CoreN2G, so this is probably to be used instead for the newest builds.
When compiling, is is sufficient to set the target in RRF, clean the project and compile. It will start compiling all libraries with the target and with the original set targets of the libraries (a bug), then RRF.
Thanks for confirming the case of M500.. Yeah 😛 I ended up doing the M307 for H0 and H1 by hand and filling them up there and then doing the M665 and M666 as well. (I'll move them to the config.g since they don't really need to live in the override either.)
So far so good!
I'm all new to RepRapFirmware and coming from old Repetier 8 bit world. 😆
maybe the 5mm requirement makes this possible by means of a trigger
try creating a M581 E0 T2 trigger for E0 endstop, and in the /sys/trigger2.g file do
that should make it move 5mm, and if the trigger condition is still asserted then it should run the trigger again, and again. You may have to experiment with the S parameter for rising or falling edge of the trigger to get the desired effect.
I tried a different cable, and every USB port on my computer with no success. I went through the “what to do if your duet won’t respond” guide on the website too. I didn’t have a different computer to use but it’s possible that would’ve fixed the problem. After rebooting the computer multiple times and rebooting the duet multiple times, it did eventually get a connection and I was able to reflash the firmware. Not sure why though.