Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.10 Gmoccapy - remap M61 disable show MDI window #3120

Open
zz912 opened this issue Sep 16, 2024 · 22 comments
Open

2.10 Gmoccapy - remap M61 disable show MDI window #3120

zz912 opened this issue Sep 16, 2024 · 22 comments
Assignees

Comments

@zz912
Copy link
Contributor

zz912 commented Sep 16, 2024

I added to LCNC remap for M61 and I found out, that after using, Gmoccapy MDI window is disabled.

For more information and test configuration look here: #3113

@zz912
Copy link
Contributor Author

zz912 commented Sep 16, 2024

M61

Modification INI file:

[RS274NGC]
........
SUBROUTINE_PATH = ./macros
REMAP=M6  modalgroup=6 prolog=change_prolog ngc=change_g43 epilog=change_epilog
REMAP=M61  modalgroup=6 prolog=settool_prolog ngc=settool_g43 epilog=settool_epilog

# the Python plugins serves interpreter and task
[PYTHON]
PATH_PREPEND = ./python
TOPLEVEL = ./python/toplevel.py
LOG_LEVEL = 0

needed file:
macros_2024-09-16.zip
python_2024-09-03.zip

@Sigma1912
Copy link
Contributor

I can reproduce this.
Toggling machine off then on seems to get things working again.

@zz912
Copy link
Contributor Author

zz912 commented Sep 16, 2024

Or you must change tool by M6 and it works again.

@Sigma1912
Copy link
Contributor

Sigma1912 commented Sep 16, 2024

The odd thing is that even if I remove these lines from the ini I still get the bug:

SUBROUTINE_PATH = ./macros
REMAP=M6  modalgroup=6 prolog=change_prolog ngc=change_g43 epilog=change_epilog
REMAP=M61  modalgroup=6 prolog=settool_prolog ngc=settool_g43 epilog=settool_epilog

# the Python plugins serves interpreter and task
[PYTHON]
PATH_PREPEND = ./python
TOPLEVEL = ./python/toplevel.py
LOG_LEVEL = 0

@Sigma1912
Copy link
Contributor

Just did some investigating:

  1. I just built current master on my test machine and I get this bug without any modification at all. (Gmoccapy version 3.4.8)
  2. I modified an older installation of 2.9 with Gmoccapy version 3.4.7.1 and I don't get the bug. (but I notice that sometimes it does not switch to mdi the first time I click on the 'MDI' button)

So I would conclude that this is not related to your remap.

@zz912
Copy link
Contributor Author

zz912 commented Sep 16, 2024

Hi,

I would like to tell you more about this issues.
I have been solving this problem since Apr 27, 2023.
It all started when I started retrofitting machines with ATC.
Until then I had no problems with Gmoccapy.
The problems started when I started using "remap M6" and "halui MDI commands". A typical feature of my problems is that they are random. 80% of my problems were caused by automatic_G43 in Gmoccapy. After that, there are 20% of weird behaviors that are related to remap and halui. For example, that the MDI button is not sensitive, but you can/must use it. These problems show up for me on a real machine and I can't simulate them in sim configurations yet. I devoted most of my energy to solving automatic_g43. Then we can move on. I am writing this to let you know that the strange behavior of remap + gmoccapy is known.

@Sigma1912
Copy link
Contributor

I know and I am with you as I was the one who actually could replicate some of the issues you have been reporting.
What I'm saying is that I observe this bug on master without the need to have a remap configured. While I cannot reproduce it on 2.9 even with the remap in place. I can reproduce this on a non-realtime simulation.
Hence I conclude that on my machine the remap is not related to the bug but that may be different to what you are observing as this is likely another race condition.

@zz912
Copy link
Contributor Author

zz912 commented Sep 16, 2024

Sorry for the confusion.
This bug is unrelated to PR #3113
Now I tested it with pure master branche.
This is a separate bug.

@Sigma1912
Copy link
Contributor

Sigma1912 commented Sep 17, 2024

Here is the debug output (with my comments added):

# Machine is homed and on, the GUI is in MANUAL screen
# Mouse click on MDI mode button in the vertical panel -> GUI changes to MDI screen

[Gmoccapy][DEBUG]  mode MDI (gmoccapy:2487)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
task: main loop took 0.022556 seconds
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MDI Mode, tool_change = False (gmoccapy:2745)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)


# Mouse click on MANUAL mode button in the vertical panel -> GUI changes to MANUAL screen

