Back
[01:49:50] <lerman_> lerman_ is now known as lerman
[02:16:14] <jmkasunich_> hi guys
[02:19:09] <cradek> hi jmk
[02:19:18] <jmkasunich_> how's things?
[02:19:30] <cradek> great - everything is coming together on my lathe project
[02:19:35] <jmkasunich_> cool
[02:20:00] <cradek> all the guts are working, now I'm just shoehorning it all into a box etc
[02:20:01] <jmkasunich_> I saw a discussion about "link" and whether it should unlink
[02:20:12] <cradek> * cradek ducks
[02:20:34] <jmkasunich_> I have absolutely no problem with changing link so it doesn't unlink any pre-existing connection
[02:20:53] <jmkasunich_> (IOW, it fails if there is already a sig linked to that pin)
[02:21:23] <jepler> jmkasunich_: including hal_link() ?
[02:21:45] <jepler> if you feel that way, I'll be happy to implement it
[02:21:46] <jmkasunich_> I don't see why not
[02:21:48] <jepler> OK
[02:21:59] <jmkasunich_> * jmkasunich_ greps to see if anything other than halcmd calls hal_link
[02:22:18] <jepler> within emc, I don't think anything does
[02:22:47] <jmkasunich_> halrmt.c does
[02:22:49] <cradek> huh, I admit to expecting a big debate
[02:23:46] <jmkasunich_> actually I have less issue with changing the hal api than I do with changing the halcmd language
[02:23:50] <jmkasunich_> fewer people use the API
[02:25:03] <jmkasunich_> hmm
[02:25:15] <jmkasunich_> /* if sig is blank, want to unlink pin */
[02:25:16] <jmkasunich_> if (*sig == '\0') {
[02:25:16] <jmkasunich_> /* tell hal_link() to unlink the pin */
[02:25:18] <jmkasunich_> sig = NULL;
[02:25:19] <jmkasunich_> }
[02:25:24] <jmkasunich_> /* make the link */
[02:25:26] <jmkasunich_> retval = hal_link(pin, sig);
[02:25:27] <jmkasunich_> halrmt uses hal_link to do an unlink
[02:25:35] <jepler> so does halcmd I think
[02:26:26] <jepler> there's also the "was already linked to this signal" case, which I think was added around the time 'halcmd net' was
[02:26:42] <jepler> so that 'net x a b c; net x a b c' never temporarily unlinked any of the pins
[02:27:12] <jmkasunich_> I wonder what makes more sense? putting the "don't link if already hooked to another signal" logic in hal_link, or in halcmd?
[02:27:45] <jepler> on one side, halcmd is already doing a preflight before doing anything
[02:28:07] <jmkasunich_> seems like hal_link is overloaded, passing a NULL to do an unlink isn't exactly obvious behavior
[02:31:53] <jepler> halcmd: net x siggen.0.sine
[02:31:53] <jepler> halcmd: net y siggen.0.sine
[02:31:53] <jepler> HAL: ERROR: pin 'siggen.0.sine' was already linked, cannot link to 'y'
[02:31:53] <jepler> HAL:3: link failed
[02:31:53] <jepler> halcmd: net x siggen.0.sine
[02:31:55] <jepler> halcmd:
[02:32:33] <jmkasunich_> is that the existing preflight for net?
[02:32:40] <jmkasunich_> or did you just add that?
[02:32:50] <jepler> that's the new hal_link error
[02:33:02] <jepler> the preflight passed -- I should change it so that it does't.
[02:33:03] <jepler> doesn't
[02:33:57] <jmkasunich_> I'm messing with hal.h - the comment blocks that define what hal_link and hal_unlink do, I suppose I should just let you finish, doesn't make sense to have us both editing in there
[02:35:42] <jepler> OK I'll try to finish up--I am just adding the "already linked" check to hal_link, not changing the sig_name==NULL case
[02:40:21] <jepler> I hope I got it right
[02:41:22] <jmkasunich_> http://pastebin.ca/481965
[02:41:30] <jmkasunich_> * jmkasunich_ looks at the commit
[02:43:37] <jmkasunich_> your approach is less disruptive than adding hal_unlink
[02:43:49] <jepler> I don't mind adding hal_unlink() too -- it's much more explicit
[02:45:35] <jmkasunich_> I see there already is an unlink_pin local function - it just needs a "find pin by name" call in the hal_unlink public wrapper
[02:47:30] <jmkasunich_> are you doing it or should I?
[02:47:35] <jepler> "unlinkp" will remain OK for pins that are not yet linked, right?
[02:47:46] <jepler> please go ahead -- I'm about to leave for the night
[02:47:53] <jmkasunich_> will do
[02:48:02] <jmkasunich_> you have no uncommitted changes?
[02:48:05] <jepler> after I finish up the change to the "updating configs" wiki page about the change I already made
[02:48:13] <jepler> I committed everything for ths hal_link business
[02:48:16] <jmkasunich_> ok
[02:48:37] <jepler> will you do the manpage changes for hal_unlink?
[02:48:41] <jmkasunich_> yes
[02:48:58] <jepler> "unlinkp" will remain OK for pins that are not yet linked, right?
[02:49:13] <jmkasunich_> and I'll fix halrmt (it uses the "hal_link( pin, NULL)" trick, I'll change it to hal_unlink
[02:49:21] <jmkasunich_> yes
[02:49:32] <jmkasunich_> #
[02:49:32] <jmkasunich_> 'hal_unlink()' unlinks any signal that is connected to a pin.
[02:49:32] <jmkasunich_> #
[02:49:32] <jmkasunich_> 'pin_name' is a string containing the pin name. If the pin is
[02:49:32] <jmkasunich_> #
[02:49:31] <jmkasunich_> not linked to any signal, the hal_unlink() returns succcess.
[02:49:54] <jepler> ok, and goodnight
[02:50:00] <cradek> thanks guys
[02:50:09] <cradek> that'll save a few questions on the lists
[02:50:39] <jepler> I hope so
[02:50:50] <jepler> but if the new users don't all have to ask questions, how will we know how many of them there are?
[02:51:42] <cradek> we could make a modified GPL that says they have to say hi on irc
[02:51:51] <jepler> what a fantastic idea
[02:52:02] <jepler> you should suggest it to the board of dictators
[02:52:09] <cradek> or the FSF
[02:52:45] <jepler> make sure it meets the DFSG guidelines though
[02:53:00] <jepler> "unless you are actually living on a desert island or are a political dissident, you must say hi on irc"
[02:53:05] <cradek> hahaha
[02:53:43] <jepler> "you must indicate your acceptance of the terms of this license by posting "I AGREE" to the debian-legal mailing list"
[02:55:02] <cradek> jepler: did you see the differential works?
[02:55:30] <jepler> cradek: yes
[02:55:35] <jepler> cradek: so everything seems OK
[02:55:35] <jepler> ?
[02:55:38] <jepler> did you test index too?
[02:55:54] <cradek> yes but only a few times
[02:56:13] <jepler> bah, that's good enough for me, especially since it's bedtime
[02:56:13] <cradek> it reliably showed 4095->0
[02:56:19] <cradek> goodnight
[03:23:53] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[03:37:19] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[10:02:15] <cncman> hello
[11:19:13] <alex_joni> hi
[18:13:59] <petev> cradek, u there?
[18:14:06] <petev> is the cvs server down?
[18:14:43] <cradek> yes, network outage
[18:14:47] <petev> ok
[18:14:54] <SWPadnos> bummer
[18:14:57] <cradek> actually I'm sure it's fine, we just can't talk to it
[18:15:19] <SWPadnos> heh - so it's out but not down? :)
[18:15:28] <cradek> right
[18:22:10] <petev> cradek, is there any preferred method on ubuntu to disable all the services you don't want from starting?
[18:22:26] <SWPadnos> ah - you noticed that there are ~75 modules loaded? :)
[18:22:42] <petev> yeah, way too much stuff not needed
[18:22:46] <SWPadnos> yep
[18:22:54] <petev> blue tooth, bit torrent, etc.
[18:23:25] <SWPadnos> though I did some testing last night with the liveCD, and the latency numbers didn't change noticeably when I removed half the modules and stopped a dozen or so services
[18:23:58] <SWPadnos> I also did testing after booting with "linux single" instead of getting to X, and that also made no difference (except that I had no graphics :) )
[18:23:59] <petev> yeah, but my X still has issues sometimes, and I want to reduce the number of variables
[18:24:20] <cradek> try sysv-rc-conf
[18:24:28] <petev> ok, thanks
[18:25:04] <SWPadnos> thta's probably something to think about for some later CD release - don't turn on things like bittorrent or postgres by default (and probably others)
[18:25:09] <SWPadnos> just to save memory, if nothing else
[18:54:15] <skunkworks> I just got a meade 90mm go-to scope for 90$ with a broken mount. brand new.
[18:54:33] <skunkworks> well - wronge window
[18:57:09] <steve_stallings> steve_stallings is now known as steves_logging
[19:30:09] <mess> high all
[20:23:17] <petev> what do the spindle speed inc/dec buttons on TkEmc do now that IO control and motion don't have pins for this anymore?
[20:23:18] <cradek> what happens if you push them?
[20:23:18] <petev> nothing I can see
[20:23:18] <cradek> the iocontrol.whatever-spindle-speed doesn't change?
[20:23:18] <petev> maybe it sends an NML to some bit bucket
[20:23:18] <petev> let me take a look
[20:23:18] <cradek> yeah it probably issues a message, but it might not do anything
[20:23:18] <SWPadnos> aren't there still spindle_speed_{inc,dec} NML messages?
[20:23:18] <cradek> probably
[20:23:18] <cradek> I think they ... increase or decrease the spindle speed
[20:23:18] <petev> I see no change in spindle-revs
[20:23:18] <SWPadnos> hmmm - lemme see
[20:23:18] <cradek> petev: wrong pin
[20:23:18] <petev> which pin then?
[20:23:18] <SWPadnos> spindle-speed-out or some such
[20:23:18] <petev> oh, sorry
[20:23:18] <petev> yeah, looks like is bumps it a couple of revs with each click
[20:23:18] <petev> holding the button still only bumps it one rev
[20:23:18] <SWPadnos> it's probably something like 1% or 0.1% increments
[20:23:18] <petev> probably not a very useful feature
[20:23:18] <cradek> no, it's kind of crappy
[20:23:18] <SWPadnos> is there a max spindle speed in the ini?
[20:23:18] <petev> no
[20:23:18] <SWPadnos> with auto-repeat, it would be more useful
[20:23:18] <petev> there also isn't a max feed
[20:23:18] <petev> which I think there should be
[20:23:18] <SWPadnos> that's in traj
[20:23:18] <petev> as you probably want it less than max rapid
[20:23:18] <SWPadnos> ah
[20:23:17] <petev> and I still think rapid and feed overrides should be separate
[20:23:17] <SWPadnos> think on :)
[20:23:17] <SWPadnos> you can only slow down a rapid though - does that change your opinion?
[20:23:17] <petev> no
[20:23:17] <SWPadnos> heh - ok
[20:23:17] <petev> if I want to slow my rapids, I don't want my feeds to change
[20:23:17] <petev> what is the major objection to separate overrides?
[20:23:17] <SWPadnos> ah - so you effectively want to program what G0 speed is
[20:23:17] <petev> a lot of guys will limit rapids to not abuse the machine
[20:23:17] <petev> but they don't want the feeds getting effected by the same
[20:23:17] <SWPadnos> you can just set [TRAJ]MAX_VEL lower - that's the rapid rate
[20:23:17] <petev> conversely, when they slow their feeds, they don't want the rapids slowing
[20:23:17] <SWPadnos> but thatisn't dynamic, of course
[20:23:17] <petev> most controls have separate overrides
[20:23:17] <petev> right
[20:23:17] <petev> usually the rapid override control is much more coarse, like 10% steps
[20:23:17] <SWPadnos> I suspect there aren't too many places where the G0 speed is loaded (in the code)
[20:23:17] <petev> where the feed is fine control
[20:23:17] <SWPadnos> it may be not-too-hairy to havea programmable G0 speed
[20:23:17] <petev> I looked at the motion command
[20:23:17] <SWPadnos> but I'm not looking at the code, or i'd be incoherent (even more so)
[20:23:17] <petev> it knows if it's feed or rapid
[20:23:17] <petev> so I don't see why motion can't apply the override
[20:23:24] <petev> I'm tempted to make the change is nobody objects
[20:24:13] <SWPadnos> feed override has a HAL input, doesn't it?
[20:24:18] <SWPadnos> (in motion)
[20:24:18] <petev> yes
[20:24:24] <cradek> I still think it's silly
[20:24:31] <petev> what is silly?
[20:24:35] <cradek> I could see a "speed cap" slider
[20:24:36] <SWPadnos> and there are still NML messages for FO?
[20:24:42] <cradek> slowing one kind of feed and not the others
[20:24:48] <petev> why?
[20:25:01] <petev> if you are adjusting feed, why would you want rapids to change?
[20:25:17] <petev> look at all the commercial controls, they don't think it's silly
[20:25:21] <SWPadnos> because the setup of the machine should be below the limits that might damage or wear out the machine
[20:25:36] <petev> SWP, that just isn't true
[20:25:42] <SWPadnos> so reducing G0 for that reason makes no sense, because it's only covering up an incorrect setup
[20:25:45] <cradek> ok I can actually see adjusting feed without affecting rapids
[20:25:50] <petev> if you have a huge load on the table, you may want to slow rapids
[20:25:55] <SWPadnos> ok, I can see that
[20:25:58] <cradek> I can NOT see adjusting rapids without affecting feeds, there's no point
[20:26:25] <cradek> I've heard people say it's for safety while testing a program
[20:26:35] <cradek> but that's crazy - the program can just as easily contain G1 F9999 in it
[20:26:36] <SWPadnos> add 1000 pounds onto the table, so you want to slow G0 down, but the programmed feedrates are still correct
[20:26:39] <petev> how about when you have a 1000 lb load on the table?
[20:26:49] <petev> you want to run full rapid speed?
[20:26:55] <SWPadnos> cradek, I think it makes more sense to look at is a dynamically adjustable [TRAJ}MAX_VELOCITY
[20:26:55] <petev> I for one would not
[20:27:07] <SWPadnos> not a scale, but a limit, as you said
[20:27:07] <cradek> SWPadnos: yes that's what I've always said
[20:27:10] <cradek> right
[20:27:20] <SWPadnos> I think that would satisfy everyone, no?
[20:27:24] <cradek> a "rapid override" is just a dumb hack that's not as good as an adjustable cap
[20:27:36] <SWPadnos> especially if you label the slider in percent :)
[20:27:37] <cradek> SWPadnos: haha you're joking right?
[20:27:41] <petev> I'm failing to see the diff
[20:27:46] <cradek> I mean about satisfying everyone
[20:27:51] <petev> we need a dynamic cap
[20:27:58] <cradek> petev: the difference is whether G1 F9999 is capped the same way
[20:28:06] <SWPadnos> well, everyone who has rendered an opinion on the subject in this IRC channel in the last 20 minutes :)
[20:28:34] <petev> so you are saying the cap is for feed and rapid?
[20:28:38] <cradek> if you want a cap, it should cap ALL motion
[20:28:38] <SWPadnos> I would quite literally attach the slider directly to [TRAJ]maxvel
[20:28:51] <cradek> yes that's the obvious place for it
[20:28:54] <SWPadnos> I don't think that's an issue
[20:29:02] <SWPadnos> the 1000lb load is a good example
[20:29:03] <petev> I have no problem with that, as I can't see feeds being higher than rapids
[20:29:07] <SWPadnos> exactly
[20:29:14] <petev> so it would essentialy be the same thing
[20:29:24] <petev> at least from the operators perspective
[20:29:32] <SWPadnos> and if someone wants a finish pass at higher speed than the machine can go (with a load), then they just can't have it
[20:30:23] <SWPadnos> a clever G-code writer could actually run the machining cycle, then for the finish pass, run a custom M-code to increase the cap (since a large part of the load is now milled away)
[20:30:26] <petev> but I still contend that traj needs separate feed/rapid caps
[20:30:43] <petev> often you will allow rapids at speeds too fast for normal feed
[20:30:53] <cradek> petev: isn't that what we just agreed about not having?
[20:30:56] <petev> servos will run at 2 to 3 x rated speed for short time
[20:31:05] <petev> no, I don't think so
[20:31:05] <cradek> arrgh
[20:31:09] <cradek> brb
[20:31:19] <petev> I think traj needs a separate cap for feed
[20:31:22] <SWPadnos> I think it's more of a semantic question now - a cap is fine, a "proportional override" doesn't make much sense - even though they may boil down to the same thing
[20:31:25] <petev> then a max cap for all motion
[20:31:40] <petev> you may want to limit feed to less than max rapid speed
[20:32:07] <SWPadnos> so FO + adjustable [TRAJ]MAXVEL
[20:32:39] <petev> I think there should also be a [TRAJ]MAX_FEED_VEL
[20:32:54] <SWPadnos> or are you saying you want 3 (0r 4) separate adjustments: proportional feed override, feed cap, rapid cap, and potentially proportional rapid override
[20:32:55] <SWPadnos> ?
[20:32:59] <petev> which also gets capped by [TRAJ]MAXVEL, but could be much less
[20:33:20] <anonimasu> hm
[20:33:24] <SWPadnos> at least all 4 would be orthogonal :)
[20:33:30] <anonimasu> rapid should probably be overridable down..
[20:33:34] <anonimasu> but not up..
[20:33:41] <petev> no, I think one global dynamic TRAJ MAXVEL would satisfy the rapid issue
[20:33:59] <petev> but I also think we need a feed cap and a dynamic feed override
[20:34:10] <anonimasu> if you look at it on a very very fast machine..
[20:34:30] <anonimasu> err speculate at it..
[20:34:51] <petev> SWPadnos, do u really want to allow feeds at [TRAJ]MAXVEL ?
[20:35:14] <SWPadnos> yes, if they're programmed that way in the G-code
[20:35:15] <petev> a stepper machine would surely have problems with this
[20:35:26] <SWPadnos> that's likely
[20:35:28] <petev> as torque drops significantly with speed
[20:35:42] <SWPadnos> but a G-code programmer that doesn't understand the problem also wouldn't reduce the maxvel
[20:35:50] <petev> so if you have two limits, you can always set them the same
[20:35:50] <anonimasu> agreed..
[20:35:55] <SWPadnos> and they can use FO to reduce the feed rate anyway
[20:36:00] <anonimasu> stepper machines isnt a issue..
[20:36:04] <petev> but I think most would like to limit feed rates to a range that would actually work
[20:36:25] <anonimasu> I guess rapids should be the fastest you can feed..
[20:36:46] <SWPadnos> I'm not opposed to you adding in the full set of controls (to TRUNK), as long as you don't break anything ;)
[20:36:56] <petev> I know my old BP stepper setup would rapid at 4x the feed rate
[20:37:03] <petev> with good reason
[20:37:08] <SWPadnos> if you find it useful, then it's likely that others would as well
[20:37:21] <SWPadnos> yeah - full stepping ;)
[20:37:28] <anonimasu> hehe
[20:37:40] <petev> it pretty well sux to feed too fast and then not find out you lost steps because you din't have enough torque when you check the part
[20:38:06] <SWPadnos> I could glibly respond "should have used servos", but I won't
[20:38:15] <anonimasu> SWPadnos: I thought the same thing
[20:38:19] <SWPadnos> heh
[20:38:23] <petev> how many people using emc actually have servos?
[20:38:24] <anonimasu> petev: that's a setup issue..
[20:38:36] <petev> anonimasu, how so?
[20:38:44] <petev> there is only one max vel now
[20:38:47] <anonimasu> petev: if your machine cant handle the speed/torque needed your motors are undersized..
[20:38:48] <SWPadnos> I will have servos, once I start using EMC
[20:39:10] <anonimasu> petev: or you are trying to do things past your hardware's limit..
[20:39:12] <petev> anonimasu, then you are saying you have to limit rapids to max feed rate
[20:39:17] <petev> thats just stupid
[20:39:39] <SWPadnos> look at it this way - any machine can cut at speeds nearly equal to rapid speed
[20:39:43] <petev> no, I'm certainly not, as I have servos on my machine
[20:39:45] <SWPadnos> the cut just has to be light enough
[20:39:51] <petev> I'm looking out for all the stepper guys
[20:39:58] <anonimasu> SWPadnos: good point
[20:40:34] <SWPadnos> not limiting feed rates separately (rwhether the ability to do so exists or not) gives the G_code programmer the maximum flexibility
[20:40:38] <petev> so how do you know when you're cutting too heavy on a stepper machine?
[20:40:51] <SWPadnos> the programmer doesn't, but the operator may
[20:41:06] <anonimasu> petev: you know your machine I guess..
[20:41:11] <SWPadnos> if the programmer doesn't know the capabilities of the machine, then they're not doing their job well enough
[20:41:19] <petev> I think there is a fundamental disagreement here
[20:41:29] <SWPadnos> the operator does have the ability to scale down the feed rates, using FO
[20:41:34] <petev> I feel that the machine should be capable of running any G-code it accepts as valid
[20:41:59] <SWPadnos> I agree with that
[20:42:11] <SWPadnos> but there may need to be operator intervention
[20:42:30] <SWPadnos> consider this: two identical machines except for spindle horsepower
[20:42:34] <petev> it should do what the specs say it can
[20:42:53] <SWPadnos> one can take heavy cuts, the other can't (limited by spindle HP)
[20:42:53] <petev> so if you are within drilling cap, etc. any accpeted g-code should run properly
[20:43:08] <petev> all machines spec a metal removal rate
[20:43:15] <petev> and you have to stay within it
[20:43:19] <SWPadnos> sure
[20:43:31] <petev> and if you do, the g-code should run properly
[20:43:50] <petev> you should have to worry about how fast can I feed without dropping steps
[20:44:02] <SWPadnos> the main thing you've taught me today is that there is a need to dynamically change the traj limits, based on the mass of the workpiece (and possibly other things)
[20:44:16] <petev> and to limit rapids to feed rate to satisfy this is unecessary
[20:44:19] <SWPadnos> well, a need if you want to optimize all types of work
[20:44:34] <anonimasu> SWPadnos: flex sensors on the column
[20:44:35] <anonimasu> ;)
[20:44:46] <SWPadnos> I agree - loading the machine changes the machine capabilities, which currently requires a restart of EMC
[20:44:48] <SWPadnos> heh
[20:45:07] <anonimasu> petev: how do you know what a heavy cut is?
[20:45:15] <anonimasu> petev: it's all dependant on depth of cut.. and the chipload..
[20:45:22] <petev> within speced machine metal removal rate
[20:45:35] <SWPadnos> consider this: if there are HAL pins for feedrate override and rapid override, then the "standard" configuration might connect the two to the same input, so the sliders would act just as they do now
[20:45:43] <petev> anonimasu, look at the specs of some commercial machines
[20:45:49] <SWPadnos> (NML not withstanding)
[20:45:59] <anonimasu> petev: you were talking about hobbyist stepper machines..
[20:46:15] <petev> they will spec a removal rate for different materials, usually in cubic inch per minute or something
[20:46:18] <SWPadnos> so there's no change for current users, except for a small HAL wiring change
[20:46:41] <petev> anonimasu, even on a hobby machine, I would figure out the capability, then config the files to stay within it
[20:46:47] <anonimasu> petev: what you are trying to patch is user stupidity..
[20:46:53] <petev> I don't see why others wouldn't want to do the same
[20:46:59] <petev> no
[20:47:12] <SWPadnos> gotta run - bbl
[20:47:19] <petev> I'm tyring to make it so EMC knows the machine limits and stays within them
[20:47:29] <petev> without the user having to worry about it all the time
[20:47:42] <anonimasu> petev: will you feed emc a material table?
[20:48:05] <petev> anonimasu, you are getting way off track
[20:48:21] <petev> how will you know what your machine can do?
[20:48:35] <petev> will you just try and make a part and see if it comes out right?
[20:48:38] <anonimasu> that comes from experience..
[20:48:47] <anonimasu> and also the specs..
[20:48:54] <petev> or are you going to do some engineering up front to determine the limits?
[20:49:09] <petev> so if you have specs, then shouldn't emc obey them?
[20:49:21] <anonimasu> petev: but, how does emc know if you are cutting acetal or iron?
[20:50:04] <petev> I'm not sure why that matters?
[20:50:26] <petev> we are talking about not allowing the machine operate outside of it's envelope
[20:50:34] <petev> not checking every case inside of it
[20:50:56] <petev> sure you can feed faster on a 2 mil cut than a 50 mil cut
[20:51:08] <petev> but you still need to be inside the capability envelope
[20:51:53] <anonimasu> ök
[20:51:56] <anonimasu> err ok..
[20:52:35] <petev> look, here's a simple example that applies to almost all servo systems
[20:52:45] <petev> the motors have a rated continuous cap
[20:52:49] <petev> and a peak cap
[20:53:15] <petev> almost all machines will use the peak rpm for rapids, because the know the load is light and the motor will not heat up
[20:53:25] <petev> but they stay within the continuous cap for feed
[20:53:29] <petev> is that unreasoneable?
[20:53:44] <petev> you can't specify that today with EMC
[20:53:52] <anonimasu> actually it's not..
[20:54:32] <petev> so how would you handle this without a separate feed vel limit?
[20:55:21] <anonimasu> I dont know
[20:55:43] <petev> that's why I feel it's needed
[20:55:53] <petev> if you don't want to use it, set both limits the same
[20:55:57] <petev> simple solution
[20:56:10] <anonimasu> * anonimasu nods
[20:56:42] <anonimasu> good point :)