GUI Discussion

Hi all,
I'm currently working on converting my Bridgeport Series II Interact II and having fun with it. However the single biggest issue for me is selecting the right kind of GUI to use. My prior controller experience is Fanuc and Fagor so traditional type of controllers. I was looking for something similar in the EMC2 family and found many, but none that really stand out. Axis and Touchy as we know are the popular ones. I also see folks talking about writing new GUI's. Axis is full featured, but too mouse dependent for my taste, Touchy is a great start.

What I do find exciting is the recent developments incorporating Glade and the possibilities it brings. We have a deep investment in the Python/GTK approach vs QT so using Glade is a natural progression. What I don't know is if Glade and GTK is robust enough for an elegant front-end.

I myself will use the Axis interface to start simply because of the feature set. But I've updated the icons slightly to make it a bit more keyboard friendly (though the Zoom In and Zoom Out don't have any keyboard shortcuts to load into the icon).



I'm not entirely convinced that a new GUI needs to be written from the ground-up. I suppose that depends on how locked down the current designs are.

BTW I've included the icons (both gif files and GIMP files).

Jay

Hey John,

The next wave of GUI design is Touchscreen technology, where we replace the mouse with a finger tip. We see it in restaurants, in hospitals, on our phones. Even Windows 8 will be touchscreen centric. Imagine swishing around our Axis backplot with our fingers, or zooming in on it with multi-touch.

Touchy is a step in the right direction, but we need to take it further. Axis has a lot of what we need to run a machine, we just need to clean up a few things, add a few things, make it touchscreen friendly and between that and a few hard controls we would have a pretty good control system.

The keyboard will always have it's place, but whether it's physical or on a touchscreen is sematics.

If we took all the great effort of folks working on different GUI designs and came together to work on a common design/architecture we could really put together a winner!

Jay

..beyond Touchscreen is Voice / Smart Systems

I've just started playing with a screen using GTK for touch screen or physical buttons.
I'm hoping to make it quite configurable but at this time am just flushing out basic look and usability.
No idea when or if it will get done.
This is using GTK theme to change the look. You can actually use this theme with Touchy.
I've used a Heidenhain DRO and always liked the soft keys so am trying to go that way.
Here is a pic of it. I'm trying to decide where to put spindle output and whether it should be digital numbers or graphical.

opinions - What is must useful info to show while in auto mode? manual mode?
Lathe vrs Mill ?

Chris,
I agree that the soft-key menus around the screen are the way to go. They provide access to many more screens with a minimum of clutter. Consider it the foundation of the GUI. I tend to take my que's from Fanuc, but you can look at any of the modern controllers from Heidenhain, Siemans, etc. and see the same framework.

Being in the software game myself (day job - not in programming but involved with data), we tend to start our designs with a functional design, then move into GUI design coupled with usability analysis (on a good day). But that's a lot of work, and OK if you get paid for it. Us volunteer folks need to cut to the chase, so I shamelessly review the other major vendors apps and try to cobble together a design based on what seems intuitive. Not exactly a copy, but certainly use any good ideas. - Do you wonder why they all look the same?

The added benefit to this approach is other machinists coming off those controls onto EMC2 will feel more at home with a control that's close to mainstream designs.

One last point, I try to keep the screen designs lightweight - just a simple sketch or drawing (storyboard) else one invests too much in the artwork and are more resistant to change during the design cycle. So the approach becomes:

1. Functional Spec - usually a doc or .xls with lots of points organized by category. This also forms the beginning of the user/developer documentation.
2. Peer Review - good ideas come in and not-so-good ones get dropped or deferred. Also scoping occurs, what functionality is done first and which are done in later phases, etc.
3. Storyboard GUI - initial design 'straw dog' where it all comes together.
4. Peer Review - more of the same (really this is throughout all steps)
5. Application Architecture - this just doesn't start here but becomes very important. This is where the Design Architect and Application Architect duke it out in a closed room and we see who wins!
6. Screen Design - where the artworks starts, stubs are written
7. Build out the code
8. Test, etc. etc.

When I first got into the game and saw those large 3 ring design binders from IBM, we thought they were the cat's meow, until we started seeing more of them shelved due to cost overruns. Over time development approaches and PM methodologies improved, now Agile is all the rage.

Jay

KPA wrote:

