Re: need help compiling EMC

[Jon Elson <elson-at-pico-systems.com>]

Paul wrote:

> Hi Jon
>
> The module causing the oops message is your univstepmod.o - Assuming your
> debugging messages were in he extDioInit() routine, then it would be save to
> assume the bug is somewhere between the EMCMOT_TASK_STACK_SIZE print
> statement and the exDioInit call in emcmot.c. At a wild guess, I'd start
> looking around line 4489 to 4525 in emcmot.c where the shared memory is
> allocated for emcmotStruct.
>
> However, I would be inclined to track down the source of the failed compile
> of the non-realtime stuff first - An error here could be passed over to the
> realtime system when you try to run things and perhaps mislead you.

Oh, I did get that!

The error was just in not initializing my pointer to my new structure in the
EMCMOT_STRUCT struct of structs.  I didn't realize I had to have my own
copy of all the pointers to the substructures.  I actually had the line there,
but
had commented it out.

Now, I'm actually running with the hardware, and finding several differences.

1.  The main keyboard numerals 0..9 used to set the feed override in 10% steps
from 10 to 100%.  They no longer seem to do this in the TkEMC GUI.

2.  I found that there is a pause in motion of large arcs in the XY plane.  I
have
a number of programs that do G03 arcs in 90 degree segments that end with
one axis reversing and the other axis moving rapidly.  The rapidly
moving axis pauses for a fraction of a second at this transition to the next
G-code
block.  (The reversing axis probably does, too, but you can't detect it as
easily.)  I
ran some other programs that had linear moves, and they didn't seem to have the
pause.  I vaguely remember this being discussed on one of these lists several
months
ago.  Is this a known problem?

I can categorically state my 20-DEC-1999 version does not have a pause in
this kind of motion.  (I checked to make sure G64 was turned on.)

Is there any sort of description on how to get my changes into the SourceForge
distribution?  Since these changes are quite extensive, there probably needs to
be some sort of evaluation and testing of these changes, to make sure they don't

break something else.  Others may be quite interested in this, however, because
it can move ALL auxilliary I/O over to the real-time side.  This allows bits
of registers to be shared without timing conflict when accessing the registers.

Jon