Re: [Emc-developers] Max velocity slider and pure rotary motion

[EBo]

On Jan 14 2017 8:37 AM, Gene Heskett wrote:
> On Saturday 14 January 2017 08:39:44 EBo wrote:
>
> [...]
>
>> It seams a little heavy handed to repurpose M7-9.  My not just 
>> define
>> your own M101-199?
>
> I probably should have, but this way I have check-button controls for
> both with a mouse click. Lcnc axis needs to grow the ability to put 
> more
> labeled check boxes on the left, control panel, just for such uses.  
> So
> I used what it brung to the pot luck dinner.

Fair enough.

>> That does pose the question that vacuum chip
>> removal that we should probably find and implement a code for it (or 
>> a
>> code that toggles yet another power plug).  I can intuit repurposing 
>> a
>> power switch for the vacuum, but if anyone reads your code they 
>> might
>> not know that you repurposed the coolant to vacuum on that machine.
>
> The actual control is by switching a charge pump, which results in 
> about
> 500 ms lag. Seemed better than having the vacuum come on when lcnc 
> was
> stopped.  The charge pump detector in turn drives a ice cube to 
> switch
> half of a duplex.

The charge pump can be pulled low, and then pumped back up, but yes, 
failure modes and power cycling behaviour is very important.

>> Also, if there is any type of feedback line, you could try putting a
>> pressure regulator in line, or maybe a delay circuit/relay in the
>> path. I once had a machine with something like this
>>  wired in.  What 
>> I
>> am thinking is that a change of state of the air valve triggers a 
>> 1.5
>> second signal trigger.  You may be able to wire it inline with
>> whatever you use to read tool-touchoffs and as soon as the line goes
>> active again, you continue the program.  Just a thought, and without
>> looking at the schematics of your machine I am not sure what could 
>> be
>> wrangled.
>
> The pressure switch, with a huge mechanical hysteresis I can get at 
> TSC,
> and if the tire pump ever gets assembled, would be used as the 
> pressure
> tally.
>
>> Also, isn't there some way to access any GPIO pins external to the
>> main controller?  Somewhere I thought I saw someone hooking up an
>> arduino, triggering a program, and waiting for a response.  Maybe 
>> that
>> was not with LCNC...
>
> Someone probably has. :) But I am nearly out of gpio on that 5i25 as 
> both
> ports are hooked up now, and if I ever put a rotary table on it, I'll
> have to move whats gpio on p3 since there doesn't seem to be a way to
> specify where (p2-p3) another stepgen would appear if enabled. The
> config has an A axis, commented put because I needed the gpio for
> something else, home switches maybe as I had not at that point added 
> a
> bob on p2. I need to change my style, and put gpio useage starting at
> the top of p2. Thats what I am doing with the 7i90 on this lathe. 
> gpio
> stuff, like the controls for the SpinX1 for the vfd, are all on the 
> top
> end of P3, at gpio.071, 070, and 069. So I can add all sorts of stuff
> w/o haveing to rewire stuff later.

Good note on planning forward.

>> Anyway, hope that helps.
>
> It gets the discussion going, and shows a bit of learning on my part 
> too.

That is what I was really hoping.  Basically you pointed out a couple 
of shortcommings on the UI design, and suggestions on layout.  Might 
make the beginnings of a nice section in the docs, on recommended layout 
rational.

   Best of luck!

   EBo --

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

[Gene Heskett]

On Saturday 14 January 2017 08:39:44 EBo wrote:

[...]

> It seams a little heavy handed to repurpose M7-9.  My not just define
> your own M101-199?

I probably should have, but this way I have check-button controls for 
both with a mouse click. Lcnc axis needs to grow the ability to put more 
labeled check boxes on the left, control panel, just for such uses.  So 
I used what it brung to the pot luck dinner.