Being in the software game myself (day job - not in programming but involved with data), we tend to start our designs with a functional design, then move into GUI design coupled with usability analysis (on a good day). But that's a lot of work, and OK if you get paid for it. Us volunteer folks need to cut to the chase, so I shamelessly review the other major vendors apps and try to cobble together a design based on what seems intuitive. Not exactly a copy, but certainly use any good ideas. - Do you wonder why they all look the same?

The added benefit to this approach is other machinists coming off those controls onto EMC2 will feel more at home with a control that's close to mainstream designs.

Jay

I did notice most are a similar design and helps to make it intuitive for pros.
I also would like to come up with a frame work that others can modify to change the look/function dramatically.
We will see what happens.
I'm thinking that utilizing a second monitor for say graphical output and maybe machine status may be interesting.

Thanks for the pointers!

Chris M

Chris,
i'd say digital numbers for spindle , shown as a seperate window similar to DRO's
certianly be interested in throwing ideas in and trying it .

cmorley wrote:

..I also would like to come up with a frame work that others can modify to change the look/function dramatically.
We will see what happens.
I'm thinking that utilizing a second monitor for say graphical output and maybe machine status may be interesting.

Chris,
Using two monitors is pretty impressive thinking, very creative! It reminds me of the old autocad days where we would have the graphic on one screen and autocad commands running on the other.

For the framework, my two cents worth are to review the other major control vendor designs and identify those attributes that are similar across them, that standardize them. Going from memory that would be:

- softkeys at the bottom and right edges
- main screen a summary screen, like a dashboard containing panes of key information. Any of those panes are expanded upon in other screens
- similar colors
- similar function sets or groups e.g. spindle group
- similar soft keys and hard keys
- contains a backplot or 3D verify. The latter being a commercial product I believe.
- group layout - what works and what doesn't

Some of that may be more restrictive than folks want. If we start to collectively create a framework I would offer:

- Touchscreen and keyboard friendly. (In my view a touchscreen replaces the mouse, the keyboard will always be around)
- Softkeys or tabs at bottom and right edges. Each jumps to a screen
- Define a minumum set of required hard keys - I strongly agree with this point in the original design intent of Touchy - for safety sake. I still like proving out code with my hand on a feed override dial, with the Cyle Stop button right next to it.
- Expose Icons for the softkeys/tabs for easy artwork
- Theme aware
- Functional group code hooks exposed (API) where end developers can pick from to build their screens, ie. spindle group, dro group, axis group, etc.
- perhaps a minimum set of prebuilt screens covering Auto, MDI, Tool, Diagnostics

I don't think there's anything new here, anyway this is a start, I'm sure there are a lot of other folks smarter than me who have valuable input here.


BigJohnT wrote:

..I mounted a monitor (not touch screen) on my lathe and hung a keyboard below with a place for the mouse. Other than the mount being a bit shaky it works well as I find I use the keyboard and mouse a lot when programming at the lathe. A touch screen for me would not work as it would be too slow to write g code at the machine. Even using ngcgui I need to mouse, tab and type in numbers so I don't know how this might work on a touch screen. Just some rambling thoughts at 7am...

Valuable insight - Agreed, coding on touchscreen alone would be aggravating. If the technology slows us down, then it's the wrong kind of tech. My preferred solution is touchscreen combined with external keyboard, and essential hard controls.


Jay

When I ran a cnc lathe many years ago it was originally punch tape run but was converted to download from a separate computer.
Writing a program at the machine was not practical - you would do it offline on the other computer, but small edits i would do at the machine.
So this is of course how I think now I could endure touch screen editing for small changes but would want a keyboard for large program creation.
i would think most use cam rather then programming on the actual machine? Anyways allowing either way should not be a big problem.
I don't like a mouse on a cnc.

The two screen idea makes the screen less crowded and to the point. one would be touch the other just for status / backplot messages.
but that would limit the screen to dual screen computers not sure how popular that is.
Again that sound be easy programically to choose one or two screens just not easy screen building wise.

I am using glade which can leverage gladVCP components.

One thing I am thinking of is what buttons or displays are needed basically al the time.
ESTOP is important - is machine on and ESTOP needed or can they be combined?
Cycle start - that could be in hardware or on the screen
separate feed hold or toggled with the cycle start button?
The DRO should be seen almost all the time, coordinate system, tool number
Axis selection - you can see the button beside the DRO in my sample they are axis selection buttons

I'll see if I can post some OEM screens.