ZMQ messages from HALUI to GUIs

[c-morley]

This is the on going work started here:
#3528
This generalizes the idea for messages.

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.

[zz912]

Hello,

I made basic manual tests for:
axis_halui_test.ini
gmoccapy_halui_test.ini
qtdragon_halui_test.ini

Everything works as I would expect. I was able to make it go into unexpected states by accidentally clicking on it, but I don't think this panel would be expected to be robust enough for regular CNC operation. These unexpected states were not related to the zmq technology. I would rather say that the external control would need to include more of the functions provided by the GUI, or more Panel-GUI cooperation.

I don't understand what "dialog control" is for.

I tested it in all GUIs, but it doesn't do anything.
In AXIS it just prints it in the terminal:

GUI OK command called
Write Msg called
[HAL bridge][DEBUG]  Sending ZMQ Message:STATUSREQUEST {"FUNCTION": "request_ok", "ARGS": true} (bridge.py:142)
[DEFAULT.COMMON.HAL_GLIB][DEBUG]  REQUESTED:{'FUNCTION': 'request_ok', 'ARGS': True} (hal_glib.py:410)
dialog control <hal_glib.GStat object at 0x7f2ce4cefbc0 (common+hal_glib+GStat at 0xaaf3980)> 1

[zz912]

I understand that you want to unify different GUIs with zmq technology. That's why I don't understand why you copied panel.ui to all GUIs?

I think it would be appropriate to rename panel.ui to panel_halui.ui.
The name of the main window "QTvcp-Panel-panel" is strange. I suggest renaming it to "HALUI control"

However, I have no idea what your plans are for this panel in the future.

[zz912]

/* pin for running program */
I think, this is ctrl+c ctrl+v bug.
What is different between cycle and program?

[zz912]

What is the "HALBRIDGE = hal_bridge" command in an ini file good for?

In some ini files you use it, in some you don't, and in some it is commented out.
I mean the ini files in this PR.

[zz912]

Feel free to tell me what I should focus on in testing.

[c-morley]

Thank you for testing - I will try to answer your questions.

Yes the control panel was just for basic testing, it would be nice to come up with a list of 'standard' buttons that each GUI would be expected to support. each GUI requires some code work to fully integrate.

Dialog control is for the popup dialogs such as tool change or warnings. I believe I only coded Qtdragon to respond for manual tool changes and warnings when unpausing the spindle when the spindle is auto lifted.

Panel.ui is just for testing the basic code - I have put no thought into final naming and most likely would build a gladevcp based panel for gmoccapy. I just copied and pasted for speed.

program_run starts the program thru linuxcnc's command channel (so bypasses the GUI).
cycle_start requests the GUI to start the program, allowing the GUI to do other things such as pre-checks.
cycle_pause is similar. Qtdragon uses it to start the spindle and lower the spindle (when in spindle lift mode).

I would be interested if HALUI INI MDI commands work better when they are a 'request' form HALUI for the GUI to run them. As I remember, you had some timing problems in Gmoccapy.
I will check to see if I finished the Gmoccapy INI MDI test code.

[c-morley]

I see the MDI buttons work in the gmoccapy test panel. Can you simulate the problem you had with HALUI MDI commands?

[zz912]

I had three problems:
First problem wasnt caused by MDI_commands. I had T6 in MDI_commands. I did not know, where was problem. That is why I wrote aboat problematic MDI comnands. Problem was: T6 in Gmoccapy caused running another command (G43). Now it is solved by removing automatic G43.
The second problem is, that Halui during MDI_commands switching modes. So GUI must be preapered for this situation. Like this #3441
The third problem is probably interesting for you.
I will test it in weekend. https://forum.linuxcnc.org/38-general-linuxcnc-questions/49445-python-command-wait-complete-does-not-wait-for-c-halui-commands

[c-morley]

I think both problems are improved by using this halui technique.
HALUI just asked the GUI to run the MDI (using ZMQ messages)
In this way the GUI can decide about mode switching and display changes.

I'll be interested in what you find.

[zz912]

Hi,

I need to explain more what is the goal of implementing ZMQ?
Can you draw a block diagram of how ZMQ should work?
Just draw it with a pencil on paper and take a picture.

I studied the codes of this PR today. I am even more confused.

