Discussion:
G33 linear motion limits exceeded error
(too old to reply)
John Morris
2017-01-20 12:46:59 UTC
Permalink
Raw Message
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."

It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.

Is this something that should be fixed, or am I reading the
documentation wrong?

[1]: http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g33-tech-info
[2]:
https://github.com/zultron/machinekit/tree/spindlesync-exceeds-maxvel-lcnc

Thanks-

John
Robert Ellenberg
2017-01-20 13:01:51 UTC
Permalink
Raw Message
I think it's a bug (or at least an oversight), see this issue:

https://github.com/LinuxCNC/linuxcnc/issues/167

I have an experimental fix:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7

It caps spindle speed based on max feed for position sync moces. It seems
to work in simulation, but it doesn't calculate the right maximum speed for
one of Sam's configs. Mixed in with that branch are some changes to spindle
tracking in the TP (not all of which are an improvement, as it turns out).

Best,
Rob
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
[1]: http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g33-tech-info
https://github.com/zultron/machinekit/tree/spindlesync-exceeds-maxvel-lcnc
Thanks-
John
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Jon Elson
2017-01-20 16:17:30 UTC
Permalink
Raw Message
Post by Robert Ellenberg
https://github.com/LinuxCNC/linuxcnc/issues/167
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7
It caps spindle speed based on max feed for position sync moces.
Yes, this is the ONLY way it can be fixed.

Jon
Gene Heskett
2017-01-20 19:33:34 UTC
Permalink
Raw Message
Post by Jon Elson
Post by Robert Ellenberg
https://github.com/LinuxCNC/linuxcnc/issues/167
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle
-sync-overhaul-2.7
It caps spindle speed based on max feed for position sync moces.
Yes, this is the ONLY way it can be fixed.
Maybe do both, belt & suspenders approach? But what about the folks
running fixed speed motors that lcnc cannot control dynamically?

So we need that looked at and reported during the load the code scan too.
Post by Jon Elson
Jon
----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
John Kasunich
2017-01-20 14:19:29 UTC
Permalink
Raw Message
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
I think it is a terminology thing. Where the manual says "it is an error",
read it to mean "if you do this, you made an error and all bets are off",
rather than "if you do this, LCNC will detect and report it".
--
John Kasunich
***@fastmail.fm
Robert Ellenberg
2017-01-20 14:30:00 UTC
Permalink
Raw Message
That's true, though I think we should warn users of errors we can detect as
early as possible, so they don't have to destroy a part to learn the
significance of a line in the documentation.
Post by John Kasunich
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
I think it is a terminology thing. Where the manual says "it is an error",
read it to mean "if you do this, you made an error and all bets are off",
rather than "if you do this, LCNC will detect and report it".
--
John Kasunich
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
John Morris
2017-01-21 09:28:00 UTC
Permalink
Raw Message
Post by Robert Ellenberg
Post by John Kasunich
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
I think it is a terminology thing. Where the manual says "it is an error",
read it to mean "if you do this, you made an error and all bets are off",
rather than "if you do this, LCNC will detect and report it".
That's true, though I think we should warn users of errors we can detect as
early as possible, so they don't have to destroy a part to learn the
significance of a line in the documentation.
I also thought of these three possible intended scenarios pointed out in
this thread, and can think of valid arguments for each, briefly:

1. The manual says it's an error, and it's up to the user to avoid it
(status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by adjusting
spindle speed

Of course "spindle synched motion" most simply means to move other axes
by a specified amount with each revolution of the spindle. In this
case, the spindle shares some characteristics with an axis, since the
goal is to produce coordinated motion of a tool across the surface of a
workpiece. In coordinated motions involving the XYZABCUVW axes, the TP
will scale down the feed rate in order not to violate constraints for
any axis.

Scenario 3 extends this thinking to scaling spindle speed to keep within
axis constraints. Aside from the theoretical elegance, I can think of
practical reasons, like having the same .ngc file produce the same tool
path on different machines.

I'm going to take a look at Rob's implementation (related thread here
[1]). Thanks-

John

[1]:
http://www.mail-archive.com/emc-***@lists.sourceforge.net/msg16953.html
Gene Heskett
2017-01-21 10:27:50 UTC
Permalink
Raw Message
Post by Robert Ellenberg
Post by Robert Ellenberg
Post by John Kasunich
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is
an error if [...] The requested linear motion exceeds machine
velocity limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis
velocity limited to its `MAX_VELOCITY` from the INI file, thus
cutting threads with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
I think it is a terminology thing. Where the manual says "it is an
error", read it to mean "if you do this, you made an error and all
bets are off", rather than "if you do this, LCNC will detect and
report it".
That's true, though I think we should warn users of errors we can
detect as
Post by Robert Ellenberg
early as possible, so they don't have to destroy a part to learn
the significance of a line in the documentation.
I also thought of these three possible intended scenarios pointed out
1. The manual says it's an error, and it's up to the user to avoid it
(status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by adjusting
spindle speed
Of course "spindle synched motion" most simply means to move other
axes by a specified amount with each revolution of the spindle. In
this case, the spindle shares some characteristics with an axis, since
the goal is to produce coordinated motion of a tool across the surface
of a workpiece. In coordinated motions involving the XYZABCUVW axes,
the TP will scale down the feed rate in order not to violate
constraints for any axis.
Scenario 3 extends this thinking to scaling spindle speed to keep
within axis constraints. Aside from the theoretical elegance, I can
think of practical reasons, like having the same .ngc file produce the
same tool path on different machines.
A definite plus.
Post by Robert Ellenberg
I'm going to take a look at Rob's implementation (related thread here
[1]). Thanks-
John
With my/our thanks John, bearing in mind that a vfd driven, multi-gear
spindle is not, or hasn't been for me, as agile in time vs speed as the
dc motors on my other machines. My G0704 can reverse from 2500 fwd to
2500 in reverse in 400 or 500 milliseconds. My vfd, although I do not
yet consider it calibrated, will be 5 seconds or more from 500 rpm. I
have not explored faster because my chuck is screw on. One of my first
projects is to make a clamp on the rear of the faceplate that puts a
death grip on the spindles flange just in front of the front bronze
bearing. Then to transfer that lock to the faceplate, pin another clamp
to the cleaned up faceplate hub. That shouldn't be a clothing catcher if
I do it right.
Post by Robert Ellenberg
953.html
----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
John Kasunich
2017-01-23 15:43:21 UTC
Permalink
Raw Message
Post by John Morris
I also thought of these three possible intended scenarios pointed out in
1. The manual says it's an error, and it's up to the user to avoid it
(status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by adjusting
spindle speed
#3 is impossible for machines where spindle speed is not controlled by LCNC.
For example my lathe has only M3/M5. Single phase motor controlled by
contactor, with manually changed belts to the spindle.

#2 is possible during actual program execution - can't do G33 without a
spindle encoder, and if you have an encoder, you have spindle speed
feedback and can decide if the speed is OK.

But #2 may not be possible during generation of the preview. During
preview the spindle is not running. The only thing LCNC can do is assume
that the spindle speed will be whatever the most recent S-word specified.
But on a machine like mine, the S-word doesn't actually control anything.
IF the programmer is disciplined enough, he can use the S-word to tell
LCNC how fast he intends to run the spindle. But LCNC can't rely on that
being the actual spindle speed.
--
John Kasunich
***@fastmail.fm
Robert Ellenberg
2017-01-23 17:18:52 UTC
Permalink
Raw Message
John, you raise a good point here. The general assumption is that the S
word is a reasonable prediction of spindle speed. What do you think of
having a check at both interp time and runtime? That would cover all cases.
For machines like yours, we could suppress the interp-time error. Is there
an INI or HAL setting to tell LinuxCNC that the spindle is manually
controlled?
Post by John Kasunich
Post by John Morris
I also thought of these three possible intended scenarios pointed out in
1. The manual says it's an error, and it's up to the user to avoid it
(status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by adjusting
spindle speed
#3 is impossible for machines where spindle speed is not controlled by LCNC.
For example my lathe has only M3/M5. Single phase motor controlled by
contactor, with manually changed belts to the spindle.
#2 is possible during actual program execution - can't do G33 without a
spindle encoder, and if you have an encoder, you have spindle speed
feedback and can decide if the speed is OK.
But #2 may not be possible during generation of the preview. During
preview the spindle is not running. The only thing LCNC can do is assume
that the spindle speed will be whatever the most recent S-word specified.
But on a machine like mine, the S-word doesn't actually control anything.
IF the programmer is disciplined enough, he can use the S-word to tell
LCNC how fast he intends to run the spindle. But LCNC can't rely on that
being the actual spindle speed.
--
John Kasunich
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
John Kasunich
2017-01-23 18:05:27 UTC
Permalink
Raw Message
Post by Robert Ellenberg
John, you raise a good point here. The general assumption is that the S
word is a reasonable prediction of spindle speed. What do you think of
having a check at both interp time and runtime?
I kinda think you're going to want that anyway. It is always better to spot
a problem during preview rather than after the part is half machined.

The preview check should use the current value of the S-word as a predictor
of what the spindle speed will be during the real run. If you run a program
with G33 moves in it and the spindle isn't turning, the program will silently
hang waiting for index. So there must be some special "preview only" code
already in place to avoid the hang. (Likewise for G95 "feed per rev" mode.)

The run-time check sould of course use the actual spindle speed from the
encoder. If you don't have an encoder you can't do G33 anyway.
Post by Robert Ellenberg
That would cover all cases.
For machines like yours, we could suppress the interp-time error.
I wouldn't suppress it. If I program an appropriate S-word (even though
I know that it doesn't directly control the spindle), I can benefit from the
preview-time check.
Post by Robert Ellenberg
Is there
an INI or HAL setting to tell LinuxCNC that the spindle is manually
controlled?
Not that I'm aware of. Nitpick - you wrote "spindle is manually controlled"
where I think you meant "spindle SPEED is manually controlled". Spindle
on/off is under LinuxCNC control using M3/M5 (I don't have reversing, so
M4 doesn't work).
--
John Kasunich
***@fastmail.fm
John Morris
2017-01-26 08:07:41 UTC
Permalink
Raw Message
If you run a program with G33 moves in it and the spindle isn't
turning, the program will silently hang waiting for index.
Additionally, a G33 move will wait for the spindle-at-speed pin. (See
below)
The run-time check sould of course use the actual spindle speed from
the encoder. If you don't have an encoder you can't do G33 anyway.
[...]
Is there an INI or HAL setting to tell LinuxCNC that the spindle
ismanually controlled?
Not that I'm aware of.
Of course an INI setting could be added to specify whether the spindle
is under LCNC control, but even without this, Rob's spindle-scaling
scheme should still work. If a fixed-speed spindle runs at 2000 RPM but
axis constraints limit max spindle speed to 1000 RPM, the program should
pause indefinitely waiting for the spindle-at-speed pin.

This behavior could be puzzling: the spindle is turning, but axes never
move, why? This might be addressed with a "spindle not coming to speed"
warning following some timeout.

If that makes sense, then here's one way to specify the checks:

- Preview-time check:
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm check
- Failure action: raise warning

- Run-time check:
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning

John
Robert Ellenberg
2017-01-27 03:44:01 UTC
Permalink
Raw Message
For anyone interested in trying this out, I have fixes / improvements in
this branch now:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7-rebase

- Less intrusive warning messages if the spindle is too fast
- Spindle RPM limit calculation should work properly now
- Improved (again) algorithm for position tracking that should have even
less acceleration ripple.

Best,
Rob
Post by John Morris
If you run a program with G33 moves in it and the spindle isn't
turning, the program will silently hang waiting for index.
Additionally, a G33 move will wait for the spindle-at-speed pin. (See
below)
The run-time check sould of course use the actual spindle speed from
the encoder. If you don't have an encoder you can't do G33 anyway.
[...]
Is there an INI or HAL setting to tell LinuxCNC that the spindle
ismanually controlled?
Not that I'm aware of.
Of course an INI setting could be added to specify whether the spindle
is under LCNC control, but even without this, Rob's spindle-scaling
scheme should still work. If a fixed-speed spindle runs at 2000 RPM but
axis constraints limit max spindle speed to 1000 RPM, the program should
pause indefinitely waiting for the spindle-at-speed pin.
This behavior could be puzzling: the spindle is turning, but axes never
move, why? This might be addressed with a "spindle not coming to speed"
warning following some timeout.
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm check
- Failure action: raise warning
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning
John
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
s***@empirescreen.com
2017-01-27 04:24:20 UTC
Permalink
Raw Message
Ooh!! Can't wait to try it.


On Fri, 27 Jan 2017 03:44:01 +0000
Post by Robert Ellenberg
For anyone interested in trying this out, I have fixes / improvements in
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7-rebase
- Less intrusive warning messages if the spindle is too fast
- Spindle RPM limit calculation should work properly now
- Improved (again) algorithm for position tracking that should have even
less acceleration ripple.
Best,
Rob
Post by John Morris
If you run a program with G33 moves in it and the spindle isn't
turning, the program will silently hang waiting for index.
Additionally, a G33 move will wait for the spindle-at-speed pin. (See
below)
The run-time check sould of course use the actual spindle speed from
the encoder. If you don't have an encoder you can't do G33 anyway.
[...]
Is there an INI or HAL setting to tell LinuxCNC that the spindle
ismanually controlled?
Not that I'm aware of.
Of course an INI setting could be added to specify whether the spindle
is under LCNC control, but even without this, Rob's spindle-scaling
scheme should still work. If a fixed-speed spindle runs at 2000 RPM but
axis constraints limit max spindle speed to 1000 RPM, the program should
pause indefinitely waiting for the spindle-at-speed pin.
This behavior could be puzzling: the spindle is turning, but axes never
move, why? This might be addressed with a "spindle not coming to speed"
warning following some timeout.
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm check
- Failure action: raise warning
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning
John
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
sam sokolik
2017-01-27 20:18:32 UTC
Permalink
Raw Message
quick testing - I don't get the error until I actually try to create a
thread that is faster than the axis limit (for a given rpm) awesome!
(and it doesn't seem to pause at the end when there is an error)

Here is with the gain set to 1 (default)
Loading Image...

and set to .5
Loading Image...

Great work!
sam
Post by Robert Ellenberg
For anyone interested in trying this out, I have fixes / improvements in
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7-rebase
- Less intrusive warning messages if the spindle is too fast
- Spindle RPM limit calculation should work properly now
- Improved (again) algorithm for position tracking that should have even
less acceleration ripple.
Best,
Rob
Post by John Morris
If you run a program with G33 moves in it and the spindle isn't
turning, the program will silently hang waiting for index.
Additionally, a G33 move will wait for the spindle-at-speed pin. (See
below)
The run-time check sould of course use the actual spindle speed from
the encoder. If you don't have an encoder you can't do G33 anyway.
[...]
Is there an INI or HAL setting to tell LinuxCNC that the spindle
ismanually controlled?
Not that I'm aware of.
Of course an INI setting could be added to specify whether the spindle
is under LCNC control, but even without this, Rob's spindle-scaling
scheme should still work. If a fixed-speed spindle runs at 2000 RPM but
axis constraints limit max spindle speed to 1000 RPM, the program should
pause indefinitely waiting for the spindle-at-speed pin.
This behavior could be puzzling: the spindle is turning, but axes never
move, why? This might be addressed with a "spindle not coming to speed"
warning following some timeout.
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm check
- Failure action: raise warning
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning
John
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
John Morris
2017-02-10 00:00:34 UTC
Permalink
Raw Message
Post by sam sokolik
quick testing - I don't get the error until I actually try to create a
thread that is faster than the axis limit (for a given rpm) awesome!
(and it doesn't seem to pause at the end when there is an error)
This branch works for me, too.
Post by sam sokolik
Post by Robert Ellenberg
For anyone interested in trying this out, I have fixes / improvements in
- Less intrusive warning messages if the spindle is too fast
I like this warning, "Reducing spindle speed from XXXX to YYYY for
synched motion," better than my warning-after-timeout proposal below:
it's simpler and it's sufficient to debug a hang on machines where
spindle speed is fixed.
Post by sam sokolik
Post by Robert Ellenberg
Post by John Morris
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm check
- Failure action: raise warning
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning
I added the preview-time check onto Rob's branch, so IMO this work is
done. I updated the issue [1] for completeness.

[1]: https://github.com/LinuxCNC/linuxcnc/issues/167

Thank you Rob for this fix, and thanks to everyone's contributions on
this thread.

John
Robert Ellenberg
2017-02-11 03:28:31 UTC
Permalink
Raw Message
Nice work, John! The only outstanding TODO's in my branch are these minor
points:

- I added a few extra HAL pins to motion that may not be necessary
(motion.spindle-tracking-gain, and motion.pos-tracking-mode) except for
testing.
- With spindle tracking gains of less than 1, the position error settles
more slowly, which could indicate an algorithm issue.

Otherwise, it should be ready to use
Post by John Morris
Post by sam sokolik
quick testing - I don't get the error until I actually try to create a
thread that is faster than the axis limit (for a given rpm) awesome!
(and it doesn't seem to pause at the end when there is an error)
This branch works for me, too.
Post by sam sokolik
Post by Robert Ellenberg
For anyone interested in trying this out, I have fixes / improvements in
- Less intrusive warning messages if the spindle is too fast
I like this warning, "Reducing spindle speed from XXXX to YYYY for
it's simpler and it's sufficient to debug a hang on machines where
spindle speed is fixed.
Post by sam sokolik
Post by Robert Ellenberg
Post by John Morris
- Input: S value
- Applicability: any machine
- Fixed-speed spindles: operator must program S to benefit fm
check
Post by sam sokolik
Post by Robert Ellenberg
Post by John Morris
- Failure action: raise warning
- Input: spindle encoder output
- Applicability: any machine with spindle encoder
- No spindle encoder: hang waiting for index; see next
- Failure action: scale spindle speed
- After timeout on index/spindle-at-speed pins, raise warning
I added the preview-time check onto Rob's branch, so IMO this work is
done. I updated the issue [1] for completeness.
[1]: https://github.com/LinuxCNC/linuxcnc/issues/167
Thank you Rob for this fix, and thanks to everyone's contributions on
this thread.
John
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
TJoseph Powderly
2017-01-31 17:07:12 UTC
Permalink
Raw Message
is the message list really this dead?
meaning: not even one msg from gene for days?
hard to believe!
paranoia: is this a result of the new regime?
if so, thanks for the (shared) memories (Bob Hope)
regards tjtr33 tomp
Nicklas Karlsson
2017-01-31 17:44:16 UTC
Permalink
Raw Message
No I am still alive though I am working all days so time is quite limited.

I am thinking about howto implement configuration of drivers, maybe CANopen over Ethernet and i needed possible UART/SPI. What is needed is essentially a standard message format for configuration and even though there there are demands on what dictionary entries should be available configuration tool will probably work fine even if only those entries used are implemented.

I tried to run one of my machines this weekend but below zero degree Celsius is really to cold to work with small cables.



On Wed, 1 Feb 2017 00:07:12 +0700
Post by TJoseph Powderly
is the message list really this dead?
meaning: not even one msg from gene for days?
hard to believe!
paranoia: is this a result of the new regime?
if so, thanks for the (shared) memories (Bob Hope)
regards tjtr33 tomp
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
TJoseph Powderly
2017-02-01 02:19:32 UTC
Permalink
Raw Message
well I'm glad its not silence, just busy quiet.
for myself I'm building 3.3 to 5V level shifters for a pci parport card
and playing in hal.
so happy lunar new year! gung hey fat choi! sawatdii pi mai!
tomp tjtr33
Gene Heskett
2017-02-01 04:18:08 UTC
Permalink
Raw Message
Post by TJoseph Powderly
well I'm glad its not silence, just busy quiet.
for myself I'm building 3.3 to 5V level shifters for a pci parport
card and playing in hal.
so happy lunar new year! gung hey fat choi! sawatdii pi mai!
tomp tjtr33
Hey now, them fur eastern languages don't grok on this side of the big
pond. Leastways here in WV.

I am reminded of our now deceased, and longest ever serving Senator from
West Virginia, Robert C. Byrd who had an excellent command of English.
He was so good at the flowery language that he could tell his esteemed
colleague across the political aisle, to go to hell in such flowery
language that he would look forward to the trip.

I have a feeling that you could do that in several languages endemic to
your side of the big pond. Unfortunately its a talent I never seemed to
have learned, let alone mastered. And I envy those that have.


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Kirk Wallace
2017-01-31 17:48:29 UTC
Permalink
Raw Message
Post by TJoseph Powderly
is the message list really this dead?
meaning: not even one msg from gene for days?
hard to believe!
paranoia: is this a result of the new regime?
if so, thanks for the (shared) memories (Bob Hope)
regards tjtr33 tomp
It might be a good sign that everything is working so well that no one
needs help or nothing needs to be fixed.

I am joking, but on the other hand. I'm on plenty of mailing lists for
software I use every day, but mostly just work (gPhoto, OpenWRT,
FreeType, come to mind).

I'm so busy, I'm finding that I don't post nearly as much as I used to.

I got a new project a couple of days ago when a friend calls up and says
"I have a lathe sitting on my trailer. When can I bring it over?".
It's a Tida Samson TD-1336 (13" x 36") and dated 1982, made in Taiwan.
It's really dirty, but doesn't look like it has been used a lot form
looking at the wear. It looks like someone didn't have a clue about
lathes from all the hammer and pipe wrench marks on the chuck and
spindle. It has a D1-4 spindle and it seems they didn't know about cam
locks. The back gears are totally stripped out.

The plan for now is to clean it up, change to a 3-phase motor/VFD and
belt drive, remove the change gears and install a ball screw and servo
for Z, remove the saddle apron and add a ball screw and servo for X. I'm
missing a tail stock. The chuck wobbles on the spindle taper, so the
spindle or chuck plate needs to be reground.

Or if I can find parts, I may restore it to original.

I'll start a different thread with pictures if I can get a start on this
project.
--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/
Gene Heskett
2017-01-31 17:54:33 UTC
Permalink
Raw Message
Post by TJoseph Powderly
is the message list really this dead?
meaning: not even one msg from gene for days?
hard to believe!
paranoia: is this a result of the new regime?
if so, thanks for the (shared) memories (Bob Hope)
regards tjtr33 tomp
Chuckle, many thanks for the concern Tomp, but I'm down for more fixes,
the $#%!^ noise finally blew my 7i90 card into the next drainage. More
7i90's are on the way.

I did find the keyboard problem, a couple of those clamp-on ferrite
chokes on the usb cable right at the pi's jack fixed it right up. Then
I blew the 7i90 card while putting a bigger one of those chokes on the
UVW wires coming out of the VFD.

So I've been working on other stuffs. Like the chuck locking clamps,
which are about 2/3rds done. Then I went to Bridgeport yesterday and
bought 10 feet of BX to use as spindle motor power, which should shield
some of the UVW radiated noise, and some more conduit and a box big
enough to hide one of the Corcom 20 amp brick wall filters a few inches
from the line lugs on the VFD. I hope to have all that done by the time
the new 7i90's arrive. That box should also have a pair of 40 amp SSR's
in it, switched by linuxcnc, to act as motor power switches. So I have
2-3 days work laid out in front of me yet before I start pestering you
kind folks again. Enjoy th vacation :)

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Linden
2017-01-31 19:34:24 UTC
Permalink
Raw Message
I'm still here thinking the same.
Post by TJoseph Powderly
is the message list really this dead?
meaning: not even one msg from gene for days?
hard to believe!
paranoia: is this a result of the new regime?
if so, thanks for the (shared) memories (Bob Hope)
regards tjtr33 tomp
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
John Thornton
2017-01-23 19:20:13 UTC
Permalink
Raw Message
For spindles that don't have control all you need is M3/4 S1.

JT
Post by Robert Ellenberg
John, you raise a good point here. The general assumption is that the S
word is a reasonable prediction of spindle speed. What do you think of
having a check at both interp time and runtime? That would cover all cases.
For machines like yours, we could suppress the interp-time error. Is there
an INI or HAL setting to tell LinuxCNC that the spindle is manually
controlled?
Post by John Kasunich
Post by John Morris
I also thought of these three possible intended scenarios pointed out in
1. The manual says it's an error, and it's up to the user to avoid it
(status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by adjusting
spindle speed
#3 is impossible for machines where spindle speed is not controlled by LCNC.
For example my lathe has only M3/M5. Single phase motor controlled by
contactor, with manually changed belts to the spindle.
#2 is possible during actual program execution - can't do G33 without a
spindle encoder, and if you have an encoder, you have spindle speed
feedback and can decide if the speed is OK.
But #2 may not be possible during generation of the preview. During
preview the spindle is not running. The only thing LCNC can do is assume
that the spindle speed will be whatever the most recent S-word specified.
But on a machine like mine, the S-word doesn't actually control anything.
IF the programmer is disciplined enough, he can use the S-word to tell
LCNC how fast he intends to run the spindle. But LCNC can't rely on that
being the actual spindle speed.
--
John Kasunich
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Gene Heskett
2017-01-23 17:29:22 UTC
Permalink
Raw Message
Post by John Kasunich
Post by John Morris
I also thought of these three possible intended scenarios pointed
out in this thread, and can think of valid arguments for each,
1. The manual says it's an error, and it's up to the user to avoid
it (status quo)
2. The controller detects the condition, and informs the user
3. The controller detects the condition, and compensates by
adjusting spindle speed
#3 is impossible for machines where spindle speed is not controlled by
LCNC. For example my lathe has only M3/M5. Single phase motor
controlled by contactor, with manually changed belts to the spindle.
#2 is possible during actual program execution - can't do G33 without
a spindle encoder, and if you have an encoder, you have spindle speed
feedback and can decide if the speed is OK.
I'd like to see that be a show stopper in the same vein as an arc that
doesn't compute. In this case I'd compare it with a factored velocity,
like 110% of what the encoder says to make double sure the accel time to
z speed really does have time to git-r-done.

I can imagine, but haven't tried to code it in hal yet, that we might be
able to block the index while the spindle is decelerating to a safe
speed, then enable the index path for the duration of that cut, and
release it back to the commanded speed. But would that not mean that hal
needs access to both the spindle rpm and the tpi the g33 needs? To be
investigated once I get the noise under control. Its getting into the
spi buss too. I got a joint error where it reported the position of x,
moving at zero speed, was suddenly 10000 feet from where it was supposed
to be. That can only be gross interference with the spi bus IMO.
Post by John Kasunich
But #2 may not be possible during generation of the preview. During
preview the spindle is not running. The only thing LCNC can do is
assume that the spindle speed will be whatever the most recent S-word
specified. But on a machine like mine, the S-word doesn't actually
control anything. IF the programmer is disciplined enough, he can use
the S-word to tell LCNC how fast he intends to run the spindle. But
LCNC can't rely on that being the actual spindle speed.
The catch-22. :) In your case & similar fixed speed no encoder situations
John, could you do an s number in your gcode 10% faster than the
nameplate speed for that belt position?

Otoh, I see this is becoming quite complex, trying to cover ALL
possibilities. Trying to save us from our own idiocy is frequently an
arduous task. So how about a halui button to check the file for
violations based on the s-word value at the time the g33/G76 code was
encountered in the file? Perhaps that would be easier?

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
John Kasunich
2017-01-23 18:10:00 UTC
Permalink
Raw Message
Post by Gene Heskett
The catch-22. :) In your case & similar fixed speed no encoder situations
John, could you do an s number in your gcode 10% faster than the
nameplate speed for that belt position?
I have an encoder.

An encoder (at least a single pulse per rev) is an absolute must for threading.

What I don't have is a VFD or other computer-controllable speed changer.
Post by Gene Heskett
Otoh, I see this is becoming quite complex, trying to cover ALL
possibilities. Trying to save us from our own idiocy is frequently an
arduous task.
Indeed. At some point the complexity introduced by trying to detect bugs
in the g-code will wind up introducing bugs of its own.
Post by Gene Heskett
So how about a halui button to check the file for
violations based on the s-word value at the time the g33/G76 code was
encountered in the file? Perhaps that would be easier?
No halui button needed. The preview can do the violation check. As
you say, it would use the s-word in effect at the point the G33 is encountered.


John Kasunich
***@fastmail.fm
Gene Heskett
2017-01-24 00:55:15 UTC
Permalink
Raw Message
Post by John Kasunich
Post by Gene Heskett
The catch-22. :) In your case & similar fixed speed no encoder
situations John, could you do an s number in your gcode 10% faster
than the nameplate speed for that belt position?
I have an encoder.
An encoder (at least a single pulse per rev) is an absolute must for threading.
What I don't have is a VFD or other computer-controllable speed changer.
After the fact conversion is pretty straight fwd, does involve money
though. I was lucky and stumbled over a air compressor with hospital
redundancy, 2 independently controlled 1 hp 3 phase motors feeding one
tank. I made the guy an offer of $50 for both of them and when I
indicated I was buying a pig in a poke since they were in unk condition,
he decided to get out the smith wrench and cut them off the mount pads.

It turned out one had some lumpy bearings so I bought two sets and put on
in, and its under the pedestal now.

But a change in the grease formula in the upper countershaft made little
diff in the bearing temps, so I guess I measure the shaft to fit some
torrington needles, pull the spindle and that shaft so I can put fresh,
not so lumpy belts in while I have it apart, but may have to get someone
else to ream the bearing holes to fit the torringtons as I looked at the
yoke this afternoon & theres no way in hell I can swing that in TLM to
do that bore job. Obviously I can't run my spindle with it while I bore
it. Nor do I have the reamers it would take. So we're still cogitating
on it. I even lowered all the belt tensions until it was slowing from
the drag as it warmed up in 3rd gear. Bearing temps in 6 or 7 minutes
were flirting with 150F. So I'm not going to be able to use more than
2nd gear until I do do something about it.
Post by John Kasunich
Post by Gene Heskett
Otoh, I see this is becoming quite complex, trying to cover ALL
possibilities. Trying to save us from our own idiocy is frequently
an arduous task.
Indeed.
In fact I'm surprised you didn't amplify that a bit.
Post by John Kasunich
At some point the complexity introduced by trying to detect
bugs in the g-code will wind up introducing bugs of its own.
There is that aspect too.
Post by John Kasunich
Post by Gene Heskett
So how about a halui button to check the file for
violations based on the s-word value at the time the g33/G76 code
was encountered in the file? Perhaps that would be easier?
No halui button needed. The preview can do the violation check. As
you say, it would use the s-word in effect at the point the G33 is encountered.
Would that not add an objectionable time delay while loading old, well
tested code? TANSTAAFL principle. OTOH, we'd get used to in time.
Post by John Kasunich
John Kasunich
Good conversation John, thank you very much.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
andy pugh
2017-01-20 15:01:46 UTC
Permalink
Raw Message
Post by John Kasunich
I think it is a terminology thing. Where the manual says "it is an error",
read it to mean "if you do this, you made an error and all bets are off",
rather than "if you do this, LCNC will detect and report it".
Having said that, LinuxCNC is in a better position to spot the problem
than the user.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Gene Heskett
2017-01-20 19:27:55 UTC
Permalink
Raw Message
Post by andy pugh
Post by John Kasunich
I think it is a terminology thing. Where the manual says "it is an
error", read it to mean "if you do this, you made an error and all
bets are off", rather than "if you do this, LCNC will detect and
report it".
Having said that, LinuxCNC is in a better position to spot the problem
than the user.
+1000 Andy.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Gene Heskett
2017-01-20 19:24:15 UTC
Permalink
Raw Message
Post by John Morris
The manual for G33 spindle synchronized motion [1] reads, "It is an
error if [...] The requested linear motion exceeds machine velocity
limits due to the spindle speed."
It seems that doing that actually doesn't cause an error, as
demonstrated by the regression test in the top commit here [2].
Instead, the G33 command is happily executed with the axis velocity
limited to its `MAX_VELOCITY` from the INI file, thus cutting threads
with smaller pitch than specified in the K flag.
Is this something that should be fixed, or am I reading the
documentation wrong?
The docs are right, but should emphasize that its an operator error

I have ran into that on TLM, quite some time back.

With my toothpick sized oar, I was resigned to adding that to my
g33-wrapper.ngc, but found my ngc code had no access to the .ini scripts
maxvel.

IMO, this error condition really belongs right in the G33 code for
everyones edification. With 3 possible outcomes.

1, its fits, and results in using less than 75% of the axis's capability
usage while accelerating to lock step speed, do it silently.

2, it can do it but uses more than 75% of that axis's ability at that
spindle rpm, do it, but warn that the spindle speed should not be
raised.

3, Issue the error and refuse to do it, stopping lcnc without any
movement at all, hopefully saving the part, and allowing you to edit a
lower speed (via an s command with a suitable wait for speed) into your
code for the next run. That of course is only possible if you CAN
control the spindle from g-code. Those that cannot, can only select a
lower rpm by changing the belts, or even bringing in the backgear, but
that would stretch the whole things execution time, killing profits.

Humm, could this test and advice be added to the initial file scan as its
being (re)loaded? That would seem to be an acceptable alternative, and
just as educational to the operator.

Catching the error at that point would save the operator lots of time as
it could be corrected before the r key was touched. Any method of
warning makes an encoderized spindle mandatory of course.

My $0.02, thanks for triggering some old memories John.
Post by John Morris
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g33-tech-info
https://github.com/zultron/machinekit/tree/spindlesync-exceeds-maxvel-
lcnc
Thanks-
John
----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Loading...