> That does pose the question that vacuum chip 
> removal that we should probably find and implement a code for it (or a
> code that toggles yet another power plug).  I can intuit repurposing a
> power switch for the vacuum, but if anyone reads your code they might
> not know that you repurposed the coolant to vacuum on that machine.

The actual control is by switching a charge pump, which results in about 
500 ms lag. Seemed better than having the vacuum come on when lcnc was 
stopped.  The charge pump detector in turn drives a ice cube to switch 
half of a duplex.

> Also, if there is any type of feedback line, you could try putting a
> pressure regulator in line, or maybe a delay circuit/relay in the
> path. I once had a machine with something like this
>  wired in.  What I
> am thinking is that a change of state of the air valve triggers a 1.5
> second signal trigger.  You may be able to wire it inline with
> whatever you use to read tool-touchoffs and as soon as the line goes
> active again, you continue the program.  Just a thought, and without
> looking at the schematics of your machine I am not sure what could be
> wrangled.

The pressure switch, with a huge mechanical hysteresis I can get at TSC, 
and if the tire pump ever gets assembled, would be used as the pressure 
tally.

> Also, isn't there some way to access any GPIO pins external to the
> main controller?  Somewhere I thought I saw someone hooking up an
> arduino, triggering a program, and waiting for a response.  Maybe that
> was not with LCNC...

Someone probably has. :) But I am nearly out of gpio on that 5i25 as both 
ports are hooked up now, and if I ever put a rotary table on it, I'll 
have to move whats gpio on p3 since there doesn't seem to be a way to 
specify where (p2-p3) another stepgen would appear if enabled. The 
config has an A axis, commented put because I needed the gpio for 
something else, home switches maybe as I had not at that point added a 
bob on p2. I need to change my style, and put gpio useage starting at 
the top of p2. Thats what I am doing with the 7i90 on this lathe. gpio 
stuff, like the controls for the SpinX1 for the vfd, are all on the top 
end of P3, at gpio.071, 070, and 069. So I can add all sorts of stuff 
w/o haveing to rewire stuff later.

> Anyway, hope that helps.

It gets the discussion going, and shows a bit of learning on my part too.

>EBo --

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 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

[EBo]

