Gmoccapy - added self.command.wait_complete() + self.stat.poll() #2552
Conversation
|
Please do not push! Just adding stat.poll and wait complete to nearly every place in the code is not only a very bad coding style, but als unnessasary and sure not the solution to the described situation. Additionally as the problem can not be reproduced on "normal" machines. I will try to review the code, but will need some time. Norbert |
Sorry if I push anyone. I appreciate the work of all people from this community.
I can reproduce 3 random bug on "simulation" machines. If there are bugs in the simulation, I believe they will show up in "normal" machines as well. This PR won't fix those bugs, but it might help. |
|
'Please do not push!' means Norbert does not want the changes 'pushed' to the repository. I don't think he means that you are being 'too pushy' about your continued investigation. |
|
I did not want to offent anybody or critisise the ongoing investment! I agree, that adding a wait complite in many places would be a good way to test for a changed behavior, but adding poll all around will slow the reaction of the GUI down in a unnecessary way. Unfortunately I do not have time to check that in detail. I will meet (hope in september) with some other LinuxCNC people for a weekend. I have a list of bugs in gmoccapy I want to investigate about and solve them if possible. Norbert |
|
Thank you for your response. I would blame the problem of misunderstanding on Google translator. I think you understand my idea, but you want to do the implementation differently. That's why I'm closing this PR and I'll look forward to the implementation from you when you have time for it. It's good that Norbert has a list of bugs. Unfortunately, it's a shame that it's not public. I wouldn't have to point out the mistakes he knows about. |
|
As this is not solved, I do reopen it. Norbert |
|
This may be clear to everybody else but I just had a bit of a lightbulb when researching this issue: It seems that adding 'self.command.wait_complete()' might actually block the GStat module from polling and thus miss changes in the state which cam then lead to Gmoccapy (which relies on GStat messages for its event driven architecture) not receiving the expected messages. I suppose this applies to any python script running (eg python remaps, vcp panels, handlers, etc) |
Hello everybody,
I added self.command.wait complete() + self.stat.poll() to avoid race condition.
This PR will not make any change in normal use, but should help in non-standard situations and/or complicated LCNC integrations.
Here is an example of how LCNC behaves when wait_complete() is omitted:
https://forum.linuxcnc.org/gmoccapy/49335-self-command-mdi-without-self-command-wait-complete?start=10#273798
It is very important to note that not using wait complete() can cause not only a bug in the given part of the code, but can cause unpredictable behavior of the entire LCNC. In this example, the LCNC remains in AUTO mode, even though this mode is not called.
If it seems to you that I used wait_complete() or self.stat.poll() only randomly and in as many places as possible, that's not the case. For each wait_complete() or self.stat.poll() I was wondering if it is necessary and if it will cause a downstream problem.
I think you can find cases where waiting_complete() or self.stat.poll() is duplicated unnecessarily. I'm convinced that it's better to use wait_complete() or self.stat.poll() multiple times than to miss somewhere.
Gmoccapy is often mentioned in the LCNC manual as a template for developing custom GUIs or custom LCNC modules. That's why I also added wait_complete() or self.stat.poll() to every function where it was needed. If someone copies such a function into their project, it will contain wait_complete() or self.stat.poll().
I know self.stat.poll() is periodic in the function so it should still be current, but with this PullRequest I'm trying to eliminate random errors.
Zdenek