gmoccapy/hal_bridge -allow hal_bridge to call macros in gmoccapy

[c-morley]

This is a proof of concept to allow 3rd party (hal_bridge) to call macros. The macros are run from Gmoccapy so no timing problems should occur and and pre checks or post changes can be covered.

There needs to be agreement on where to put macro definitions in the INI. Gmoccapy puts them under [MACROS], iniinfo under [DISPLAY] python ZMQ module package must be available for this to work

[hansu]

Sorry I haven't managed yet to set up my computer after the move...

[c-morley]

No problem - I moved a few months ago - ya what a pain :)

@zz912 this might be interest to you too.

[zz912]

@zz912 this might be interest to you too.

I've looked at this PR in the past and didn't understand what it's exactly good for.
If I understand correctly, zmq is something like NML, but more modern and widespread.
I don't use macros in Gmoccapy, but if you want, I'll be happy to help with testing, whatever zmq is for. I use halui mdi_commands.
My findings:

• you added something to Gmoccapy, but you didn't add anything to the manual http://linuxcnc.org/docs/devel/html/gui/gmoccapy.html
• you chose gmoccapy_right_panel.ini as the sample configuration. I think that Gmoccapy has some unnecessary sim configurations and this one is one of them. I don't think anyone will look for a sample for zmq here.
• does zmq cause mode switching? MDI, MANUAL, AUTO If so, it is necessary to solve the problem of hiding this effect. In Gmoccapy, the mode change is more noticeable than in other GUIs. For example like this:
  Gmoccapy-integration halui MDI commands #3441

[c-morley]

Thanks for looking

This is a different use of ZMQ then the previous pull request. This uses GSTAT between the ZMQ messages and the GUI.
Here a separate program,halbridge runs and sends messages to GSTAT AND GSTAT sends them to the GUI.

1. it's a proof of concept, not a finished pull request. I am looking for input before putting more effort in.
2. i choose the config because it has gkadevcp panels in it to make sure no bad interactions showed up. If everyone is happy, we could add the halbridge entry to all configurations.
   3)halbridge only sends a request to gmoccapy, what happens is up to the code in gmoccapy. In this case I checked for MDI mode and errored if it's not in it.

MDI commands would be easy to add. Halbridge already looks for them. One would only need to add code to gmoccapy to run them.

[c-morley]

I'll try to find time tonight to add mdi commands to make it worth your while 😀

[zz912]

O still dont understand what this PR is good for. Could you give example, how should I test this PR? For my understanding. Mayby this PR is over my programing skills.

[c-morley]

Look here:
https://linuxcnc.org/docs/devel/html/gui/qtdragon.html#_hal_bridge

Similar to halui but without the timing and mode change problems.

[c-morley]

To be clear, this code only covers running macros. Jog rate and increment rate are not coded.l yet.

[zz912]

So if I understand correctly:

• you made a new HAL component bridge (in the past)
• the HAL component bridge is based on zmq technology
• the HAL component bridge contains HAL pins, based on the chosen GUI

I think this component would deserve its own page like halui:
http://linuxcnc.org/docs/devel/html/man/man1/halui.1.html

Will there be some common HAL pins in "bridge" that will always exist?

What is your goal?

• will the HAL pins "gmoccapy.xxx" disappear? With "bridge.xxx" replacing them?
• will "bridge" replace "halui"?

I would say it's a lot of work to rewrite everything, but it would unify all GUIs a lot.

---

Next, there's the question of whether it wouldn't be possible to unify macros and halui.mdi-command.

now:
macro - has no HAL pin and has a button
halui.mdi-command - has HAL pin and has no button

There would only be bridge.macro-cmd with some switch whether the GUI should create a button for this macro. I sometimes use halui.mdi-commands that I don't want the operator to be able to run.

---

3)halbridge only sends a request to gmoccapy, what happens is up to the code in gmoccapy. In this case I checked for MDI mode and errored if it's not in it.

I need to run halui.mdi-commands from manual mode. This is ATC control.

---

Which GUIs use bridges?

[zz912]

@Sigma1912 this might be interest to you too.

[c-morley]

Qtdragon now can use hal bridge. Seems to work fine. It also allows external axis selection and reports jog rate and jog increment.

I didn't quite get the mdi command code in gmoccapy working quite night. Probably tonight I'll finish it and push to this branch.

