- LinuxCNC
- General LinuxCNC Questions
- Mysterious interaction between running the spindle and the tool length probing c
Mysterious interaction between running the spindle and the tool length probing c
- Jonathan_H
- Offline
- Junior Member
Less
More
- Posts: 23
- Thank you received: 0
27 Aug 2022 03:56 #250556
by Jonathan_H
Mysterious interaction between running the spindle and the tool length probing c was created by Jonathan_H
Hi,
I'm setting up a Denford 2600 converted to LinuxCNC using a Mesa board for our hackspace.
As part of that conversion I added a tool length sensing plunger switch that sits in the corner of the bed. The M6 tool change command is redirected to a macro that moves the spindle to front and centre, prompts you to change the tool, then goes off and measures the length of the tool and compensates for it in subsequent operations, not unusual (my code is a slightly modified version of somebody else's.
Now, a few weeks ago this was working perfectly, I ran a job with multiple tool changes, each tool was successfully measured and the job completely perfectly.
Since then, I'm not aware of having made any changes that seem like they would affect that code at all (nor does it seem likely that anyone else has messed with things). I've not done any more cutting as I've been focused on sorting out convenience controls for the gui (axis). When I did the successful job I had a pyvcp panel with buttons for resetting the tool length compensation, probing the material surface height (using a plate on the work and a wire clipped to the tool, as in many youtube videos).
I've moved those over to gladevcp and added some others. That's been a bit of a learning curve. One of the features was a button to do a spindle warmup (the Denford manual states that one should be done daily before any actual cutting), and it was in testing that, that I came across the problem.
The problem is this. If I start up Linux CNC, then from fresh it seems I can run as many tool changes and as many length compensation resets as I like and it will work exactly as predicted.
BUT, spin up the spindle, even just a teensy bit, and stop it, and then the tool change routine will stall.
This happens no matter how I spin it up, with a manual MDI command, with an MDI command from python, with the linux cnc command interface from python, or with the buttons on the axis GUI.
It won't stall in the same place every time either. Sometimes it doesn't move at all, sometimes it gets as far as hovering over the plunger switch before stalling. I think it may also occasionally have got to the bit where it asks for the new tool, and then stopped after that (I'm not 100% certain, I was getting tired by this point).
If I stop it and rerun it, the same thing, except occasionally it gets itself in a state where when I try to do a tool change I get some message about G53 not being allowed in relative mode or somesuch.
I am completely stumped, so I am hoping someone here can help me.
The tool changing code is attached, the M100 command just goes to python code that generates a message dialog.
I'm setting up a Denford 2600 converted to LinuxCNC using a Mesa board for our hackspace.
As part of that conversion I added a tool length sensing plunger switch that sits in the corner of the bed. The M6 tool change command is redirected to a macro that moves the spindle to front and centre, prompts you to change the tool, then goes off and measures the length of the tool and compensates for it in subsequent operations, not unusual (my code is a slightly modified version of somebody else's.
Now, a few weeks ago this was working perfectly, I ran a job with multiple tool changes, each tool was successfully measured and the job completely perfectly.
Since then, I'm not aware of having made any changes that seem like they would affect that code at all (nor does it seem likely that anyone else has messed with things). I've not done any more cutting as I've been focused on sorting out convenience controls for the gui (axis). When I did the successful job I had a pyvcp panel with buttons for resetting the tool length compensation, probing the material surface height (using a plate on the work and a wire clipped to the tool, as in many youtube videos).
I've moved those over to gladevcp and added some others. That's been a bit of a learning curve. One of the features was a button to do a spindle warmup (the Denford manual states that one should be done daily before any actual cutting), and it was in testing that, that I came across the problem.
The problem is this. If I start up Linux CNC, then from fresh it seems I can run as many tool changes and as many length compensation resets as I like and it will work exactly as predicted.
BUT, spin up the spindle, even just a teensy bit, and stop it, and then the tool change routine will stall.
This happens no matter how I spin it up, with a manual MDI command, with an MDI command from python, with the linux cnc command interface from python, or with the buttons on the axis GUI.
It won't stall in the same place every time either. Sometimes it doesn't move at all, sometimes it gets as far as hovering over the plunger switch before stalling. I think it may also occasionally have got to the bit where it asks for the new tool, and then stopped after that (I'm not 100% certain, I was getting tired by this point).
If I stop it and rerun it, the same thing, except occasionally it gets itself in a state where when I try to do a tool change I get some message about G53 not being allowed in relative mode or somesuch.
I am completely stumped, so I am hoping someone here can help me.
The tool changing code is attached, the M100 command just goes to python code that generates a message dialog.
Please Log in or Create an account to join the conversation.
- Jonathan_H
- Offline
- Junior Member
Less
More
- Posts: 23
- Thank you received: 0
28 Aug 2022 22:44 #250660
by Jonathan_H
Replied by Jonathan_H on topic Mysterious interaction between running the spindle and the tool length probing c
OK, So I've done more investigation and I've got a clearer idea of when things go wrong, but not really why. It turns out the probing was a bit of a red herring, it's just certain combinations of spindle commands and move commands.
So, this program will run just fine
But this one , where the only difference is that the G54 G1 command has been removed will stall on the G53 command. It just stops without any error messages and stays there until I hit the program stop button on the axis gui. The only exception is if the carriage is already at the destination location (so no movement necessary), in which case it continues on to the end of the program
As will this one, note the slightly slower spindle speed, that is the only difference from the first, working program
This one however will stall on the G54
I'm pretty much stuck as to what to try next, I really hope someone has an idea
So, this program will run just fine
%
#<_TravelZ> = -1 ( machine Z coordinate for travelling, typically near max Z to avoid ever hitting the work )
#<_TravelFeed> = 4000.0 ( feedrate used for general Z moves when avoiding G0 )
M70
(MSG, Done M70)
G90
(MSG, Done G90)
M3 S210
(MSG, Done Spindle)
G54 G1 X57.986 Y43.593 Z0 F4000
(MSG, Done G54)
M5
(MSG, Done M5)
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
(MSG, Done G53)
M72
(MSG, Done M72)
M2
But this one , where the only difference is that the G54 G1 command has been removed will stall on the G53 command. It just stops without any error messages and stays there until I hit the program stop button on the axis gui. The only exception is if the carriage is already at the destination location (so no movement necessary), in which case it continues on to the end of the program
%
#<_TravelZ> = -1 ( machine Z coordinate for travelling, typically near max Z to avoid ever hitting the work )
#<_TravelFeed> = 4000.0 ( feedrate used for general Z moves when avoiding G0 )
M70
(MSG, Done M70)
G90
(MSG, Done G90)
M3 S210
(MSG, Done Spindle)
M5
(MSG, Done M5)
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
(MSG, Done G53)
M72
(MSG, Done M72)
M2
As will this one, note the slightly slower spindle speed, that is the only difference from the first, working program
%
#<_TravelZ> = -1 ( machine Z coordinate for travelling, typically near max Z to avoid ever hitting the work )
#<_TravelFeed> = 4000.0 ( feedrate used for general Z moves when avoiding G0 )
M70
(MSG, Done M70)
G90
(MSG, Done G90)
M3 S210
(MSG, Done Spindle)
M5
(MSG, Done M5)
G54 G1 X57.986 Y43.593 Z0 F4000
(MSG, Done G54)
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
(MSG, Done G53)
M72
(MSG, Done M72)
M2
This one however will stall on the G54
%
#<_TravelZ> = -1 ( machine Z coordinate for travelling, typically near max Z to avoid ever hitting the work )
#<_TravelFeed> = 4000.0 ( feedrate used for general Z moves when avoiding G0 )
M70
(MSG, Done M70)
G90
(MSG, Done G90)
M3 S200
(MSG, Done Spindle)
G54 G1 X57.986 Y43.593 Z0 F4000
(MSG, Done G54)
M5
(MSG, Done M5)
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
(MSG, Done G53)
M72
(MSG, Done M72)
M2
I'm pretty much stuck as to what to try next, I really hope someone has an idea
Please Log in or Create an account to join the conversation.
- LinuxCNC
- General LinuxCNC Questions
- Mysterious interaction between running the spindle and the tool length probing c
Time to create page: 0.052 seconds