On Jan 14 2017 3:40 AM, Gene Heskett wrote:
> On Saturday 14 January 2017 04:09:28 John Morris wrote:
>
>> On 01/13/2017 08:39 AM, Gene Heskett wrote:
>> > On Friday 13 January 2017 04:05:51 John Morris wrote:
>> >> On 01/07/2017 02:42 AM, John Morris wrote:
>> >>> I've been asked about some seemingly unintuitive behavior:  the
>> >>> max velocity slider is not applied to rotary-only motion.  You 
>> can
>> >>> try this yourself by running the `axis_9axis.ini` config, 
>> setting
>> >>> the max velocity slider to zero, and noting rotary axes still 
>> move
>> >>> after e.g. `g0 a180 f40`.
>> >>
>> >> So, I now have a proof-of-concept branch that plumbs a max 
>> angular
>> >> velocity from the UI to TP and back.  Similar to max [linear]
>> >> velocity, it uses units (degree)/minute.  In the Axis GUI, it's
>> >> easy to scale max angular velocity proportionally to (max
>> >> velocity)/([DISPLAY]MAX_LINEAR_VELOCITY) wrt
>> >> [DISPLAY]MAX_ANGULAR_VELOCITY.  The plumbing involves adding 
>> extra
>> >> args or fields to existing functions, structs and NML messages
>> >> related to max velocity, so when one is set, the other is always
>> >> set at the same time.
>> >>
>> >> However, I'm leaning away from submitting the changes for 
>> mainline
>> >> inclusion.  My heart isn't really in this one, and I'm not 
>> feeling
>> >> the passion for doing what it takes to ready it for GA (sincere
>> >> thanks to Norbert for offering to do the gmoccapy integration!),
>> >> although I'm happy to push it somewhere if anyone's curious.
>> >> Thanks again for all the replies.
>> >>
>> >>   John
>> >
>> > This one I can see a need for. I don't often have my table mounted
>> > and plugged in, but I have often, thru sloppy coding no doubt, had
>> > lcnc ask the table for a faster move than the motor can muster up
>> > because that cheap $100 when I bought it years ago table has so 
>> much
>> > backlash that I've tightened it up so that I need to apply an
>> > airhose to exert some internal lifting pressure by easing the
>> > holddowns friction, an air bearing of sorts. I made a hole into 
>> the
>> > side of the base casting, and a hole in the bearing face that
>> > intersected that hole, and a groove for that air all the way 
>> around
>> > the face of the base casting. Without that, perhaps a whole minute
>> > for a whole 360 turn. any faster and the motor will stall as its
>> > only a 220oz nema23.  I've a 12 volt compressor I've always 
>> intended
>> > to rig so I could turn it on with gcode, wait a second for 
>> pressure,
>> > and turn it off when the move was done. But so far that itch 
>> hasn't
>> > been scratched. What I really need is a bigger table that doesn't
>> > mount the motor at an angle so its always hitting something.
>> >
>> > So this one I'll vote up by 1.  Being able to limit it, and make 
>> the
>> > rest of the program wait on the slow table, would be helpful to 
>> me.
>>
>> As long as your rotary axis has a correct e.g. 
>> `[AXIS_3]MAX_VELOCITY`
>> parameter set, mainline LCNC will do the right thing, and the linear
>> axes' velocity will be limited as appropriate by the rotary axis to
>> produce coordinated motion (the converse is also true).  I actually
>> wrote a unit test in this branch that verifies this.  So if I'm
>> understanding your concern, you're already covered, and don't need
>> these changes.
>>
>> These changes apply only to those wishing to apply the max angular
>> velocity slider setting (whether combined with or separate from the
>> existing max velocity slider) to pure rotary motion.  Many folks
>> needing needing to limit pure rotary motion can still use feedrate 
>> (in
>> degrees/minute) for pure rotary G01 A/B/C moves, and there's a
>> separate angular jog speed slider in Axis that appears when a rotary
>> axis is configured.
>>
>>  John
>
> What I would try and do, is a wrapper around the angular motion that
> starts the little compressor, but exerts a motion hold for long 
> enough
> for the pressure to come up and free the table, say about 1.5 
> seconds,
> then does the move at 10x the speed, then stops the compressor, 
> exerting
> a motion hold for about thats same 1.5 seconds while the pressure 
> bleeds
> away. Both motion holds would of course be queue breakers, but for 
> long
> moves, like sharpening a tool with a diamond disk, where the moves 
> would
> be say 95 degrees, it would still be faster.
>
> Sure, I can write it in gcode, but making it work completely self
> contained would be handier than that famous sliced bread or bottled
> beer. As is I have to set that angular speed limit to about 5% of 
> what
> it can do if 100 psi of air is being fed into the face groove.
>
> So, I guess I'll keep writing code the old way. But I'd still need 2 
> or 3
> more mist/flood type of control signals out of motion on the G0704 as 
> I
> have already repurposed both mist and flood, the m7-8-9 functions on
> that machine. m7 turns on the vacuum cleaner for chip 

Re: [Emc-developers] Max velocity slider and pure rotary motion

[Gene Heskett]

On Saturday 14 January 2017 04:09:28 John Morris wrote:

