EMC stops executing code (code format issue?)

NICKKINSMAN wrote:

I opened up Machine -config and picked the spindle-revs and it counts up at like 20 decimal places on the 'watch'. I also checked the motion-spindle-enable and it shows;

FALSE motion.spindle-index-enable <=> spindle.index.enable

When selected in 'watch' it shows a red dot.

I believe that means it's connected?

Yes.

The next question is whether index-enable changes state when you run the code. (you probably need Halscope to see that).
Though I am not at all sure that G94 uses index.

Wait, hang on, I have my modes confused (as, possibly, does BobCAM)

G95 is feed-per-rev mode, and is what you might use for a thread if G76 was too confusing.
G94 is feed per minute. I think that G0code just gives you a very, very, slow feed of .063 in/minute. That would look like a stopped machine.

Yes, I added some notes to my previous post, you are absolutely right, it is not changing state - see previous if you would!

And yes you are right BCC is putting out a feed per min based on pitch, which is not cool. They say they will modify the processor as I request, we'll see....

Nick

So, perhaps I didn't ask the important question clearly enough. Is the machine actually stopped, or just moving very slowly. (0.063 ipm is rather glacial)
The CAM appears to be specifying a feed-per rev as a feed per min, or perhaps a feed-per-sec.

Thanks for the feecback - the additon of theM6 command does bring up the tool change prompt on running!

For some reason EMC does not like the 'S500 M3 G94 F.063" on that same line with the G01 code, when I get rid of that it runs thru it fine! It might be part of this index-enable problem as well, that it is not getting the OK to proceed because it is waiting for spindle speed to show OK. I'll have to figure this out and try it again!

NICKKINSMAN wrote:

It might be part of this index-enable problem as well, that it is not getting the OK to proceed because it is waiting for spindle speed to show OK.

I don't think this is it, as I don't think that G-code is even using a mode where spindle synchronisation happens.
So, not only is it not using G76, or the slightly less suitable G33, it isn't even using G95 (feed per rev) mode. It is actually trying to cut a thread with absolutely no reference to the spindle at all, and just assuming that your spindle speed is spot-on.

I am beginning to see why JT has the opinions he has.

Yes, I am finding several errors in the G-code generator from Bob-CAD. I found one straight-up bug where if you select 'separate moves' for facing it just rapids to the very center and back out, have to select 'canned cycles' and then it will face it.

We'll see how they do, I've sent the edits into them to work on, and they say they are. Maybe they wil get a better post processor out of it. I would suspect there are not many shops running EMC with Bob-CAD which is probably why the processor has the problems.

But, to my earlier thought, if you have speed feedback to EMC and you tell it to run at S500, won' t it wait until you get in range to proceed? I thought I read that and it might be why it was not proceeding (poor Gcoding aside).

I noticed my spindle range setting was at 0.90 in HAL, (directions aren't clear here, but my interpreation is speed needs to be from 90 to 100% of the requested) and I was actually running around 520 RPM, so maybe I was out of range and it would not proceed?

Anyway, just glad I figured out where the code problem was (besides just poor G-coding in general)!

Thanks!