DRAFT: ZMQ messages from HALUI to GUIs - #3580
Conversation
|
Hello, I made basic manual tests for: 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. |
|
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. However, I have no idea what your plans are for this panel in the future. |
| FIELD(hal_bit_t,program_is_running) /* pin for notifying user that program is running */ \ | ||
| FIELD(hal_bit_t,halui_mdi_is_running) /* pin for notifying user that halui MDI commands is running */ \ | ||
| FIELD(hal_bit_t,program_is_paused) /* pin for notifying user that program is paused */ \ | ||
| FIELD(hal_bit_t,cycle_start) /* pin for running program */ \ |
There was a problem hiding this comment.
/* pin for running program */
I think, this is ctrl+c ctrl+v bug.
What is different between cycle and program?
|
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. |
|
Feel free to tell me what I should focus on in testing. |
|
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). 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 see the MDI buttons work in the gmoccapy test panel. Can you simulate the problem you had with HALUI MDI commands? |
|
I had three problems: |
|
I think both problems are improved by using this halui technique. I'll be interested in what you find. |
|
Hi, I need to explain more what is the goal of implementing ZMQ? 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. |
|
|
|
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. 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. |
Not gtk_action.py? |
|
Thank you for picture. Right now, I can only be your rubber duck until I understand the whole thing.
@Sigma1912 made something similar #3504 Why is bridge just a library? Could you describe to me better how MACRO0 works when using Gmoccapy? MOTION CONTROLLER is still some kind of abstract thing for me. Which specific files are these? gtk_action.py / qtk_action.py should be in the GUI image. |
I miss spelled gtk_action |
|
ZMQ is not realtime.
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: |
|
|
Is NML realtime? |
|
Do you think that HAL between GUI and HALUI should be replaced by ZMQ in the future? |
|
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 |
|
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. |
|
I always wondered why we need NML or ZMQ when theoretically we could be done via HAL? |
|
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. |
|
What advantages does ZMQ have over HAL? |
|
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. |
|
Thank you for explaining your thoughts. Now I can get back to testing. My test procedure: Test number 1: Test number 2: Test number 3: |
|
For another test: You must modify in INI file: You must modify in gmoccapy.py My test procedure: Old mdi_commands make errors: New gui_mdi_commands can be broken by another python command without any message. |
|
Ok Excellent notes. Thank you for testing! |
scroll the gcode if in auto and not running otherwise zoom the gcode display. Only if the MPG is enabled from HALUI
gmoccapy -add a 4 axis halui test config to confirm angular jograte works
axis -add softkey, exit and reload actions axis -allow MPG scrolling of gcode axis -add mdi/macro calls from halui
|
Hello Chriss,
Disadvantages of double pins:
|
|
In principle I agree with removing dual HAL pins. But... First I'd like to have the code used in the wild without breaking everyone's systems. |
|
@zz912 |
|
I recommend removing gmoccapy_halui_test.ini and leaving only gmoccapy_halui_test_4_axis.ini . Having two configurations doesn't add anything, it just means more work for testing. Short answer: Recommendations for Gmoccapy redesign: Long answer: I would like to ask you to reconsider the philosophy of macros: I would like to have only one way to create macros. I would like each macro to have multiple parameters. For example like this: Description parameters: I took this way of writing multiple parameters for one thing from embedded tab: |
| MACRO = i_am_lost | ||
| MACRO = halo_world | ||
| MACRO = jog_around | ||
| MACRO = increment xinc yinc | ||
| MACRO = go_to_position X-pos Y-pos Z-pos | ||
|
|
| if self.type_linear_jog: | ||
| print('linear jograte ->>',self.type_linear_jog) | ||
| self._status.connect('jograte-changed', lambda w, data: self.set_value(data)) | ||
| elif self.type_angular_jog: | ||
| print('Angular jograte ->>',self.type_angular_jog) | ||
| self._status.connect('jograte-angular-changed', lambda w, data: self.set_value(data)) |
There was a problem hiding this comment.
debug prints...
| if self.type_linear_jog: | |
| print('linear jograte ->>',self.type_linear_jog) | |
| self._status.connect('jograte-changed', lambda w, data: self.set_value(data)) | |
| elif self.type_angular_jog: | |
| print('Angular jograte ->>',self.type_angular_jog) | |
| self._status.connect('jograte-angular-changed', lambda w, data: self.set_value(data)) | |
| if self.type_linear_jog: | |
| self._status.connect('jograte-changed', lambda w, data: self.set_value(data)) | |
| elif self.type_angular_jog: | |
| self._status.connect('jograte-angular-changed', lambda w, data: self.set_value(data)) |
|
I tested a bit 😄 It's really cool that the cycle start/pause is now working also in MDI-mode. I Love it! The MACRO pins It's a bit confusing to have two kinds of macros now. Currently the Further I would group it with a dot:
It clears the plot actually
The naming could be made more clear. Maybe Does it have the same function in axis?
I would not execute a system shutdown via halui. But if you really want this, you should decide whether to shutdown linuxcnc OR system.
Maybe also further:
I am not sure if it's a good idea to have unnormalized values for the jog speeds.
zmq-bug-1.mp4zmq-bug-2.mp4
9.1 The log level should be the same like from the GUI - here it floods the console with debug messages. 9.2 I think this was also introduced here: 9.3 The INIINFO log level setting worked before, now also debug messages here:
|
|
[zz912]
I agree on Chris that there is no hurry removing the pins now. That can be done later.
Agree.
What speaks against the current implementation with a ngc file for each macro? This allos parameters and an image.
This is a bigger issue I guess ... |
My intention is not only to replace the current Gmoccapy macro syntax. The new [MACROS] mechanism combines the current Gmoccapy MACRO functionality with the HALUI MDI_COMMAND functionality, so that the same macro can be triggered both from the GUI and through a HAL signal. Now: My suggestion:
Regarding MACRO_SWITCH_MODE, I agree that the mode-switching issue is a separate issue and should not be addressed in this PR. The parameter was only a proposal for how this could potentially be handled, not something I consider essential to this PR. |
ie search by integer
as discussed on github
|
Thanks for the thorough testing. Here is some responses.
Thanks I'll do some work and bug you again :) |
|
@zz912 Mode switching is a problem that can't really be fixed until linuxcnc doesn't require mode changes. You can mask it in the gui and that is why the halui.gui. mdi commands should be better then having halui do the command while the gui has no idea till it sees the mode switch. |
|
I think we all agree on the main goal: we want to unify the current macro mechanisms. The current situation, where we have several different ways of doing this, is not ideal. Maybe we should therefore first define what we expect from a common Macro mechanism, and only then discuss the specific syntax and implementation. From my point of view, a Macro should have approximately the following properties:
I consider the last point important. If the Macro is to be a truly common mechanism for both GUI and HAL, the GUI should be able to determine the state of the macro — whether it is currently running or not. I am not suggesting any specific implementation for this information at this point; that can be addressed later, for example as part of the communication between LinuxCNC and the GUI. Regarding the specific INI syntax, as an integrator I originally liked the multiline approach using an embedded tab. If a Macro has multiple properties, I find it clearer to have them structured on separate lines rather than having a large amount of information packed into a single line. However, I am not fixed on this particular syntax. If we have the same understanding of the properties and behavior of a common Macro mechanism, I am open to other ways of representing them in the INI. Maybe it is therefore better to first reach agreement on this model and then work together on how to implement it best. |
|
I have been thinking about how we could move forward with the macro unification without making this PR much larger than originally intended. I realize that implementing the common Macro mechanism we are discussing would be a significant amount of additional work. Since the original purpose of this PR is mainly the ZMQ/HALUI-to-GUI integration, perhaps we don't need to implement the whole Macro unification here. What if we first agree on the rules and semantics of the common Macro mechanism and document them in the GUI Development Reference? The rules could define what a Macro should provide and how it should behave, while leaving the actual implementation for separate future work. This would also allow the implementation to be done gradually and by different developers. If we can agree on the basic rules, I would be happy to prepare a PR for updating the GUI Development Reference with them. I think this could give us a clear target for future implementation without requiring all of the work to be done as part of this PR. And of course, I understand that we are all doing this in our free time, so I would prefer a solution that doesn't unnecessarily increase the scope of this PR. |
|
I agree @zz912 we can discuss mdi/macro unification later and document it in gui development docs. |
9 participants
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.