- Posts: 20
- Thank you received: 1
Gmoccapy - A new screen for linuxcnc
- papaours
- Offline
- Junior Member
-
www.dropbox.com/sh/21w4c5arxa3b9ho/AACmY...zsUbsvfGvRdcbAa?dl=0
Please Log in or Create an account to join the conversation.
- LAIR82
- Offline
- Elite Member
-
- Posts: 197
- Thank you received: 3
newbynobi wrote: Hallo Rick,
I tried with an own program and could not reproduce that behavior. I do quiet often pause a program, measure an diameter, stop the program, make a new touch off or change tool offsets and then start a new run of the program. I never had any behavior as you mentioned.
I will need a program of yours to reproduce the behavior. Otherwise I will not be able to check where it comes from and will not be able to fix it.
IMHO it should not be a gmoccapy issue, as I am using only linuxcnc commands to run a program, but I will check that as soon as I got the sample program.
Norbert
Sorry for the delay Norbert, I have been so busy, I didn't realize you replied to this.
I will get a program, and post it for you.
The operator isn't even pausing it, the program stops on the MO1, as it should, and waits to be restarted, but sometimes the operator will just hit the "program stop" button (to theroretically abort, and reset the interpreter) and then "program start" ( which should start from the first line of the program), but I looks like it is starting off at the first coordinated G01 move, that is maybe 5-10 lines down in the program, totally bypassing the tool change, spindle command, and other modal codes.
Rick
Please Log in or Create an account to join the conversation.
- andypugh
- Offline
- Moderator
-
- Posts: 19899
- Thank you received: 4655
LAIR82 wrote: The operator isn't even pausing it, the program stops on the MO1, as it should, and waits to be restarted, but sometimes the operator will just hit the "program stop" button (to theroretically abort, and reset the interpreter) and then "program start" ( which should start from the first line of the program), but I looks like it is starting off at the first coordinated G01 move, that is maybe 5-10 lines down in the program, totally bypassing the tool change, spindle command, and other modal codes.
That sounds like a different problem. (though possibly related).
Please Log in or Create an account to join the conversation.
- Connor9220
- Offline
- New Member
-
- Posts: 17
- Thank you received: 1
Please Log in or Create an account to join the conversation.
- microsprintbuilder
- Offline
- Premium Member
-
- Posts: 115
- Thank you received: 4
Please Log in or Create an account to join the conversation.
- newbynobi
- Offline
- Moderator
-
- Posts: 1931
- Thank you received: 394
It is may be related to the STOP / RESUME / START bug i just solved.The operator isn't even pausing it, the program stops on the MO1, as it should, and waits to be restarted, but sometimes the operator will just hit the "program stop" button (to theroretically abort, and reset the interpreter) and then "program start" ( which should start from the first line of the program), but I looks like it is starting off at the first coordinated G01 move, that is maybe 5-10 lines down in the program, totally bypassing the tool change, spindle command, and other modal codes.
I checked all possibilities and could not reproduce that. But if the user did not press STOP, but twice the PAUSE, than I get a similar behavior.
So if you update to 1.3.1 the behavior should be gone.
Please check and confirm!
Norbert
Please Log in or Create an account to join the conversation.