Gmoccapy - A new screen for linuxcnc
newbynobi wrote: Hallo James,
I just builded a virtual machine and tried gmoccapy under buildbot.
Unfortunately buildbot does not include all the sub folders from gmoccapy, not only the icons folder is missing, also the subroutine folder, so you will not be able to execute macros in MDI mode.
May be Chris can give us a hand, finding out, why the sub folders are missing.
It seems the buildbot does include the folders and icons - it's the config picker that doesn't copy them into your local linuxcnc directory.
configpicker is written in TCL language that I find difficult to read and understand.
I will inquire about a fix on the maillist.
Today I played a bit with an ELO touch monitor and Moccagui.
Almost everything was OK, except one thing:
the Velocity , Feed override and Jogging sliders hard to tap and slide exactly in the place where its required. I mean the small button of the slider is too small to grab it with finger. That's not an issue when you use mouse, because the tip of them mouse is much smaller and you can locate it very precisely. But with fingers that was not an easy job, even when I tried to use the tip of the finger. My finger is not especially big or fat, I suppose it's normal . It was a 17" monitor and I made the mocca screen as big as I could (I used the simulated hw buttons too).
So the question is: would it be possible to make the sliders bigger or different shape?
Does anybody have similar experience?
that is the reason I export hal pins to connect MPG Wheels to the sliders.
I found exactly the same problem, because I am using also an 17" Touch screen.
If you push left or right from the slider, it will move slowly, so you can adjust it easier.
If I got a little time, I will try to build an own widget with larger "handling bar" or one with intergrated Plus minus buttons.
Here are the results from Version 0.8.9:
- new icon for btn_user_tabs
- new icon for btn_fullsize_preview
- all dialogs do react to keyboard input now
- System theme has not been set properly on start up, fixed this.
- added a new place for user tabs, within ntb_preview, showing then the tabs behind the preview, like in axis
- added a test to show actual velocity in machine units.
- added hal pins to be able to connect a hardware selection switch to jog_increment radio button
- entering the edit mode sets the focus in the hal_sourceview widget, so working with keyboard
is possible without any click
- After editing the tool offsets in table, the button "Apply" will not only apply the changes to
tool table, but also to the tool in spindle, but only if G43 is in active g-codes
- added hal pins for jogging the axis with hardware buttons for each axis in self.data.axis_list
- deleted the metric button from settings page
- changed hal_pin_names to use "-" instead of "_"
- on tool table page I missed to add tool tip text to the buttons, I added them now
- added a hal pin to unlock the settings page, so a key-switch can be used to unlock the page
The WIKI has been updated.
I think there are two aspects of the touch handling GUI:
The touch interface could provide an easier to use function for the sliders.
Don't misunderstand me, I don't want to blame anyone I am just trying to say that those sliders could be improved or changed or substituted by a solution which works better than the current implementation. It can be a bigger handle, other type of slider (for example with big enough "+" and "-" signs at the ends of the slider to push).
Or the slider can be substituted totally by one button and 4-5 feedback LEDs: LED1: 40% LED2: 60% LED3: 80% .....etc.
When you push the button say Feed Override, then you cycle the speed through the values associated to the LEDS.
Another way could be using 4 separate buttons for the predefined velocity settings and some kind of speed meter for feedback.
On the other hand in my opinion few external hardware handlers/switches are absolutely necessary in most cases beside touch, keyboard or mouse controlled GUI:
a) MPG jog wheel
b) Axis selector for MPG
c) Jog increment selector
c) Feed/Speed/Spindle override selector
The above functions are mostly available on a minimalistic pendant.
I'll test further the industrial Gscreen and Mocca GUI because I believe that they are excellent candidates to replace AXIS.
Thanks for the the effort and frequent updates!
all hal connections you asked for are already included in gmoccapy.
Here are the most important hal-pin (see also the WIKI):
4.2. Velocitys and overides
All sliders from gmoccapy can be connected to hardware encoder.
Therefor the following hal pins are exported:
gscreen.max-vel-counts (Maximal Velocity of the machine)
gscreen.jog-speed-counts (Jog velocity)
gscreen.spindle-overide-counts (spindle overide)
gscreen.feed-overide-counts (feed overide)
gmoccapy_postgui.hal offers an example connection of one encoder to a parallel port.
But we are in simulate folder so the corresponding lines are commented out and you will have to adapt the parport address according to your system.
4.3. jog hal pins
All axis given in the INI File have a jog-plus and a jog-minus pin,
so hardware momentary switches can be used to jog the axis. For the standard config following hal Pin will be available:
4.4. jog increment hal pins
The jog increments are selectable through hal pins, so a
select hardware switch can be used to select the increment to use.
There will be a maximum of 10 hal pin for the increments given in the INI File,
If you give more increments in your INI File, they will be not reachable and will also not been displayed in the GUI.
If you have 7 increments in your hal you will get following pins:
jog-inc-0 is unchangeable and represents continuous jogging
4.5. hardware unlock pin
to be able to use a key switch to unlock the settings page the following pin is exported.
The settings page is unlocked if the pin is high.
To use this pin, you need to activate it on the settings page.
So it is no problem ton connect hardware to the GUI.
I am planing to include some more hal-pin to operate the spindle and cooling, but at the moment I haven't thought about a axis selector. Until now I do activate the axis to jog, by pressing and holding down a hardware button on my hand-pendant and then move the JogWheel to move the axis, so the two hand operating is assured.
Also a jog increment selector can be build quiet easy with hal connections in your hal file, or should we have this also in gmoccapy?
Thanks for the quite extensive feedback.
I know that many hal pins are available. That's really good. I am going to try them as well.
My intention was to explain, that even if most of the manipulating functions are available from touch interface, few hardware buttons and switches are inevitable for "real" machinists. And it's very easy to do with those hal pins.
Nevertheless, if the usability of the sliders can be improved, then the less 'hardcore' operators may not need the hw buttons at all...
For those of us, who came from computer and IT business (as myself) , it's easier to use a GUI, but for people coming from machine shops I suppose, the knobs and MPGs are better.
I am now considering what type and style of external manipulators would be the best for Gscreen/Mocca as pendant or control panel.
How it's possible to make the GUI localized, I mean , how and where shall I do the translation to local language?
The question is generally about Gscreen because I suppose it's handled in the same way in Mocca.