re: CNC keybd usage was RE: more R,P,Y axis conventions (rotary)

Hi Ballendo and the list,

Hope everyone and their families had a good Thanksgiving!

See below!

ballendo@... wrote:

>
> Alan,
>
> (snips, inserts below:)
>
> >Yep, decimal key. Bad thing? at this "main" level, it can't do
> >anything else! Alias to either '.' or '>'. I'm open for
> >suggestions.
>
> Bad thing? Depends on the "structure" of your program and your
> beliefs about operators (your users). If you feel it is not confusing
> now, or in the future... OK. Personally, I don't like to mix "move"
> keys with "data" keys... And I like keys to be used for ONE thing, if
> possible ("soft" or "function" keys, properly used, are an
> exception). More so if the "one thing" is a commonly used thing! Like
> a decimal point.

I take your point. Perhaps the left and right shift keys should be used
instead. Slightly complicates the top menu loop, but only slightly.
This function needs only a simple (low speed) key detection as do other
"menu items".

The structure of the program is preliminary. As a "test bead" to try
out bits of code, I purposely did not write a "full screen interface".
The other (CY525) program I alluded to has a "user interface" consisting
of menu objects, dialog boxes, entry boxes and so forth. If I "grow"
this program into a full controller program (PC), I will use this
interface (text screen in DOS).

The original "target" for this code is/was a hand held computer, with a
limited, 2 or 4-line LCD interface. Clearly the two interfaces are
different, and require different schemes. The full screen interface is
obvious to me, the constrained LCD interface requires more thought.
Even the 256x320 graphics screen (GUI) I also have available for a hand
held requires a different interface. It's closer, but requires more
effort due to the reduction in screen area from a PC.

This test code currently has two levels of "command loops". The "main"
level, where absolute and incremental "commands" may be issued, and a
"jog" level, where the jog keys (common keys) function, and currently
also the panel encoder. For the hand held computer, dedicated keys are
available for the jog keys. I have 20 keys available, so it shouldn't
be difficult.

>
> Specific to your program, I still don't know if you are implementing
> the increment as a list, a user-defined entry, or both?

To set the increment value, a "menu selection" prompts for a numeric
value. Currently in the test code, an 'I' does the selection from the
top level. Similarly, to command an absolute move, an 'E' is pressed, a
value entered, and the move completed. I dislike using "letter keys" to
effect "menu" functions. BUT, they are easy to cobble up for test
code. All but the jog keys and a pair of keys for the increment will
probably be menu items. I suppose the + & - increment functions could
also be menu items.

With the "re-discovery" of the phase settings for the 'Y' axis, and the
removal of an unneeded sign change in the scaling parameters, I now
appear to have the rotary table turning in the proper direction, and the
proper sign!

>
> >Setting the increment is an "entry string", a '3'. As is the
> >absolute position command.
>
> So this will set the increment to 3 inches, or 3 degrees depending on
> axis selected ?

Yes, a "dual" mode, if you will. The difference is the scale that must
be used, 80 for degrees, or 8000 for inches. Shifting to degrees for
positioning the rotary table seems useful. Are there any other "modes"
that might be useful? I currently do absolute, incremental and jog type
moves. And I'm thinking of adding expression evaluation to the current
"numeric entries" of absolute and incremental. So one could type in
360 / 5 for an increment entry, thus giving the required 72 degree
step.

Alan