Welcome to LinuxCNC.org

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:
Chris,

That is pretty neat!

I wonder if there are some screen shots out there of commercial touch controls to compare to?

I like the idea of rolling your own screen to suit your needs exactly.

As for RPM the set speed with a green indicator that your actual speed is close enough might look good. Digital numbers might jump around too much and be distracting.

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...

John

cmorley wrote:
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:
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.

Here is a web site that simulates OEM screens:

fanuc:
www.swansc.com/en/cnc/fanuc21im.htm

cmorley wrote:
Yuck! those are ugly...

John

That site has been out there a while. I remember using it many moons ago before I picked up my first CNC Mill and CNC lathe. GE/Fanuc used to sell a DVD called Fanuc i-Docs that contained electronic copies of all their manuals, though not sure if it's still available.

Here's a few more links that provide additional material on the Fanuc Series 30i/31i/32i. There are many others if you google on Fanuc 30i

http://www.eagleeyecnc.com/manual/fanuc.pdf
http://www.cnc1.com/Content/FANUC_CNC_Standard_Features_and_Options.asp
http://www.cnc1.com/Content/FANUC_Brochures_and_Specs.asp

Heidenhain also contains documentation on their controllers on their main web site


.Jay

BigJohnT wrote:

fanuc:
www.swansc.com/en/cnc/fanuc21im.htm[/quote]

Yuck! those are ugly...

John[/quote]

I agree. I am more interested in the intuitive functionality of the screens.
Just scanning for ideas.

the one I posted was Fanuc but the site has many more.

looking at the heidenhain cnc pilot control
here is a link to the brochure ( it's too big to post)
www.heidenhain.de/doku/cncpilot4290/html...x/N10431/N10431.html

most of the GUI is about programming.
But this is the style I'm roughly basing things on at the moment.

I was reading about recutting threads. I wonder how difficult it would be to get EMC to be capable of that.
I also wonder how often it would be used.
C axis machine interests me too.

KPA wrote:
I think the Glade/GTK framework is robust enough to do that, and some folks like for instance Norbert Schechner, are venturing doing standalone applications solely based on that.

A major piece is the - undocumented - gremlin preview widget - while it seems to work fine, I have no idea as to what would be missing if anything to replace the Axis preview and live plot.

I would guess a Glade/GTK/Gremlin based Axis-like application would be more easily customized and extended as Axis stands now. Personally I am usually lost in a comment-free maze of layers, TCL code, undocumented widgets, and a control flow which is very hard to follow for me.

- Michael