Previously, there were halui.mdi_commands in halui. These commands were triggered by the hal signal. The halui.cc file switched modes and triggered MDI commands. That was it.

Now there is halui.gui.mdi-command-MACRO0. These commands are triggered by the hal signal as well.
These commands are in the files:
halui.cc
gmoccapy.py
bridge.py
gtk_action.py
I didn't understand why it is in so many places, nor how it works there.

[c-morley]

[c-morley]

The HALUI pin halui.gui.mdi-command-MACRO0 uses ZMQ messages to request the GUI to run the commands it's self.

The best place to make sure mode changes and widget changes that are in sync with the MDI commands is the GUI.

HALUI is probably the most common way to connect a panel to the GUI, but because it thinks it's the only UI, some things like MDI and jogging do not work so well.

HALUI and bridge are really the same program. Bridge is a python library pulled into HALUI.
Bridge looks in the INI to see what macro pins need to be made.
It also reads/sends the ZMQ messages to ask Gmoccapy to run the INI macro command
It does similar things for jog rate and axis selection.

Gmoccapy use the library qtk_action to run the INI macro command.

The key here is that Gmoccapy is the one that runs the INI macro command, so it can be programed to set appropriate widgets and modes without having to worry about what HALUI is doing.

[zz912]

Gmoccapy use the library qtk_action to run the INI macro command.

Not gtk_action.py?

[zz912]

Thank you for picture. Right now, I can only be your rubber duck until I understand the whole thing.

The best place to make sure mode changes and widget changes that are in sync with the MDI commands is the GUI.

@Sigma1912 made something similar #3504
My problems with halui.mdi_commands will be solved here: #3441
So I still don't see the benefits of this PR.
ZMQ is realtime technology, but GUI, halui, bridge are userspace component. It is wierd combination for me now.

Why is bridge just a library?
What else will it be used for?
If bridge were a replacement for halui, it would be easier to maintain.

Could you describe to me better how MACRO0 works when using Gmoccapy?

The communication between the control panel and the halui is clear to me.
For MACRO0 HAL2 and HAL3 and NML1 it is not used. Is that right?

MOTION CONTROLLER is still some kind of abstract thing for me. Which specific files are these?
Let's limit ourselves to just running MACRO0, let's not make the pictures complicated.

gtk_action.py / qtk_action.py should be in the GUI image.
What does gtk_action.py / qtk_action.py do? Does it work with NML4 and HAL3?

[c-morley]

Gmoccapy use the library qtk_action to run the INI macro command.

Not gtk_action.py?

I miss spelled gtk_action

[c-morley]

ZMQ is not realtime.
For a macro call:

1. HAL is used from control panel to HALUI
2. ZMQ is used between HALUI and GUI
3. NML is used between the GUI and the MOTION CONTROLLER (aka Linuxcnc Gcode motion controller)

gtk_action is just a library of python functions for doing GUI related chores such as sending MDI commands defined in the INI.

bridge is part of HALUI, it extends HALUI to do the new functions. It can not work without HALUI.

While there are other ways to work around these problems, I believe this is better and also it covers all the GUIs (when it;s finished) and a consistent interface for users.

To summarize:
This code extends HALUI to request the GUI to run INI defined MDI commands and sync axis selection and jograte between HALUI and the GUI.
Having the GUI run the INI MDI commands (rather then HALUI) eliminates any mode state problems and allows the GUI to decide how to react to the request.
Having Jograte and axis selection in sync allows better integration of a control panel and screen controls.
Right now GUI screen jog controls are completely separate from HALUI jog controls.
Finally, having the interface the same between all GUIs makes it easier for users to set up.

[c-morley]