> On 01/13/2017 08:39 AM, Gene Heskett wrote:
> > On Friday 13 January 2017 04:05:51 John Morris wrote:
> >> On 01/07/2017 02:42 AM, John Morris wrote:
> >>> I've been asked about some seemingly unintuitive behavior:  the
> >>> max velocity slider is not applied to rotary-only motion.  You can
> >>> try this yourself by running the `axis_9axis.ini` config, setting
> >>> the max velocity slider to zero, and noting rotary axes still move
> >>> after e.g. `g0 a180 f40`.
> >>
> >> So, I now have a proof-of-concept branch that plumbs a max angular
> >> velocity from the UI to TP and back.  Similar to max [linear]
> >> velocity, it uses units (degree)/minute.  In the Axis GUI, it's
> >> easy to scale max angular velocity proportionally to (max
> >> velocity)/([DISPLAY]MAX_LINEAR_VELOCITY) wrt
> >> [DISPLAY]MAX_ANGULAR_VELOCITY.  The plumbing involves adding extra
> >> args or fields to existing functions, structs and NML messages
> >> related to max velocity, so when one is set, the other is always
> >> set at the same time.
> >>
> >> However, I'm leaning away from submitting the changes for mainline
> >> inclusion.  My heart isn't really in this one, and I'm not feeling
> >> the passion for doing what it takes to ready it for GA (sincere
> >> thanks to Norbert for offering to do the gmoccapy integration!),
> >> although I'm happy to push it somewhere if anyone's curious. 
> >> Thanks again for all the replies.
> >>
> >>John
> >
> > This one I can see a need for. I don't often have my table mounted
> > and plugged in, but I have often, thru sloppy coding no doubt, had
> > lcnc ask the table for a faster move than the motor can muster up
> > because that cheap $100 when I bought it years ago table has so much
> > backlash that I've tightened it up so that I need to apply an
> > airhose to exert some internal lifting pressure by easing the
> > holddowns friction, an air bearing of sorts. I made a hole into the
> > side of the base casting, and a hole in the bearing face that
> > intersected that hole, and a groove for that air all the way around
> > the face of the base casting. Without that, perhaps a whole minute
> > for a whole 360 turn. any faster and the motor will stall as its
> > only a 220oz nema23.  I've a 12 volt compressor I've always intended
> > to rig so I could turn it on with gcode, wait a second for pressure,
> > and turn it off when the move was done. But so far that itch hasn't
> > been scratched. What I really need is a bigger table that doesn't
> > mount the motor at an angle so its always hitting something.
> >
> > So this one I'll vote up by 1.  Being able to limit it, and make the
> > rest of the program wait on the slow table, would be helpful to me.
>
> As long as your rotary axis has a correct e.g. `[AXIS_3]MAX_VELOCITY`
> parameter set, mainline LCNC will do the right thing, and the linear
> axes' velocity will be limited as appropriate by the rotary axis to
> produce coordinated motion (the converse is also true).  I actually
> wrote a unit test in this branch that verifies this.  So if I'm
> understanding your concern, you're already covered, and don't need
> these changes.
>
> These changes apply only to those wishing to apply the max angular
> velocity slider setting (whether combined with or separate from the
> existing max velocity slider) to pure rotary motion.  Many folks
> needing needing to limit pure rotary motion can still use feedrate (in
> degrees/minute) for pure rotary G01 A/B/C moves, and there's a
> separate angular jog speed slider in Axis that appears when a rotary
> axis is configured.
>
>   John

What I would try and do, is a wrapper around the angular motion that 
starts the little compressor, but exerts a motion hold for long enough 
for the pressure to come up and free the table, say about 1.5 seconds, 
then does the move at 10x the speed, then stops the compressor, exerting 
a motion hold for about thats same 1.5 seconds while the pressure bleeds 
away. Both motion holds would of course be queue breakers, but for long 
moves, like sharpening a tool with a diamond disk, where the moves would 
be say 95 degrees, it would still be faster.

Sure, I can write it in gcode, but making it work completely self 
contained would be handier than that famous sliced bread or bottled 
beer. As is I have to set that angular speed limit to about 5% of what 
it can do if 100 psi of air is being fed into the face groove.