[Gmoccapy][DEBUG]  mode Manual (gmoccapy:2482)
emcTaskPlanLevel() returned 0
task: main loop took 0.018408 seconds
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MANUAL Mode (gmoccapy:2724)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)

# Mouse click on Tooleditor button in the bottom horizontal panel -> GUI changes to Tooleditor screen
# Change tool and click on 'M61 Q?' button in the bottom horizontal panel -> GUI changes to Manual screen

[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
task: main loop took 0.023131 seconds
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(M61 Q2) returned 2
emcTaskPlanLevel() returned 1
emcTaskPlanSetWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanSynch() returned 0
emcTaskPlanClearWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanExecute((null)) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  MDI Mode, tool_change = True (gmoccapy:2745)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  hal signal tool changed (gmoccapy:2638)
[Gmoccapy][DEBUG]  Tool is now 2 (gmoccapy:3497)
[Gmoccapy][DEBUG]  G43 is active (gmoccapy:3499)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
task: main loop took 0.022600 seconds
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(G43) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)


# Mouse click on MDI mode button in the vertical panel -> GUI does NOT change to MDI screen

[Gmoccapy][DEBUG]  mode MDI (gmoccapy:2487)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0


# Mouse click on MANUAL mode button in the vertical panel -> GUI remains in MANUAL screen

[Gmoccapy][DEBUG]  mode Manual (gmoccapy:2482)
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MANUAL Mode (gmoccapy:2724)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)



# Mouse click on MDI mode button in the vertical panel -> GUI does NOT change to MDI screen

[Gmoccapy][DEBUG]  mode MDI (gmoccapy:2487)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MDI Mode, tool_change = True (gmoccapy:2745)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:28

@zz912
Copy link
Contributor Author

zz912 commented Sep 17, 2024

Source of problem is "tool_change = True". I THINK.

"tool_change = True" is for hidden blinkink modes during tooling change after homing. I dont know, why is activated after M61.

@Sigma1912
Copy link
Contributor

I agree.

There is a comment in gmoccpy.py:

        self.tool_change = False  # this is needed to get back to manual mode after a tool change

That may explain why it is set during a tool change so maybe the question is why it is still on when we click on the MDI button later.

The only place I can find where that happens is in 'on_hal_status_interp_idle' (which is clearly not called as we do not see the debug message 'IDLE'):
on_interp_idle

@Sigma1912
Copy link
Contributor

Sigma1912 commented Sep 17, 2024

I went back to version 2.9 on my system and noticed that the severe form of the bug sometimes also occurs but most of the time I observe the less severe form where the MDI button functionality can be recovered by clickin on the MANUAL button and then on the MDI button again. in this case the behavior is like this:

[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5264)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(M61 Q1) returned 2
emcTaskPlanLevel() returned 0
emcTaskPlanSetWait() called
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
3 2
[Gmoccapy][DEBUG]  MDI Mode True (gmoccapy:2748)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5264)
[Gmoccapy][DEBUG]  RUN (gmoccapy:2622)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2824)
emcTaskPlanSynch() returned 0
emcTaskPlanClearWait() called
[Gmoccapy][DEBUG]  IDLE (gmoccapy:2570)
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  hal signal tool changed (gmoccapy:2641)
[Gmoccapy][DEBUG]  Tool is now 1 (gmoccapy:3507)
[Gmoccapy][DEBUG]  G43 is active (gmoccapy:3509)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(G43) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0



[Gmoccapy][DEBUG]  mode MDI (gmoccapy:2485)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  mode Manual (gmoccapy:2480)
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MANUAL Mode (gmoccapy:2727)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2824)
[Gmoccapy][DEBUG]  mode MDI (gmoccapy:2485)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MDI Mode False (gmoccapy:2748)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5264)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2824)

Note the

[Gmoccapy][DEBUG]  IDLE (gmoccapy:2570)

If it misses the interp_state being idle then we get the severe form if it catches the idle state we get the less severe form.

[EDIT]
removed speculation about the python module not catching the change in the interp_state as I cannot reliably tell from just watching the Status window.

@Sigma1912
Copy link
Contributor

I notice that if we artificially prolong the M61 command by inserting a G4 into your 'settool_g43' remap we can actually make the bug go away:

; using the code being remapped here means 'use builtin behaviour'
m61 q#<tool>
g4 p.1

Of course that does not fix it when the remap is not used.

@zz912
Copy link
Contributor Author

zz912 commented Sep 17, 2024

I forgot remove it. BUT it cant be source of problem. Gmoccapy must akcept everything in remap. g4 p10 for example.