Here is a better diagram (The other was slightly wrong with the HAL connections to the motion controller from HALUI

[zz912]

ZMQ is not realtime.

Is NML realtime?

[c-morley]

No.
https://linuxcnc.org/docs/devel/html/code/code-notes.html

[zz912]

Do you think that HAL between GUI and HALUI should be replaced by ZMQ in the future?
In an ideal world.

[c-morley]

Possibly but certainly not necessarily. I think the things that are very standard (say jogging, axis selection) are better done in standard way (in this case I chose HALUI) that does not require connecting HAL pins.

I would bet that non standard things would still be added using HAL pins - it's easy to do

[c-morley]

Well I said without connecting HAL pins, but I meant not connecting HAL pins from the GUI to HALUI, you still connect some HAL pins in HALUI, say for a control panel.
It just makes things standard and easier, while still allowing much customization.

[zz912]

I always wondered why we need NML or ZMQ when theoretically we could be done via HAL?

[c-morley]

Outside my cone of hard knowledge, but as I under stand it, NML is a Neutral Message Layer for networking. I believer the idea was the GUI, IO controller and motion controller could be on different computers. Certainly the GUI side could be networked at one time.
HAL uses shared memory scheme, so can not directly be networked.

[zz912]

What advantages does ZMQ have over HAL?

[c-morley]

In this case, zmq automically connects the gui to halui and any other program that registers to it. This creates consistent information in the system and a consistent connection path for doing jogging or axis selection.

[zz912]

Thank you for explaining your thoughts.

Now I can get back to testing.

My test procedure:
1 ) Run gmoccapy_halui_test.ini
2 ) Turn off E-stop
3 ) Turn on machine
4 ) Home machine

Test number 1:
5 ) In the control panel press Manual
6 ) In the control panel press 0
You will see an ugly mode switch.
(If you don't see it, you have a very powerful PC and you should add G4 P10 to gui_mdi_commands)
This ugly mode switch also happens when using the classic mdi_commands too. I created a fix for it #3441 .

Test number 2:
7 ) In the control panel press MDI
8 ) In the control panel press 0
There is no problem

Test number 3:
9 ) In the control panel press AUTO
10 ) In the control panel press 0
Result:

[zz912]

For another test:

You must modify in INI file:
MDI_COMMAND_MACRO0 = G91; G1 Z-10

You must modify in gmoccapy.py

# =========================================================
# Coolant an mist coolant button
    def on_tbtn_flood_toggled(self, widget, data=None):
            self.command.wait_complete(30)
            self.command.mode(linuxcnc.MODE_MDI)
            self.command.wait_complete(30)
            self.command.mdi("G91 G1 X10 F200")
            self.command.wait_complete(30)
            self.command.mdi("G91 G1 Y10 F200")
            self.command.wait_complete(30)           
            self.command.mode(linuxcnc.MODE_MANUAL)
            self.command.wait_complete()

My test procedure:
1 ) Run gmoccapy_halui_test.ini
2 ) Turn off E-stop
3 ) Turn on machine
4 ) Home machine
5) go to 0 position => g90 => g0 x0z0y0
6 ) In the control panel press 0 and wait
Result:

Everything is OK now.
7 ) In the control panel press 0 and immediately press cooling and wait for a few seconds.
Result:

You are not in position Z-20 , because self.command.wait_complete(30) doesn't wait for gui_mdi_commands

Old mdi_commands make errors:
https://forum.linuxcnc.org/38-general-linuxcnc-questions/49445-python-command-wait-complete-does-not-wait-for-c-halui-commands

New gui_mdi_commands can be broken by another python command without any message.

[c-morley]

Ok Excellent notes. Thank you for testing!
I'll digest the information and probably ask follow up questions.

[c-morley]

@hansu I (again) think this is ready. Do you wish to test comment before I push?
Anyone else willing to audit the C++ code in HALUI?

[hansu]

Looks good so far. Only some slightly little notes:

• The last character of the dialog title doesn't fit the size. No idea why this is the case:
  

• You have now 81 commits which are showing your development including going back and forth some times.
  This is quite a lot and makes it hard to track the real changes. May I ask if you could squash your commits a bit or split them into meaningful commits?

[c-morley]

Are you using a particular theme? this is what I see but I use Mint:

[c-morley]

I could shrink the Gmoccapy commits to one if you like, but I think it could be used to show how each feature was set up. It's a lot of code touched. I started with about 120 commits. The problem comes if you reorder them to combine, then you can break git bisect. I have then down to 66 now. I'm not sure what to do with the shutdown dialog.

[hansu]

Are you using a particular theme? this is what I see but I use Mint:

I am using Debian Trixie from the LinuxCNC ISO for developing and I guess most users use this.

I could shrink the Gmoccapy commits to one if you like, but I think it could be used to show how each feature was set up. It's a lot of code touched.

No I think it's fine how you have it now, thanks!

I'm not sure what to do with the shutdown dialog.

Let me have a try if there is possibility to get this dialog wider. Otherwise I suggest to shorten the text.

[hansu]

