Anyone tried EMC2Arduino

neilhand
Posts: 24
Joined: Thu Apr 26, 2012 7:03 pm

Re: Anyone tried EMC2Arduino

Post by neilhand » Thu May 31, 2012 5:26 am

Progress report...

Dewy721 - thanks for the file - and yes you beat me to it, on the bright side my changes (partially implemented) were not that different for yours, so at least i have a basic understanding of what was going on.

The different axis delays have helped and i now have X, Y and Z movement. The timing seems somewhat important (more so than i would have thought) so i think some tuning may be in order, but for the moment I am using 1000uS for the Z-axis and 25uS for the X and Y. when everything else is up an running i will break out the datasheets and logic analyzer to figure out what is going on (i would have assumed an 8x or so delay Z to compared to X, but that did not work).

I decided to go with setting the limits to +-8 for X and Y with home at 0, and +-2 with home at 0 for the Z (taken from Edwards linuxcnc setup). While effectively making the limits rather useless it did give me a change to play more as well as running hello world.

So the good news - X, Y, Z are working, and i can process gCode to the ShapeOko from LinuxCNC via the Arduino - and it is very nice to watch the tool progress.

Now the bad news - there are two issues one small that i think can be resolved in the setup - its slow... The bigger issue is that nothing lines up so the quality is very poor (everything works fine with GRBL so the machine itself is behaving).

For the latter i can observe what i believe is the problem and hopefully Dewy721 can tweak his mental and programatic models to fix the issue.

What seems to be happening is that the X, Y, Z movements are not co-ordinated. The best example of this in the "hello world" is that it begins to move in the X/Y on each letter before the Z has completed. This should not happen since the Z movement is independent of the XY (ie: there is no overlap of X/Y and Z). Even accounting for the running start and end that Z is getting on the XY movement, the endpoint of each letter is shifted so i suspect that what is happening in the Z axis is also happening in the X and Y. That is that X and Y are not correctly co-ordinated and as a result the alignment is fractionally off.

So in short we are getting closer, but not there yet.

Dewy721 - does this tweak anything in the mental model for you... I hope so...

On the power-up side of things the setting enable to inactive during start up helps, and the power down works as you planned. I tried adding the gotoSleep command to the +P and -P commands in "process commands" assuming that it would trigger the hold and release of the axis once the machine is powered off in the GUI - but it had no impact.

neilhand
Posts: 24
Joined: Thu Apr 26, 2012 7:03 pm

Re: Anyone tried EMC2Arduino

Post by neilhand » Thu May 31, 2012 1:58 pm

Thinking about it, it seems that with the implementation as it is, a new position command can come in while one is already underway. This is mostly an issue with Z since it takes longer to complete, but it could happen with others.

It seems that you would need to finish processing one set of commands before starting the other. which would require either buffering the incoming commands, or implementing a handshake with the host and buffering in the host.

Lets say the first command moves X and Y to 10, and 10, while underway a new command sets it to 8 and 8 before completing now the new endpoint is 8 and 8 and it will never move to 10, and 10.

dewy721
Posts: 16
Joined: Sun May 20, 2012 10:12 pm

Re: Anyone tried EMC2Arduino

Post by dewy721 » Thu May 31, 2012 6:33 pm

I'm glad to here that you have full movement and that expanding the timing options helps get you there.

powerConservation vs control:
If you'd like to control the drivers though Axis (via +P/-P) then you'll need to set conservePower to false. Otherwise its only called from near the bottom of the loop statement. (Scroll all the way down as its in the very bottom page worth of text.)

Movement coordination:
You closer to golden than you think. The problem is that LinuxCNC has no way of "feeling" the position of the machine (yet), and is outrunning your Arduino's ability to move things. The easy solution is to slow LinuxCNC way down. Take a look at the my-mill.ini excerpt that was included in the zip file. It has been tweaked to slow down just enough to keep EMC2Arduino busy 95% of the time. Leaving 5% headroom for catching up and keeping up with LinuxCNC. (Although I dialed it in for the Mega2560 I have in front of me.)

Since it sounds like the Z-Axis is based on a lead screw while the X/Y are direct drive belt driven, the Z-axis will be a tremendously stronger/slower. This isn't a problem though. LinuxCNC's motion controller can cater to it quite well, as long as its giving the Arduino enough time to get into position before moving to the next.

Speed and buffering:
Well, EMC2Arduino has become a bit of a wonder turtle. It offers a lot, but its slow. I would welcome anybody interest in optimizing it. As is, I can get about 180'ish rpm per stepper motor. On a belt feed machine that's a decent clip but for a powerhouse screw driven monster it's not.

As far as buffering goes I have not implemented it yet, why? 1. If LinuxCNC is set to NOT outrun the Arduino it becomes an unnecessary programming burden on an already aged platform. 2. More to the reality of the matter, it is technically beyond my skill level to introduce it. I'm just a diesel mechanic by trade, not a programmer. I don't have but the foggiest grasp on serial buffed mangling of data, storage and reduction of backlogged commands.

As a 'hands-on' person I'm not very good at giving textual tutorials but if You'll 'bear' with me, I'll give it a try....

Dialing in the best speed for your CNC the easy way...
Your ultimate speed cap within EMC2Arduino is the step delay timings. Were higher numbers = reliability while lower numbers = speed.
With that mentioned lets get to tweaking:
Open my-mill.ini with a text editor and minimize it for the moment.
Next fire up the Axis GUI and home your machine. Ideally it should move an axis and bring it to a full stop before moving on to the next one. Beginning with Z then X then lastly Y. All three movements should be separate operations. If two (or more) motors are in motion simultaneously then the Arduino has not had a chance to finish it's work before receiving new commands.