[Sigma1912]

As somebody who would like to keep Gtk and Qt based guis separate I'm somewhat weary of requiring the QT library just so I can have a separate component give me functionality that I could have by creating the pins in Gmoccapy in the first place.

[c-morley]

This does not add qt libraries to gmoccapy.

The idea is to have a more universal fix for the ongoing problems of having every GUI need different pins for the same thing. Also it allows programs to share states that are otherwise not available. For instance HALUI has no idea of jog rate, jog increment or axis selection of the GUI and you can not get that info from linuxcnc's status because there is no such thing. Also for instance It might be nice for a glade vcp panel to know what the current jog rate and selected acts is. This would be available thru hal_glib (aka GSTAT)

[c-morley]

Ok this adds INI MDI command running in Gmoccapy (thru hal bridge),
The MDI commands must be under heading [MDI_COMMAND_LIST]
I added a couple commands to the sample config for testing.

[Sigma1912]

This does not add qt libraries to gmoccapy.

While this statement is not wrong it is also not really true either. You know as well as I do that this is part of a larger strategy to remove as many of gmoccapy hal pins as possible and replace them with a service shared with your QT based guis.
#3504 (comment)
If this service uses the QT library (and your 'hal_bridge' component does) then gmoccapy will no longer be fully functional without QT as it can simply no longer access those hal pins.

I'm not the maintainer of Gmoccapy, so it clearly is not my decision to make but I think it should be clear that this 'unification' will make ALL affected guis dependent on QT.

[c-morley]

You don't have to remove Gmoccapy's pins. Might want to in the long run, but it's not required.
hal bridge uses qt as I'm most familiar with that at the moment - it could be rewritten in GTK.

While I understand not wanting (as a general rule) to mix gtk/qtin gladevcp/gmoccapy, this idea that qt cannot be used in any way, in any part of linuxcnc that gladevcp code connects is just too hard of a line.
If suddenly qt fell off the earth, we would just rewrite hal bridge or create a new program or add ZMQ to HALUI etc.- no different if NML disappeared.

irrespective of all that, how about we try this code and see if there is any technical problem with the idea.

[zz912]

Hi Chriss,

You don't have to remove Gmoccapy's pins. Might want to in the long run, but it's not required.
hal bridge uses qt as I'm most familiar with that at the moment - it could be rewritten in GTK.

I think you're missing the concept of what you're trying to do. Rewriting Python2 to Python3 was a lot of work, but it was done. I was involved as a tester here.

I'm not the one to decide. If we remove Gmoccapy's pins and replace them with bridge, I have no problem with that.
I understand that now we need to test whether the zmq technology is functional and suitable for us.
I understand that there will be a temporary time when gmoccapy pins and bridge pins will coexist.

It's already annoying when integrating Gmoccapy, I have to connect something to gmoccapy pin and something to halui pin.

I like the document:
https://github.com/zz912/linuxcnc/blob/d18322a81fd526cb625781bfdaed55c398e03f02/docs/src/gui/gui-dev-reference.adoc

Make a PR where you propose the future of GUI in LCNC. It will be easy to follow future developments.

Zdenek

[c-morley]

It's already annoying when integrating Gmoccapy, I have to connect something to gmoccapy pin and something to halui pin.

Yes I agree, it's a hurdle for users. I actually wanted to just add ZMQ (through a python instance) into HALUI. It would have been the easiest integration for users. I just don't know anything about setting compiler/linker flags to work on that code. Maybe if I got some help, then I could remove hal bridge.

I like the document:
https://github.com/zz912/linuxcnc/blob/d18322a81fd526cb625781bfdaed55c398e03f02/docs/src/gui/gui-dev-reference.adoc

I understand, and will if/when it's all confirmed and figured out, but right now we are still 'hammering out' the details (and testing)

[c-morley]

So I went in a different direction and added the zmq messages to halui to be more universal.
This is in a different testing branch:
https://github.com/LinuxCNC/linuxcnc/tree/python_halui
There are three proof of concept sims:
axis_halui_test.ini
gmoccapy_halui_test.ini
qtdragon_halui_test.ini

They will load the respective gui and a separate simulated control panel.
You can notice the jograte slider on the control panel changes the jog rate on the gui.
I would love it if someone could test these rough changes.
I will add a daft pull request if there is interest in discussion.
The new branch work would supersede this branch.