Hello Guest it is April 23, 2024, 06:51:12 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - washcomp

Pages: 1
1
Feature Requests / Keyboard translator
« on: May 12, 2008, 08:43:39 AM »
In my case, I use a keyboard emulator to interface my control panel to MACH.  In order to convert some of the keystrokes to MACH friendly versions (so I don't have to substantially modify the standard screen sets), I use Les Newell's "Keygrabber" utility.  It would be helpful to have a "front end" translator built into MACH to accomplish the same function without the use of an external utility.  Just a coulpe of columns of "if MACH receives this stroke -> interpet as that stroke" to allow the ASCII character set to be used based on whatever gadget is creating keystrokes.

Regards,
Jeff



2
I just dusted off my mill after a couple of years, downloaded the latest MACH3 and started to test to make sure everything was OK.  I have an MPG pendent that I built which has two rotary switches. These go into a keyboard emulator (IPAC) then into KeyGrabber (utility software) to pass the appropriate keystrokes to MACH3.  I modified the 1024 standard screen set as follows:

Note:  I'm set to Imperial units

MPG X axis    <ALT X>    OEM Code 259
MPG Y axis    <ALT Y>    OEM Code 260
MPG Z axis    <ALT Z>    OEM Code 261
MPG OFF       <ALT T>    OEM Code 276 (Which I use to turn MPG on/off)

All of the above work, so the scheme is fine
Now the problem is with the rosolution:
.01           <ALT U>    OEM Code 267
.001          <ALT V>    OEM Code 268
.0001         <ALT W>    OEM Code 269

The above values were taken from the standard settings (or at least how I interpeted them) from MACH3 default configuration.

The MPG is calibrated to 4 clicks per detent

The problem:
Regardless of the setting I choose for the resolution, I seem to get about .0014" movement of an axis for each click of the MPG.  I also have a joystick set up and I get the same result from the joystick on step mode (actually, the joystick sometimes steps and sometime not, the MPG always steps.  When the joystick does step it's the same about .0014".

I have not been auditing the group for a while, so if this was addressed before, I appologize.

Any ideas about what's going on and how to fix the problem would be appreciated.

Jeff

3
I think we should have a discussion to decide if there are benefits of certain screen design philosophies compared to others.  A beginning few possabilities come to mind:

1)  Is there an advantage to a "modal" design (like Mach Lathe, or the mill one I posted) over an all-in-one design?  Is an all-in-one design the way to go?

2)  Are square buttons advantageous over rectangular ones.  Are other shapes beneficial?

3)  Are graphic images on buttons superior to text?

4)  Is there an optimal list (or maximum number) of desirebale screens.

5)  Is there an advantage of using certain colors and backgrounds to increase contrast and ease of use.

6)  Is is important to maintain consistant formats and locations of functions from screen to screen?

7)  What are the important functions to include on each tool's screen set (plasma, mill, router, etc.)?

There are probably many other factors which I have not thought of, but I think the above might be enough to start a conversation concerning screen layout practices.

Once we've decided what makes the most sense, then the best way to approach creating screens to implement these practices can be decided (and maybe assisted by Art if required?).

Regards,
Jeff

4
Works in progress / Development screen set from about a year ago
« on: April 26, 2006, 07:42:10 PM »
This is a screen set that I made up about a year ago to test concepts of screen design in MACH3.  It used the premise that a "modality" function might be advantageous.  Each screen is called from the main screen (sort of the way that the Newfangled Wizard set and the Lathe screen work today), however the keyboard function keys (other than F1 reserved for HELP) should move you from screen to screen.

Yes, I know that some of the graphics are a bit disjointed (a few different software packages used for buttons [some even labled "DEMO"]), but the attempt was to see if I could reduce the required real estate and make the screens intuitive.  An attempt was made to have similar functions fall in the same positions on different screens.  The black background was to increase contract with the buttons.  The coolant configuration was to see if a small, but recognizable method made sense.

There is a lot going on in the "off the screen" area, so these are best viewed at 1152x864 (or to take them appart in Screen Designer).

Hopefully some of the design concepts will be useful to this new crop of screen designers (I felt very lonely back then).  I would also welcome constructive criticism (other than to point out the obvious fact that some of the graphics are a bit weird and out of place).

As I pointed out in past posts, there was no requirement to copy the way things had been done in the past.  and I figured I'd break with tradition with some of the concepts.  I'm curious what you guys think.

Regards,
Jeff

Pages: 1