This behavior alone is a good guide to gauging an initial speed threshold for your particular hardware setup. Here's how to fix it:
In the editor (within my-mill.ini) you should see max velocity settings for each axis. Its worth noting here that there is a difference between the .ini file speed settings and the GUI's report and corresponding slider bars. Axis reports speed in IPM (Inches per minute) were as the .ini its in IPS (Inches per second). So with that in mind lets get you guys setup at first to run slowly but reliably. (You can speed it up afterwards.) I found that You'll want to tweak BOTH the MAX_VELOCITY and SEARCH_VEL to be the same on a per axis basis. For starters try the value of 0.05 (3.0-ipm) this should be safe enough to get you going albeit pretty slow. Z being screw driven may actually need to be even slower. (I don't know without having one myself.)

Another way to test is to do a pen on paper drawing test and play with the feed speed slider within Axis while your rig is doing mock-up circuit board milling, its good for spotting transitional movements and flaw patterns that the lines and diagonals will expose pretty well. Although something like a CDS (Circle, Diamond & Square) may ultimately be better for calibrating accuracy. If you dig around in LinuxCNC's example files it may still have one. It's an industry standard test pattern for machine accuracy. (CNC or otherwise.)

From here on out your tweaks are located in both the my-mill.ini file and within EMC2Arduino's stepper timings. Ironing out the these details is really just trail and error at this point but it pays off very well.

All I can do from my end now is show you were to look.

For those whom need it: 60ipm = 1ips or ips*60=ipm, or ipm/60=ips. Simple math.

Sounds like you guys have all the hard work out of the way. All that is left is to strike a balance between the rate at which LinuxCNC issues movements vs the Arduino's ability to process them fast enough to keep up.

Happy hunting and good luck.

neilhand
Posts: 24
Joined: Thu Apr 26, 2012 7:03 pm

Re: Anyone tried EMC2Arduino

Post by neilhand » Thu May 31, 2012 9:47 pm

Thanks for the write up and explanation, it makes a lot of sense. You guess is correct that the Z is a leadscrew in the design and the XY are belt driven.

I'll play around with the setup again tonight and see how far i get. I will tweak the code to change the Idle LED to create a collision detection indicator (when a new command comes before the old is finished) - that way i can play a little more to see what is going on and try to dial it in as best i can.

Once i have it working I'll then look into some possible optimizations to pick up the speed a little - i am not sure how effective the AVR complier is at operator reduction, so removing some of the unnecessary calculations may help speed things up. I also have an idea for some limited buffering and storage of the movement data so we can push closer to the limit. My background is in Electrical Engineering and computer Science, before turning to the dark side and becoming a marketing person - so i should be able to dust off some programming skills.

If i make any changes to the code i will send them back.

What i have been using for calibration is some block text drawing from the "hello world" gcode file that Edward generated. I'll look for a version of the CDS you mention since that seems it would be both more accurate as well a faster for some of the initial tests.

dewy721
Posts: 16
Joined: Sun May 20, 2012 10:12 pm

Re: Anyone tried EMC2Arduino

Post by dewy721 » Thu May 31, 2012 10:05 pm

I think that would be awesome, I could DEFINITELY use the help!

If you would like or if it would make code dissemination easier I could give you a fork on github. A place you can collaborate/merge code from the work several people into one place. I think EMC2Arduino could stand to offer a 3-axis centric flavor. I'm sure the community would welcome it.

dewy721
Posts: 16
Joined: Sun May 20, 2012 10:12 pm

Re: Anyone tried EMC2Arduino

Post by dewy721 » Thu May 31, 2012 10:22 pm

Oh, found that cds.ngc file I mentioned earlier. You should be able to find it at ~/linuxcnc/nc_files/examples/cds.ngc
You'll need to use the "Touch Off" buttons to touch the offsets. Home the machine, select the X click Touch Off, enter 2 inches then repeat for Y and enter 3 (I think) for Z then it should run just fine. May I suggest some air cutting followed by construction foam board.

neilhand
Posts: 24
Joined: Thu Apr 26, 2012 7:03 pm

Re: Anyone tried EMC2Arduino

Post by neilhand » Fri Jun 01, 2012 3:01 am

By all means create a GitHub fork (i'll have to figure out how to use GitHub, but it seems simple enough).

I plan on refactoring the code to make it easier to maintain, as part of that i am going to make the #axis configurable so a seperate 3-axis only implementation would not be needed - just configure compile and upload. One i get the code a little more maintainable i work on the other things.

dewy721
Posts: 16
Joined: Sun May 20, 2012 10:12 pm

Re: Anyone tried EMC2Arduino

Post by dewy721 » Fri Jun 01, 2012 3:30 am

Looks like you need to make a user account in order to be added to the admin list. Its free though.

neilhand
Posts: 24
Joined: Thu Apr 26, 2012 7:03 pm

Re: Anyone tried EMC2Arduino

Post by neilhand » Sun Jun 10, 2012 2:22 am

For those following along at home - this is still active, i have just been short of time this week. With help and guidance i am working on optimizing the software to improve both quality and performance.

Stay tuned...

edwardrford
Posts: 1250
Joined: Mon Apr 09, 2012 5:40 pm
Location: Dixon, IL
Contact:

Anyone tried EMC2Arduino

Post by edwardrford » Sun Jun 10, 2012 12:21 pm

Fantastic news. Thankls for keeping us posted.

-Edward

Sent from my BlackBerry 9930 using Tapatalk
Shapeoko 1 #0 - a couple of upgrades.
Shapeoko 2 #0 - a couple of upgrades.
Shapeoko 3 #2 - Stock

Post Reply