LinkBack URL
About LinkBacks
look here:
http://axis.unpy.net/01198594294
I'm looking to build a custom keypad which would have a large number of keys, some of which I'd like to include status lights which would reflect the state of the machine (such as the G20/G21 for inch vs mm mode).
Basically, I will have too many I/O lines for simplistic use of the parallel port, and I'd prefer to avoid something like a Mesa card, mainly for cost reasons.
I've built a bunch of things using the Arduino boards before, and I'm curious whether anyone has gotten one to talk with EMC. If there is a way to send discrete messages ("G20 is enabled") between the two systems, then I can easily figure out how to wire up the keypad with the Arduino.
Has anyone done or seen anything along these lines?
Thanks Chester. That worked--well, I was able to turn an LED on and off using the test control panel. I don't really understand the parts well yet, or how they fit together, but at least they seem to fit! From experience I know it's easy to spend hours trying to get Plug A to fit into Socket B so it is always nice to see "hello world." Now the real work begins....
Since my last post I've managed to get things working pretty well. I ended up starting over pretty much from scratch compared to the example chester88 posted, cribbing together bits from various tutorials and asking stupid questions on the EMC lists and IRC channel.
This video shows an Arduino being used as both an MPG with an encoder and a remote DRO with a 20x4 LCD. Cost of the whole setup is a little under $100 so far.
[nomedia="http://www.youtube.com/watch?v=flajZMff28U"]YouTube - Integrating an Arduino with EMC[/nomedia]
Next step is to design and etch up a board to support a full keypad. I have 10 I/O lines to work with, which would give me room for a 25-key matrix. If I can squeeze all that in, it will make a pretty nice unit. As it continues to mature a bit more I will post sources for anyone who wants to see how it all goes together.
Nice! I'd love to see a finished product. Maybe as a kit
seconded. A kit for a usb pendant/remote DRO would be really cool.
OK, so here's the latest:
[nomedia="http://www.youtube.com/watch?v=n9YMpQjsab4"]YouTube - Arduino EMC Pendant II[/nomedia]
This adds a 25-key keypad to the mix, which I wasn't sure if the Arduino could cope with on top of the encoder and LCD. So far, so good. 25 keys is a pretty healthy number, and unless your machine has an ATC or some other sophisticated systems, should be enough to cover around 95% of what you'd want on a hardware interface. As it is now, I have these:
- XYZA axis selection
- Jog rate selection (4 positions)
- Spindle speed and feed rate override select (uses the encoder)
- X and Y continuous jog
- Coolant on/off
- Axis home (homes the selected X/Y/Z/A axis)
- Cycle start, stop, pause, and single block mode
If anybody has some suggestions for what they'd like to have, I'm all ears. I'm considering getting some quotes for proper membrane keypads to see how much it would cost to do say 50-100 of them, versus a PCB with switches and a printed overlay. Obviously there are going to be some differences between a router table, milling machine, and lathe, so whatever I do, you're probably going to end up with a few labels stuck on top of it. Either way, the hardware config will be hackable to allow you to get it to do what you want.
Hi sansbury!
Nice work.
This is something that i have been looking fore. One thing to implement is the connection of touch probe so you can use it for scanning, center finding and so on with the G38.2 code.
Why are you not using Z in continuous?
Thanks Gunnar!
The keypad design is still evolving. The main reason I didn't add continuous jog keys for the Z was that in my experience, the Z moves a lot less than X/Y. If you want to retract the Z all the way, there is always the homing function, assuming your Z homes away from the table (as is usual).
But, if you prefer, you could modify the keypad and firmware pretty easily to support a Z jog instead of tool release, coolant, or some other function you don't care about that I do
Probing is a good question. My sense was that the right place to implement this might be in the EMC GUI layer, rather than the pendant. Probing the center of a pocket is easy since there's only one way to do it, but edges have four possible ways to go, so you need at least 5 keys, unless you want to have multi-key functions (e.g. select probe function, select axis, select direction) which are harder to use and make the software more complicated.
One thing I might look into is the use of soft keys, though these also add a good deal of complexity to the software, and I'm not sure how much headroom I have at this point.
Sansbury, good job so far. I am planning on using an arduino or a teensy++ for my sensors (limits, over-current, axis encoders etc). I was wondering if you could share any of the details. For instance, are you running firmata on the arduino and grabbing the info from within EMC? Any info you can share as far as setup on the EMC side? Are you using USB serial or direct serial? In case you are curious about the teensy, it has a higher gpio count (45 in the case of the ++ model) plus speaks at usb bus speeds vs serial speeds. Did I mention that it is cheaper and easier to breadboard?
half_life, I did a longer write-up on my blog that goes into a bit more detail:
Arduino-EMC Integration: How it Works | Just Milling Around
I am not using Firmata, I implemented my own serial protocol. Outputs to the Arduino are seven-character fixed-length messages like "X123456" which would be interpreted as "the X axis position is now 12.3456." The Arduino outputs are shorter, only 3 chars, as they don't need to carry nearly as much information. I could probably cut the length of both in half, at the cost of making them harder for humans to work with. Given that current performance appears adequate, I'm leaving it be.
The reasons I chose the Arduino are simple: it's drop-dead easy to work with, and has a huge installed base. If somebody wants their pendant to have probing functions instead of coolant and spindle control, I want it to be easy for them to do that. Right now, I think Arduino is the best place to start with that goal in mind. The teensy or some other less-common solution, let alone something that requires an external programmer, would be great if I really wanted to extract maximum commercial value at the cost of end-user openness. For an example, the Shumatech DRO's software and schematics are open, but as best as I know, the only DROs out there using that code are Shumatech's. Given that this thing can do a lot more than a DRO, I'd rather give up some number of sales to people who DIY the whole stack and benefit from the whole community contributing code and using this platform as the basis for more intricate HMIs.
Does your sourcecode/ the HAL system in general allow the arduino to also generate step and dir signals to control steppers directly from EMC?
Posting Permissions
