Re: Linux vs. DOS

Tim Goldstein wrote:

> From: "Tim Goldstein" <timg@...>
>
> I finally have made my first item using EMC!!!
>
> If you want to check it out you can see it on my website at
> http://www.ktmarketing.com/emcproject1.html

Very cute! You should send one to Fred Proctor! I think it
would look nice on his desk!
<snip>

> Here is a question for Matt or Jon or anyone else running EMC:
> Is there a way to run the g-code through EMC's code interpreted without just
> loading it in Xemc and running it? I found that if I tried running the code
> with the my stepper controller turned off so I could crank up the feed rate
> to just check the code more quickly I would get an error that would abort
> the code referring to a "follow error" on an axis. If I ran the code with
> the controller turned on I had no errors in this section of code, but it
> took MUCH longer as I had to use realistic feed rates.

Hmm, you must have your encoders hooked up. What you can do is
build a 'demo' version of EMC, that has simulation code rather than
motion hardware code. In fact, you should have these programs and
scripts on your system. It will give you a quick check of a program,
but you'll still have the same problem of identifying WHERE the error
is. Fred is supposed to be working on a major revamp of this whole
area.

>
> Now for some observations that may help others over the EMC learning curve a
> little faster:
> The enter key by your number pad and the enter key by your letter keys are
> not equivalent in EMC. If you use your mouse to click on either the feed
> rate or the feed override it pops up a window to enter a rate into, but to
> get it to accept the rate and use it you have to use the enter key by your
> letter keys. The one on the number pad will close the box, but your entry
> disappears.

All this keyboard stuff is one of the biggest bags of worms in Linux. It has
to do with the huge variety of keyboards that have been made, and the wide
variety of keyboard scan codes they produce. All of this can be fixed in
the X-windows setup script, but it is not that easy to decipher the wrong
keycodes. There are a couple of utilities that tell you what keycodes and
scancodes are being generated by various keys.

> EMC seems VERY picky about the g-code it will accept. The other controller
> software product I was using will let you run most any code you throw at it
> as long as you don't give it a code it doesn't handle. EMC seems to require
> everything is exact. This is not a bad thing, but it does make the debugging
> lengthy particularly in light of the fact that when it errors you have no
> clue of the line that caused it.

I addressed some of this in a response to another message on this list.

> On the plus side, my machine seems to run much smoother under EMC than on
> any of the other softwares I have tried.

Yes, the smooth blending of any move into the next move, whether linear,
arc or helical, in any of the 3 planes, is tough enough that I shied away
from rolling my own CNC for exectly that reason. That's why a group
of guys spent a couple of years figuring all this out at taxpayer's expense!
Next time you pay your taxes, remember that that is also funding the
great guys like Will Shackleford and Fred Proctor who beat this path
through for us!

So, I can understand why Allen-Bradley and Fanuc have this, and
why Ah-Ha and Microkinetics might not.

Jon