Gscreen -usability development

So Gscreen and it's variants have been used quite a bit now by some brave pioneers -even so much as on production machines.

Big thank you for feedback, bug reports and general enthusiasm!

I have done a lot of development changes to Industrial (still more to go) and neglected default Gscreen.
I am currently working on separate jogging rates for rotary axes. This has forced me to look at the default screen because of changes needed for that.

I have made some small changes in the status window to include rotary axes jog info (if required) and it led to me placing the 'spindle at speed' LED there.
It has made me reconsider the placement of manual spindle controls.

Do they need to use prime real-estate?
Could they be in a dialog brought up from a bottom button ?
I would move the spindle speed indicator to the status window.
Does anyone think they would miss direct accessibility to these buttons?

What about other controls? Is there something missing? or really clunky? or just never used?
What about slider controls? I really hate them for touch screens but that's me. Sliders would allow less clunky jogging controls.
And Shannon figured out how to use the theme to make sliders bigger.

To be fair one must remember the screens are designed for general use and for someone with no physical buttons.
If you add some physical buttons some of the clunkyness goes away.

I am looking for feedback from people who have used the control - real world feedback.

Chris M

i do not see a valid reason not to ... hitting a tab or button and to then have the spindle controls available to use ..
although I do see a vaild reason to say see rpm on the main screen , but then hit the tab or button to then be able to manualy alter ..

Yes that's the idea.
The abort button is always available and it will kill the spindle too.

One comment on the Industrial screen was that they didn't want buttons that would make the machine move on screen.
This change would allow them to hide the spindle 'dialog launch' button and easily achieve that.
It also helps with DRO real-estate for say a 5 axes machine.

Chris M

Sample pic of status window and rotary jog increment adjustment.

yes i'd agree Chris ,

it would also perhaps help later on , if for example we expanded to control lasers or 3d printers , that dont particulay have spindles
but need for example power level or extrusion speeds , this would enable expansion without upsetting the main screen
for any control of say M3 - M5 codes

Halo Chris,

you layout is getting closer to gmoccapy I like that!

I would like to get the error and other messages in a "axis" way, if you get several messages, we do see only the last one in the statusbar and after getting a lot of messages it is very cumbersome to delete them one by one.

Is there a way to delete all messages at ones and to display lets say the last ten messages?

What about buttons to home and jog a turrent?
What about a touch off dialog to calculate the rotation Z and set the pin accordingly?
We need a lube pin, that will activate lubrication after a given time period, but not switched on, only the working time should count!
A pin for maintenance of the machine is also a good feature.
There should be a pin "door-is-closed" witch will only allow start a cycle if it is high.
What about a the lovely axis feature of program property, Cycle time, etc. (helps to calculate prices)

I will surely find more wishes, shell I?

I am planing to introduce al the mentioned features to gmoccapy, but we should not make both the same work.

Norbert

Norbert

The nicest way I have seen to handle messages is the desktop notify system included with Ubuntu.
Unfortunately Ubuntu screws with it making it useless for our purposes.
You can't specify how long the messages stay up nor have multiple sent at once.

There is a fix - a PPA that restores the features. I use it and use desktop notify.

The status bar is specifically made for displaying only one message.
We could have a button clear all messages but the you could easily miss reading them.
This is another reason I used both notify and status bar.
The alarm page should have all the messages recorded as well

I personally hated AXIS's error messages, but you could replicate them by opening multiple dialogs.
Not sure if you can get dialogs to be a small as you like.

home and jog turret? Turret usually means a tool turret - is that what you mean?
Besides a button to initiate the sequence what else do you need?
Typically I would not add this button as it is pretty specific to certain machines and easy to add.
I would consider adding it to a screen made to cater to that type of machine such as Industrial.
Nobody has every asking me for it.

A touchoff dialog for rotation calculation would be useful.

lube pin - seems unnecessarily fancy. Plain timed lubing would seem sufficient. motion.in-position could be used in a HAL based system.

maintenance pin - you'd have to explain more.

Door-is-closed pin - I agree in principal, but I actually think it should be at HAL level, probably in motion. And called something more general such as interlock maybe a few pins - currently you can trick feed-hold to do this but feed-hold can be masked - No good!

AXIS cycle time - is that the estimated time or just a timer? Estimated time is usually badly out. It doesn't take into account acceleration. Particularly if very short line segments are used. Its possible he axis never gets to the set feed rate. This would need to be worked on in the graphics plotter IFAIK.

Chris M

PS

I have been happy to work with you, yet in an independent way.
I am glad we have different ideas/solutions on common problems.
Gmoccapy is a very nice and usable screen - you have considerable more artistic talent then me!
Thank you for your continued collaboration !

I personally hated AXIS's error messages, but you could replicate them by opening multiple dialogs.
Not sure if you can get dialogs to be a small as you like.

I have thought about the dialogs, but I didn't follow that up, because of leek of time. This can get my next work after finishing the touch file selection, (it is nearly done)

home and jog turret? Turret usually means a tool turret - is that what you mean?
Besides a button to initiate the sequence what else do you need?
Typically I would not add this button as it is pretty specific to certain machines and easy to add.
I would consider adding it to a screen made to cater to that type of machine such as Industrial.
Nobody has every asking me for it.

