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
On 01/27/2017 02:18 PM, sam sokolik wrote:
> 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.
> On
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)
Ooh!! Can't wait to try it.
On Fri, 27 Jan 2017 03:44:01 +
Robert Ellenberg wrote:
> For anyone interested in trying this out, I have fixes / improvements in
> this branch now:
>
>
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
On 01/23/2017 12:05 PM, John Kasunich wrote:
> 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
On Monday 23 January 2017 13:10:00 John Kasunich wrote:
> On Mon, Jan 23, 2017, at 12:29 PM, Gene Heskett wrote:
> > 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
For spindles that don't have control all you need is M3/4 S1.
JT
On 1/23/2017 11:18 AM, Robert Ellenberg wrote:
> 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
On Mon, Jan 23, 2017, at 12:29 PM, Gene Heskett wrote:
>
> 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
On Mon, Jan 23, 2017, at 12:18 PM, Robert Ellenberg wrote:
> 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
On Monday 23 January 2017 10:43:21 John Kasunich wrote:
> On Sat, Jan 21, 2017, at 04:28 AM, John Morris wrote:
> > 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
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
On Saturday 21 January 2017 04:28:00 John Morris wrote:
> On 01/20/2017 08:30 AM, Robert Ellenberg wrote:
> > On Fri, Jan 20, 2017, 9:22 AM John Kasunich
wrote:
> >> On Fri, Jan 20, 2017, at 07:46 AM, John Morris wrote:
> >>> The manual for G33 spindle synchronized
On 01/20/2017 08:30 AM, Robert Ellenberg wrote:
> On Fri, Jan 20, 2017, 9:22 AM John Kasunich wrote:
>
>>
>>
>> On Fri, Jan 20, 2017, at 07:46 AM, John Morris wrote:
>>> The manual for G33 spindle synchronized motion [1] reads, "It is an
>>> error if [...] The requested
On Friday 20 January 2017 11:17:30 Jon Elson wrote:
> On 01/20/2017 07:01 AM, Robert Ellenberg wrote:
> > 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:
> >
> >
On Friday 20 January 2017 10:01:46 andy pugh wrote:
> On 20 January 2017 at 14:19, John Kasunich
wrote:
> > 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",
On Friday 20 January 2017 07:46:59 John Morris wrote:
> 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
>
On 01/20/2017 07:01 AM, Robert Ellenberg wrote:
> 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
On 20 January 2017 at 14:19, John Kasunich wrote:
> 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.
On Fri, Jan 20, 2017, 9:22 AM John Kasunich wrote:
>
>
> On Fri, Jan 20, 2017, at
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].
21 matches
Mail list logo