Re: [Emc-developers] tkemc (on emc2) bugs/nits

[Jeff E. <je...@un...>]

Hi Paul!

We'd love for you to try AXIS, but I'm not sure it will fix any of these
items.

Are all these emc1 vs emc2 differences?
>     - if i've been running in Auto mode (running a program), and
> 	then pause the program and switch to MDI mode to enter a
> 	command manually, MDI mode is non-functional.  nothing
> 	happens.  if after pausing i first select Manual mode,
> 	and then (immediately, or after jogging a bit) select MDI
> 	mode, then MDI is functional.

In AXIS, this is deliberately prevented in the front-end.  When the
program is not stopped, MDI and manual functionality are disabled.
Pausing is not enough to get these features enabled, a full stop is.

If this is too strong a restriction on MDI/manual modes, we will
investigate how to relax it.

On the other hand, if there's a bug in emc, it's the AXIS philosophy to
hide it from the user by removing functionality---an example I recall
offhand is that using single-step from the beginning of the program
doesn't seem to leave emc in the right state (interp_state should be
INTERP_PAUSED, but it seems to stay at INTERP_IDLE IIRC).  So we don't
allow the program to be started with a step from the menu item or
toolbar item.  (I think it can still be done with the keyboard shortcut,
but that in itself is probably a bug)

>     - there seems to be a disconnect between MDI and Auto modes with
> 	respect to feed rate.  typing different feedrate setting commands
> 	(like "G01 F5" vs. "G01 F1") at MDI seems to have no effect
> 	on the actual feed rate used by the MDI commands.  the=20
> 	"modes in effect" line of settings just below the data
> 	entry line does update with the new value, but it doesn't
> 	"stick".  the visible value sometimes resets to my
> 	maximum velocity.  i can work on a more reproducible
> 	scenario if someone needs it.

I'm pretty sure this exists in emc1 too.  An IRC discussion with paul_c
when Chris and I were planning AXIS revealed that the rs274
interpreter's idea of (eg) the S-value could be different than the
machine's, because the manual-mode keystrokes and buttons send RCS
messages like EMC_SPINDLE_INCREASE without talking to the interpreter.

One possible option here is for those particular buttons to act as
though they are entering MDI commands, not by directly sending the RCS
messages.  Paul commented something to the effect that this would lead
to "interesting data flows", but when pressed he wouldn't come right out
and say it was a bad idea.

The same discussion led me to believe that the values shown may
correspond to a later line in the file than the one that is currently
being performed on the mill, because the g-code interpreter runs ahead.

>     - as i mentioned in another thread the other day (but for
> 	completeness i'll mention it here), there seems to be a
> 	default feedrate in effect for the program, but only the
> 	first time it's run.  the default seems to be the current
> 	"axis speed" setting, which i now understand is only
> 	intended to control jog speeds.

Again, I think I've seen this on emc1, too, and AXIS won't fix it.  It's
probably a bug that the program works the first time!  Maybe AXIS should
figure out what it needs to do to make every program run act like the
second program run.

>     - the default font (56pt, i think) doesn't seem to work on my
> 	system.  one smaller (48) or one bigger works just fine.=20
> 	is there a config entry to let me permanently set the
> 	default?

AXIS doesn't use a big font for coordinate display, so you shouldn't run
into this problem.  I have the same problem in xemc on my
emc1/simulation-only machine, which is based on fedora core 3.

Jeff