So, I guess I'll keep writing code the old way. But I'd still need 2 or 3 
more mist/flood type of control signals out of motion on the G0704 as I 
have already repurposed both mist and flood, the m7-8-9 functions on 
that machine. m7 turns on the vacuum cleaner for chip collection, and m8 
enables a positioning flapper to fall down when a new piece of wood is 
being mounted, and an m9 turns off the vacuum and lifts the flapper out 
of the way so its not destroyed by the machining of the same face 

Re: [Emc-developers] Max velocity slider and pure rotary motion

[John Morris]

On 01/13/2017 08:39 AM, Gene Heskett wrote:
> On Friday 13 January 2017 04:05:51 John Morris wrote:
>
>> On 01/07/2017 02:42 AM, John Morris wrote:
>>> I've been asked about some seemingly unintuitive behavior:  the max
>>> velocity slider is not applied to rotary-only motion.  You can try
>>> this yourself by running the `axis_9axis.ini` config, setting the
>>> max velocity slider to zero, and noting rotary axes still move after
>>> e.g. `g0 a180 f40`.
>>
>> So, I now have a proof-of-concept branch that plumbs a max angular
>> velocity from the UI to TP and back.  Similar to max [linear]
>> velocity, it uses units (degree)/minute.  In the Axis GUI, it's easy
>> to scale max angular velocity proportionally to (max
>> velocity)/([DISPLAY]MAX_LINEAR_VELOCITY) wrt
>> [DISPLAY]MAX_ANGULAR_VELOCITY.  The plumbing involves adding extra
>> args or fields to existing functions, structs and NML messages related
>> to max velocity, so when one is set, the other is always set at the
>> same time.
>>
>> However, I'm leaning away from submitting the changes for mainline
>> inclusion.  My heart isn't really in this one, and I'm not feeling the
>> passion for doing what it takes to ready it for GA (sincere thanks to
>> Norbert for offering to do the gmoccapy integration!), although I'm
>> happy to push it somewhere if anyone's curious.  Thanks again for all
>> the replies.
>>
>>  John
>>
> This one I can see a need for. I don't often have my table mounted and
> plugged in, but I have often, thru sloppy coding no doubt, had lcnc ask
> the table for a faster move than the motor can muster up because that
> cheap $100 when I bought it years ago table has so much backlash that
> I've tightened it up so that I need to apply an airhose to exert some
> internal lifting pressure by easing the holddowns friction, an air
> bearing of sorts. I made a hole into the side of the base casting, and a
> hole in the bearing face that intersected that hole, and a groove for
> that air all the way around the face of the base casting. Without that,
> perhaps a whole minute for a whole 360 turn. any faster and the motor
> will stall as its only a 220oz nema23.  I've a 12 volt compressor I've
> always intended to rig so I could turn it on with gcode, wait a second
> for pressure, and turn it off when the move was done. But so far that
> itch hasn't been scratched. What I really need is a bigger table that
> doesn't mount the motor at an angle so its always hitting something.
>
> So this one I'll vote up by 1.  Being able to limit it, and make the rest
> of the program wait on the slow table, would be helpful to me.

As long as your rotary axis has a correct e.g. `[AXIS_3]MAX_VELOCITY` 
parameter set, mainline LCNC will do the right thing, and the linear 
axes' velocity will be limited as appropriate by the rotary axis to 
produce coordinated motion (the converse is also true).  I actually 
wrote a unit test in this branch that verifies this.  So if I'm 
understanding your concern, you're already covered, and don't need these 
changes.

These changes apply only to those wishing to apply the max angular 
velocity slider setting (whether combined with or separate from the 
existing max velocity slider) to pure rotary motion.  Many folks needing 
needing to limit pure rotary motion can still use feedrate (in 
degrees/minute) for pure rotary G01 A/B/C moves, and there's a separate 
angular jog speed slider in Axis that appears when a rotary axis is 
configured.

John

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

[John Morris]

