Building New GUI

I'm in the process of configuring LinuxCNC for a press brake, that's been upgraded with all new PLC control and MESA based IO.

Now I've spent quite a bit of time manually coding and hacking configs, I'm starting to really understand the mechanics of LinuxCNC, and where I want to go with the config.

To diagnose various issues, I've gone back to basics, and built a simple DRO based UI using PyVCP, along with a very streamlined (and I think fairly optimal) HAL config. This is loaded with halrun, so I'm not using EMC within the config - all purely HAL.

I can pretty much get away at this stage of using PyVCP, but I'm wanting to add more UI functionality (like tools for calculating bend radius, or means of running sequences/bend programmes).

I've given quite a bit of detail of the machine in other threads, but in short, there is an axis for controlling the beam of the press brake and a read-only axis that gives back the position of the beam. There's then a backgauge, that in the future will have additional axes. The backgauge and its axes are Cartesian, and could be controlled via EMC with trivial kinematics (a few hacks needed given some of the axes are parallel).

But, for now there's only one backgauge axis, so EMC isn't necessary... And whilst the beam axes also have virtual "waypoints", that need to trigger certain things, they're better off in nowhere near EMC, and instead I can use HAL logic (or maybe ClassicLadder) to build that out.

Long term, I see the use of EMC to control the backgauge, and then other HAL logic and Python scripts controlling the beam and positioning calcs. Being so hybrid, kind of makes sense to have a custom UI!!

So, in building a more elaborate UI, I'm torn as to what direction to take. I'm hitting limitations with PyVCP (I need to have more programmatic control over the UI), so I'm trying to evaluate what the best approach is. I'll likely use Python in the user space for things like bend solving tools (give it a material thickness, type and Vee size, and it spits out the positions the axis should be in etc) and this will allow me to separate controllers from the view...

But, what language and what UI framework should I start with, or existing UI should I start/hack from? I've read that AXIS is a mess under the hood, and see quite a few starting with Gmocappy. The examples with LinuxCNC also have a few more left field combos, and of course there's commercialised implantation (ie PathPilot).

I like the XML approach for building UI as is used with PyVCP - is that just PyVCP or are TK interfaces built like that in general?

I'm happy enough using Python (more of a Ruby fan personally, but built enough stuff in Python), so Python plus TK seems a good start.

In terms of integration with HAL (i.e. passing pins back and forth), is that a good combo, or is there a framework/libraries already about to save a lot of the work (like with the Python userspace module)?

So, if starting from "scratch", what's the ideal combo of language and UI framework to work with LinuxCNC, or if better to hack an existing interface, what's the best one to work with?

Thanks!

gladevcp uses python to control GTK ui widgets.
It is extensible by adding python 'handler files'

Gscreen and Gmoccapy use a modified version of this for their screens.

linuxcnc.org/docs/2.7/html/gui/gladevcp.html

and yes you can add this with the python HAL usrspace library - again this is what gscreen and gmoccapy do.

Chris M

Have you looked at Glade? That is what Gmoccapy and Gscreen are built with.
linuxcnc.org/docs/html/gui/gladevcp.html
And a small tutorial.
gnipsel.com/linuxcnc/gui/index.html

Thanks Chris & Todd, just the answers I was looking for!

I was screwing about with Glade (with Ruby) on Mac OS a couple of months back - it was mostly for building UI for non realtime montoring (i.e. SCADA for ModBus devices) that was multi-platform (i.e. solely Mac & Linux . I didn't get far with time constraints, but liked what I was seeing, which is reassuring.

I'm keen to integrate the UI with some server based backend services - mostly for centralised storage of bend sequences, pictures/videos of the bending process etc. I can scan an job sheet or part number, and it will bring up what I need. This obviously introduces the unreliable non-realtime world into the realtime world - so where am I best putting this code? In the UI layer, or even in the Python userspace? I don't need it to affect HAL, if anything I just want to load a CSV/XML file with bend sequences into an MDI of some kind (not sure if it'll be G-Code or custom). The other stuff could just be an embedded web browser that the UI simply opens with a URL or the bar code scanned sequence. And the idea is the content will be consumed inbetween bending, so watching a video of the bending or browsing web content shouldn't affect things!

True! Definitely makes more sense now!

Dumb question maybe, but what is the difference between running via halrun or linuxcnc?

It would appear that linuxcnc is driven by the .ini file, and in turn uses that to generate the relevant hal commands needed to setup the environment. So for example, loads the corresponding user hal files, sends hal commands to load the UI (with whatever additional parameters are there), sends hal the commands to wire up the motion, kinematics etc components using the axis and parameters defined in the .ini file... From what I gather the rest of the .ini file is then used for variable substitution in .hal configs.

It seems to just benefit then from having a UI based config loader, making it easier to select configs. So, if I'm not using the functionality of the motion/kinematics components (motion control, trajectories, etc), would my app still working using linuxcnc and the .ini file? If so, what should I *not* be putting in my hal file if linuxcnc will be generating stuff using parameters in the .ini file? For example, if I'm using userspace Python or ClassicLadder for logic (or maybe just driving stuff from the UI). Then again, I suppose probably best off not using linuxcnc in those scenarios, but understanding why is key here!

So, using halrun, it appears to be driven by the .hal file, and in turn uses the .ini file (if present) for variable substitution only. From what I gather, I can put all of the motion, kinematics, UI component config, and anything else needed into a .hal file and run that using halrun to give me the same environment as running linuxcnc with an .ini file would give...

What I'm getting at, is that from what I gather, the difference between hardcoding everything in a .hal file for use with halrun, and using an .ini file with linuxcnc, is that the latter auto 'wires' everything together using the parameters given, whereas the former requires you to manually wire it together and choose the right components...

One thing I've seen mention of in the docs, is NML, which appears to be a messaging system within linuxcnc. Looking at io and iocontrol, I'm not sure I see a point, as they could be controlled directly via the UI layer (so not under strict timing anyway). Ditto with halui, but I'm guessing this links back to NML, and the ability to operate IO via messaging, versus direct HAL pins hooked up to the UI.

I'm struggling to find anything that explains all of this!