I'm not sure what to do with the shutdown dialog.

Let me have a try if there is possibility to get this dialog wider. Otherwise I suggest to shorten the text.

I haven't found a nice way to fix this. I suggest to increase the minimal window width of the dialog with:

dialog.set_size_request(300, -1)

in def yesno_dialog(self) in gmoccapy/dialogs.py

[hansu]

@c-morley why did you commit all your commits of this PR directly to master ??

[c-morley]

It was convient to push directly. Why does it matter? The conflicts from other code come either way.

[hansu]

It was convient to push directly. Why does it matter? The conflicts from other code come either way.

Then I wonder why do we have PRs and the review mechanism? It also makes it easier to track the changes.
Never heard of the term "feature branch" ?
Will you now just close this PR unmerged? It will look like these changes are never added...

[c-morley]

You reviewed the code. This was the feature branch. I merged it.
I will close this later.
What is the difference?

I push directly all the time. This was different strictly because I wanted others to look at the code and give suggestions and you did.
Not sure why you are upset.

[hansu]

You reviewed the code. This was the feature branch. I merged it. I will close this later. What is the difference?

But I didn't finally approve it. For example the docs lacks some information resp. they doesn't match the function. And you did NOT merge it. You cherry-picked your commits detached to master.
That's quite a difference. Pushing the merge button on Github would even have been much more convenient.

I push directly all the time. This was different strictly because I wanted others to look at the code and give suggestions and you did. Not sure why you are upset.

Because it's a very big change which affects several GUIs AND if you open a PR one would expect the feature doesn't silently go in on another way.

[c-morley]

If you had indicated you wanted me to wait then I would have. You told me issues I fixed all of them and said I was ready to push this.
I did that at least twice.

I rebased the commits on top of master so they all were in a row. I almost always do that. There were no conflicts.

The unspoken pull request etiquette is new to me.

I am sorry this didn't work out as we hoped. It was not intentional to screw anybody up.

[rmu75]

That was.... unexpected.

@BsAtHome is in the midst of a massive refactoring / change of the HAL interfaces, it's probably not the best time to introduce new stuff that uses the old API.

[hansu]

