Gcode preview and remap
29 Jul 2014 03:40 - 29 Jul 2014 03:41 #49230
by andypugh
My T-remap calls both M6 and T.
What version are you running? I guess it must be 2.6 or Master to even _have_ remapping.
Replied by andypugh on topic Gcode preview and remap
I think there's additional problems caused when the M6 subroutine calls M6 (special code prevents recursion by ignoring the mapping when M6 is called inside the M6-mapped subroutine.) .
My T-remap calls both M6 and T.
What version are you running? I guess it must be 2.6 or Master to even _have_ remapping.
Last edit: 29 Jul 2014 03:41 by andypugh.
Please Log in or Create an account to join the conversation.
29 Jul 2014 13:08 - 29 Jul 2014 13:14 #49241
by newbynobi
Replied by newbynobi on topic Gcode preview and remap
Hallo,
as far as I found, the problem is the signal "file-loaded", emitted from GStat. It is emitted, at the time the remapped subroutine is loaded, but not emitted again when the subroutine ends and the work on the main program goes on. If that signal would be emitted, all would be fine.
Unfortunately my C++ knowledge is so week, that I do not understand the behavior. I tried to understand beginning with:
[linuxcnc.git] / src / emc / rs274ngc / interp_remap.cc
There is a part
bool Interp::remap_in_progress(const char *code)
with may help, but as far as I see, it is not exported to the python bindings.
[linuxcnc.git] / src / emc / rs274ngc / pyinterp1.cc
If that would be exported, we could check in GStat for remaped in progress and avoid emitting the file-loaded signal.
That should work on all GUI.
The best solution would be that the file-loaded signal is emitted also at the time the interpreter returns to the main program, as that would result in showing the work on the subroutine and also the ongoing steps of the main program. But where to implement that?
May be someone can help.
Norbert
as far as I found, the problem is the signal "file-loaded", emitted from GStat. It is emitted, at the time the remapped subroutine is loaded, but not emitted again when the subroutine ends and the work on the main program goes on. If that signal would be emitted, all would be fine.
Unfortunately my C++ knowledge is so week, that I do not understand the behavior. I tried to understand beginning with:
[linuxcnc.git] / src / emc / rs274ngc / interp_remap.cc
There is a part
bool Interp::remap_in_progress(const char *code)
with may help, but as far as I see, it is not exported to the python bindings.
[linuxcnc.git] / src / emc / rs274ngc / pyinterp1.cc
If that would be exported, we could check in GStat for remaped in progress and avoid emitting the file-loaded signal.
That should work on all GUI.
The best solution would be that the file-loaded signal is emitted also at the time the interpreter returns to the main program, as that would result in showing the work on the subroutine and also the ongoing steps of the main program. But where to implement that?
May be someone can help.
Norbert
Last edit: 29 Jul 2014 13:14 by newbynobi.
Please Log in or Create an account to join the conversation.
30 Jul 2014 01:44 #49271
by mhaberler
Replied by mhaberler on topic Gcode preview and remap
could you guys please isolate the issue into a simple example running on a sim config?
I might be able to help, but I want to see and reproduce the fault before concocting hypotheses how to fix it
- Michael
I might be able to help, but I want to see and reproduce the fault before concocting hypotheses how to fix it
- Michael
Please Log in or Create an account to join the conversation.
01 Aug 2014 00:18 #49357
by newbynobi
Replied by newbynobi on topic Gcode preview and remap
Hallo Michael,
thanks for offering your help. You can easily reproduce the behavior.
Please use from master or 2.6 gmoccapy_tool_sensor.ini and open the file nc_files/gmoccapy_2_tools_with_cutter_radius_compensation.ngc
You might have to do touch off to be in the working range.
After start of the program, you will be prompted to change the tool, after that please simulate the probe contact using the corresponding button.
You will see, that the content of the gcode preview window will change to the content of "change.ngc" and after the change the content will remain, and lines are highlighted, but that do not correspond to the graphical preview. After the last tool change, the gcode window will be filled with the correct content of the main program.
Hope that helps, otherwise I am sure you will ask
Norbert
thanks for offering your help. You can easily reproduce the behavior.
Please use from master or 2.6 gmoccapy_tool_sensor.ini and open the file nc_files/gmoccapy_2_tools_with_cutter_radius_compensation.ngc
You might have to do touch off to be in the working range.
After start of the program, you will be prompted to change the tool, after that please simulate the probe contact using the corresponding button.
You will see, that the content of the gcode preview window will change to the content of "change.ngc" and after the change the content will remain, and lines are highlighted, but that do not correspond to the graphical preview. After the last tool change, the gcode window will be filled with the correct content of the main program.
Hope that helps, otherwise I am sure you will ask
Norbert
Please Log in or Create an account to join the conversation.
10 Aug 2014 18:18 #49648
by andypugh
It seems that this is also an issue in the "lathe-fanucy" demo config that I wrote to demonstrate T0201 style tool changing using G43.2.
I think all you need to do there is change the GUI to gmoccapy and MDI T0101 (but I am away from my machines at the moment).
This is starting to look like a Gmoccapy thing. I won't call it a bug, as I think it is mainly caused by Gmoccapy refreshing when asked to, when other GUIs don't bother but possibly should.
Replied by andypugh on topic Gcode preview and remap
could you guys please isolate the issue into a simple example running on a sim config?
It seems that this is also an issue in the "lathe-fanucy" demo config that I wrote to demonstrate T0201 style tool changing using G43.2.
I think all you need to do there is change the GUI to gmoccapy and MDI T0101 (but I am away from my machines at the moment).
This is starting to look like a Gmoccapy thing. I won't call it a bug, as I think it is mainly caused by Gmoccapy refreshing when asked to, when other GUIs don't bother but possibly should.
Please Log in or Create an account to join the conversation.
11 Aug 2014 01:25 #49664
by newbynobi
Replied by newbynobi on topic Gcode preview and remap
Andy,
could you please check with gscreen as GUI? as only gmoccapy and gscreen uses the glade hal gcode preview and hal status. I am sure in there the bug is located.
Unfortunately at the moment, I am out of time to check further stuff.
Norbert
could you please check with gscreen as GUI? as only gmoccapy and gscreen uses the glade hal gcode preview and hal status. I am sure in there the bug is located.
Unfortunately at the moment, I am out of time to check further stuff.
Norbert
Please Log in or Create an account to join the conversation.
10 Aug 2023 04:51 #277504
by zz912
Is there a clean fix in version 2.9?
I have the same problem.
I am getting spindle movement during ATC. I don't see the movements for machining.
I experimented with:
(PREVIEW, hide) and (PREVIEW, show) in g-code
but all I got was nothing showing up in the preview.
Zdenek
Replied by zz912 on topic Gcode preview and remap
Hello Norbert,Hallo,
a very dirty fix would be to add a test to /linuxcnc/lib/gladevcp/hal_sourceview.py at line 81, after the line
fn = self.filename
if fn.split(os.sep)[-1] == "change.ngc": return Then the gcode window will not be filled with the remaped code, if it is called change.ngc The problem is caused IMHO, due to the reason, that the remap emits a file changed signal, but when it ends, there is not emmited the signal again from the running main program. It would be possible to exclude also any program, beginning with "remap_", so it would be possible to exclude all remap stuff. What do the reals developers think about excluding files to be displayed? I tested that with gmoccapy_tool_sensor.ini On the other way, the test for remaped code could be done in hal-glib / GStat. Does someone know if a remaped state signal is set during remap? Norbert
Is there a clean fix in version 2.9?
I have the same problem.
I am getting spindle movement during ATC. I don't see the movements for machining.
I experimented with:
(PREVIEW, hide) and (PREVIEW, show) in g-code
but all I got was nothing showing up in the preview.
Zdenek
Please Log in or Create an account to join the conversation.
10 Aug 2023 07:42 #277509
by newbynobi
Replied by newbynobi on topic Gcode preview and remap
This is a thread from 2013!
This bug has been solved long time ago.
Please describe you problem as detailed as possible, as you may have found a new bug .
Norbert
This bug has been solved long time ago.
Please describe you problem as detailed as possible, as you may have found a new bug .
Norbert
The following user(s) said Thank You: zz912
Please Log in or Create an account to join the conversation.
12 Aug 2023 10:15 #277718
by zz912
Replied by zz912 on topic Gcode preview and remap
A similar bug can be easily simulated.
Use this procedure:
github.com/LinuxCNC/linuxcnc/issues/2448
End at point 6.
Then open the file 3D_chips.ngc.
That line below the penguin is the ATC trajectory.
In this simulation, preview behaves a little differently to me than in a real machine. Anyway, I think the behavior is weird.
Use this procedure:
github.com/LinuxCNC/linuxcnc/issues/2448
End at point 6.
Then open the file 3D_chips.ngc.
That line below the penguin is the ATC trajectory.
In this simulation, preview behaves a little differently to me than in a real machine. Anyway, I think the behavior is weird.
Attachments:
Please Log in or Create an account to join the conversation.
15 Aug 2023 19:31 #278068
by zz912
Replied by zz912 on topic Gcode preview and remap
I would like to ask you to move this thread to the Gmoccapy section. Maybe more people will notice my problem there.
Please Log in or Create an account to join the conversation.
Time to create page: 0.124 seconds