Yes, that is for a tool turret. Many of them must be homed! That is all, just start a home cycle, that can be defined with a user python file:

lube pin - seems unnecessarily fancy. Plain timed lubing would seem sufficient. motion.in-position could be used in a HAL based system.

Oh no, I do not agree at all! I have an Hekler & Koch Mill, witch need to get lubrication every 15 Minutes one impulse. Unfortunately this is done at the moment by a hardware timer and that one will give the lubrication even if the machine is just switched on, but not working! So If you go away to have a coffee and get back after 2 Hours the oil it leeking out of the spindle. I ask some customers of mine and most machine need a lube cycle after a special working time. This time should only cont while the machine is moving! Yes, it can be done in hal, but do we want to give our "customers" more benefits?

maintenance pin - you'd have to explain more.

Same as above, each machine has a maintenance cycle, lets say every 1000 hous of work, the spindle gear box must be cleaned or any other work has to be done. Profesional controls count the work time (machine in motion) and display that time and gives the user an advice that some maintenance have to be done. I want that display and user configurable messages. "Please call me and give me your money!" Professional retrofitter will love that!

Door-is-closed pin - I agree in principal, but I actually think it should be at HAL level, probably in motion.

Again I do not agree. The connection has to be made in hal, that is right, but the GUI should set sensitive(False) to certain button, like cycle start if the door is open! So the GUI must be prepared to react to that pin!

AXIS cycle time - is that the estimated time or just a timer? Estimated time is usually badly out. It doesn't take into account acceleration. Particularly if very short line segments are used. Its possible he axis never gets to the set feed rate. This would need to be worked on in the graphics plotter IFAIK.

Yes I mean the smal dialog what appear if you click File / Propertys in axis. I do know, that that is not perfekt, but in most cases it gives you a good idear:
Users who need the time in a accuracy within seconds will use a CAM to get the results.

Thanks for your compliment!
I will stay with the linuxcnc comunity for a while, and surely go on developing gmoccapy. Even if my testers are quiet quiet at the moment, there are only two reasons, they do not use the GUI any more, or they do not have additional wishes;-)

Norbert

Lube pin
Fair enough. I haven't used my machine for production work (it just did first cut) so the oiler doesn't bother me but I can see your point.
I would wonder if such options would be useful too?:
first start lube time (might lube longer when first started)
on time
interval time or distance

Maintenance message.
I think you have to be careful with this. I personally would be annoyed by pop ups telling me to call the installer for maintenance.
Just like I'm annoyed by the 'maintenance required' light in my truck cause I haven't changed the oil.

Interlock pins
Yes the GUI should be aware of the interlock status.
What I meant is the actual locking should be in HAL and realtime. eg the switch should not be interpreted by the GUI and the GUI set the interlock.
The switch should set the interlock and the GUI notice it. We should not trust interlock safety to userland programs.
Without interlocks built in to motion, there are ways to defeat it. eg cycle start is greyed out in Gmoccapy but HALUI cycle start will still work.

Cycle time.
It really depends on what kind of program you use. If the cycle times are fairly accurate for your programs great. I am not wanting to add a feature that badly lies to people who do short segment programs.
I'm not actually sure how AXIS get this info - it may be extractable from Gremlin - if you wish for it in Gmoccapy.

Chris M

Lube pin
Fair enough. I haven't used my machine for production work (it just did first cut) so the oiler doesn't bother me but I can see your point.
I would wonder if such options would be useful too?:
first start lube time (might lube longer when first started)
on time
interval time or distance

Wow this additional options would be great!

Maintenance message.
I think you have to be careful with this. I personally would be annoyed by pop ups telling me to call the installer for maintenance.
Just like I'm annoyed by the 'maintenance required' light in my truck cause I haven't changed the oil.

This messages should be user editable! It can be used, but nobody should be forced to do that. Volkswagen has just introduced a new system witch will prevent the car from starting if you do not have filled up the blue motion liquit. IMHO it is a reason not to buy such a car!

Interlock pins
Yes the GUI should be aware of the interlock status.
What I meant is the actual locking should be in HAL and realtime. eg the switch should not be interpreted by the GUI and the GUI set the interlock.
The switch should set the interlock and the GUI notice it. We should not trust interlock safety to userland programs.
Without interlocks built in to motion, there are ways to defeat it. eg cycle start is greyed out in Gmoccapy but HALUI cycle start will still work.

I do agree completely! Al security things must be on real time and where it is possible they must be hard wired! Here in Germany emergency stop has to be hard wired by law! But in case of doors the GUI should prohibit to do some actions. If the user uses halui or other methods not through the GUI to start a cycle, it is within his responsibility! He can use a key switch to work with open doors, but I am thinking about coloring the complete background of my GUI in red if the option to work with open doors has been disabled! And the user should be allowed to do that, because there are also reasons to do that.

I'm not actually sure how AXIS get this info - it may be extractable from Gremlin - if you wish for it in Gmoccapy.

as far as I checked, yxix has an own calculation in axis.py. You say to extract it from gremlin, I haven't looked in it, is there a option?

Norbert