I put a commit on top to be able to merge it that it has at least the state "merged" in GitHub. (Which might wasn't the best idea).

However, the original commits are:

d0ac241 qtvcp -pushbutton: fix setting of group pin type
8c7ef3a axis -docs: add info about HALUI gui pins
b87ecdc axis -sim: for halui zmq messages
08846ca axis -incorporate zmq messages
4c03568 gmoccapy -add docs for halui messages
f25a9cb gmoccapy -add a halui test config with a sim test panel
2c229a6 gmoccapy -dialogs: allow setting of message type for yes/no dialog
814ca65 gmoccapy -fix request to run macro with variables
a6c2482 gmoccapy -fix request macro function to call macro properly
2ad3a0b gmoccapy -create a dialog in gmoccapy for system shutdown
7552e60 gmoccapy -dialogs: cleanup/fixes
8763580 gmoccapy -add MPG input to zoom and scroll
e28edfe gmoccapy -respond to softkeys and make exit do shutdown
29a41fb gmoccapy -honour shutdown request
900acbd gmoccapy -update the angular speedcontrol to new angular type
eb46c63 gmoccapy -dialogs: search through focused dialogs, clean up code
1766ccb gmoccapy -entry dialog respond to halui, add non blocking wait code
fe0ac1d gmoccapy -update external pause/start behavior
ba36508 gmoccapy -can submit the current MDI command from HALUI
e1e7b58 gmoccapy -use halui message to cancel notifications
b25c710 gmoccapy -set jog speed control widget to use messages
e7514d7 gmoccapy -change warning dialogs to accept HALUI messages
d61f24f gmoccapy -change system dialog to accept halui messages
5466ba2 gmoccapy -used new mode return INI MDI function
5e4c53a gmoccapy -add gstat message control of start and pause
45a82f5 gmoccapy -ability to run INI MDI commands using HAL bridge
5d45ef0 gmoccapy -allow ZMQ messages to call macros in gmoccapy
38cdc1c qtdragon -add docs for halui messages/gui pins
c0e0fb6 qtdragon -add halui test sim
2459b4f qtdragon -adjust request macro function signature
78ba9e9 qtdragon -add basic support for softkeys to select main tabs
bcb5f0b qtdragon -external run of macros, use cycle start for MDI running
2416dea qtdragon -fix MPG selection from panel
b930b9f qtdragon -find the currently visible dialog to send messages to
a03370e qtdragon -add mpg_select button logic control
432d089 qtdragon -adjust external pause message to toggle
6e43ebb common/iniinfo -parse ini commands in a better way
851d6df qtvcp -allow setting of window title from designer
35b69b1 qtvcp -fix close dialog response when using zmq messages
c2a036f qtvcp -dialog_widget: check ZMQ messages directly
2638f03 qtvcp -axis tool button: allow for MPG selection
c372dce qtvcp -baseclass: register dialogs for later checks
429ae62 qtvcp -dialog widget: add status message control of tool change dialog
b52b5bd gladevcp -gtk_action: get shutdown to work reliably
d594e96 gladevcp -hal_gremlin: clear the plot if reloading the screen
3144696 qtvcp/gladevcp -action: add ability; return to mode after INI mdi
b2fed2c gladevcp -gtk_action: add ability to run new style INI MDI commands
450da54 gladevcp -speedcontrol: add angular jograte type and command and Gstat
e1869a5 halui - add docs for halui zmq messages and pins
7836c07 bridge -Don't break everything if there is no ZMQ library
a3dbe9e bridge - send out a key string with macro/mdi name
9da2cc9 halui/bridge -quiet print statements
1015177 halui -change gui. pin names
822e4c1 halui -add softkey pins and message
d1ba8cc halui -add reload display and shutdown pins
ee2369c hal_bridge -add a warning if the write address is already used
d8e9af9 halui -use angular jograte pin/messages for angular axis
29c46c4 halui -add an angular jograte pin and send angular jograte messages
72ab87b halui initial testing of embedded python halui
cffe26d add python3-zmq to python3 depends
0741c23 add python3-zmq package for halui
0f3d22e hal_glib -check if zmq read socket is available
7aaff76 hal_glib -add soft key messages
3b8bdf9 hal_glib -change request macro function signature to add a key string
eb1e890 hal_glib -add function to process one ZMQ message
75e015e hal_glib -add a function to run the gobject mainloop once

[BsAtHome]

I push directly all the time. This was different strictly because I wanted others to look at the code and give suggestions and you did. Not sure why you are upset.

I think nobody should be pushing directly to master. It is a serious problem that can take everybody off-guard. We have an established review process using PRs and those are generally merged when it is agreed upon. At least they give everybody a fair chance to look at the proposal and have their say if they wish to do so.

FWIW, it has bothered me before that there are out-of-PR commits to master. There is only a justification to do so on the very rare occasion when there is a serious problem. For everything else, we should all adhere to the PR process.

Besides, we would also have squashed the commits.

[rene-dev]

I have turned on branch protection, and reverted the changes, Please open a new PR.

[grandixximo]

the merge button is gone from all PRs?

[rene-dev]

no, but the branch needs to be rebased, and the rip-and-test needs to pass. I also send a mail to emc-developers.

[grandixximo]

I'm not sure there was an agreement on reverting, at least not that I can read here, am I safe to rebase my PRs now? or should I wait till this settle to avoid doing it twice?

[c-morley]

I am definitely more then annoyed about this behavior. Branch protection?
I didn't know we had an lunuxcnc authority that would penalize everyone for a misunderstanding.
Where are the written policies and when did they come into effect and who decided?
Let's not overreact t here.

[grandixximo]

I'm not sure we want the
"Require branches to be up to date before merging" do we?

now practically everything will need to be merged with the grey button and have extra commit with wrong author on sunday meeting? If I understand correctly?

[rene-dev]

@grandixximo the same thing happend before, if the branch was out of date. you can click on the arrow and rebase.
https://docs.github.com/en/pull-requests/reference/pull-request-merges
@c-morley
at least 3 people were very surprised by your commits. When I saw them in master, I thought it was a mistake.
branch protection is in general a good idea, this is not about you.
I reverted because there are multiple problems with this change, it does not look ready to me.
We have been doing the PR review process for a long time, and generally everyone agrees that it is a good idea, especially for large changes like this. It is even in the documentation.
https://linuxcnc.org/docs/devel/html/en/code/contributing-to-linuxcnc.html

Please continue this conversation in the discussion area, or on emc-developers.