Re: [CAD_CAM_EDM_DRO] EMC Source M-codes pause motion

On Wednesday 03 September 2003 18:57, foxprints2003 wrote:

> You may recall my earlier inquiry into the motion pausing to execute
> m-codes issue.

Yes. Sorry about not responding earlier. I talked with Fred Proctor at NIST
about your problem, but I never typed out a response...

> Nobody had a quick fix for me so I decided to read through the
> source files to see if I could isolate the problem. Since I am just
> beginning to learn programming the do-it-yourself way I'd like to
> get some expert advice.

I'm not an expert, but I'll try to explain as best I can.

> Findings:
> I read through the rs-274ngc files & did not see anything associated
> with the m-codes that would generate a delay.

Correct!

> I am assuming the rs-
> 274ngc files are what everyone refers to as the "interpreter".

Correct!

> I read emctaskmain.cc & found this to be the command sequencing
> controller (I think). My understanding of how the m-codes in
> question (m3, m4, m5, m7, m8, m9) are handled is; in all modes
> except auto/reading (processing a file) these functions are executed
> immediately.

Correct!

> Hypothesis:
> If these commands are removed from the emcTaskCheckPreconditions
> section & the emcTaskCheckPostconditions sections & inserted into
> the auto/reading immediate commands section they will be executed
> without forcing a wait for motion.

Yes, but then those commands would be executed as soon as they were
interpreted, perhaps lots earlier than you would like if a bunch of moves
were stacked up in the motion queue waiting to be executed.

A similar, but not exactly the same, issue was encountered when trying to
support laser cutters. It was necessary for the laser to be turned on at the
exact start of a block so that the workpiece material could be pierced before
motion began. To see how this was done, search for occurrences of "LASER" in
bridgeporttaskintf.cc. This still resulted in pauses at the beginning of the
block when an M7 was commanded. Perhaps this would work for you if you began
your spraying move with the paint gun slightly ahead of the workpiece and
ended the move slightly past the workpiece (where you could do an M9 in the
next block)?

Fred and I talked for a while about how to do what you want to do, but since
the current design doesn't have I/O operations in the motion queue (the
motion is done in real time, the I/O is done on the user, or non-realtime
side), it's difficult to synchronize them. We are in the process of
refactoring all the code and we should be able to work this idea into a
future version.

> Is this anywhere near the ballpark? Are there other issues that
> would be left open by this change such as messaging?

You've basically nailed it as far as where this functionality is controlled in
the code. For an amateur coder, you did real good! why not join the
emc-developers list at sourceforge.net and help us design and implement the
new, re-designed version? We need the help, and you could get the features
you want... See:

http://sourceforge.net/mail/?group_id=6744

> In other topics, does anyone have a flow chart or any type of aid
> that describes the interrelationship of all the different components
> of EMC? I have a copy of the source notes but they are too
> microscopic in scope (no offense intended to the author(s)), they
> don't describe the bigger picture.

In a word - No. This is one of the biggest problems we have when trying to
recruit new developers. The source code is so big and so complicated, it's
hard to wrap your brain around the whole thing. You might be interested in
some audio recordings I made at:

http://www.obstinate.org/emc/

Also, send me your phone number in a separate e-mail and I can give you a call
and answer more of your questions in real time as it's a lot to type! I've
got this new flat rate long distance plan and I want to get my money's
worth...

Matt