On 01/07/2017 02:42 AM, John Morris wrote:
> I've been asked about some seemingly unintuitive behavior:  the max
> velocity slider is not applied to rotary-only motion.  You can try this
> yourself by running the `axis_9axis.ini` config, setting the max
> velocity slider to zero, and noting rotary axes still move after e.g.
> `g0 a180 f40`.

So, I now have a proof-of-concept branch that plumbs a max angular 
velocity from the UI to TP and back.  Similar to max [linear] velocity, 
it uses units (degree)/minute.  In the Axis GUI, it's easy to scale max 
angular velocity proportionally to (max 
velocity)/([DISPLAY]MAX_LINEAR_VELOCITY) wrt 
[DISPLAY]MAX_ANGULAR_VELOCITY.  The plumbing involves adding extra args 
or fields to existing functions, structs and NML messages related to max 
velocity, so when one is set, the other is always set at the same time.

However, I'm leaning away from submitting the changes for mainline 
inclusion.  My heart isn't really in this one, and I'm not feeling the 
passion for doing what it takes to ready it for GA (sincere thanks to 
Norbert for offering to do the gmoccapy integration!), although I'm 
happy to push it somewhere if anyone's curious.  Thanks again for all 
the replies.

John

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

[John Morris]

Based on the feedback, I'll look for a way to use the one slider for 
both purposes, while preserving the absolute units/minute readout. 
Hopefully a dig into the code will reveal an elegant way to do that. 
Thanks for the helpful and encouraging replies!

John

On 01/07/2017 01:32 PM, Chris Morley wrote:
> It is still possible to have the MV slider display actual feed rate while the
>
> underlying code uses percentage.
>
> It just means the GUI must calculate what feedrate is that percentage of max 
> velocity  and
>
> display it. I've done the opposite in Gscreen to show MV as a percentage.
>
> Then everyobe can be happy []
> Chris M
> 
> From: sam sokolik <sa...@empirescreen.com>
> Sent: January 7, 2017 2:27 PM
> To: EMC developers
> Subject: Re: [Emc-developers] Max velocity slider and pure rotary motion
>
> I love the MV slider - use it all the time.  I need to know that
> feedrate because a lot of the time I am capping the velocity to the feed
> rate for testing (or just above)  I don't know the solution (as of right
> now I don't need to cap rotary only motion)  But the scaling of actual
> feed rate is a must for me.
>
> sam
>
> On 01/07/2017 04:16 AM, Niemand Sonst wrote:
>> Hallo John,
>>
>> I agree with you, that the actual behavior is not what a user expect.
>> Just changing max_vel to "%-Slider" is unfortunately not enough, as also
>> the GUI must be changed to support the new feature.
>>
>> I from my side can tell that for gmoccapy the amount of work is doable.
>> I will be pleased to do that.
>>
>> Norbert
>>
>> Am 07.01.2017 um 09:42 schrieb John Morris:
>>> I've been asked about some seemingly unintuitive behavior:  the max
>>> velocity slider is not applied to rotary-only motion.  You can try this
>>> yourself by running the `axis_9axis.ini` config, setting the max
>>> velocity slider to zero, and noting rotary axes still move after e.g.
>>> `g0 a180 f40`.
>>>
>>> This can't be trivially fixed by applying the max velocity setting to
>>> rotary-only motion.  Back in 2007, Chris explained [1] (referring to a
>>> document still available from NIST [2]) that feed rate in units/minute
>>> can be unintuitive for rotary-only motion, since the units are degrees
>>> instead of inches or millimeters.
>>>
>>> Ok, so damned if we do, and damned if we don't; then what are the other
>>> options?  Axis has a couple of instructive examples:
>>>
>>> - The rapid override slider reads on a percentage scale, and the same
>>> slider does what one would expect, both for linear and rotary-only motion.
>>>
>>> - The jog speed slider reads in linear units/minute, and when a rotary
>>> axis is configured a second slider reading in degrees/minute appears.
>>>
>>> Right now, I'm leaning toward recommending the max velocity slider be
>>> changed to a percentage scale and applied to both, similar to rapid
>>> override.  I'd love to hear other opinions.  Thanks-
>>>
>>>   John
>>>
>>> [1]: https://sourceforge.net/p/emc/mailman/message/13618943/
>>> [2]: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374
> The NIST RS274NGC Interpreter - Version 
> 3<http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374>
> ws680.nist.gov
> RS274/NGC Interpreter - Version 3 ii Disclaimer Commercial equipment and 
> materials are identified in order to specify certain procedures adequately.
>
>
>
>>>
>>> --
>>> 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
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> Emc-developers Info Page - 
> SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs 
> on Linux and is available under the terms of the GNU General Public License.
>
>
>
>>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> Slashdot: News for nerds, stuff that matters<http://sdm.link/slashdot>
> sdm.l

