GUI - internal code / HAL connect

This Topic:
Disable cycle start / run button until conditions are met?
forum.linuxcnc.org/gmoccapy/49281-disabl...ons-are-met?start=10
inspired me to ask this question:

Why does the control part of the LCNC use HAL signals and the GUI part of the LCNC use internal code?
Why don't both parts of the LCNC use HAL signals?

As for internal codes, I see only disadvantages.
1) nothing can be changed without interfering with the source codes
2) when there is a bug in the source codes, you cannot use HAL show for diagnostics.
3) using, editing, repairing internal codes requires very specialized knowledge
 

Not sure, but it seems that the python interface was created so users can easily create a custom GUI. Of course not everybody is comfortable working with python but then not everybody is comfortable working with Hal either.
I have never written a GUI but if I did then I'm not sure I would want to add the extra complexity of having hal connections on top of the gui code just so users can customize it more easily.
However , I presume that one could create a python gui that creates hal pins.

If you would have a GUI where all buttons have to be connected via HAL would result in a huge additional HAL file and would make it just error-prone. And remember this is only a rare use case. Compared to the other applications where the simple "fixed" solution is sufficient.

 

zz912 wrote:

Why does the control part of the LCNC use HAL signals and the GUI part of the LCNC use internal code?
Why don't both parts of the LCNC use HAL signals?


 

I've also wondered about this, but wasn't able to articulate it.

My speculation is that somone who wants some new feature or function in LCNC would find it easier to create/modify LCNC's behavior through a GUI than to modify LCNC itself.

Upside: massive flexibility and options
Downside: end-users must learn multiple frameworks (LCNC + GUI) to be able to modify GUIs or even troubleshoot effectively

I'd rather there be a standardized HAL-only interface for GUI's, but changing LCNC to this framework would be, I suspect, an insurmountable hurdle. 

All current GUIs would be broken to some extent.  And an extensive expansion of HAL components would be necessary to duplicate functions available in GUIs and passed through via python.
 

Biggest reason is because HAL came after NML. The original design required re compiling to make IO changes. HAL was primarily imagined for easy IO changes without compiling.

Also the GUI side was built with the idea that multiple GUis could be connected at one time, though that capability in practice would be/is difficult now. Networked GUIs were possible and at the time, networked HAL was not available.

I don't immediately see the advantage of HAL for machine controller internal data.
HALshow displays most of the important internal data.
How could you reconnect the internal data in a meaningful HAL way without code changes anyways.
Still would need the specialized knowledge.

Good documentation of the internal code, switching to more common/standard libraries and using more python when appropriate would be very helpful to lower the bar of machine controller development.

All current GUIs would be broken to some extent.

There is no need to break anything.
Python components can already create hal pins. So if somebody wanted they could write a hal-connectable GUI right now.

It is clear to me that there will be supporters of internal code and supporters of HAL connect.
Thanks to both parties for speaking up. I would be happy if more people would express their opinion here.
My goal is to at least think about the HAL connect path.

[HansU]

If you would have a GUI where all buttons have to be connected via HAL would result in a huge additional HAL file and would make it just error-prone.

I think quite the opposite. At the moment, Gmoccapy has the following bugs:
github.com/LinuxCNC/linuxcnc/issues/2489
github.com/LinuxCNC/linuxcnc/issues/2453
github.com/LinuxCNC/linuxcnc/issues/2448

I devoted almost a month and a half to solving them. Zero result.

I have not spent more time on any other issue in LinuxCNC. When I solved problems with Mesa cards, encoders, stepgens, parrports, switch buttons, carousel, debouncing etc. so I solved these problems relatively immediately. I was always able to test each component separately or watch it in the HAL show or HAL scope.


 

Aciera wrote:

All current GUIs would be broken to some extent.
There is no need to break anything.
Python components can already create hal pins. So if somebody wanted they could write a hal-connectable GUI right now.

Thank you.  My ignorance is generally limitless when it comes to GUIs, python, and most of the 'backstage' stuff in LCNC.

Making a GUI only based on HAL connections is very easy, as you can use GLADE and place any HAL WIDGET with drag and drob on a main window. This is just like making a Glade panel.

But a GUI does a lot more that just representing widgets.
I.E. in my first gmoccapy release (just made for myself) the spindle buttons was active all the time, as I do know, that switching off the spindle while a program is running is not a good idea.  After I published the GUI, a user mentioned a bug and claimed that his cutting tool was damaged due to my GUI. He clicked on the spindle Off button while the tool was cutting material. So I added a function to disable the button while a program is running, checking the "is Idle" status.

If a GUI is based only on hal, the user need to connect the button according to the interpreter state.
Have you ever tried that?

If you want to modify gmoccapy:
- Search for "_make_hal_pins" and add a Hal Pin
like:

add something like around line 2600:


all out of memory

Norbert