Make your very own CNC machine or Robot the easy way, with an Arduino!
April 9, 2012
Filed under Emc2Arduino
So here’s a question: how does this work on PCs that can’t run normal EMC2 with parallel-port step generation, like a laptop, or any machine running emc2 in a virtual environment? One of the biggest obstacles to wider adoption of EMC2 is the need for somewhat specialized hardware. If this can allow someone to, say, run EMC2 in a virtual machine on their laptop, then that’s great. I’m assuming all the critical timing is done in the Arduino because the serial-over-USB is not reliable.
Besides making it possible to run EMC2 on a machine which can’t produce reliable software stepping or doesn’t have a parallel port, I think the second thing I’d like to see would be to divorce it completely from EMC2, or at least provide a neutral API. EMC2 is a huge pile of nasty monolithic code almost no one knows well (you’ve probably figured that out for yourself!) and the front ends for it are not much better. I feel like a fresh take on that could open a lot of doors. If you take out the very high-end industrial capabilities that probably >95% of DIY users will never touch, you could probably simplify things dramatically. On the UI side, I’d like to move towards more modern modular frameworks and support things like Android tablets, and make it easier for developers to add functionality. Think of it like the ngcgui plugin for Axis, but much more flexible and extensible.
Wow! Stunning insight btw.
1. Well, Emc2Arduino does do the timing internally its actually a simple step generator routine that continously moves the steppers to a given refference point. Rather then having EMC pump the stepgen signals over serial. All it has to send are the coordinates per axis in ascii text and 115200bps is actually overkill for that. The stepper routine responds quick enough that the motors actually have some idle time between position updates (if tuned properly of course).
2. One can easily drive Emc2Arduino with any program that can sling Asci text over the serial link. As far as EMC goes, it can get quite complicated but so can the Arduino, try programming the same thing in port nemonics. (In Atmel’s raw code format.) You’ll want to rip your hair out. The extra features will be trimmed back into smaller sketches as part of a overall scheme I like to call microBuilds. This would allow two main benefits. One, would be smaller more friendly chunks of code that can be configured and dropped in to a container sketch for custom-picked user selections of code. (grab just the bits you want and upload it.) Two, smaller lighter code base = simplicity = efficiency = performance. I’ll be the first to admit that currently its feature bloated, but for now thats ok. I’m building up a code base to pick pieces out of later.
2.5 Neutral API’s droid apps. If you can hack it. Have at it! Let me know how it works. I’ve got my hands full at the moment wrapping my head around EMC to HAL to Python to Arduino. I’m not even a programmer, by trade I’m a diesel mechanic. This is only my hobby intrest.
Side question–does this handle acceleration rates on each axis, as well? That was one of the things we were having a hard time figuring out how to implement. The thing was that with a 25KHz step rate and a 16MHz clock, you have something like 640 CPU clock cycles per step. That sounds like a lot, but they’re easy to eat up doing lots of calculations. A lot of the Arduino library calls are VERY inefficient and can eat 100 cycles on what seems like a very simple thing, but you can drop back to C and get around some of that, at cost of code flexibility.
The way I think about it, once you have the step-generator working, that code pretty much never needs to change except to accomodate new hardware or to improve performance. THe feature set is pretty much fixed in stone. So if it’s complex spaghetti code, that isn’t so much of a problem, since the need to update it is limited.
In that, I feel like the step-gen component should really only implement a few things:
– Step/Dir generation based on primitive position/accel commands
– Home switch in
– Estop in (e.g. manual switch, limit switches)
– Estop out (to trip relays or other system components if it generates an Estop)
Human-machine interface stuff feels to me like something you implement on another board that communicates with the host PC (running EMC) which can then send commands to the step generator. Given that these boards are very cheap (esp. compared to everything else in the shop) I feel like it’s just good conservative design to keep the realtime stuff isolated. I’d also put things like spindle control in that category. Aside from threading and rigid tapping, you never need truly coordinated spindle-axis motion.
If you look around, what the DIY CNC world is still missing is a good, really usable intermediate step generator. GRBL has been the most advanced effort to date, but you have to choose between support for arcs (which are pretty basic, really) OR acceleration. They don’t seem to have a version that has both.
The acceleration is handled by the host software. Emc2Arduino is just playing follow the ball. If the ball accelerates then Emc2Arduino chases it faster. I tried to do integrated acceleration through modulating the microStepping mode from 1/16″ up to full steps but juggling the timing, pin IO every to set the mode every step cycle while still accounting the position, created too much overhead. The stepMode() routine is still there but only called once during setup(). However since the motion control is idling MOST of the time it has enough headroom to handle acceleration as input. There is a globalIdle variable to check idle state for non-criticals.
I plan to do more of a plugin based implementation in the future, it will allow users to pick the options they need while skipping the bloat that’s not. Basing the plugins on process priority will allow E-Stop and motion control routines to take precedence over say, LCD updates for example. Once I get my head around python enough to setup swarming users will be able to use multiple Arduinos on a per task(s) basis.
That way allows people to choose all-out multi-Arduino performance minded hardware layouts all the way down to a simple single Arduino economy based solution that still fits there needs.
how important, if at all, is the realtime kernel to the operation of emc2arduino. I am trying to set up a configuration to test with a shapeoko mill, but my laptop is not playing nice with the RT kernel (an old lenovo/ibm)
Its not important to the arduino at all.
RTAI pertains to the use of CNC controllers when driven via the parallel port. (The ol’ school way.)
Which *IS* important to CNC machining but only if your doing high-end stuff like cutting threads at high speeds. The kind of stuff that you would do with a $100k+ machine. (In those cases an Arduino is most likely not in the picture.)
So, for Arduino controlled DYI CNC rigs out there its not needed, unless your planning on a one-off custom hybrid traditional CNC + Arduino based addons. Then you might have some weird timing constraints.
However for us regular folks that just want a garage CNC router/mill/lathe/etc. Real-time kernel = unnecessary.
In a nut-shell: RTAI only pertains to parallel ports.
If i install the simulation version of EMC2 will the control delegation needed for emc2arduino function?
Good question, I don’t see why it wouldn’t work but I can’t say for sure. I haven’t tried out sim mode for my self. Give it a shot, let me know if it works.
Saw your reply on the shapeoko forum – have still been playing but reverted to a standalone linux box. Seems to be an issue with timing – check the post if you have a minute and let me know what you think.
one additional question – how can i avoid the “unexpected realtime delay” messages…
Ah, that is based on the latency timer that (as I recall) is defined in mymill.ini run the latency time test to get an idea of the min value for the latency clock. Then edit the ini file and exaggerate the associated number somewhat. (I’m in windows on brand new box at the moment and have to do hardware changes to boot linux.)
Have you thought about adding pre-canned pin definitions for some of the RepRap electronics boards like RAMPS? For details see http://reprap.org/wiki/RAMPS and http://reprap.org/wiki/Pololu_Electronics#Other_Pololu_Designs
That sounds like a good idea! I’ll look into it. At the moment I don’t have one handy, but I’ve been considering them for a while now.
Arduino DUE is out. Operating on 84Mhz. So its better suitable for EMC2ARDUINO, right? Can i use DUE?
I don’t have one yet. So I cannot say for certain. But I do imagine it should be able to run EMC2Arduino.
Unlike the UNO/MEGA series with 5volt IO, the DUE however has a lower 3.3volt IO so you will need to be careful about attachments.
Also the code should run fine once you replace all instances of digitalFastWrite() with regular digitalWrite(). The DUE’s performance should more than offset the performance requirements.
The digitalFastWrite.h was written with hardware specific PORT commands for the then common 8-bit AVR chips, PORT commands are necessary to wring enough performance out of these old-school 8 bit chips.
The performance of the DUE should be more than able pull it off with out any special tweaks.
If you get it working please let me know. I’m interested in one of these myself.
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.
Notify me of new posts via email.
Create a free website or blog at WordPress.com.