Re: [Emc-developers] Max velocity slider and pure rotary motion

[Chris Morley]

It is still possible to have the MV slider display actual feed rate while the

underlying code uses percentage.

It just means the GUI must calculate what feedrate is that percentage of max 
velocity  and

display it. I've done the opposite in Gscreen to show MV as a percentage.

Then everyobe can be happy []
Chris M

From: sam sokolik <sa...@empirescreen.com>
Sent: January 7, 2017 2:27 PM
To: EMC developers
Subject: Re: [Emc-developers] Max velocity slider and pure rotary motion

I love the MV slider - use it all the time.  I need to know that
feedrate because a lot of the time I am capping the velocity to the feed
rate for testing (or just above)  I don't know the solution (as of right
now I don't need to cap rotary only motion)  But the scaling of actual
feed rate is a must for me.

sam

On 01/07/2017 04:16 AM, Niemand Sonst wrote:
> Hallo John,
>
> I agree with you, that the actual behavior is not what a user expect.
> Just changing max_vel to "%-Slider" is unfortunately not enough, as also
> the GUI must be changed to support the new feature.
>
> I from my side can tell that for gmoccapy the amount of work is doable.
> I will be pleased to do that.
>
> Norbert
>
> Am 07.01.2017 um 09:42 schrieb John Morris:
>> I've been asked about some seemingly unintuitive behavior:  the max
>> velocity slider is not applied to rotary-only motion.  You can try this
>> yourself by running the `axis_9axis.ini` config, setting the max
>> velocity slider to zero, and noting rotary axes still move after e.g.
>> `g0 a180 f40`.
>>
>> This can't be trivially fixed by applying the max velocity setting to
>> rotary-only motion.  Back in 2007, Chris explained [1] (referring to a
>> document still available from NIST [2]) that feed rate in units/minute
>> can be unintuitive for rotary-only motion, since the units are degrees
>> instead of inches or millimeters.
>>
>> Ok, so damned if we do, and damned if we don't; then what are the other
>> options?  Axis has a couple of instructive examples:
>>
>> - The rapid override slider reads on a percentage scale, and the same
>> slider does what one would expect, both for linear and rotary-only motion.
>>
>> - The jog speed slider reads in linear units/minute, and when a rotary
>> axis is configured a second slider reading in degrees/minute appears.
>>
>> Right now, I'm leaning toward recommending the max velocity slider be
>> changed to a percentage scale and applied to both, similar to rapid
>> override.  I'd love to hear other opinions.  Thanks-
>>
>>   John
>>
>> [1]: https://sourceforge.net/p/emc/mailman/message/13618943/
>> [2]: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374
The NIST RS274NGC Interpreter - Version 
3<http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374>
ws680.nist.gov
RS274/NGC Interpreter - Version 3 ii Disclaimer Commercial equipment and 
materials are identified in order to specify certain procedures adequately.



>>
>> --
>> 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
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
Emc-developers Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on 
Linux and is available under the terms of the GNU General Public License.



>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Slashdot: News for nerds, stuff that matters<http://sdm.link/slashdot>
sdm.link
Slashdot: News for nerds, stuff that matters. Timely news source for technology 
related news with a heavy slant towards Linux and Open Source issues.



> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
Emc-developers Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on 
Linux and is available under the terms of the GNU General Public License.



>


--
Check out the vibrant 

Re: [Emc-developers] Max velocity slider and pure rotary motion

[sam sokolik]

I love the MV slider - use it all the time.  I need to know that 
feedrate because a lot of the time I am capping the velocity to the feed 
rate for testing (or just above)  I don't know the solution (as of right 
now I don't need to cap rotary only motion)  But the scaling of actual 
feed rate is a must for me.

sam

On 01/07/2017 04:16 AM, Niemand Sonst wrote:
> Hallo John,
>
> I agree with you, that the actual behavior is not what a user expect.
> Just changing max_vel to "%-Slider" is unfortunately not enough, as also
> the GUI must be changed to support the new feature.
>
> I from my side can tell that for gmoccapy the amount of work is doable.
> I will be pleased to do that.
>
> Norbert
>
> Am 07.01.2017 um 09:42 schrieb John Morris:
>> I've been asked about some seemingly unintuitive behavior:  the max
>> velocity slider is not applied to rotary-only motion.  You can try this
>> yourself by running the `axis_9axis.ini` config, setting the max
>> velocity slider to zero, and noting rotary axes still move after e.g.
>> `g0 a180 f40`.
>>
>> This can't be trivially fixed by applying the max velocity setting to
>> rotary-only motion.  Back in 2007, Chris explained [1] (referring to a
>> document still available from NIST [2]) that feed rate in units/minute
>> can be unintuitive for rotary-only motion, since the units are degrees
>> instead of inches or millimeters.
>>
>> Ok, so damned if we do, and damned if we don't; then what are the other
>> options?  Axis has a couple of instructive examples:
>>
>> - The rapid override slider reads on a percentage scale, and the same
>> slider does what one would expect, both for linear and rotary-only motion.
>>
>> - The jog speed slider reads in linear units/minute, and when a rotary
>> axis is configured a second slider reading in degrees/minute appears.
>>
>> Right now, I'm leaning toward recommending the max velocity slider be
>> changed to a percentage scale and applied to both, similar to rapid
>> override.  I'd love to hear other opinions.  Thanks-
>>
>>  John
>>
>> [1]: https://sourceforge.net/p/emc/mailman/message/13618943/
>> [2]: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374
>>
>> --
>> 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
>> Emc-developers@lists.sourceforge.net
>> 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
> Emc-developers@lists.sourceforge.net
> 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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Max velocity slider and pure rotary motion

[John Morris]

I've been asked about some seemingly unintuitive behavior:  the max 
velocity slider is not applied to rotary-only motion.  You can try this 
yourself by running the `axis_9axis.ini` config, setting the max 
velocity slider to zero, and noting rotary axes still move after e.g. 
`g0 a180 f40`.

This can't be trivially fixed by applying the max velocity setting to 
rotary-only motion.  Back in 2007, Chris explained [1] (referring to a 
document still available from NIST [2]) that feed rate in units/minute 
can be unintuitive for rotary-only motion, since the units are degrees 
instead of inches or millimeters.

Ok, so damned if we do, and damned if we don't; then what are the other 
options?  Axis has a couple of instructive examples:

- The rapid override slider reads on a percentage scale, and the same 
slider does what one would expect, both for linear and rotary-only motion.

- The jog speed slider reads in linear units/minute, and when a rotary 
axis is configured a second slider reading in degrees/minute appears.

Right now, I'm leaning toward recommending the max velocity slider be 
changed to a percentage scale and applied to both, similar to rapid 
override.  I'd love to hear other opinions.  Thanks-

John

[1]: https://sourceforge.net/p/emc/mailman/message/13618943/
[2]: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374

--
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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers