This looks exciting! i'd love to control the Ormerod with a Pi, would make the Ormerod massively easier (cheaper?) to replicate.

[www.allthingsmicro.com]


Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

Still need to crack the heating circuits
Greg

Edited 1 time(s). Last edit at 02/04/2014 02:49AM by GregL.

---

Ormerod #17

Interesting. I see each board is managed by a PIC24FJ64GA106 which can be re-programmed. The Pi GPIO appears to be passed thru on the shrouded headers so additional IO for heater control, endstops etc. would be available.

Of course it would also require the appropriate RPi software to convert gcodes to stepper drive signals. I've been searching around for something similar to run the motors in my cheapo Chinese 40W laser cutter and the closest thing I found was this RaspberryPi laser engraver project. This project has python code talking directly to H-bridge drivers so it should be fairly easy to adapt it to talk over I2C instead. But I wonder if I2C fast enough for this kind of application?

I wonder if RRP ever considered this approach - they seem to rely on 3rd party electronics design and some kind of additional driver board would have been required, but the design of that would be far simpler than the duet. Still, the cost of a RPi would probably exceed the cost of the microcontroller and peripherals integrated on the due - and the micro's full resources are available for a real-time application which isn't so well catered for by the RPi.

If it was all practical I still think the "All things Micro" board could be vastly improved upon to be a general purpose 3D printer interface. They mention 3D printing as an application example yet it would always have to be expanded with additional I/O to be of any use.

---

RS Components Reprap Ormerod No. 481

Quote
Radian
But I wonder if I2C fast enough for this kind of application?

A quick back-of-an-envelope calculation shows that with an I2C clock speed of 100kHz, it would be capable of feeding full-step commands to both the X and Y axis separately to drive them both in excess of 200mm/s, so it is theoretically plenty fast enough to max out the motors (and the I2C could probably be driven at a faster clock rate). But I wonder whether the Linux OS might introduce excessive delays from time to time, preventing smooth execution of the 3D printing code? Depends what priority can be assigned to the timer interrupts, I guess. With the Raspberry CPU having no datasheet available (which is what turned me off the Raspberry), all hardware operations will probably have to go via the OS.

One day I will probably have a go at writing some Ormerod firmware for the Duet completely in ARM assembler - it looks like a fun CPU to play with, and ARM has the best instruction set I've ever used. Apart from having operands that can be manipulated within the same instruction they are used, almost every instruction can be executed conditionally, and you also get to define whether the result of an instruction sets the condition codes or not. This means that you can achieve in a single instruction what would take at least 4 instructions to achieve in most other CPUs.

Dave
(#106)

Hi Dave. For my laser I currently use LinuxCNC which comes as a special distro claimed to be based on a real-time version of Linux. I have no idea what worst-case latency to expect with Raspbian but I've seen reports of 10ms which would be an issue. ARM assembler is my favorite too I started on the very first generation (when the A in ARM stood for Acorn). I recently tried out the Acorn RiscOS release for RPi and that brought back some memories! Actually, that OS is much closer to real-time... I just can't see people developing 3D printer apps on a 25 year old OS.

Er, well, maybe?

---

RS Components Reprap Ormerod No. 481

Quote
Radian
Hi Dave. For my laser I currently use LinuxCNC which comes as a special distro claimed to be based on a real-time version of Linux. I have no idea what worst-case latency to expect with Raspbian but I've seen reports of 10ms which would be an issue. ARM assembler is my favorite too I started on the very first generation (when the A in ARM stood for Acorn). I recently tried out the Acorn RiscOS release for RPi and that brought back some memories! Actually, that OS is much closer to real-time... I just can't see people developing 3D printer apps on a 25 year old OS.

Er, well, maybe?

I do not use any general-purpose OS for embedded firmware. I have a simple real-time OS framework that allows multi-tasking and handles dynamic memory allocation (when required), but I customise it for every product. I have my own modules for various common tasks such as floating-point arithmetic (though many ARM CPUs have that in hardware), an OCHI USB module, TCP/IP stack etc. Yes, a 10mS latency would be unusable, although I could see the motor movements being handled entirely in a timer interrupt routine, which if the timer interrupt can take priority over most everything else might be able to overcome that limitation. Except I can't see an interrupt routine being able to wait for a busy I2C bus, so it would need a fair bit of thought.

Dave
(#106)