GUI Discussion

yes if in fact u can track the thread by turning the spindle by hand, then you could roughly move the tool to a thread section then either rotate the stock to align the thread or reposition the tool in the tool holder.
Another interesting way would be allowing X and Z movement while sync ed to the spindle.

But while interesting to see if it works I think it has limited actual use.
I've done it a couple times on a manual lathe over the years.

here is another shot not much different.
there is actually two screens here - the second one would go to a second monitor or could be not shown.
I can see getting the buttons and status indicator, without clutter right is gonna take some planning.

looking good Chris ,
i'm not to sure over the spindle speed dial size in relation to the rest of the screen , althoug i appricate it's scaleable etc
i'd be tempted to have it small around the size of the dro's for example , and probably a fixed size leaving the rest of the screen usable

but it's looking exactly along the lines i'm thinking of , yes keeping the clutter out is the major headace
having a seperate screen for diagnostic listing would be nice i.e halpin listing
feed rates etc keep to the buttons as in touchy , would save space and lesser used functions

i'd say have a home axis screen from machine start , then once homed it changed to the above screen
after all until the machine is homed everything else is not needed
and a jog menu screen

i much prefer the look as it is at the moment simple screens ,
and probably split over 6 screens to cover everything
keeping the important major items to one screen

Chris,
The spindle gauge is nice looking as it adds some splash. but my thought would be to change the "Vel:" label to "Feed:" (more intuitive), and to have the spindle speed as "RPM:" just under the Feed: This is one of those 'less is more' thoughts.

What I would really like to see in the gauges (linear or dial) are load meters for each axis, with a memory tick on the dial that remembers the highest load encountered - perhaps an alarm when an overload condition occurs.

Jay

Hey guys.

The second screen is just there to prove the concept. The objects, sizes and placement are in a state of flux.
The size of the spindle dial readout is too big I agree. I just didn't adjust it. i added it just to prove out the program and to see which display is better. (there is a bar graph for spindle speed on the main page).

Jay - the labels you are referring to are part of a gladeVCP widget so I cannot change them unless I commit code to EMC (which I might later)
The option at the moment is show the readout or don't - as you can see the main display I have turned it off as I have my own DRO. (you can't see that screen in the pic)
Peak meters are an interesting Idea. either as an option to the existing meter or bars or as a separate widget. This would be code added to gladeVCP again.
I'm close to having it be able to actually do something in manual mode. then I'll add MDI It will still need to be used in tandem with a regular GUI.
Then maybe I'll post a test code for people to play with.

So we all agree a keyboard being required is not the end of the world? Even if it is, to begin with It will be required.

cmorley wrote:

..i added it just to prove out the program and to see which display is better. (there is a bar graph for spindle speed on the main page).

Hmm.. good question.When I look around I see analog dial gauges everywhere. Bar type of guages less so. That's probably historical due to how mechanical gauges are built. However I feel both gauges convey information well. I think it will boils down to a 'Traditional' style (dial) vs a 'Modern' style (bar)

cmorley wrote:

..part of a gladeVCP widget so I cannot change them unless I commit code to EMC..

And therein lies the big issue. To build out a modern controller is no small task. I've been pouring through the AXIS code recently, and I see redundant code, scattered code, and just plain lots of code. None-the-less it has a LOT of features, things that fall outside of a common CNC controller and more into experimental or University uses. Things like joints, complex kinematics, full 9 axis, and I hear multiple spindle in the wish list. Terms like Max Velocity - nobody says that, in the CNC world it's feeds and speeds (feedrate and RPM). Personally I think EMC2 has enough capability in the back-end, and with the right team doing add-on development - to run something like Big Dog




You know it's exciting to work with this capable of a program, it reminds me of my University days when we were writing a control system to power a Golf Cart with a Ballard Fuel Cell.

As for front ends,
AXIS tries to be all things to all people - it caters to all of the above type of uses. To maintain that kind of application requires a real team effort, good architecture and good modularity. I went into the Sourceforge Tracker to see the outstanding bugs and feature requests, many open ones go back a couple of years. I think our development team is taxed out.

This begs a futher question, do we encourage folks to contribute to the main GUI, if so perhaps to modernize the look and feel and code structures to attract more developers, or do we start building purpose-built front-ends for specific machine types. Hmm.... now that I think of it, this is open software, so we do both!

cmorley wrote:

So we all agree a keyboard being required is not the end of the world? Even if it is, to begin with It will be required.

I think it's fundamental

Chris, I think you're doing good work putting this together - no small feat!

Jay

Andy thanks for posting video- that is exactly what i was talking of. Very cool !
I wonder how difficult to have EMC respond to a Z handwheel during threading then you wouldn't have to move the stock.
Something to play with in the future.

Jay
If I knew one could do stuff like Big Dog in college when I was younger I woulda been in heaven!

Yes Gscreen as it stands in default will only display for 4 axis plus spindle.
I will try to keep the under lying code capable of more axis.
The long term idea is that a user can do small tweaks by changing the glade file, or
by writing / editting a python file do major changes.
By adding these two files to their config folder then it would load automatically.
I had done something similar to Touchy (just the glade part) at one time but the developer didn't like the idea
So now I\ll try to make my own.
i am purposely writing about it here so user that are interested such as yourself may have some influence.

That is my dream goal anyways
If I can't / don't finish it i will post the code so others can continue to play.

I now have the Estop button working - it funny how exciting it is to push Gscreen's estop button and watch the AXIS estop change.
In Gscreen the estop button will turn the machine on as well, os either estopped or machine on.

KPA wrote:

Terms like Max Velocity - nobody says that, in the CNC world it's feeds and speeds (feedrate and RPM).

Jay

I think the reason you see terms like this is because most of the developers are programmers first machinists second.
( Not to say they are not good machinists understand )

This is why for instance EMC has a non standard threading behavior. ( you must calculate the hypotenuse on tapers )
While technically if gives more feature , no machinist is going to think that way !
Thread pitch is measured parallel to an axis not parallel to the angle.

But if they weren't programmers then there wouldn't be EMC !