My recommendation for the main board: A Duet 0.8.5 with 32-bit processor, 5 motors total, 5 endstops + 1 Z-probe, 2 nozzle heaters, 1 bed heater, 2 always on fans, 2 PWM fans, compatible to 24VDC, Ethernet featuring HTTP, FTP and Telnet (obviously with my web interface) And probably rather optional, but these boards are excellent too: dc42's PanelDue dc42's mini IR sensor boardby chrishamm - Controllers
Quotedc42 G32 won't run if the towers have not been homed. Running M0 turns the motors off and the homing is deemed to have been lost. So what you probably want in your starting script is G28 followed by G32. That's not right, M0 doesn't turn off the drives, it only puts them in idle mode which is why the axis positions remain valid. You'd have to run M1 to turn them off entirely. Theolodian, cby chrishamm - Fisher
From my experience you need to use a different Z trigger height for each bed material (and colour) - if all of your bed surfaces are e.g. white though, I figure you won't have to adjust it again. But if you do, you could create a few macros for the web interface and adjust the trigger height on-the-fly. You could even put them in a separate directory if the macro list becomes too crowded.by chrishamm - Ormerod
I was considering to add layer actions to the web interface, but OTOH everything necessary can be done in the G-code files already. In fact this is even the better solution, because you can only roughly predict at which move the print will pause once you've sent M26. As dc42 already said, you can insert M226 in your G-code file to pause the print after a certain move and I've done this multiple tby chrishamm - Ormerod
The MXL belt should fit in there quite tightly. Getting to this point can be a bit tricky and AFAIR I used a pair of pliers to push it in, but not with excessive force. I haven't had a Replikeo kit yet, so I don't know how good their printed parts are, but if the belt really doesn't fit you can carefully enlarge the slot a bit more with a knife or so. Also take care to get a good tension on the bby chrishamm - Ormerod
To those who are interested: I've just released version 1.09l which fixes a bug where certain pull-ups weren't properly disabled.by chrishamm - Ormerod
To those who are interested: I've just released version 1.09l which fixes a bug where certain pull-ups weren't properly disabled.by chrishamm - Fisher
Thanks for that ifconfig output, it looks quite useful. So here is my proposal for an alternative configuration: 1) Configure your MacBook's LAN (ethernet) adapter in this way: - IP address: 192.168.2.10 - Subnet mask: 255.255.255.0 2) Change the network configuration of your printer to: M552 P192.168.2.20; Set the IP address M553 P255.255.255.0; Set netmask M554 P192.168.2.10; Set the gatewayby chrishamm - Ormerod
The two firmware forks are entirely compatible - there is no need to adjust your config file if you want to try it out. This is what I wrote in my firmware thread on the Fisher forum: Quote At the moment, the biggest differences between dc42's and my fork are the smaller memory footprint, improved layer statistics during file prints, usage of a customised Arduino board to build the firmware withby chrishamm - Ormerod
Please post the output of "ipconfig getifaddr" instead, this will hopefully provide the information we need. I'm still a bit reluctant to believe that your configured IP address works, but I'll provide an alternative suggestion once I see which IP addresses are used by your MacBook.by chrishamm - Ormerod
QuoteTreito Did you change your FW-name to ch now? Don't you use zpl anymore? That's correct When I initially started my firmware development, I honestly didn't think I'd continue my development work for such a long time. That's why I really didn't care about my nickname either - I thought I'd submit one or two patches, but as you probably noticed there's always something left that could be impby chrishamm - Ormerod
Yes, it's been a while since I officially released my last firmware version 1.09g, but since then I've made quite some progress on my fork of the firmware. Here the complete changelog since that version: Quote Arduino device tree version 1.0.4: - Merged in latest version from Arduino GitHub repo - Merged in T3P3's changes for the Duet 0.8.5 (thanks Tony) Preliminary firmware version 1.09h: - Meby chrishamm - Fisher
Yes, it's been a while since I officially released my last firmware version 1.09g, but since then I've made quite some progress on my fork of the firmware. Here the complete changelog since that version: Quote Arduino device tree version 1.0.4: - Merged in latest version from Arduino GitHub repo - Merged in T3P3's changes for the Duet 0.8.5 (thanks Tony) Preliminary firmware version 1.09h: - Meby chrishamm - Ormerod
I remember there is a bug in the official 1.09 firmware release which causes the firmware to hang until a second T0 is sent (via Pronterface). Although running "T0" in the config.g file is still not recommended, this bug has been fixed in my firmware fork, and dc42's firmware wasn't affected anyway AFAIR. If you want to stick with RRP's official 1.09 firmware, the only solution is to remove thatby chrishamm - Ormerod
Network connection error -11 means that a TCP connection has been reset and I suspect your PC to be the reason - I don't get any with my configuration here. If you're interested in why this is happening, you may want to check out this article. OTOH, if everything is working, there's probably no need to investigate this any further.by chrishamm - Ormerod
Hi Bart, as you say, it's the "Lift Z" option that confuses the firmware which reports the layer stats to the web interface. I will improve the responsible component quite soon, so we can hopefully get rid of this problem once and for all.by chrishamm - Ormerod
No problem! My firmware fork supports the same auto-calibration feature, because it uses basically the same movement code. I can confirm that it works well on a Fisher delta printer. I admit my Makefile cannot download the required files, but you only need three components to compile my firmware fork (and RRP's) anyway: 1) The firmware itself 2) Arduino 1.6.5 3) An installed version of my Arduiby chrishamm - Ormerod
You may want to check out my Makefile, see - you can use it to build either the official RRP firmware or my fork. Just be aware you need to install the required Arduino board before you can use it, please have a look at the Hardware directory on my repo first.by chrishamm - Ormerod
Yes, a simplified interface for rather naive users is already on my TODO list. It will probably be implemented in the next version of my DWC.by chrishamm - Fisher
Hi Bart, I suggest you upgrade to either dc42's firmware or to my latest one. Don't forget to add the M574 code as seen here to your config.g file. The reason you're experiencing this problem is an invalid JSON response sent from the firmware and I remember having fixed a related bug a while ago. If an upgrade doesn't fix your symptoms, this would mean you're having a really unreliable networkby chrishamm - Ormerod
I'm happy to release version 1.09g of my firmware fork with full support for the Fisher Delta printer. Again, huge thanks to dc42 for providing his excellent move code and thanks once more to RRP for providing a fully-functional delta printer! My firmware fork basically works the same way as dc42's, but in addition I've implemented an extra 'H' parameter for M140 to set the heated bed heater numby chrishamm - Fisher
Would you mind posting the output of M122 after a crash occurred? A Wireshark dump might help as well...by chrishamm - Ormerod
No, that can't be right. My firmware is about 290kb big, so I suggest you download it once again from the link above. Make sure you click on the "raw" button to get it. HTH!by chrishamm - Ormerod
Quotebgkdavis M569 P0 S0 when I try it from the web interface it give me an Error: invalid drive number Then please download it again from and let me know if it works this time.by chrishamm - Ormerod
Yes I'm sorry, M569 didn't work as it should. I've just updated the file above though, so you can now test it on your Mendel.by chrishamm - Ormerod
bgkdavis, it actually sounds like your issue is related to the Ethernet connection. I've prepared an experimental firmware binary that assigns a lower interrupt priority to the ethernet IRQ. Would you mind checking if it makes any difference? You can get it here: Treito, although this may help, I don't think it's the right way to deal with this circumstance. The SAM3X allows us to set prioritieby chrishamm - Ormerod
Treito, I tried a recent FreeCAD version about two weeks ago and it crashed when I tried to create a bit more complex geometry - I only had a block and tried to build something on top and FreeCAD really didn't like that. That's why I cannot recommend it for now, but it's good to see there is at least one open-source approach with a more or less active development. Dave, the parametrics feature iby chrishamm - Ormerod
QuoteFpex is there a way to get step files of the printed parts? This will make it very easy to modify them and after rebuilding it a second time, I want to change some parts more than ever. Yes - a STEP assembly for each Ormerod revision can be found here: Well, I've been using Inventor for my designs and it's just far more stable than FreeCAD. Compared to Inventor, FreeCAD really feels likeby chrishamm - Ormerod
I've just released version 1.09f of my firmware fork on GitHub, which incorporates many fixes from dc42's latest release. Here the complete changelog of this version: Quote Enabled warning messages by default and bumped Arduino version to 1.6.5 Fixed many (potential) issues and merged in improvements (thanks dc42) X+Y delta corrections may be specified using M665 (thanks dc42) Reduced output bufby chrishamm - Ormerod