@Sigma1912
Copy link
Contributor

I'm saying that if I insert 'g4 p.1' the issue goes away.
Removing it makes it come back.
At least on my machine

@zz912
Copy link
Contributor Author

zz912 commented Sep 17, 2024

I understand now.

@Sigma1912
Copy link
Contributor

Here is the difference in the debug output

Without 'g4 p.1' -> Bug: MDI button unresponsive:

[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(M61 Q2) returned 2
emcTaskPlanLevel() returned 1
emcTaskPlanSetWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanSynch() returned 0
emcTaskPlanClearWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanExecute((null)) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  MDI Mode, tool_change = True (gmoccapy:2745)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  hal signal tool changed (gmoccapy:2638)
[Gmoccapy][DEBUG]  Tool is now 2 (gmoccapy:3497)
[Gmoccapy][DEBUG]  G43 is active (gmoccapy:3499)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(G43) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)

This it with 'g4 p.1' -> MDI button works fine

[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(M61 Q1) returned 2
emcTaskPlanLevel() returned 1
emcTaskPlanSetWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanSynch() returned 0
emcTaskPlanClearWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanExecute((null)) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
3 2
[Gmoccapy][DEBUG]  RUN (gmoccapy:2619)
[Gmoccapy][DEBUG]  hal signal tool changed (gmoccapy:2638)
[Gmoccapy][DEBUG]  Tool is now 1 (gmoccapy:3497)
[Gmoccapy][DEBUG]  G43 is active (gmoccapy:3499)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(G43) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  IDLE (gmoccapy:2567)
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MANUAL Mode (gmoccapy:2724)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)

@Sigma1912
Copy link
Contributor

Now I get this slightly different output with 'g4 p.1' -> MDI button works fine

[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(M61 Q2) returned 2
emcTaskPlanLevel() returned 1
emcTaskPlanSetWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanSynch() returned 0
emcTaskPlanClearWait() called
emcTaskPlanLevel() returned 1
emcTaskPlanLevel() returned 1
emcTaskPlanExecute((null)) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
3 2
[Gmoccapy][DEBUG]  MDI Mode, tool_change = True (gmoccapy:2745)
[Gmoccapy][DEBUG]  ntb_button_switch_page (gmoccapy:5254)
[Gmoccapy][DEBUG]  RUN (gmoccapy:2619)
[Gmoccapy][DEBUG]  hal signal tool changed (gmoccapy:2638)
[Gmoccapy][DEBUG]  Tool is now 2 (gmoccapy:3497)
[Gmoccapy][DEBUG]  G43 is active (gmoccapy:3499)
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanExecute(G43) returned 0
emcTaskPlanLevel() returned 0
emcTaskPlanLevel() returned 0
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)
[Gmoccapy][DEBUG]  IDLE (gmoccapy:2567)
emcTaskPlanLevel() returned 0
emcTaskPlanSynch() returned 0
[Gmoccapy][DEBUG]  MANUAL Mode (gmoccapy:2724)
[Gmoccapy][DEBUG]  hal status motion mode changed (gmoccapy:2821)

@Sigma1912
Copy link
Contributor

If I understand this correctly then 'on_hal_status_interp_idle' is called from 'GStat' which would be outside of the GUIs control (but I really know too little about 'GStat'):
GStat signal

So I get the impression that some GCode execution (like 'M61 Q') may simply have become too fast for the event to reach the python handlers in the GUI.

maybe @c-morley would be able to give a more educated opinion.

@Sigma1912
Copy link
Contributor

Since I have a system where this issue can easily be reproduced I'll try to find out if the GStat Python Module is actually sending the message about the change in inter-idle.
https://linuxcnc.org/docs/devel/html/gui/gstat.html

@Sigma1912
Copy link
Contributor

Actually looking at the GStat documentation I may not even have to look much further as it seems that the LinuxCNC status is checked in 0.1s intervalls:
Gstat

So if we have Gcode that takes less then 100ms to execute the chances are that GStat does not register a change and it would make sense that adding G4 P.1 would make the issue go away.

@Sigma1912
Copy link
Contributor

Sigma1912 commented Sep 17, 2024

As a first idea.
Adding a 'G4 P.1' to the two places where M61 is used this seems to fix it (for M61 with and also without remap):

fix 4888

fix 5049

It might make sense to look for other 'self.command.mdi()' calls that could potentially suffer from this bug.

@zz912 zz912 changed the title Gmoccapy - remap M61 disable show MDI window 2.10 Gmoccapy - remap M61 disable show MDI window Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants