Back
[00:02:22] <jmkasunich> hmm
[00:02:33] <jmkasunich> the rc-46 slot has a differnet error:
[00:02:34] <jmkasunich> make: *** No rule to make target `objects/rthal/components/and2.o', needed by `../rtlib/and2.o'. Stop.
[00:53:00] <jepler> hm -- I probably never got the rules right for building comps into .o
[00:54:17] <jepler> @echo ../rtlib/$(notdir $*).so: objects/rtobjects/$*.o >> $@.tmp
[00:54:17] <jepler> @echo ../rtlib/$(notdir $*).o: objects/rt$*.o >> $@.tmp
[00:54:30] <jepler> the first line is for sim-rt and the second should be for pre-kbuild systems
[00:54:39] <jepler> so probably it needs to be objects/rtobjects/$*.o in both cases
[00:55:26] <jepler> and it will turn out there are lines missing for COMP_DRIVERS as well
[00:56:01] <jmkasunich> * jmkasunich watches as jeff's words fly right over his head
[00:56:47] <jmkasunich> it was working before (or were all the .comp things getting skipped because of no yapps?)
[00:56:50] <jmkasunich> I guess that was it
[00:57:31] <jmkasunich> I just made a motion on the board list to officially drop support for BDI-2, -TNG, and -Live
[00:57:42] <jmkasunich> basically all the pre-2.6 stuff
[00:57:59] <jepler> well I thought it passed once after the yapps change .. but maybe not
[00:58:21] <jmkasunich> well 2.18 and TNG never did, because they have python 1.5
[00:58:31] <jmkasunich> I'm not sure about -Live
[00:58:38] <jmkasunich> when it fails now, it fails much later in the process
[00:58:53] <jmkasunich> so maybe it did that the first time and we were distracted by the two that failed right away
[00:59:07] <jepler> 16:37:05 <CIA-8> compile-farm BDI-Live rc46 (2.4.25-adeos) * emc2head/: build FAILED
[00:59:12] <jepler> yeah looks like it did fail
[00:59:27] <jepler> thanks for doing that dirty work of making sure the 'comp's were right
[00:59:33] <jmkasunich> you're welcome
[00:59:40] <jepler> now that we've got so much code written that it's hard to change, what are your thoughts about 'comp'?
[00:59:56] <jmkasunich> I like it
[01:00:23] <jmkasunich> for instance - when I changed some pins to params - the _only_ thing I changed were the pin decls... the code didn't need touched
[01:00:33] <jmkasunich> no removal of *, etc
[01:00:50] <jmkasunich> there are one or two rough spots I noticed
[01:00:57] <jepler> what were they?
[01:01:04] <jmkasunich> like match8, it has pins a0 thru a7 and b0 thru b7
[01:01:22] <jmkasunich> they need to be individually declared, and appear as individuals in the man page
[01:01:41] <jmkasunich> it might be nicer to lump them into a single entry in the man page
[01:01:55] <jepler> I thought about adding this syntax: pin ... a0, a1, a3, a4, a5, a6, a7; but that won't help with the manpage
[01:02:38] <jmkasunich> the other complication is that the code itself used to access the a and b pins as arrays
[01:02:45] <jmkasunich> instead of hardcoded names
[01:02:51] <jepler> maybe I should do arrays
[01:03:01] <jepler> pin ... a[8] "the alpha bits"
[01:03:12] <jmkasunich> pin bit a[0-7] "doc string for all";
[01:03:35] <SWPadnos> even a different type, or a modifier would be great
[01:03:40] <jmkasunich> right, a[8], not 0-7
[01:03:59] <jepler> I don't think I can get the bare name syntax to work if it's an array, though
[01:04:03] <SWPadnos> bitarray or array bit a[8] "yadda yadda"
[01:04:45] <jmkasunich> right now, 'foo' becomes '*(ptr->foo)', right?
[01:04:50] <jepler> right
[01:05:07] <jmkasunich> foo[n] would become *(ptr->foo[n])
[01:05:16] <jepler> but you can't do that with the preprocessor
[01:05:31] <jmkasunich> I guess the trick is seeing the [n] and slipping it inbetween the foo and the )
[01:05:39] <jepler> if you look at the 'comp' output, you will see that everyting after the ";;" is passed verbatim to the compiler
[01:05:47] <jmkasunich> where [n] might be [somebigmessyexpression]
[01:05:55] <jepler> in the prologue section I write #define foo *(ptr->foo)
[01:06:08] <jmkasunich> oh
[01:06:56] <jepler> I could do something like #define foo(x) *(ptr->foo[x]) but then you have to write the function-call-like foo(1) not foo[1].
[01:07:08] <jmkasunich> right, I was just thinking of that
[01:07:14] <jmkasunich> and dismissed it for the same reason
[01:07:35] <jmkasunich> its not a fatal problem if 5% of the components are written the old way
[01:07:43] <jepler> you want to use array syntax so that you can write for(...) instead of 8 sequential statements, right?
[01:07:53] <jepler> in which case call-like a(1) would be better than what I have now
[01:07:56] <jmkasunich> in the case of match8, yes
[01:08:04] <jepler> bbiab
[01:10:32] <jmkasunich> I just stopped the first 2 farm slots, tired of hearing them complain
[01:10:44] <jmkasunich> slot 4 is still going so we can see if your fix worked
[01:18:12] <SWPadnos> jmkasunich, WRT your board proposal, do you think there are any code simplifications that can be made?
[01:18:42] <SWPadnos> maybe dropping RTLinux as well (though that doesn't seem to be a big headache for maintenance at the moment)
[01:20:20] <jmkasunich> RTLinux isn't a headache because I don't think anyone is using it
[01:20:26] <SWPadnos> right
[01:20:37] <jmkasunich> at least, if they are they are smart enough to figure things out themselves
[01:20:39] <SWPadnos> none of the farm slots are RTL?
[01:20:48] <jmkasunich> BDI-2.xx is RTL
[01:21:01] <SWPadnos> ok, so it compiles but isn't known to work
[01:21:06] <jmkasunich> right
[01:21:42] <jmkasunich> if we dropped all pre-2.6 kernels, that would _definitely_ simplify the build system
[01:22:00] <jmkasunich> we basically have two build systems in one right now, one for pre-2.6 and one for 2.6
[12:11:44] <jepler> jmk_away: --with-python=/usr/local/python2.4
[12:17:06] <jepler> @(echo '#!$(PYTHON)'; sed '1 { /^#!/d }' $<) > $@.tmp && chmod +x $@.tmp && mv -f $@.tmp $@
[12:17:26] <jepler> that is supposed to put the right #!-line on the python scripts, and remove the existing first line if it starts with #!
[12:17:30] <jepler> I wonder what's wrong with that
[12:19:40] <jepler> maybe try sed -e '1 { ... }' < $<
[12:19:55] <jepler> or: head +1 $<
[12:20:04] <jepler> assuming the previous first line was always a #!-line
[12:27:44] <jepler> ah maybe I have the fix .. add a ';'
[12:43:39] <alex_joni> jepler: you're talking foreign languages again :)
[12:45:50] <jepler> alex_joni: whoops, sorry
[12:46:03] <jepler> anyway, jmk should try farm slot 2 again
[12:46:10] <alex_joni> I think it'll try again
[12:46:17] <alex_joni> but it takes 20-30 minutes to respond
[12:46:26] <alex_joni> s/respond/build/
[13:04:06] <jmk_away> I just restarted the first 2 slots
[13:04:15] <jmk_away> if they work I'll leave them running
[13:04:40] <jmk_away> if not, should I shut them down again to prevent lots of messages (I'm gonna be away all week) ?
[13:10:28] <alex_joni> let them spam
[13:15:25] <jepler> eek tough question
[13:16:02] <jepler> I'd rather not have complaints every half hour for a week
[13:16:40] <jepler> on the other hand, it looks like we're close
[13:23:51] <jepler> the bdi-tng failure is more confusing
[13:26:08] <SWPadnos> are there success messages anywhere after a failure?
[13:26:36] <alex_joni> SWPadnos: on #emc
[13:26:56] <SWPadnos> I haven't been noticing them, but maybe that's due to lack of success so far :)
[13:27:18] <jepler> there is a message for each failure, but only a message for a success if the prior one was a failure
[13:27:22] <jepler> net result: you see mostly failures
[13:27:33] <SWPadnos> yep - it's those messages I haven't been noticing
[13:27:50] <SWPadnos> I remember that it's supposed to be once onlly after a failure
[13:28:24] <jmk_away> assuming I have internet access from my hotel, I can ssh into the farm and turn it on or off
[13:28:31] <jmk_away> but if I don't...
[13:28:37] <SWPadnos> then you can't ;)
[13:28:52] <SWPadnos> spam is fine - it'll be better than last night's fiasco :)
[13:29:02] <jepler> yeah, what the hell was that?
[13:29:15] <jmk_away> idiots
[13:29:21] <SWPadnos> the IRC equivalent of script kiddies, I think
[13:29:23] <jmk_away> probably idiot actually
[13:30:17] <SWPadnos> two, from the IPs they had
[13:30:30] <jmk_away> ah
[13:30:34] <jmk_away> I didn't look to closely
[13:30:44] <SWPadnos> me either, until now ;)
[13:31:18] <alex_joni> you talking about the morons in #emc ?
[13:31:31] <SWPadnos> yes
[13:31:33] <jmk_away> how does one change a password? I thought it was setpass
[13:31:43] <SWPadnos> on irc?
[13:31:46] <alex_joni> passwd ?
[13:31:48] <jmk_away> no, on linux
[13:31:52] <alex_joni> passwd
[13:31:54] <SWPadnos> yeqah, passwd
[13:31:58] <SWPadnos> yeah
[13:32:27] <jepler> jmk_away: any easy way to send me a copy of the include/GL directory from bdi-tng?
[13:32:36] <jepler> if not, don't worry about it
[13:33:39] <jmk_away> fsckin passwd is finicky
[13:35:24] <jmk_away> jepler: I was trying to figure out a way to let you ssh into the farm
[13:36:17] <jmk_away> cradek has root access to cvs2, which is where incoming traffic to jmkasunich.dyndns.org goes
[13:36:45] <jmk_away> if he creates an account on that box for you, you can login there, then ssh to boxen on my internal net, including the farm
[13:37:23] <jmk_away> but the farm slots are running as me, so you'd need to login as me
[13:38:50] <alex_joni> jmk_away: how about setting up ssh keys?
[13:39:02] <jmk_away> not in the 15 mins before I have to leave
[13:39:04] <alex_joni> sounds like the most secure way without sharing the passwd
[13:39:05] <alex_joni> :)
[13:39:14] <alex_joni> bet cradek will do it in 10 mins
[13:39:15] <jmk_away> jmk_away is now known as jmkasunich
[13:39:29] <cradek> does it matter if these platforms build over the next week or so?
[13:39:44] <jmkasunich> cradek: only if jeff is trying to get them to work
[13:39:46] <jmkasunich> which he is
[13:39:55] <cradek> ah
[13:39:55] <jepler> I'd rather put it off for a week really
[13:40:27] <cradek> that also has the advantage of waiting until after the vote
[13:40:32] <jmkasunich> ok
[13:40:54] <jmkasunich> then as soon as the current builds end (assuming they fail) I'll shut them down again
[13:41:09] <jepler> for the record, it looks like there's only a small amount of effort to get bdi2 and bdi-tng back to building
[13:41:24] <jepler> because the new thing, 'comp', runs
[13:42:09] <cradek> ok
[13:42:34] <jmkasunich> if I get online once I'm in finland, I'll turn the farm back on
[13:44:24] <cradek> jmkasunich: hope you enjoy your trip
[13:45:55] <jmkasunich> I'll try
[13:46:53] <jmkasunich> I'm not looking forward to 11 hours in airplanes
[13:47:12] <jmkasunich> each way
[13:47:25] <cradek> yeah ick
[13:47:37] <cradek> hope for sleep I guess
[13:47:45] <jmkasunich> must sleep
[13:48:05] <jmkasunich> we arrive at 8am finland time, and go straight into a meeting
[13:49:07] <jepler> yuck
[13:49:18] <alex_joni> jmkasunich: going east is not nice
[13:49:27] <alex_joni> jet-lag should be crazy that way
[13:50:24] <jmkasunich> not looking forward to it
[13:50:38] <jmkasunich> ok, farm slots 2 and 3 are idling again
[13:50:48] <jmkasunich> if I get online (Tuesday evening) I'll turn them back on
[13:50:56] <jmkasunich> jmkasunich is now known as jmk_away
[13:51:07] <jmk_away> I'm off...
[13:51:12] <alex_joni> jmk_away: have a safe trip
[13:51:14] <alex_joni> fun too
[13:51:16] <jmk_away> thanks
[17:05:25] <Lerneaen_Hydra__> Lerneaen_Hydra__ is now known as Lerneaen_Hydra
[18:17:46] <cradek> I did not understand what Manfredi was asking
[18:18:49] <alex_joni> I didn't understand it completely either
[18:19:07] <cradek> I see you replied but didn't answer a question :-)
[18:19:14] <SWPadnos> it looked to me like he was sondering why he couldn't jog after he manually tripped a limit switch
[18:19:17] <SWPadnos> an odd question, IMO
[18:19:26] <cradek> you must be right that he doesn't quite understand how limit switches work
[18:20:03] <alex_joni> cradek: what question?
[18:20:19] <cradek> that's the problem, I don't know
[18:20:37] <alex_joni> "Have you any suggestion?"
[18:20:39] <alex_joni> :-P
[18:21:09] <alex_joni> I think the "switch" for feed & spindle override wouldn't be that bad :)
[18:21:19] <cradek> this is why you should use the "here's what I observed and here's how it deviates from what I expected" question format
[18:21:49] <alex_joni> hmm.. where's that guide again?
[18:22:04] <SWPadnos> the G48/49 thing is being misunderstood, I think
[18:22:08] <alex_joni> http://catb.org/~esr/faqs/smart-questions.html
[18:22:17] <cradek> SWPadnos: I think so too
[18:22:22] <SWPadnos> what he wants is a feedhold input
[18:22:23] <alex_joni> SWPadnos: I think he took "switch" literally
[18:22:28] <SWPadnos> which isn't the same thing
[18:22:34] <SWPadnos> he did, but in the wrong literal sense ;)
[18:22:35] <alex_joni> * alex_joni agrees
[18:22:44] <cradek> I think we all agree we need a feedhold pin
[18:22:51] <SWPadnos> (the FO and hypothetical SO sliders on the GUIS are the switches)
[18:23:02] <alex_joni> SWPadnos: yes and no
[18:23:37] <alex_joni> I see it like this: if you program M48, then moving the sliders shouldn't have any effect
[18:23:38] <SWPadnos> I also think the FO/SO disable should be there - it is in the docs after all (and shouldn't be too hard to do)
[18:23:42] <SWPadnos> exactly
[18:23:55] <alex_joni> if you program M49, then it should work again
[18:24:08] <SWPadnos> "switch" = FO slider on GUI, not physical thing to decide whether to ignore FO or not
[18:24:10] <alex_joni> question: should the last values be retained after an M48?
[18:24:23] <alex_joni> or should it default to 100% ?
[18:24:58] <SWPadnos> good question. I'd say yes at first, but then again that could cause a discontinuity when G49 is issued
[18:25:07] <SWPadnos> or M49, whichever ;)
[18:25:21] <alex_joni> actually M48 is what I'm concearned
[18:25:33] <alex_joni> M49 just enables the sliders
[18:25:50] <alex_joni> hint: the sliders always get updated to the internal value of the override
[18:26:04] <SWPadnos> right, so if a slider is set to 200%, and you issue M49, then you end up with a discontinuity in speed
[18:26:11] <SWPadnos> sure
[18:26:33] <cradek> SWPadnos: that's a problem with adaptive feed and everything else too. It's pretty much solved.
[18:26:36] <alex_joni> you cannot set a slider to 200% if M48 is active
[18:26:43] <SWPadnos> the easy way to do it is to check the M48/49 status, and set FO/SO to 100% if needed
[18:27:14] <SWPadnos> alex_joni, it doesn't actually say that the override will be set to 100%, it says that overrides will be ignored
[18:27:27] <SWPadnos> that implies to me that they'll be left alone, but not used
[18:27:31] <alex_joni> SWPadnos: I'm thinking about how it works in emc2
[18:27:41] <alex_joni> if you move a slider it tries to set a value
[18:27:52] <SWPadnos> though it's probably not important enough to worry about. the side effect of the sliders not moving when you drag them isn't a big issue
[18:27:55] <alex_joni> and the position of the slider will _always_ be based on the current value
[18:28:09] <cradek> can we back up for a second? do you guys think someone really wants m48/m49 or is it a sidetrack issue?
[18:28:14] <SWPadnos> I understand - there will be weird feedback to the user
[18:28:32] <alex_joni> cradek: I imagine M48/M49 can be usefull
[18:28:48] <SWPadnos> I think it's a sidetrack from the original request, but also of some importance since not having it is a deviation from the specs
[18:29:39] <cradek> well we have a lot of that... we should concentrate on the most useful new features, I'm just asking if you guys think this is one of them
[18:29:48] <cradek> (I know I've never wanted it)
[18:30:07] <SWPadnos> not for home/hobby machines, but for actual machine shops it can be quite useful
[18:30:14] <alex_joni> I can imagine a machining center supervisor wanting to switch it off
[18:30:27] <SWPadnos> the Mazak is a good candidate for this ;)
[18:30:50] <alex_joni> cradek: I've seen lots of operators which crank the speed really up
[18:31:01] <cradek> ok
[18:31:03] <alex_joni> otoh programming a max_override of 1.0 in the ini would solve that too
[18:31:16] <SWPadnos> too bad there's no min_override
[18:31:30] <alex_joni> SWPadnos: there is for spindle speed
[18:31:37] <cradek> I know we need feedhold and I just wondered if this is a distraction from that issue, seems like it's separate so I'll not bother you guys anymore
[18:31:45] <SWPadnos> it is separate, agreed
[18:31:47] <alex_joni> it's separate
[18:32:01] <alex_joni> cradek: we like beeing bothered
[18:32:17] <SWPadnos> heh - or being a bother :)
[18:33:08] <cradek> I think I agree with swp that the mcodes should temporarily set FO to 100; I don't know what the gui will look like though
[18:33:20] <alex_joni> gui will jump to 100
[18:33:27] <alex_joni> it's what it does currently
[18:33:50] <SWPadnos> actually, I don't think that's the ideal solution, but I suspect it's the easiest (and safest for when the overrides are re-enabled)
[18:34:16] <alex_joni> SWPadnos: I'm probably not expressing myself right
[18:34:21] <alex_joni> say you were at about 50%
[18:34:26] <alex_joni> then you encounter M48
[18:34:27] <cradek> is this is another queue buster where the interp has to not queue moves past that mcode?
[18:34:38] <alex_joni> cradek: don't think so
[18:34:42] <SWPadnos> don't think so
[18:34:53] <SWPadnos> it's just an instantaneous change to the effective FO
[18:34:55] <cradek> we have to change canon then
[18:34:58] <alex_joni> SWPadnos: stop repeating after me :D
[18:35:00] <SWPadnos> heh
[18:35:07] <alex_joni> cradek: not very much to change .)
[18:35:07] <SWPadnos> ok, I'll stop repeating after you
[18:35:09] <cradek> to say some moves can't be overridden
[18:35:30] <SWPadnos> where is FO applied?
[18:35:36] <cradek> tp
[18:35:37] <alex_joni> how close to the standard would this be?
[18:35:44] <alex_joni> 1. if I have FO set at 50%
[18:35:54] <alex_joni> 2. I can change it however I like..
[18:36:01] <alex_joni> 3. say I leave it at 50%
[18:36:06] <alex_joni> 4. M48 is encountered
[18:36:21] <SWPadnos> that's where there needs to be a flag: FeedRate = ProgrammedRate * (FOAllowed ? FO : 1);
[18:36:33] <cradek> right
[18:36:34] <alex_joni> 5. I try to change FO, but the NML message to set the new FO will be discarded
[18:36:40] <cradek> and the flag goes along with the certain moves
[18:36:57] <SWPadnos> no, the flag is changed ny M48/49
[18:37:03] <alex_joni> how about leaving it to what it was?
[18:37:35] <alex_joni> I see 2 possible behaviours. 1. set it to 100%, 2. freeze it to what it was
[18:37:47] <SWPadnos> I see the real problem in two places: if FO is set low, and Ignore is turned on, it will jump to 100% instantly (with no operator intervention)
[18:38:04] <SWPadnos> conversely, if FO is set high, there will be a change when re-enabling overrides
[18:38:23] <SWPadnos> that's the issue with setting it to 100% or leaving it alone (frozen or modifiable, it doesn't matter)
[18:38:23] <alex_joni> why should there be a change on re-enable?
[18:38:28] <cradek> I'm starting to think this whole feature is stupid
[18:38:47] <SWPadnos> no, it's necessary in "real" shops
[18:38:52] <alex_joni> cradek: I'm starting to agree
[18:38:58] <alex_joni> SWPadnos: you can do that by editing the ini
[18:39:02] <cradek> SWPadnos: I'm not seeing that
[18:39:04] <alex_joni> for real machine shops
[18:39:27] <SWPadnos> no, because an operator can still reduce the speed, which can cause other problems (burning, tool wear, etc)
[18:39:36] <alex_joni> but that's his problem
[18:39:45] <SWPadnos> so is overspeed ...
[18:39:45] <alex_joni> you can always break really hard while on the highway
[18:40:14] <SWPadnos> this is a feature for the guy who writes the G-code, preventing the machine operator/monkey from screwing up the work
[18:41:03] <alex_joni> SWPadnos: then how about freezing/unfreezing the current value
[18:41:06] <SWPadnos> I think the main debate here is what to do with the FO value while it's being ignored, right?
[18:41:10] <cradek> I read section 2.2.1 as 'm49 forces feed override to 100% (in our case, ignores the slider)' 'm48 puts it back (now paying attention to the slider's position again)'
[18:41:11] <alex_joni> that will cause no jumps
[18:41:21] <cradek> how many of us agree with my reading ^^ ?
[18:41:27] <SWPadnos> that's my reading as well
[18:41:28] <alex_joni> * alex_joni reads again
[18:41:55] <cradek> let's not talk right now about what happens to the slider during m49 (a gui issue)
[18:42:22] <alex_joni> I agree
[18:42:32] <alex_joni> on M48 both overrides need to jump to 100%
[18:42:40] <cradek> m49
[18:43:15] <alex_joni> right..M49
[18:43:27] <alex_joni> so.. if I was at 50%, on M49 it goes to 100%
[18:43:35] <alex_joni> that will cause the slider to jump to 100% too
[18:43:40] <cradek> the feed does, the slider doesn't necessarily
[18:43:44] <alex_joni> and on M48 it will stay at 100%
[18:43:45] <cradek> ignore the gui issue for now please
[18:43:56] <cradek> ok that's where I disagree
[18:44:06] <alex_joni> cradek: just stating what it's doing right now
[18:44:09] <cradek> I think it needs to go back to the previous FO value (second paragraph)
[18:44:11] <SWPadnos> I disagree along with cradek ;)
[18:44:22] <alex_joni> I'm not saying that's how it should be or not
[18:44:31] <SWPadnos> there should be no change to the FO value
[18:44:34] <SWPadnos> it should just be ignored
[18:45:09] <alex_joni> SWPadnos: going to 100% from whatever value there was is no change?
[18:45:22] <SWPadnos> as far as I'm concerned, the GUI sliders should still change the FO value, they just won't change the feed rate
[18:45:24] <cradek> I think as far as the standard is concerned, the interp cannot change these "switches" (our slider), it can only ignore the "switches"
[18:45:38] <SWPadnos> exactly
[18:45:42] <alex_joni> I don't see the slider as a switch
[18:45:53] <SWPadnos> it's an analog switch ;)
[18:46:00] <cradek> I do think it's the "switches" 2.2.1 talks about
[18:46:16] <cradek> it's a rotary switch with many settings
[18:47:01] <alex_joni> I hate it when people use the same word for different things
[18:47:03] <cradek> just like the optional program stop "switch" is on our gui as a button or whatever
[18:47:19] <cradek> (nearby in section 2.2.3)
[18:47:36] <alex_joni> I see the "switch" as a logical switch wich enables/disables taking values from the slider
[18:47:38] <cradek> alex_joni: I think they envisioned a panel, not a gui, that's all
[18:47:50] <alex_joni> then it's a fscking knob
[18:47:55] <alex_joni> not a switch
[18:48:17] <alex_joni> there's a "switch" (controlled by M48/49) which enables the "knob"
[18:48:17] <cradek> I understand your interpretation, that's where I started too, but I disagree now
[18:48:42] <alex_joni> is that how you interpret it?
[18:49:07] <cradek> yes the "switch" tells motion to ignore the "knob" or not
[18:49:13] <cradek> the "switch" is m49, the "knob" is the FO slider
[18:49:22] <SWPadnos> heh - really intuitive, those guys are :)
[18:49:23] <alex_joni> right
[18:49:33] <alex_joni> SWPadnos sounds like yoda
[18:49:43] <SWPadnos> yodaspeak sounds like it does
[18:50:00] <alex_joni> cradek: I agree so far
[18:50:04] <cradek> oh good :-)
[18:50:11] <alex_joni> so lets pretend the knob was at 45%
[18:50:12] <SWPadnos> but it also says that the FO will go back to the original value when the switch is turned off
[18:50:20] <alex_joni> then there's a M48
[18:50:21] <SWPadnos> ie, the knob isn't moved
[18:50:23] <alex_joni> SWPadnos: where?
[18:50:33] <cradek> The EMC control system reacts to the setting of the speed or feed override switches on the control panel, when these switches are enabled.
[18:50:48] <cradek> (I think this is what says that)
[18:50:54] <alex_joni> I'm not so sure
[18:50:55] <SWPadnos> one sec - lemme reread the original
[18:51:01] <cradek> control panel = our gui
[18:51:08] <alex_joni> at least I always keep in mind the NIST model of control
[18:51:22] <alex_joni> where you don't have knobs which stay only at one value
[18:51:31] <alex_joni> e.g. potentiometer vs. encoder
[18:51:37] <cradek> they don't, you can change the FO all you want, but it's being ignored
[18:51:50] <SWPadnos> ok - nevermind
[18:51:59] <alex_joni> cradek: if the above knob is a potentiometer, then M48 will cause a jump back to the old FO
[18:52:01] <cradek> in fact, if you change it while it's ignored, it will run at the new value when it's unignored
[18:52:09] <SWPadnos> that was my concern
[18:52:14] <SWPadnos> the jumo in speed
[18:52:16] <SWPadnos> jump
[18:52:23] <cradek> that's the feature isn't it??
[18:52:35] <cradek> "temporarily jump to a fixed speed"
[18:52:36] <SWPadnos> though that'll also happen if a person programs F1 then F200 on successive lines
[18:52:36] <alex_joni> * alex_joni would like it to stay at 100%
[18:52:56] <cradek> I think that's the entire point
[18:53:06] <cradek> alex_joni: stay when?
[18:53:21] <SWPadnos> that jump is the reason why I can agree with forcing the actual override value to 100%
[18:53:23] <alex_joni> 40% -> M49 -> 100% -> M48 -> 100%
[18:53:37] <cradek> no, I firmly disagree
[18:53:41] <SWPadnos> otherwise, I think it shuold stay at its s"setpoint", but be ignored
[18:54:16] <alex_joni> 40% -> M49 -> 100% -> M48 -> (whatever value has been set blindly in the meanwhile) ?
[18:54:19] <SWPadnos> and I think I've convinced myself that the jump is acceptable, since G-code can have sudden speed changes embedded in it anyway
[18:54:22] <cradek> then you've destroyed M48 (enable the override now)
[18:54:32] <cradek> alex_joni: yes
[18:54:41] <alex_joni> how do you mean destroyed?
[18:54:51] <cradek> you've made it do nothing
[18:55:05] <alex_joni> force it go 100% on M49
[18:55:14] <alex_joni> I think that _is_ the feature
[18:55:21] <cradek> I still disagree :-)
[18:55:46] <cradek> the feature is to override the switches and use the programmed value when between m49 and m48
[18:55:49] <alex_joni> "The idea is that optimal settings have been included in the program, and the operator should not change them."
[18:56:02] <SWPadnos> I think we can all agree that the feedrate should be fixed at 100% of programmed rate when M49 is programmed, right?
[18:56:07] <alex_joni> right
[18:56:11] <cradek> yes
[18:56:29] <SWPadnos> so the only question is what happens to the actual FO variable
[18:56:38] <SWPadnos> which also has consequences for the GUIs
[18:56:55] <alex_joni> the GUI slider actually has 2 things
[18:57:04] <SWPadnos> my preference is to have the sliders work, but have no effect on the actual feedrates until M48 is seen
[18:57:17] <SWPadnos> I understand - it's a control and an indicator
[18:57:20] <alex_joni> it's current position, which gets updated from the internal emc fo-value
[18:57:28] <alex_joni> and the control, which sets things
[18:57:43] <cradek> I think this is a tangent
[18:57:59] <SWPadnos> yeas
[18:58:00] <alex_joni> so we can have it A). set a flag on M49, and have TP use 100% always
[18:58:01] <SWPadnos> yes
[18:58:14] <alex_joni> in that case the user can do whatever to the FO
[18:58:23] <alex_joni> and it'll be active on M48
[18:58:36] <SWPadnos> right - that's my vote
[18:59:10] <alex_joni> B). catch the FO messages in task or canon, that way the slider will stay at 100%, and maybe on M48 you can use some internal value from canon/task to restore it
[18:59:27] <alex_joni> B). will behave similar to A). but the slider won't update location
[19:00:21] <SWPadnos> I think (A) captures the correct functionality with the fewest side effects
[19:00:40] <SWPadnos> the only real side effect is that the machine operator may wonder why the FO slider doesn't seem to do anything
[19:00:50] <alex_joni> and he'll really change it
[19:00:52] <cradek> right
[19:00:57] <alex_joni> because there's no effect
[19:01:00] <alex_joni> maybe turn it way up
[19:01:07] <skunkworks> * skunkworks is wondering where this spec is - Its not in the 3.0 nist specs.
[19:01:13] <cradek> the gui should show that it's being ignored ... somehow
[19:01:18] <SWPadnos> it's the last pair of M codes, I think
[19:01:20] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_32a.html#1011642
[19:01:21] <alex_joni> gray it out maybe
[19:01:38] <skunkworks> n/m found it. sorry.
[19:01:40] <cradek> yes graying out is close to what we want, but the user should be able to change it
[19:01:42] <SWPadnos> M48/49 would be a modal group or something, and would need to be in the status struct
[19:02:02] <SWPadnos> (from which the GUIs can do something appropriate)
[19:02:20] <Lerneaen_Hydra> (common end user). the little m48/49 functionality I've seen behaves like this: FO 40%, M48 -> FO 100%, ... , M49, FO 40% again. (mostly because of the fact that the FO is a mechanical wheel/knob, though GUI controls have the same effect. also a change in FO during the fixed-100% time changes the FO when exiting forced-100%
[19:02:41] <Lerneaen_Hydra> err, swap M49/M48 around
[19:02:52] <Lerneaen_Hydra> nothing like standardisation
[19:02:57] <alex_joni> Lerneaen_Hydra: that's what we were starting to agree on I think
[19:03:08] <SWPadnos> interesting - so if anyone has fiddled, you set it so there's no discontinuity - I can go for that
[19:03:37] <cradek> brb
[19:03:38] <alex_joni> SWPadnos: how do you mean discontinuity?
[19:04:21] <skunkworks> Yes - our old machine had this. And the fo was a mechanical... So exiting out it would go back to where ever the fo dial was set.
[19:04:29] <SWPadnos> ie, FO=40%, M49 -> FO 100% (effective), operator cranks FO to 300% because it isn't working, M48 -> 100% (the same as with M49, because it's been tampered with)
[19:05:13] <SWPadnos> the other way would have been FO=40% -> M49 -> 100% -> fiddle to 300% (ignored) -> M48 -> 300% (or 7.5x the former FO)
[19:05:32] <Lerneaen_Hydra> the mill/lathes I've seen spit out big colorful error messages onscreen when you change FO during M49
[19:05:33] <SWPadnos> that's the discontinuity we've been discussing, I think :)
[19:06:01] <SWPadnos> in the immortal words of Laser Chess, "What're you doing? You can't do that."
[19:06:06] <Lerneaen_Hydra> the commercial stuff I've worked with behaves as SWPadnos just said (jump to 300%)
[19:06:28] <Lerneaen_Hydra> not that I'm saying that that's good or bad
[19:06:33] <SWPadnos> ok, is that different from what you first mentioned though?
[19:06:42] <SWPadnos> (ie, force 100% if it's been adjusted)
[19:06:59] <alex_joni> he didn't say that
[19:07:18] <alex_joni> oh.. he did :)
[19:07:19] <SWPadnos> "also a change in FO during the fixed-100% time changes the FO when exiting forced-100%"
[19:07:21] <Lerneaen_Hydra> I tried to say the same thing that you just said
[19:07:21] <SWPadnos> heh
[19:07:42] <SWPadnos> well, whatever you were trying to say, I like how I interpreted it ;)
[19:07:48] <Lerneaen_Hydra> haha
[19:07:49] <alex_joni> so keep it 40% if not tempered with, and set it to 100% if changed
[19:07:53] <SWPadnos> yep
[19:07:58] <alex_joni> sounds nice
[19:08:11] <alex_joni> quick .. lets decide before chris comes back
[19:08:14] <SWPadnos> done
[19:08:17] <Lerneaen_Hydra> commercial stuff sets to whatever the knob is set at, but I like this proposed idea more
[19:08:20] <SWPadnos> err, I mean "aye"
[19:08:30] <alex_joni> yarrr
[19:08:32] <Lerneaen_Hydra> how do you "unlock" >100% speeds?
[19:08:39] <Lerneaen_Hydra> go under 100% then up again?
[19:08:45] <SWPadnos> set the FO ini variable to some number (not in percent)
[19:08:47] <alex_joni> no.. turn it after M48
[19:08:53] <SWPadnos> err - nevermind ;)
[19:09:11] <Lerneaen_Hydra> (assuming you set FO to 300% during m49)
[19:09:30] <Lerneaen_Hydra> would you set FO to a value <100%, and then raise it again?
[19:09:32] <alex_joni> Lerneaen_Hydra: keep rotating it after M48
[19:09:42] <alex_joni> we're talking encoders here
[19:09:48] <Lerneaen_Hydra> oh, right
[19:09:55] <Lerneaen_Hydra> no absolute-value stuff?
[19:09:59] <alex_joni> nope :)
[19:10:09] <Lerneaen_Hydra> what if you have an absolute-value knob?
[19:10:11] <SWPadnos> so this effectively becomes your (alex's) original idea, except that the original value is kept in the FO variable until an attempt is made to change it
[19:10:12] <alex_joni> sliders which magically jump to 100%
[19:10:15] <Lerneaen_Hydra> (which is not all too uncommon)
[19:10:22] <Lerneaen_Hydra> SWPadnos: yeah
[19:10:26] <alex_joni> bbl
[19:10:28] <alex_joni> need to run
[19:10:29] <SWPadnos> LH - that's not allowed, according to the NIST principle
[19:10:35] <Lerneaen_Hydra> ooh, right
[19:10:37] <Lerneaen_Hydra> ok
[19:10:38] <SWPadnos> see you later Alex
[19:10:44] <alex_joni> Lerneaen_Hydra: you have multiple GUI's and physical buttons
[19:10:45] <Lerneaen_Hydra> so that would break lots of internal stuff?
[19:10:49] <alex_joni> likely to run you into problems
[19:11:07] <alex_joni> and you cannot move a fixed knob from the outside :)
[19:11:29] <Lerneaen_Hydra> huh?
[19:11:48] <SWPadnos> if you have 6 knobs (physical ones) that are set to 0% through 1000% for override, you can have strange things happen when you move control from one to the other (front/back panels on a large lathe, plus a pendant and a GUI or two)
[19:12:29] <SWPadnos> so NIST says that there must be exactly one locus of control at a time, and that changing control from one location to another should cause no discontinuities
[19:13:09] <Lerneaen_Hydra> yeah having multiple control panels with absolute knobs is just inviting issues
[19:13:20] <SWPadnos> so something like a pendant with coolant control might be a 3-position momentary switch (mom-off-mom) and a light, instead of a simple DPDT switch
[19:13:25] <SWPadnos> right
[19:13:42] <SWPadnos> "no surprises" is the general principle ;)
[19:14:46] <Lerneaen_Hydra> yeah, my psuedo-on/off spindle controll is somewhat surpising till one gets used to it
[19:15:27] <Lerneaen_Hydra> it's on/off, but I've added some logic so that when switched to on it sends an on signal for 2 seconds, and when off sends an off signal for two seconds
[19:16:30] <SWPadnos> ah
[19:17:07] <SWPadnos> I was kind of wondering what you were referring to, but I'm also trying to figure out why a particular motherboard isn't working :(
[19:17:50] <Lerneaen_Hydra> no POST?
[19:17:57] <Lerneaen_Hydra> or less dramatic?
[19:19:22] <SWPadnos> no nothing
[19:19:29] <SWPadnos> it's the second RMA replacement, too
[19:19:39] <Lerneaen_Hydra> oh. nice. :/
[19:20:34] <SWPadnos> err - yeah
[19:30:44] <skunkworks> make sure your mouse and keyboard are plugged into the correct spots (if they are ps/2 style) I have had more than one motherboard not even post because of it
[19:30:57] <skunkworks> stupid I know
[19:51:34] <jepler> setp sim-encoder.0.ppr 64
[19:51:34] <jepler> setp encoder.position-scale 256
[19:51:56] <jepler> /* convert speed command (revs per sec) to counts/sec */
[19:51:57] <jepler> freq = rev_sec * sim_enc->ppr * 4.0;
[19:53:41] <skunkworks> hmmm. Is that what I think it is? Or am I totally missing it again :)
[19:57:44] <alex_joni> back
[19:59:31] <jepler> skunkworks: that was apropos of nothing
[20:01:58] <alex_joni> so.. did we get to a conclusion regarding M48/M49 ?
[20:03:16] <SWPadnos> chris never came back to argue, so I think the last we discussed is OK ;)
[20:03:33] <cradek> there are too many words to read back
[20:03:35] <alex_joni> well.. I'd like him to give his ok before coding this
[20:03:36] <alex_joni> :)
[20:03:36] <SWPadnos> (maintain FO setting until someone messes with it)
[20:03:47] <cradek> I assume you decided the sane thing, which is by definition what I want :-P
[20:03:53] <alex_joni> if it's been messed with , set it to 100%
[20:03:56] <SWPadnos> if messed with during M49, then lock at 100%
[20:04:00] <alex_joni> if not, it stays how it was
[20:04:04] <SWPadnos> of course
[20:04:14] <cradek> what's "lock"?
[20:04:15] <SWPadnos> wait, I didn't understand one of those words ;)
[20:04:25] <SWPadnos> force to 100%
[20:04:40] <cradek> during or after the m48?
[20:04:49] <cradek> err during m49 or after the m48?
[20:04:59] <SWPadnos> essentially, it's what alex was proposing, except that the slider (and FO setting) are unchanged *unless* someone messes with them
[20:05:19] <SWPadnos> if you mess with it, it gets set to 100%, so there are no surprises later
[20:05:26] <alex_joni> cradek: start with 40%, switch to M49 (100%), user messes with slider, M48 (100%)
[20:05:31] <SWPadnos> if you leave it alone, the old setting is retained
[20:05:41] <alex_joni> cradek: start with 40%, switch to M49 (100%), user doesn't mess with slider, M48 (40%)
[20:06:03] <cradek> that seems otherworldly and magical to me
[20:06:08] <SWPadnos> perfect
[20:06:14] <cradek> sounds like the exact flip side from "no surprises"
[20:06:32] <SWPadnos> no feedrate surprises, one GUI-related surprise
[20:06:42] <alex_joni> I'll try to code it up, and see how it feels
[20:06:58] <alex_joni> maybe you can look at it too sometimes
[20:06:59] <cradek> so if during the m49 I slide to 0, it doesn't stop when I issue m48, it keeps going full speed?
[20:07:03] <SWPadnos> having the slider jump out of your control and stay at 100% would be disconcerting, I'm sure
[20:07:16] <Lerneaen_Hydra> oh, that's not what I had imagined. I thought you guys meant that mess with FO *and* set it to over 100%, then it locks to 100%
[20:07:30] <Lerneaen_Hydra> everything else sets it to the output value on m49
[20:07:57] <SWPadnos> hmmm - that may make sense as wekll - if fiddles with, then cap at 100%
[20:07:57] <cradek> I think that's still strange, but less insane
[20:08:05] <SWPadnos> fiddled
[20:08:51] <cradek> um, why not just do what the spec says?
[20:09:09] <Lerneaen_Hydra> because if m49 starts and I set to 0% then I probably have a reason to have 0% when the move is completed
[20:09:21] <Lerneaen_Hydra> s/move/m49
[20:09:22] <cradek> yes, that's according to the spec
[20:09:26] <SWPadnos> well, that was my original thought. leave FO alone entirely, but ignore it if M49
[20:09:33] <cradek> yes
[20:09:43] <alex_joni> that's even easier to code
[20:09:44] <cradek> I really think that's what it says, and it's also the most sane thing to do
[20:09:57] <alex_joni> ok, so while M49 any changes to FO will be dropped
[20:10:06] <cradek> no!
[20:10:17] <alex_joni> I mean recorded, but not applied
[20:10:22] <cradek> m49 *ignores* the FO, m48 *honors* it again
[20:10:24] <SWPadnos> but the idea of a discontinuity when dwitching between M48/M49, and the idea that the GUI controls would have no effect, made me think something else might be better
[20:10:26] <Lerneaen_Hydra> however you're left with the issue of operator/monkey thinks "hmm this is a tad slow", so he tries to up it to 110%, no change, he thinks wtf?! and changes to 300%, right then m48 is issued :(
[20:10:38] <alex_joni> SWPadnos: discontinuity is not a problem
[20:10:39] <Lerneaen_Hydra> bang!
[20:10:42] <SWPadnos> s/dwitching/switching/
[20:11:01] <cradek> SWPadnos: I think the discontinuity is the feature we're implementing
[20:11:06] <alex_joni> SWPadnos: it would still honour accel & all
[20:11:10] <SWPadnos> well, if discontinuity is no problem, then I'm with cradek. no changes to GUI or anything else related to FO
[20:11:12] <cradek> but I do agree with LH about the gui surprise
[20:11:14] <Lerneaen_Hydra> I was thinking that it would behave as cradek described, except that the output FO cannot be over 100%
[20:11:15] <SWPadnos> only ignored when in M49
[20:11:31] <alex_joni> Lerneaen_Hydra: why 100%?
[20:11:38] <alex_joni> why not the value in the ini?
[20:11:42] <alex_joni> or 97%
[20:11:50] <SWPadnos> because that's what you're at while in M49
[20:11:53] <Lerneaen_Hydra> so when m48 is issued if FO>100% set FO to 100%, else leave FO alone
[20:12:00] <SWPadnos> not change the FO limit, but change the FO setting
[20:12:11] <cradek> now hang on a sec guys
[20:12:21] <cradek> if the bug is that the user doesn't realize FO is disabled, isn't that a gui bug?
[20:12:28] <alex_joni> probably so
[20:12:38] <cradek> we don't have to make the motion do a bizarre thing to work around a gui bug.
[20:12:43] <cradek> that's the wrong way to go about it.
[20:13:13] <SWPadnos> the slider needs to be italicized, so people can tell it won't do anything ;)
[20:13:14] <Lerneaen_Hydra> the commercial stuff I've worked with barfs out error messages when trying to change FO during a m49 bit
[20:13:24] <SWPadnos> that's one UI solution
[20:13:28] <cradek> right
[20:13:38] <cradek> disabling the slider so it can't be moved is another
[20:13:52] <cradek> turning it hot pink to tell the user something odd is up with it is another
[20:14:08] <alex_joni> yay hot pink
[20:14:09] <cradek> but my point remains that this is a gui issue only
[20:14:11] <SWPadnos> yep
[20:14:21] <SWPadnos> or change the label to Feed Override (ignored)
[20:14:27] <alex_joni> * alex_joni closed another feature request
[20:14:28] <cradek> sure
[20:14:36] <cradek> yay!
[20:14:45] <SWPadnos> added optional stop to halui?
[20:14:51] <alex_joni> it was already there
[20:14:52] <alex_joni> :D
[20:14:54] <SWPadnos> cool ;)
[20:15:04] <cradek> that's the best kind of bug report close
[20:15:07] <alex_joni> M48/M49 is next :)
[20:15:18] <cradek> no wait, already there and tested is even better :-)
[20:15:25] <SWPadnos> and documented
[20:15:29] <SWPadnos> and publicized ;)
[20:15:29] <alex_joni> who said anything about tested?
[20:15:30] <alex_joni> :D
[20:15:36] <cradek> with a snarky link to the documentation
[20:15:37] <cradek> haha
[20:15:40] <SWPadnos> heh
[20:15:51] <SWPadnos> and a configuration wizard
[20:16:21] <SWPadnos> "What would you like to optionally stop today?"
[20:16:31] <alex_joni> with a pointy hat up your a$$
[20:16:36] <SWPadnos> heh
[20:16:38] <jepler> http://emergent.unpy.net/files/sandbox/spindle-estimated-speed.png
[20:16:42] <SWPadnos> thank you Harry Potter
[20:17:10] <cradek> jepler: very nice
[20:17:22] <jepler> red is encoder output reset by index pulses every revolution. cyan is a noisy estimate of speed based on counts per servo period. green is a smoothed version of cyan
[20:17:24] <alex_joni> jepler: eyecandy
[20:17:33] <cradek> this gives us "spindle at speed" for almost free right?
[20:18:04] <alex_joni> hmm.. ubuntu xinit update
[20:18:30] <jepler> cradek: sure, you could add a 'wcomp' to check that the speed is within a window of the desired speed
[20:18:42] <cradek> cool
[20:18:44] <alex_joni> jepler: getting messages about cats during the build process
[20:18:45] <jepler> if you've got an encoder on your spindle
[20:18:47] <alex_joni> is that normal? ;)
[20:18:49] <cradek> alex_joni: hmm, nothing on bugtraq
[20:18:50] <jepler> alex_joni: yeah that's new
[20:19:03] <jepler> alex_joni: it's so that 'apropos' works for emc2 manpages
[20:19:12] <alex_joni> goody
[20:19:18] <jepler> $ apropos shm | head -1
[20:19:18] <jepler> rtapi_shmem (3rtapi) - Functions for managing shared memory blocks
[20:19:38] <alex_joni> too many new things to keep track :D
[20:19:56] <cradek> I'm finally getting used to 'make tags'
[20:20:03] <alex_joni> same here
[20:21:17] <jepler> I think you'd use a different method for estimating speed if you've got a 1 pulse per revolution spindle -- track the number of base_periods between pulses .. if it gets too large, assume the spindle is stopped. otherwise, spindle_speed = scale / counts_between_pulses
[20:23:21] <alex_joni> hmm.. does HEAD run for you?
[20:23:57] <jepler> yes, I was just using it to make that screenshot
[20:24:54] <skunkworks> jepler: Very nice :)
[20:25:08] <alex_joni> I'm getting some strange errors I've never seen
[20:25:25] <alex_joni> HAL:0: ERROR: systemv failed, returned 1
[20:25:25] <alex_joni> HAL:0: ERROR: rmmod failed, returned -1
[20:25:25] <alex_joni> HAL:0: ERROR: unloadrt failed
[20:25:43] <alex_joni> and pastebin isn't really working
[20:25:53] <jepler> hm -- it's not that you forgot make setuid is it?
[20:26:06] <alex_joni> it didn't prompt me to, but I did anyways lateron
[20:26:10] <alex_joni> still the same problem
[20:26:50] <alex_joni> if it's of no use, I'll try to make clean, and reconfigure&&make
[20:27:05] <alex_joni> unless you want me to look at something
[20:27:20] <cradek> I saw that once but don't remember how I fixed it
[20:27:21] <jepler> what's the line before 'systemv failed'?
[20:27:22] <skunkworks> I thought thats what I was geting because of #2 on
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[20:27:23] <alex_joni> http://pastebin.ca/205447
[20:27:35] <cradek> a clean probably (switching between sim & rt)
[20:27:52] <alex_joni> cradek: this RT configured repo was running a few days ago
[20:28:19] <jepler> pastebin sure is slow
[20:28:37] <Lerneaen_Hydra> http://rafb.net/paste/
[20:29:32] <alex_joni> http://rafb.net/paste/results/fMwPmD14.html
[20:30:19] <SWPadnos> looks like comp modules didn't get built or something
[20:30:46] <jepler> is or2.ko in rtlib/?
[20:30:48] <alex_joni> they did get built
[20:30:57] <alex_joni> there is an or2.ko in rtlib/
[20:31:06] <alex_joni> but I somehow think it's not an rip configure
[20:31:10] <alex_joni> not sure what happend
[20:31:16] <alex_joni> I'll make clean, and run all again
[20:31:31] <alex_joni> don't waste any more time on this until I can say for sure :/
[20:32:50] <alex_joni> although RUN_IN_PLACE = yes
[20:39:57] <alex_joni> something changed about scripts/realtime stop
[20:40:05] <alex_joni> I get lots of errors if the modules aren't loaded
[20:42:32] <alex_joni> http://rafb.net/paste/results/R5CRNw53.html
[20:43:39] <alex_joni> http://rafb.net/paste/results/eaFgsj36.html
[20:44:18] <alex_joni> http://rafb.net/paste/results/cJ99XO76.html
[20:44:33] <alex_joni> last one contains the others aswell
[20:44:42] <alex_joni> something wrong about registering the module
[20:48:38] <alex_joni> found a problem
[20:48:47] <alex_joni> or2.comp had not as the component name
[20:50:55] <jepler> oops!
[20:51:20] <alex_joni> still doesn't run here
[20:51:23] <alex_joni> sim/axis.ini
[20:51:45] <alex_joni> some module_helper problem, rebuilding now
[20:52:51] <jepler> "or" is just as wrong as "not"
[20:53:46] <alex_joni> argh.. yes
[20:53:47] <alex_joni> :(
[20:53:49] <alex_joni> or2
[20:55:28] <alex_joni> jepler: ty, works now
[20:55:55] <jepler> I guess I wasn't running sim/axis, but max, so I didn't see the problem
[20:56:13] <alex_joni> I tried a few sim's .. but always got the same error :)
[21:55:09] <alex_joni> anyone still around?
[21:57:22] <SWPadnos> yes
[21:58:38] <alex_joni> http://rafb.net/paste/results/NTSGQV14.html
[22:03:54] <SWPadnos> err - around lines 74 and 76, why are those the all caps constants, rather than variables like the lines just below?
[22:04:40] <SWPadnos> perhaps I'm not reading the diff correctly, since it's a CVS diff rathen than context diff
[22:04:42] <alex_joni> those are commands
[22:04:55] <alex_joni> emcmot commands, the others are variables
[22:05:31] <SWPadnos> ok - phone
[22:06:19] <jepler> yeah -- consider putting "diff -upN" in ~/.cvsrc for more readable diffs
[22:10:11] <alex_joni> jepler: will do :)
[22:11:46] <SWPadnos> back
[22:12:11] <SWPadnos> so the CVS diff shows the line numbers where the changes go and the new line(s), right?
[22:12:55] <alex_joni> hang on, I have a new dif f;)
[22:13:01] <alex_joni> http://rafb.net/paste/results/tN6GE875.html
[22:13:24] <SWPadnos> ahhh - so much more readable (for the likes of me ;) )
[22:14:01] <SWPadnos> well, stylistically, "mode" isn't very descriptive ;)
[22:14:18] <alex_joni> any suggestions?
[22:14:30] <SWPadnos> on line 123, I'm talking about
[22:14:42] <SWPadnos> maybe fo_so_mode or override_mode
[22:14:59] <alex_joni> it's for both
[22:15:19] <alex_joni> and it only makes sense together with EMCOT_FEED_OVERRIDE
[22:15:27] <SWPadnos> that looks like a more generic struct though (emcmot_command_t)
[22:15:29] <alex_joni> or EMCMOT_SPINDLE_OVERRIDE
[22:15:40] <alex_joni> SWPadnos: yeah, it contains all possible command fields
[22:15:46] <SWPadnos> maybe I should read further
[22:16:12] <SWPadnos> I suppose "mode" oculd me used for any command that needs a mode, huh (as long as it's a char)
[22:16:18] <SWPadnos> could be, not oculd me ;)
[22:16:31] <alex_joni> right
[22:17:40] <SWPadnos> what are the names of the commands that set FO right now?
[22:17:48] <SWPadnos> the FO amount, not hte ignore
[22:18:06] <alex_joni> set_scale
[22:18:09] <jepler> alex_joni: nothing jumps out at me as "fishy" about that patch, so if it also tests right then check it in
[22:18:19] <alex_joni> it test right from what I've seen
[22:18:30] <SWPadnos> oh, in that case check it in ;)
[22:18:38] <alex_joni> I specifically tested with spindle speed
[22:18:48] <alex_joni> easier to see with halscope
[22:19:07] <SWPadnos> I thnk axis shows actual feedrate in the modes display, doesn't it?
[22:19:16] <SWPadnos> (alogn with G20/21, etc)
[22:19:19] <SWPadnos> garrh
[22:25:15] <alex_joni> this is confusing:
https://sourceforge.net/tracker/index.php?func=detail&aid=1576851&group_id=6744&atid=356744
[22:26:39] <skunkworks> I think you guys descided that he was wanting one thing but using incorrect solution.
[22:27:01] <skunkworks> He wanted the feed to hold until the spindle was up to speed.
[22:27:05] <alex_joni> right
[22:27:11] <skunkworks> At least that is how I read it.
[22:27:18] <alex_joni> he can do that with adaptive feed set to 0
[22:27:54] <skunkworks> is that how it was done on the mazak?
[22:28:22] <alex_joni> I think so
[22:28:29] <SWPadnos> cradek pointed out the problem with adaptive feed - you have to turn it on
[22:28:39] <cradek> I think that bugreport means "we need a motion.feedhold pin"
[22:28:40] <SWPadnos> and it can be turned off
[22:28:45] <SWPadnos> yep
[22:29:01] <cradek> maybe someone should attach that as a comment
[22:29:06] <jepler> do we want a generic feedhold that always works, or a special "spindle at speed" signal (which holds motion after spindle speed changes until it's asserted), or both?
[22:29:49] <cradek> I think both pins, so you can hook /atspeed to feedhold if you want
[22:30:02] <alex_joni> I just did
[22:30:18] <jepler> oh, I meant a "spindle at speed" input to motion, not an output
[22:30:26] <cradek> ohh
[22:30:27] <alex_joni> then they do the same thing..
[22:31:01] <jepler> kinda like tool-change-complete: after the related g/m-code is executed, hold everything until this signal is asserted
[22:31:11] <cradek> I thought about a spindle-speed-changed -> spindle-at-speed loopback
[22:31:16] <cradek> yeah just like tool change
[22:33:15] <alex_joni> question.. would it be interesting to have M1xx programs return something?
[22:33:41] <alex_joni> I'm thinking about a return value (like a simple bit reading from HAL)
[22:33:52] <alex_joni> then to be able to check that with an O-word IF
[22:34:14] <jepler> where does it return something to?
[22:34:45] <alex_joni> jepler: maybe some predefined variable?
[22:34:50] <SWPadnos> M127 Pxx Qxx > #270
[22:34:53] <alex_joni> 5000+1xx ?
[22:35:29] <alex_joni> M127 Pxx Qxx (result in #5127)
[22:35:40] <alex_joni> the only problem is knowing when it finished
[22:37:31] <cradek> I think execution should wait for M1xx
[22:37:45] <cradek> (if you don't want that, you can just spawn a child and exit)
[22:40:39] <alex_joni> sounds like a good thing
[22:40:45] <alex_joni> how about having a return value?
[22:40:55] <alex_joni> I mean carrying some data :)
[22:41:21] <alex_joni> I see a lot of flexibility in this :D
[22:41:29] <cradek> I do too
[22:41:43] <cradek> but I'm afraid it's a poor substitute for real interp-hal connection
[22:42:25] <cradek> (but if it's simple then I guess there's no reason not to do it)
[22:43:26] <alex_joni> well.. not tonight :)
[22:43:40] <jepler> we should do something good, not something simple.
[22:44:05] <jepler> I would also hate to see something that is too difficult for the live preview to deal with
[22:44:17] <jepler> if the interpreter tries to create hal pins, axis won't be able to embed an interpreter to do the preview
[22:44:53] <alex_joni> right.. no hal pins from the interp
[22:45:00] <alex_joni> that would be really odd
[22:50:24] <alex_joni> anyways.. nuff for today
[22:50:35] <alex_joni> good night all
[22:52:38] <jepler> see you alex_joni
