Back
[00:07:09] <alex_joni> ROFLMAO
[00:07:18] <alex_joni> anyone knows of a screenrecorder for linux?
[00:07:27] <alex_joni> I have a puma gone berzerk
[00:07:28] <alex_joni> :))
[00:08:44] <cradek> haha
[00:09:15] <alex_joni> this is definately something nice to see
[00:09:16] <cradek> I saw someone told you how to convert between degrees and radians correctly :-)
[00:11:02] <alex_joni> yeah ;)
[00:11:28] <alex_joni> I was too lazy to check all the code :)
[00:25:15] <jmkasunich> hi
[00:26:06] <alex_joni> the puma kins are better now
[00:26:17] <alex_joni> still a bit of problems, but it's working
[00:26:28] <alex_joni> http://imagebin.org/7471
[00:26:29] <cradek> cool!
[00:26:52] <alex_joni> it needs to learn straight lines :D
[00:28:02] <alex_joni> when switching from joint to world space, make sure the joint 4 is not at 0
[00:28:48] <jmkasunich> Jack Ensor is a danger to himself and everybody around him!
[00:28:56] <alex_joni> haha
[00:29:10] <cradek> ha
[00:29:22] <jmkasunich> there are two ways to do things
[00:29:44] <jmkasunich> you can just use the samples and be blissfully ignorant, or you can learn the underlying principles and customize
[00:30:09] <cradek> ... or you can ask someone else to figure it out for you, one bit at a time, on a mailing list
[00:30:12] <jmkasunich> you CANNOT customize and troubleshoot without knowing what the hell is going on underneath
[00:30:19] <cradek> there are lots of ways you didn't cover there
[00:31:50] <jmkasunich> I have nfc why his his 2nd parport doesn't work, and why the stuff he targets at it comes out the first one
[00:32:06] <cradek> I didn't read his messages well enough to even understand that
[00:32:08] <jmkasunich> his attempt a troubleshooting is doomed, because he doesn't understand the concept of a thread
[00:32:22] <alex_joni> probably he used the wrong config
[00:32:37] <jmkasunich> he does loadrt, link and sets and expects it to work without a thread or addf
[00:33:07] <alex_joni> we had another one like that in #emc
[00:33:12] <alex_joni> only a couple of hours earlier
[00:33:13] <jmkasunich> and when he got a loadrt failure because of unknown symbol, he didn't post the dmesg line to identify the symbol
[00:33:34] <alex_joni> loadrt hal_par_port "0x0378"
[00:33:43] <jmkasunich> oh, duh
[00:33:53] <alex_joni> * alex_joni would say what symbol that is, but it wouldn't be appropiate
[00:33:58] <alex_joni> jmkasunich: I think that's just a typo in his mail
[00:33:58] <jmkasunich> loadrt parport cfg="0x0378"
[00:34:13] <alex_joni> insmod: error inserting
[00:34:13] <alex_joni> '/usr/realtime-2.6.15-magma/modules/emc2/hal_parport.ko': -1 Unknown symbol in
[00:34:16] <alex_joni> module
[00:34:27] <alex_joni> that does sound like a proper error
[00:34:27] <jmkasunich> leaving out the cfg= isn't a typo
[00:34:36] <jepler> you've both must misspelled the name of the module, but maybe that's part of the joke
[00:34:41] <alex_joni> err..
[00:34:53] <cradek> no, that's in his email
[00:35:07] <jmkasunich> hal_par_port is in one place in his mail
[00:35:10] <jmkasunich> and a typo
[00:35:23] <jmkasunich> the place where he actually tried it he did hal_parport
[00:35:23] <alex_joni> < jmkasunich> loadrt parport cfg="0x0378"
[00:35:25] <alex_joni> :-P
[00:35:38] <alex_joni> jepler: only jmk tries the other one ;)
[00:35:45] <jmkasunich> ?
[00:35:50] <alex_joni> < jmkasunich> loadrt parport cfg="0x0378"
[00:35:56] <jmkasunich> I can't rememvber if there is a hal_ on the front or not
[00:36:01] <alex_joni> there is one
[00:36:08] <jepler> we actually had a good question on #emc earlier, with a lot of useful information presented right away
[00:36:11] <jepler> unfortunately it was about ppmc so I was clueless :(
[00:36:16] <jepler> er, usc
[00:36:24] <alex_joni> I found something though :)
[00:36:31] <alex_joni> more of a luck thing
[00:36:39] <jepler> true
[00:36:52] <alex_joni> * alex_joni doesn't like that the usc uses PID
[00:37:19] <jepler> the feedback loop being integrated in stepgen sure is nice
[00:37:22] <jepler> no tuning
[00:37:27] <alex_joni> right
[00:37:33] <jmkasunich> yeah, I've been thinking about that
[00:37:40] <jmkasunich> the 5i20 stepgen works like the ppmc one
[00:37:47] <jmkasunich> so it will need pid too
[00:37:48] <jmkasunich> I'
[00:38:07] <jmkasunich> I've been thinking about pulling the stepgen "position loop" out into a component
[00:38:58] <jmkasunich> either that, or duplicating a bunch of code to embedd the loop in ppmc and 5i20
[00:40:16] <cradek> you could pull it out and make an API in C, not in HAL
[00:40:40] <alex_joni> you may play with puma now :)
[00:41:30] <cradek> ooh
[00:42:21] <alex_joni> not too hard though.. if you break it you will have to fix it :P
[00:43:27] <alex_joni> j-<TAB>: I was wondering about the pumagui, where does that backplot come from?
[00:46:35] <cradek> hey that looks really close!
[00:46:49] <cradek> the geometry measurements must not be quite right
[00:47:15] <jepler> alex_joni: in the geometry specification it says where the "work" and "tooltip" are
[00:47:21] <jepler> position and orientation
[00:47:50] <jepler> dunno exactly how it's written, look at the pumagui source if you care
[00:47:50] <jmkasunich> the puma visualization model isn't as nice as the scara one - the segment lengths aren't clearly identified
[00:47:50] <jepler> jmk wrote that part
[00:47:59] <jepler> dinnertime
[00:48:29] <jmkasunich> I wonder if the kins take into account the offsets at the shoulder and elbow joints?
[00:50:37] <alex_joni> jmkasunich: might be
[00:51:55] <alex_joni> jmkasunich: btw, the names you changed in scarakins the ones you didn't like
[00:52:01] <jmkasunich> heh, I just noticed the first sentence in Jack's mail: " I am having trouble getting failures on pinout.hal. "
[00:52:17] <alex_joni> it seems those are the default ways to specify these things
[00:52:18] <jmkasunich> totally wrong - he is actually doing great getting failures on pinout.hal
[00:53:03] <alex_joni> from the D-H (Denavit-Hartenberg) convention
[00:53:02] <jmkasunich> alex_joni: you are welcome to change them to anything you want, as long as you keep the comments in there so people (including me) can figure out what they are
[00:53:20] <alex_joni> http://en.wikipedia.org/wiki/Robot_control
[00:53:20] <jmkasunich> "standards" are only good if everybody know about them - those comments assume you don't know
[00:53:27] <cradek> jmkasunich: that'll be fixed in English 2.0
[00:54:00] <alex_joni> " The indications in the
[00:54:10] <alex_joni> error report indicate a problem with the parallel port."
[00:54:21] <alex_joni> that sounds bad even to me
[00:54:41] <jmkasunich> he's either lazy or dense
[00:55:00] <cradek> a lot of people are imprecise in their language use.
[00:55:12] <jmkasunich> I'm not talking about his language anymore
[00:55:31] <alex_joni> he's even lazy beeing dense
[00:55:34] <jmkasunich> I'm sure I've made mistakes like forgetting the "cfg=" part of a parameter
[00:55:37] <cradek> often, but not always, it's a sure sign of fuzzy thinking
[00:55:51] <jmkasunich> I don't drop everything and yell for help, I stop, review what I did, and fix it
[00:55:54] <alex_joni> fuzzy thinking?
[00:56:02] <jmkasunich> he even has it right earlier in his own email
[00:56:09] <alex_joni> probably something else than I imagine under fuzzy thinking
[00:56:42] <cradek> fuzzy thinking is the opposite of clear, logical thinking
[00:57:01] <alex_joni> hmm.. I work sometimes that way
[00:57:13] <jmkasunich> before coffee?
[00:57:17] <alex_joni> not trying to look at actual contents/data, but rather go by workflow
[00:57:23] <alex_joni> not sure I can explain it right
[00:58:02] <alex_joni> for example when using PCs.. I stopped a long time ago reading popup messages & such.. I rather go by shape, text arrangement, buttons, etc
[00:58:07] <cradek> sometimes I forget to troubleshoot a problem at first - I just dink around
[00:58:11] <alex_joni> most of the time it works great
[00:58:17] <alex_joni> cradek: yeah, that too
[00:58:19] <cradek> but when that fails for a while, I think `maybe I should start troubleshooting for real'
[00:58:25] <jmkasunich> he's been dinking for a week
[00:59:21] <alex_joni> wonder if it would be very nasty of me to reply something like: "this will be fixed in the next version, in a couple of weeks"
[01:01:29] <jmkasunich> what will? his denseness?
[01:01:38] <alex_joni> I won't say what will :)
[01:02:17] <alex_joni> anyways.. nuff' for today
[01:02:24] <alex_joni> * alex_joni head to bed
[01:02:26] <alex_joni> good night all
[01:02:51] <cradek> g'night alex
[01:03:25] <alex_joni> cradek: get a gamepad.. it's sooo nice to jog with it
[01:03:34] <cradek> I have a jogwheel!
[01:03:40] <alex_joni> well.. this is 4 axes ;)
[01:03:58] <cradek> does it have a detent every .001 inch??
[01:04:02] <alex_joni> but I guess a jogwheel is more precise
[01:04:04] <alex_joni> no..
[01:04:32] <cradek> the emc jogwheel works VERY nice
[01:04:46] <alex_joni> so does hal_input
[01:04:50] <alex_joni> :-)
[01:04:56] <cradek> we'll have to compare at fest...
[01:04:59] <alex_joni> heh
[01:05:16] <cradek> I'm off to make the hummus... mmmm
[01:05:16] <alex_joni> one of these fest's
[01:05:24] <cradek> yeah, one of them
[01:05:56] <alex_joni> well.. 'night
[01:05:59] <cradek> bye
[01:06:07] <alex_joni> maybe I'll have a look at the rigid tapping tomorrow
[01:06:35] <cradek> no hurry, the planner part isn't done yet either
[01:06:47] <cradek> and I can fake something up to test with
[04:57:50] <jmkasunich> crapski
[04:58:12] <jmkasunich> can't divide long long ints in kernel space
[04:58:43] <cradek> what are you doing?
[04:58:50] <jmkasunich> 5i20 stepgen
[04:58:54] <jmkasunich> driver
[04:58:57] <cradek> ah
[04:59:37] <jmkasunich> got a variable that is 48 bits of counts + 16 bits of fractional counts, gotta divide by scale and return a float
[04:59:52] <jmkasunich> although I thought it would become a double first
[05:00:31] <jmkasunich> maybe thats not where its happening, I do other long long math
[05:01:02] <jmkasunich> dirhold_ns * clock_freq / 1000000000 thats probably it
[05:01:38] <jmkasunich> should probably just do that math in floating point and intify the result
[05:04:01] <jmkasunich> ah, bonus, that actually eliminates a divide
[05:17:17] <jmkasunich> better
[05:44:33] <jmkasunich> 100KHz stepping ;-)
[05:46:25] <jmkasunich> 120 KHz - 3600 RPM
[05:48:25] <jmkasunich> and it can accel to that speed in 1/3 second
[05:49:28] <jmkasunich> 180 revs/second squared
[05:50:23] <jmkasunich> accel from zero to 1800 rpm at 500 revs/second squared
[12:55:43] <alex_joni> cradek: ping
[13:14:04] <alex_joni> * alex_joni has a couple of rigid tap questions for when you wake up :)
[13:23:48] <alex_joni> http://wiki.linuxcnc.org/uploads/Haas-G84.PNG
[14:55:09] <cradek> hi
[14:56:43] <cradek> I hear G84 isn't usually a rigid tap
[14:56:58] <cradek> hmm, +pid 11657 (httpd), uid 80, was killed: out of swap space
[14:57:44] <alex_joni> I found mostly references to G84 for tapping
[14:57:56] <alex_joni> http://www.mmattera.com/g-code/gcodes.html
[14:58:07] <cradek> yes
[14:58:17] <cradek> my rs274d reference says that too
[14:58:26] <cradek> also the rs274ngc doc
[14:58:27] <alex_joni> http://numeryx.com/cnc/drilling6.htm
[14:59:11] <alex_joni> anyways.. the question I had is how we want to do it?
[14:59:18] <alex_joni> shouldn't it be like threading?
[14:59:25] <alex_joni> spindle_sync_on, move forward
[14:59:36] <alex_joni> stop spindle, reverse, move back
[14:59:41] <alex_joni> spindle_sync_off ?
[15:00:12] <cradek> what level are you talking about? canon?
[15:01:59] <cradek> I think the ngc writers intended that - you'd turn on SPEED_FEED_SYNC and then do whatever (like you say) then turn it off
[15:02:53] <alex_joni> canon and interp
[15:03:16] <alex_joni> but I'm not sure how it would fit with what you've done already
[15:03:28] <cradek> it wouldn't :-(
[15:03:43] <cradek> it seems to me the TP has to do all those things itself
[15:03:45] <cradek> here's my thinking
[15:03:59] <cradek> (and what I've coded so far)
[15:04:28] <cradek> you start at a certain Z (actually it's generalized for any direction, but let's say Z) with the spindle turning clockwise
[15:04:41] <cradek> you have a goal depth in mind
[15:05:02] <cradek> you synchronize to the spindle (just like a G33 lathe thread) and start moving in Z
[15:05:29] <cradek> when you hit the goal, you command the spindle to reverse
[15:05:40] <cradek> the spindle will keep going forward - you follow it with Z
[15:06:23] <cradek> when you see the spindle stop/reverse, you build another TP segment starting there, pointing up in Z, with the goal being the original position
[15:06:57] <cradek> now you follow the Z axis the same way (notice this following is special because you don't wait for index pulse to start moving)
[15:07:49] <cradek> when you get the to goal, you command the spindle forward, but still follow it since it will be going in reverse for a while
[15:08:16] <cradek> when spindle stops you will be above the original position, so rapid to it
[15:08:52] <cradek> now, the cycle is over, the tool is where it started (this is important, because interp has to know the position)
[15:09:21] <alex_joni> I see
[15:09:31] <cradek> ok sorry for the paragraph, but that's the special handling of a tap that I think we have to do
[15:09:47] <alex_joni> so the canon call RIGID_TAP actually does the canned cycle but in motion
[15:10:16] <cradek> if that's many canon calls, (synchronize, feed, spindle, feed, spindle, unsynchronize) I think task will have to intercept those and throw most of them away
[15:11:11] <cradek> well I'm thinking of rigid tap as its own kind of move in the TP - how it gets there doesn't matter too much really
[15:12:16] <cradek> interp's G84 (or whatever) could generate a TAP canon directly, or task could recognize a particular pattern of canon calls and call motion's EMCMOT_TAP (or whatever)
[15:12:31] <alex_joni> I don't like the second variant
[15:12:42] <cradek> I don't either, but it's more in line with the ngc doc
[15:13:08] <alex_joni> recognizes sequences of canon's leads to mess in the code
[15:13:09] <cradek> I already violated the ngc scheme with G33 (because I put a pitch parameter on SPEED_FEED_SYNC)
[15:13:24] <cradek> yes I agree
[15:13:39] <cradek> so I think a new canon call is much simpler
[15:14:14] <cradek> we are never going to have SPEED_FEED_SYNC [then do anything you want] then UNSYNC work - it's just a fantasy
[15:14:43] <alex_joni> heh
[15:15:22] <cradek> so back to interp now
[15:16:37] <cradek> maybe using G84 is more standard, but I don't like that you don't specify the pitch directly
[15:17:29] <cradek> although someone said on mazak you specify pitch with F word
[15:17:51] <alex_joni> F vs. S ?
[15:18:37] <cradek> I think mostly pitch is F/S, but on mazak pitch is F alone
[15:19:12] <cradek> I think using F/S (inch/min)/(rotations/min) is crazy
[15:19:49] <alex_joni> http://www.shadowcnc.com/shadowmanual.htm
[15:19:53] <alex_joni> search for G84
[15:20:08] <alex_joni> F 25. STORE Sets the feedrate to match spindle speed/threads per inch.
[15:21:22] <cradek> right
[15:21:25] <cradek> so they use F/S
[15:22:27] <cradek> I bet this is not a rigid tap
[15:22:58] <cradek> someone said yesterday G84 is never rigid tap
[15:23:44] <alex_joni> well.. I saw some pages where they use G84 for rigid too
[15:23:58] <cradek> oh ok
[15:24:38] <cradek> what do you think is easiest? I hate to get bogged down in these decisions, we can change the interp (accept more than one way to tap) later if we want
[15:25:49] <cradek> G33.1 P(pitch) Z(endpoint)
[15:26:22] <cradek> or K(pitch), like G33
[15:26:49] <alex_joni> what's G33 again?
[15:26:58] <cradek> single point thread in any direction
[15:27:40] <cradek> to me (programmer, not machinist) rigid tap is exactly like single point thread, but with reversal
[15:31:32] <alex_joni> right
[15:33:12] <cradek> looks like either would be easy to add to interp - G84 is almost there already, G33.1 would be just like G33
[15:34:31] <cradek> G33.1, but not G33, should error if the rotary axes change during the move
[15:35:53] <alex_joni> so.. should I add G33.1 ?
[15:36:06] <alex_joni> we can change it to G84 later if we want
[15:36:06] <cradek> yes I think so
[15:36:14] <cradek> yes, or we could easily have both
[15:36:20] <alex_joni> so.. the syntax is:
[15:36:32] <alex_joni> G33.1 P(pitch-float) Xe Ye Ze
[15:37:15] <cradek> how about K = pitch so it matches G33
[15:37:21] <alex_joni> fine by me
[15:38:13] <cradek> and the canon calls will be SPEED_FEED_SYNC(k), RIGID_TAP(x,y,z), UNSYNC()
[15:39:08] <cradek> task (emccanon.cc) will know that RIGID_TAP does not move the endpoint
[15:40:44] <cradek> meaning: do not call canonUpdateEndPoint(x,y,z)
[15:40:50] <cradek> (I think)
[15:41:12] <alex_joni> or canonUpdateEndPoint(initial point)
[15:41:20] <cradek> yes
[15:42:15] <cradek> maybe RIGID_TAP(x,y,z,a,b,c) where a,b,c are initial
[15:43:18] <cradek> (be sure you're on rigid_tap cvs branch)
[15:44:02] <alex_joni> yeah, I checked it out :P
[15:48:10] <alex_joni> http://pastebin.ca/381043
[15:49:01] <cradek> perfect
[15:58:09] <alex_joni> should canon throw an error if a,b,c differ?
[16:07:32] <cradek> interp should have already errored and stopped interpreting
[16:07:37] <alex_joni> right..
[16:07:48] <alex_joni> except when it's not this interp calling the canon call
[16:08:45] <cradek> maybe RIGID_TAP(xyz) is better for that reason
[16:08:46] <cradek> you decide :-)
[16:09:01] <cradek> bbl, I need shower + breakfast
[16:09:15] <alex_joni> ok, I'll try to have the rest done by the time you come back :P
[16:09:50] <cradek> thanks for doing this!
[16:10:15] <alex_joni> no sweat
[16:25:02] <alex_joni> cradek: do we need vel/accel settings for rigid_tap ?
[16:25:12] <alex_joni> * alex_joni wonders why..
[16:27:01] <skunkworks> alex_joni: I thought there was a spindle up to speed pin or something like that - I remember them fixing it on the mazak - because the first time they went to cut something the spindle was not up to speed before the axis was moving. but later it worked.
[16:27:47] <alex_joni> skunkworks: I think they used feedhold
[16:35:03] <skunkworks> ok
[16:38:54] <cradek> alex_joni: because the axis motion still needs to be within machine constraints
[16:39:10] <cradek> especially at the last move which is unsynced
[16:39:17] <alex_joni> right.. I just concluded that
[16:48:14] <alex_joni> well.. it compiles :)
[16:48:33] <alex_joni> (didn't do the G33.1 part yet, only CANON -> tp)
[16:50:21] <jtr> from yesterday - "07:05:13 <jmkasunich> "if spindle-on and not delayed-spindle-on then feedhole = true"
[16:50:30] <alex_joni> jtr: I know..
[16:52:30] <jtr> ok
[16:52:39] <alex_joni> thanks for pointing it out though :)
[16:57:48] <alex_joni> STRAIGHT_FEED(boring?
[16:57:53] <alex_joni> lol
[17:13:45] <alex_joni> cradek: here you go :)
[17:14:25] <alex_joni> gotta run for a while.. bbl
[17:16:47] <jmkasunich> morning
[17:17:32] <alex_joni> hi jmk..
[17:18:14] <jmkasunich> hi
[17:21:52] <alex_joni> * alex_joni doesn't leave anymore..
[17:21:57] <alex_joni> so.. what's new?
[17:22:14] <jmkasunich> nothing
[17:22:19] <jmkasunich> still doing 5i20 stuff
[17:25:29] <alex_joni> nice :)
[17:25:36] <alex_joni> I'm still waiting for mine
[17:26:12] <jmkasunich> I'm going to try my first real VHDL stuff today
[17:26:21] <jmkasunich> found a minor bug in the step generator
[17:27:54] <jepler> in stepgen? or in the vhdl step generator
[17:28:03] <jmkasunich> the 5i20 vhdl one
[17:29:08] <jmkasunich> I think the first step is making sure I have the "build" process right (do a build from the unmodified vhdl files and test it)
[17:29:11] <alex_joni> hi jeff
[17:29:27] <jmkasunich> it really sucks that the build takes the better part of an hour
[17:30:18] <jmkasunich> side note: sooner or later (sooner I hope) I'm gonna have to commit all my new 5i20 stuff (both vhdl and driver) to CVS
[17:30:33] <jmkasunich> there's already a m5i20 driver and directory full of vhdl
[17:30:44] <jmkasunich> I don't want to break the people who are using that
[17:31:14] <jmkasunich> although eventually I hope to transition them over to the new driver
[17:31:54] <jepler> jmkasunich: an hour? yuck
[17:32:06] <jmkasunich> place and route takes the longest
[17:32:17] <jepler> I would get impatent when pluto took 2 minutes to build
[17:32:32] <jmkasunich> for testing, I'm thinking of doing a top level file that only invokes a single stepgen instead of 8 of them, plus encoder counters plus...
[17:33:10] <jepler> that should cut the time considerably, especially if there are "prefer fast builds to speed/size" settings you can tweak
[17:33:38] <jmkasunich> well the thing about the tweaks is - the default settings don't quite meet a timing constraint
[17:33:49] <jepler> oh
[17:34:04] <jmkasunich> I dunno if peter has tweaked things differently and is meeting the constraint, or if his results are about like mine
[17:34:41] <jmkasunich> (missing a 22nS target by 2-4nS, can probably get away with it because of tolerances and temperature affects
[17:35:00] <jepler> btw do you want emc's 'make' to rebuild the VHDL stuff if a person has the tools installed? I could help out with that part if you do
[17:35:10] <jmkasunich> not sure
[17:35:16] <jepler> but on the other hand so few people will have these tools installed, a standalone script or makefile might be the better choice
[17:35:30] <jmkasunich> I'm still vaccilating between using a script and using a standalone makefile
[17:35:30] <jepler> I do (heart) the idea of having the exact commands to invoke in a file
[17:35:49] <jmkasunich> oh definitely
[17:35:56] <jmkasunich> otherwise it ain't pretty
[17:35:57] <cradek> alex_joni: yay thanks!
[17:36:13] <jepler> make can invoke a script just fine
[17:36:44] <jepler> raw_firmware_file: all vhdl files ; sh rebuild-firmware.sh
[17:37:45] <alex_joni> cradek: should we start testing?
[17:38:11] <jmkasunich> jepler: its a multi-step process, and if I was using make I'd let make handle the steps
[17:38:17] <jmkasunich> http://www.pastebin.ca/381144
[17:38:23] <jmkasunich> my notes so far
[17:40:19] <cradek> alex_joni: the planner part is not done yet :-)
[17:40:31] <jmkasunich> the last part about RAM/ROM and .bmm files is probably something I should forget about
[17:40:41] <jmkasunich> just embed the ram contents in the vhdl
[17:41:15] <alex_joni> cradek: oh, ok.. I was afraid to try it :P
[17:41:51] <alex_joni> hmm.. forgot some AXIS part.. will be there soon
[17:42:13] <jmkasunich> jepler: what gets interesting is that I'd like to simplify the task of building different fpga configs
[17:42:30] <jmkasunich> that means not hardcoding the name of the top level vhdl file in the makefile
[17:42:57] <jepler> I understand
[17:43:22] <jmkasunich> eventually I'd like to automate creation of that top level file too
[17:43:31] <jmkasunich> but I should start small
[17:43:36] <jepler> I was trying to make my example short, but in reality there would be arguments to rebuild-firmware.sh that depend on the target raw_firmware_file
[17:43:56] <jmkasunich> raw_firmware is the end result - the bitstream?
[17:44:17] <jepler> yes, I think so
[17:44:32] <jmkasunich> you think so?
[17:44:34] <jepler> I think it's desirable to store raw_firmware, not the .h file version, in CVS -- it's a smaller download in bytes, for instance
[17:44:51] <jmkasunich> right
[17:45:11] <jepler> it could be anything -- whatever the "output" of the script you write is
[17:45:12] <jmkasunich> in fact, I've been planning to drop the entire .h mess
[17:45:21] <jmkasunich> ok
[17:45:39] <jmkasunich> when I asked that question, I wasn't sure if raw meant output or source
[17:46:04] <jmkasunich> embedding the bitstream in the driver implies that there is a preferred bitstream
[17:46:35] <jmkasunich> the new scheme will not have a preferred bitstream - you load the one you want, and the driver discovers what it has and exports the right hal pins
[17:47:14] <jepler> sounds good to me, as long as someone else writes it
[17:47:20] <jmkasunich> heh
[17:47:31] <jmkasunich> thats what the ram stuff is about
[17:47:34] <alex_joni> jepler: in gcodemodule.cc : _pos_x & co are the positions after an action?
[17:47:40] <jepler> alex_joni: yes I think so
[17:47:45] <alex_joni> ok..
[17:47:52] <jmkasunich> the ram (or rom, depending on your point of view) tells the driver what is available
[17:51:16] <jmkasunich> jepler: if the process always has to start over from the beginning, is there really much benefit to using make?
[17:52:05] <jmkasunich> unlike C, the "link" stage happens very early in the chain, so if you change any source file, the link output changes, and then the rest of the chain needs re-run
[17:54:12] <jepler> jmkasunich: if you have several configurations and one of them doesn't have encoders, then make helps you avoid rebuilding that one when only the encoder vhdl file is changed
[17:54:59] <jmkasunich> true
[17:55:20] <jmkasunich> although that will require some sort of dependency discovery process
[17:55:39] <jmkasunich> vhdl doesn't have include
[17:56:01] <jepler> verilog is a bit like that as well
[17:56:15] <jepler> you just create instances, and it looks in god-knows-where for the associated source file
[17:56:23] <alex_joni> cradek: was just about to commit that
[17:56:33] <cradek> crap, sorry
[17:56:35] <jmkasunich> for the xilinx tools, the prj file tells it which files to use
[17:56:38] <cradek> didn't know you were still working
[17:56:41] <alex_joni> cradek: no problem..
[17:56:43] <jmkasunich> make would have to parse that I guess
[17:56:48] <alex_joni> I'll commit an fix for axis now
[17:56:55] <cradek> ok
[17:57:11] <alex_joni> wonder if I got it right..
[17:57:21] <cradek> I always wonder that
[17:57:41] <jmkasunich> duh.... /me was wondering why the compile farm didn't react to the latest commits
[17:57:50] <jmkasunich> on a branch ;-)
[17:58:29] <jepler> jmkasunich: given all that, I think a script is just fine
[17:58:57] <jepler> let me know if you want help on the top-level vhdl creation script
[17:59:03] <jmkasunich> I'm thinking that I should define a few conventions
[17:59:09] <jmkasunich> yes, I do
[17:59:17] <jmkasunich> thats why I keep talking at you ;-)
[17:59:27] <alex_joni> * alex_joni grins
[17:59:37] <jmkasunich> convention: foo.vhdl is the top level file that creates foo.bit
[17:59:58] <jmkasunich> it can invoke all kinds of other vhdl files, but all the working files are named foo.whatever
[18:02:30] <jmkasunich> you'd think the vhdl folks would understand the concept of include files
[18:03:05] <jmkasunich> entity and component are basically the same thing
[18:03:25] <jmkasunich> except one is in the file that defines the item, and the other is in the file that uses it
[18:03:34] <jmkasunich> they are both "prototypes" of a sort
[18:06:36] <jmkasunich> jepler: py is good a parsing stuff isn't it?
[18:06:49] <jmkasunich> (as opposed to doing heavy grep-fu)
[18:07:32] <jepler> jmkasunich: you know I like python for almost every purpose
[18:08:34] <jepler> ghdl - VHDL compiler/simulator using GCC technology
[18:08:54] <jmkasunich> compiler simulator yes
[18:09:00] <jmkasunich> synthesis no
[18:09:09] <jmkasunich> http://www.pastebin.ca/381182
[18:09:42] <jepler> a simulator means you wouldn't have to spend your hours waiting just to test a step generator bugfix
[18:10:03] <jmkasunich> how nasty would it be to pick out lines like 339 and 408
[18:10:24] <jmkasunich> instead I'd spend twice as many hours developing stimulus files
[18:11:12] <jmkasunich> including simulating the PCI bus transactions, and even the execution of some of the driver code
[18:11:16] <jmkasunich> no way I want to go there
[18:12:00] <jmkasunich> hmm, first step on parsing that file is to lose the newlines
[18:12:15] <jepler> are you talking about parsing, for dependency generation?
[18:12:19] <jmkasunich> yeah
[18:13:03] <jmkasunich> I think the structure I want to find is "<identifier> : <identifier> port|generic"
[18:13:03] <jepler> it looks like there are available VHDL parsers for python
[18:13:20] <jmkasunich> I should have known
[18:13:28] <jmkasunich> * jmkasunich always tries to re-invent the wheel
[18:13:32] <alex_joni> * alex_joni wonders what doesn't exist for python
[18:14:53] <alex_joni> cradek: I would say the interp, canon part works OK
[18:14:54] <alex_joni> emcTaskPlanExecute(G33.1 K1 Z0) returned 0
[18:14:54] <alex_joni> Outgoing motion id is -3.
[18:14:54] <alex_joni> Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+20, +0,1.000000,)
[18:14:54] <alex_joni> Issuing EMC_TRAJ_RIGID_TAP -- (+237,+84, +0,)
[18:14:57] <alex_joni> Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+20, +0,0.000000,)
[18:15:05] <jmkasunich> anyway, the 2nd identifier in that structure is the entity that is being invoked
[18:15:30] <jmkasunich> and usually (we could make it a convention) the name of the vhdl file that needs to be "included"
[18:15:30] <jepler> lunchtime here, bbl
[18:15:59] <jmkasunich> lunchtime here too (or breakfast, or something)
[18:16:19] <alex_joni> foodtime :)
[18:16:54] <cradek> so do any of you use lxr on linuxcnc?
[18:17:07] <alex_joni> I used it twice I think
[18:17:15] <alex_joni> (since it was set up..)
[18:17:46] <cradek> 66.249.65.133 - - [04/Mar/2007:12:15:19 -0600] "GET /lxr/source/src/libnml/buffer/Submakefile HTTP/1.1" 200 4269 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +
http://www.google.com/bot.html)"
[18:18:21] <cradek> this is why cvs is so slow today
[18:18:33] <alex_joni> flooded by google bots?
[18:18:41] <cradek> yeah it's crawling the lxr
[18:18:50] <alex_joni> well.. it'll pass I guess
[18:18:58] <alex_joni> don't think they crawl too often
[18:19:02] <cradek> not for a long time - lxr is sllloooowww
[18:19:17] <alex_joni> hmmm
[18:19:19] <cradek> must be a way to fix that with robots.txt
[18:19:58] <alex_joni> User-agent: *
[18:19:59] <alex_joni> Disallow: /lxr
[18:20:12] <cradek> "GET /lxr/source/debian/changelog HTTP/1.1" 200 69158 "
http://www.google.co.uk/search?hl=en&q=input+scale+emc2&meta="
[18:20:29] <cradek> here's someone who used that to find us though
[18:20:49] <alex_joni> it's the 3rd hit
[18:20:56] <alex_joni> and the least relevant imo :D
[18:21:05] <cradek> ok
[18:22:18] <alex_joni> heh.. didn't see this in a while:
http://www.metalworking.net/
[18:22:21] <cradek> can I have more than one Disallow line there?
[18:22:26] <alex_joni> sure
[18:22:43] <alex_joni> my usual robots.txt is:
[18:22:44] <alex_joni> User-agent: *
[18:22:44] <alex_joni> Disallow: /cgi-bin
[18:22:44] <alex_joni> Disallow: /stats
[18:22:43] <alex_joni> Disallow: /include
[18:22:48] <cradek> ok thanks
[18:22:55] <cradek> saved me from reading documentation
[18:23:14] <alex_joni> np
[18:28:11] <alex_joni> was that Peter Wallace in #emc ?
[18:28:34] <cradek> probably
[18:32:21] <jmkasunich> dang
[18:33:00] <cradek> wish I had noticed
[18:33:21] <alex_joni> I only noticed when he went away
[18:34:23] <jmkasunich> he was only there for less than a minute
[18:34:33] <jmkasunich> drive-by
[18:42:45] <jepler> I wonder how soon google will re-check robots.txt ...
[18:42:53] <cradek> next time probably
[18:42:59] <cradek> that's ok I guess
[18:57:45] <skunkworks> jmkasunich: peter is back
[20:34:22] <petev> alex_joni u there?
[20:36:42] <alex_joni> yup
[20:39:10] <petev> did u see my post to the dev list re spindle control?
[20:45:37] <alex_joni> petev: the second one?
[20:46:03] <alex_joni> I replied to the first one.. didn't see another one
[20:46:09] <alex_joni> but we can talk it out in here ;)
[20:46:22] <petev> I only posted once, I think
[20:46:28] <petev> the first post bounced
[20:46:40] <petev> jmk said I was no longer subscribed to dev list
[20:46:44] <alex_joni> ok.. I got that, and replied to it
[20:46:51] <petev> I'm in digest mode so didn't see a reply yet
[20:46:50] <alex_joni> First of all, I gotta say it's a very good topic. This is an area that can take some improvement.
[20:46:53] <alex_joni> Would this input be active only when starting the spindle? When changing spindle speed?
[20:46:56] <alex_joni> Or always? (e.g. if the spindle speed drops too much, the ladder takes this bit low, and emc2 stops with an error message).
[20:47:01] <alex_joni> Note: for regular users that don't care about this I'd have the pin default to 1 (current behaviour)
[20:47:21] <petev> I think it should be active always
[20:48:00] <petev> most VFD have some IO or relay that can be programmed for such indication
[20:48:18] <petev> for simple machines, a contact from the contactor could be used
[20:48:30] <petev> and for dumb machines, just wire it to 1 as you say
[20:48:37] <alex_joni> guess then it's just like feedhold then :)
[20:49:09] <petev> I thought about using the feed hold, but it seems like it's combining 2 different funcs
[20:49:17] <petev> and there is another issue
[20:49:31] <petev> what about when the spindle transitions from off to on"
[20:49:47] <petev> the ok input would be ok in the off state
[20:49:52] <petev> then EMC turns the spindle on
[20:50:05] <petev> the ok input needs to change
[20:50:28] <petev> so things get a bit tricky, or we need a special input for spindle
[20:50:37] <alex_joni> I'd say track it with CL :)
[20:50:51] <petev> but that doesn't help
[20:51:05] <petev> would you keep the machine in feed hold at all times?
[20:51:21] <petev> and only enable when spindle is up to speed and manual hold is off?
[20:51:34] <alex_joni> no, only when spindle is on (motion.spindle.on) and not up to speed
[20:51:50] <alex_joni> what's manual hold?
[20:51:57] <petev> but then you get the glitch when going from off to on
[20:52:09] <alex_joni> explain glitch..
[20:52:08] <petev> manual hold being some button from the console
[20:52:31] <petev> the glitch happesn because the feed hold is not on when the spindle starts
[20:52:44] <petev> but then has to transition to on until the spindle is up to speed
[20:52:56] <alex_joni> I'm not sure I'm following
[20:53:00] <petev> at which time it is turned off again
[20:57:30] <petev> motion sets spindle-on
[20:57:30] <alex_joni> right
[20:57:30] <petev> feed-hold is not set yet
[20:57:30] <petev> so machine may start to move
[20:57:30] <petev> then feed-hold is de-asserted because spindle is not up to speed
[20:57:30] <petev> machine stops
[20:57:30] <petev> seems a bit ugly
[20:57:30] <alex_joni> yeah, but that's in the fast thread
[20:57:30] <petev> would be nicer to have dedicated pin for spindle and have motion block there until it's ready
[20:57:30] <alex_joni> so less than a stepper step
[20:57:30] <petev> still ugly
[20:57:30] <petev> why not treat it more like an IO and not even let motion start until it completes?
[20:57:30] <petev> the same as tool change
[20:57:30] <alex_joni> tool change is in userspace
[20:57:30] <petev> I know I don't want my machine moving until I'm done setting the spindle speed right
[20:57:30] <petev> tool change has the tool-changed handshake
[20:57:30] <alex_joni> yeah.. I know
[20:57:30] <alex_joni> I'm still trying to think ;)
[20:57:30] <petev> also, what about spindle failures?
[20:57:30] <jmkasunich> I think a handshake is the appropriate method
[20:57:30] <jmkasunich> and for dumb systems, a jumper, just like we have now
[20:57:30] <petev> having a dedicated line would handle this too
[20:57:30] <alex_joni> it's not really a handshake..
[20:57:30] <petev> it's kind of a spindle good/up to speed status
[20:57:30] <jmkasunich> * jmkasunich hides again
[20:57:30] <alex_joni> it's more like a safety input.. while not on, machine doesn't move
[20:57:30] <petev> I think it indicates spindle status
[20:57:44] <petev> if anything is wrong with spindle, machine doens't move
[20:57:56] <alex_joni> right.. and user sits and looks baffled :)
[20:58:20] <petev> well, you could use ladder and a timeout to generate a fault indication
[20:58:36] <petev> or we could have two inputs, one for fault and one for status
[20:59:01] <petev> come to think of it, this brings up some other spindle control questions I had
[20:59:12] <petev> cradek is working on rigid tapping
[20:59:15] <alex_joni> right
[20:59:33] <petev> but as roltek points out, what he is doing will only be good for through hole tapping
[21:00:00] <jmkasunich> because he doesn't start slowing down until he hits the desired depth
[21:00:06] <petev> without a servo on the spindle, you can't do bilnd, tool changes, or other oriented spindle stuff with boring bars, etc.
[21:00:27] <petev> so how is a tool change handled without oriented spindle?
[21:00:39] <jmkasunich> on the mazak, we implemneted spindle orient in hal
[21:00:49] <petev> if there was a servo on the spindle, I guess you would have the normal amp-fault input
[21:01:10] <petev> jmk, what about blind hole tapping?
[21:01:16] <jmkasunich> when toolchange-request comes on, the spindle drive command is disconnected from EMCs output and hooked to a pid loop
[21:01:32] <jmkasunich> blind holes would never work with todays design
[21:01:50] <petev> so the mazak had a spindle servo?
[21:02:01] <jmkasunich> no, it has a rather generic DC drive
[21:02:12] <petev> with encoder?
[21:02:19] <jmkasunich> and we attached an encoder to the spindle itself so we could use the index to orient the spindle
[21:02:49] <jmkasunich> the drive accepts a speed command only, and had IIRC an analog tach on the motor for feedback
[21:03:17] <petev> how did it do tool change before the retrofit?
[21:04:33] <jmkasunich> well. thats a long story
[21:04:42] <jmkasunich> the spindle drive in there was not original
[21:04:52] <petev> so do we need two models for spindle support?
[21:04:57] <jmkasunich> the original drive was probably more capable (it was a fanuc)
[21:05:07] <jmkasunich> and there was an analog sensor for spindle postion
[21:05:08] <petev> one for servo spindles and one for dumb spindles with an encoder?
[21:05:24] <jmkasunich> I'm thinking that we should keep motion as generic as possible
[21:05:44] <jmkasunich> perhaps it has a position command output and a velocity command output
[21:05:50] <jmkasunich> and a bit that says "switch modes"
[21:06:07] <petev> that's no bad
[21:06:11] <jmkasunich> along with an ini param or something that says "you can't switch modes, you got a dumb spindle"
[21:06:47] <petev> how would the trajectory planner use this for tapping?
[21:06:53] <jmkasunich> then the actual position control and velocity control can be done however - if the drive has a position mode, just use it, if not, put pid and a mux in hal
[21:06:55] <jmkasunich> I dunno ;-)
[21:07:05] <jmkasunich> I assume it would use the position mode
[21:07:24] <jmkasunich> tell the spindle to turn 20 times, while telling Z to go 1 inch
[21:07:28] <petev> so there would be two algorithms in trajectory?
[21:07:35] <jmkasunich> I dunno ;-)
[21:07:42] <jmkasunich> * jmkasunich does hardware drivers
[21:07:48] <petev> with position it's like a coordinated move
[21:07:52] <jmkasunich> right
[21:07:54] <petev> without, it's like a slave axis
[21:08:04] <jmkasunich> cradek should be in this conversation
[21:08:39] <petev> what time is he usually on?
[21:09:15] <jmkasunich> he was here earlier
[21:09:17] <jmkasunich> he comes and goes all day
[21:09:24] <jmkasunich> (just like the rest of us)
[21:09:37] <petev> what's your preference for the short term?
[21:11:20] <jmkasunich> I'm up to my elbows in 5i20, and can't really give spindle the thought it deserves
[21:11:47] <jmkasunich> the position mode seems usefull, but I'd want cradek's thoughts on it before I advocated it
[21:13:10] <petev> I think for short term just adding a spindle-speed-ok input would be good
[21:13:25] <petev> with the full servo model, it's probably not needed
[21:20:21] <skunkworks> our spindle actually engages a cog to index the spindle for a keyed tool.
[21:21:14] <jmkasunich> skunkworks: thats what we thought the mazak had - we thought orient was going to be a simple matter of "start turning very slowly, and when you see the pulse, engage the cog"
[21:23:51] <SWPadnos> re spindle, a spindle-at-speed input would be good, and possibly a timeout parameter so that an error can be reported if the spindle doesn't get to speed fast enough
[21:24:48] <petev> yeah, the true servo spindle would use the amp-fault for that, but something may be needed for the dumb spindle model
[21:24:51] <skunkworks> ours just rotates the spindle slowly - engages the cog - waits a designated amount of time and assumes it is where it should be. It has no real feedback from the spindle except a tach that is only used for 'at speed'
[21:25:20] <skunkworks> we hope to do it a bit better.
[21:25:22] <SWPadnos> you'd build external components (or ladders ...) to handle non-simple spindle setups, such as gearchangers and the like
[21:26:22] <petev> true, but I see two major spindle types, servo (with position control), and simple with just encoder feedback
[21:26:37] <petev> maybe a third dumb type that can't even support tapping
[21:26:57] <SWPadnos> sure - an on/off with manual speed control (like a BP without servoed sheaves)
[21:27:02] <jmkasunich> btw, the mazak has a gearchanger - we did both gearchange and orient with a combination of ladder and HAL blocks
[21:27:22] <SWPadnos> right - I remember several discussions about spindles and gearchanging
[21:27:29] <SWPadnos> mostly with Ray, I think
[21:27:36] <jmkasunich> I'm trying to remember how we made the machine wait during a gearchange
[21:27:56] <SWPadnos> probably feedhold or a mux into feed override
[21:28:18] <petev> what happens with feed override at 0?
[21:28:23] <petev> does motion stop too?
[21:28:24] <SWPadnos> feed stops
[21:28:52] <petev> oh, I was thinking spindle speed override
[21:28:59] <SWPadnos> so that's another way of doing at-speed, mux a 0 and the "actual" FO into the FO pin
[21:29:01] <SWPadnos> ah
[21:29:27] <petev> FO is a float though, no?
[21:29:34] <SWPadnos> yes, but so is the mux
[21:29:41] <petev> the feed-hold is probably more convenient
[21:29:45] <SWPadnos> it has a bit input for select
[21:29:49] <SWPadnos> true
[21:30:09] <SWPadnos> though you should still have a mux arrangement so there can be an external feedhold control
[21:30:16] <SWPadnos> (even if it's in halui)
[21:30:54] <petev> yes, for now I will probably always keep feed-hold on unless no manual hold and spindle is up to speed
[21:31:23] <alex_joni> you mean off ?
[21:31:35] <alex_joni> I think when on it stops
[21:31:36] <petev> no, on to avoid glithces
[21:31:43] <petev> right
[21:32:02] <petev> I guess this may be an issue for rapids and manual mode though
[21:32:07] <petev> sounds like more complex logic needed
[21:32:13] <petev> or a new pin ;-)
[21:32:18] <SWPadnos> you'd have to and in the spindle-on output(s)
[21:32:20] <SWPadnos> heh
[21:32:44] <petev> swpadnos, that's where the glitch is
[21:32:47] <SWPadnos> feedhold unless enabled and ((spindle enabled and at speed) or (spindle disabled))
[21:32:51] <petev> if you condition with spindle on
[21:33:06] <petev> then when it first turns on, feed-hold is not set yet
[21:33:31] <SWPadnos> I think there's a hard-coded delay (though it may be commented out now)
[21:33:49] <SWPadnos> Alex and I discussed that in the last few months, but I don't remember what the status is
[21:33:59] <alex_joni> there is no delay at all
[21:34:13] <petev> why not just add the spindle-at-speed input and make it simple?
[21:34:33] <petev> then external logic would be trivial with no glitches
[21:34:35] <alex_joni> petev: because it needs to get into TP probably
[21:34:49] <petev> why? I'm not familiar with TP
[21:34:55] <alex_joni> * alex_joni neither
[21:35:01] <petev> I though all commands waited for completion
[21:35:03] <SWPadnos> also, is the spindle at speed when commanded to 0 but still turning?
[21:35:13] <SWPadnos> I/O isn't that simple, unfortunately
[21:35:18] <petev> wouldn't it just be a matter of changing the spindle on command to wait?
[21:35:33] <SWPadnos> (or so I hear - I'm not familiar with the code either)
[21:35:38] <alex_joni> petev: then it only works when turning spindle on
[21:35:45] <alex_joni> but it doesn't work if the speed drops later
[21:35:59] <petev> true, but that would be a decent start
[21:36:01] <SWPadnos> yep - what happens with a set of G-codes that also happen to have Sxxx words in them
[21:36:12] <petev> and probably needed for final behavior anyhow
[21:36:19] <alex_joni> petev: don't think it would help lots..
[21:36:28] <petev> why?
[21:36:37] <petev> initial ramp up can be long
[21:36:41] <petev> something is needed
[21:36:45] <alex_joni> because it would need ot be redone properly
[21:36:57] <alex_joni> I'm talking about the implementation, not the actual result
[21:37:00] <SWPadnos> actually, you can do it by hand, if we have a "wait for input" M-code
[21:37:12] <SWPadnos> did that ever get implemented?
[21:37:28] <jmkasunich> you can hack a "wait for input" m code today
[21:37:42] <jmkasunich> custom M code can invoke any script
[21:37:47] <alex_joni> that's a whole nother can of worms
[21:37:53] <alex_joni> jmkasunich: yeah, but you don't wait for them to finish
[21:37:55] <alex_joni> so ..
[21:38:12] <alex_joni> it won't wait
[21:38:12] <SWPadnos> we have multiple overlapping worm-sets
[21:38:14] <petev> alex_joni, sounds like this is similar to feed-hold, but conditioned
[21:38:15] <jmkasunich> emc doesn't wait for a custom M code script to finish?
[21:38:25] <alex_joni> jmkasunich: no, just spawns it
[21:38:27] <jmkasunich> barf
[21:38:29] <petev> so it shouldn't be that hard to look at how the feed-hold input works
[21:38:56] <alex_joni> petev: no, shouldn't be that hard :)
[21:39:06] <jmkasunich> wtf good are custom M codes if the g-code ignores the result?
[21:39:21] <alex_joni> SWPadnos: I was very much in favour of custom M codes
[21:39:30] <jmkasunich> s/ignores/doesn't even wait for/
[21:39:33] <alex_joni> I mean ones to check for input pins
[21:39:51] <SWPadnos> yeah - I recall some discussions about M-code for aux I/O
[21:39:54] <SWPadnos> codes
[21:40:09] <alex_joni> but we talked it through a couple times, and I was convinced we don't want to do that
[21:40:16] <SWPadnos> heh
[21:40:16] <alex_joni> can't remember what the argument was
[21:40:27] <alex_joni> something about loops & problems
[21:40:47] <alex_joni> anyways.. different worms
[21:40:53] <SWPadnos> one of those "like probing, you don't know the state of the machine after it's done" things, no doubt
[21:41:00] <alex_joni> right
[21:42:21] <alex_joni> jmkasunich: I somehow agree with you
[21:43:24] <alex_joni> petev: regarding feed-hold
[21:44:01] <alex_joni> as it is now, there are a set of flags (feed-hold is one of them) that get embedded in the trajectory planner along with the move commands (linear, circular, etc)
[21:44:18] <petev> so maybe feed-hold is not the answer, maybe feed-override is better as SWPadnos suggested
[21:44:34] <petev> I don't think feed-override is looked at for g0 moves
[21:44:38] <jmkasunich> alex_joni: not quite
[21:44:45] <jmkasunich> the flags aren't feed hole
[21:44:47] <jmkasunich> hold
[21:44:54] <jmkasunich> they are feed hold disable
[21:44:57] <SWPadnos> petev, I think FO is always used
[21:45:07] <petev> what?
[21:45:17] <petev> should only be for G1 type stuff
[21:45:22] <SWPadnos> but since G0 is at "full speed" , you can never go faster, only slower, on a G0 move
[21:45:28] <jmkasunich> you can disable feedhold, feed override, spindle override, and adaptive feed, individually, in the g-code
[21:45:40] <alex_joni> jmkasunich: right, I was assuming they are all enabled
[21:45:40] <SWPadnos> well, for proving that your rapid will clear a clamp, the ability to slow down G0 is great
[21:45:45] <petev> hmm, that's no good
[21:45:56] <jmkasunich> this is for things like "I know that if the operator slows down the feed on this cut the part is gonna work harden and ruin the tool"
[21:46:13] <jmkasunich> its those enable/disable bits that get attached to individual moves and pass thru the queue
[21:46:20] <petev> no, I meant for using any for spindle control
[21:46:21] <alex_joni> or increases the feed (if FO > 1)
[21:46:54] <jmkasunich> the fact that they can be disabled may be bad if you want to use them for spindle control
[21:46:56] <alex_joni> petev: that's mostly usefull for threading/lathe work
[21:47:14] <petev> jmk: exactly
[21:47:15] <jmkasunich> but I wanted to clear up that its the enables, not the actual hold or overrride that gets queued
[21:47:23] <petev> does FO really effect G0?
[21:47:26] <alex_joni> jmkasunich: right.. I remembered
[21:47:28] <alex_joni> petev: yes
[21:47:29] <petev> that seems totally wrong
[21:47:45] <jmkasunich> others agree with you, but not all others
[21:47:52] <SWPadnos> remember - you can't speed up a G0, only slow it down
[21:47:55] <jmkasunich> some people even wanted a different override for rapids
[21:47:55] <SWPadnos> that has its uses
[21:48:08] <petev> if you want to change your feed rate, you don't want it to mess with all your rapids
[21:48:12] <petev> what good is that?
[21:48:22] <petev> it would mess up the whole program
[21:48:29] <SWPadnos> proving a program while single-stepping
[21:48:32] <jmkasunich> dunno, but I'm not gonna get sucked into _that_ discussion again
[21:48:49] <petev> the rapid override is a config thing to me, shouldn't need to be touched after that
[21:48:50] <SWPadnos> Ray was a major proponent of G0 being affected by FO, I think
[21:48:59] <SWPadnos> I'm mainly parroting what I believe he said
[21:49:00] <alex_joni> petev:
http://sourceforge.net/tracker/index.php?func=detail&aid=1536176&group_id=6744&atid=356744
[21:49:04] <petev> that makes no sense
[21:49:05] <jmkasunich> thats the way the original NIST spec is written
[21:49:23] <petev> that make FO worthless
[21:49:55] <jmkasunich> rapid override does seem to have its uses
[21:50:04] <petev> fine if it's separate
[21:50:10] <jmkasunich> for proofing a program, you turn rapid down to the point that you can estop in time
[21:50:13] <petev> but shouldn't be the same as for G1
[21:50:21] <jmkasunich> turn feed up to the point that it doesn't waste your time
[21:50:22] <jmkasunich> and go
[21:50:29] <petev> combining them is the issue
[21:50:41] <petev> I would rather have nothing for G0 than combined
[21:51:03] <alex_joni> petev: "guess it's been 10 years like it is now"
[21:51:09] <alex_joni> one of the few reasons it's like that
[21:51:17] <jmkasunich> you are welcome to start a discussion on -dev and try to convince people, or better yet, make the change and submit a patch
[21:51:32] <petev> what good is it the way it is?
[21:51:46] <petev> why would you want changing the feed speed to effect rapids?
[21:51:46] <jmkasunich> not arguing with you about that
[21:51:57] <jmkasunich> not arguing with you about that
[21:51:58] <alex_joni> petev: to go slower I guess
[21:52:06] <alex_joni> * alex_joni won't argue either ;)
[21:52:11] <petev> or maybe too fast on a rapid
[21:52:17] <jmkasunich> we're not discussiing whether it is right or wrong
[21:52:16] <petev> sounds dangerous to me
[21:52:25] <alex_joni> it can't go faster than G0
[21:52:44] <alex_joni> even if you have FO at 10000%, motion is still limited by machien capabilities
[21:52:48] <jmkasunich> the facts are that the last time it was discussed some people (not here at the moment I think) managed to successfully argue that it should stay the way it is
[21:52:49] <alex_joni> machine even
[21:53:02] <alex_joni> what jmk said
[21:53:19] <petev> what jmk said is a good reason for a G0 override
[21:53:20] <jmkasunich> you don't have to convince me, you have to convince them
[21:53:24] <jmkasunich> or just do it
[21:53:24] <petev> not for combining them
[21:53:29] <alex_joni> I mean the "< jmkasunich> the facts are that the last time it was discussed some
[21:53:34] <alex_joni> people (not here at the moment I think) managed to
[21:53:36] <alex_joni> successfully argue that it should stay the way it is
[21:53:39] <alex_joni> 23:46 < alex_joni> what jmk said
[21:53:40] <alex_joni> "
[21:53:55] <alex_joni> petev: I am also feeling neutral about the whole issue
[21:54:01] <petev> ok, I'll look at the code and see what it takes to add a second override
[21:54:03] <alex_joni> I'm ok with either way really
[21:54:15] <alex_joni> petev: it's not hard to do..
[21:54:16] <jmkasunich> I think the biggest hassle is not the motion code, its the guis
[21:54:23] <jmkasunich> they need yet another slider
[21:54:28] <alex_joni> but you need to fix GUIs, NML, task, CANON, motion
[21:54:34] <jmkasunich> which might hurt the little brains of some of the users
[21:55:10] <petev> hmm, so how do you guys handle this stuff then?
[21:55:20] <petev> present for vote?
[21:55:21] <SWPadnos> leave it the way it is ;)
[21:55:30] <petev> but it sux as is
[21:55:34] <alex_joni> bring it up on the devel list
[21:55:35] <jmkasunich> usually we manage to come to a conclusioin that makes everybody happy, then we go off and implemnet it
[21:56:13] <jmkasunich> that time, I guess nobody on the "needs to be separate" camp felt as strongly about it as you do
[21:56:17] <alex_joni> petev: 'we' in here are mostly newer emc users/developers
[21:56:34] <petev> I don't care to have a G0 override, but I can see it's use
[21:56:42] <skunkworks> If I wasn't listening to this discussion - I would have never thought about it. the few machines I have run - FO effects g0 and g1,2,3 the same
[21:56:44] <petev> but I really don't want G0 and G1 combined
[21:56:51] <alex_joni> there are older users, like ray, that feel very strongly about changing things
[21:57:12] <petev> skunkworks, what controls were on those machines?
[21:57:29] <skunkworks> fanuc and a really old ge controller.
[21:57:44] <SWPadnos> you can modify your code to prevent FO with G0
[21:57:50] <petev> which fanuc?
[21:58:19] <skunkworks> petev: don't know off the top of my head - it was running a laser - maybe 12 years old.
[21:58:23] <jmkasunich> petev: just to make you more upset.... FO affects homing and jogging moves too
[21:58:32] <petev> nice
[21:58:33] <alex_joni> jmkasunich: you had to :)
[21:58:36] <jmkasunich> it is basically a global scale on all velocities
[21:58:51] <SWPadnos> as is AF, right? (if it's enabled)
[21:59:01] <alex_joni> SWPadnos: yeah, but that can't increase
[21:59:03] <skunkworks> isn't there a FO disable now though?
[21:59:05] <alex_joni> SWPadnos: only 0..1
[21:59:09] <SWPadnos> right
[21:59:10] <skunkworks> for threading and such
[21:59:16] <jmkasunich> yeah, AF, FH, FO all affect a single variable called "scale"
[21:59:16] <alex_joni> skunkworks: there is a disable for all the overrides
[21:59:28] <SWPadnos> spindle-synchronized ignores FO
[21:59:34] <SWPadnos> spindle-synchronized motion ignores FO
[21:59:35] <alex_joni> right SWPadnos
[21:59:45] <petev> so we still have this problem for spindle and these being able to be disabled
[21:59:57] <SWPadnos> yes
[22:00:06] <SWPadnos> can FH be disabled?
[22:00:10] <jmkasunich> yes
[22:00:16] <SWPadnos> ok - then "yes" is right :)
[22:00:18] <alex_joni> petev: what do you mean 'these being able to be disabled' ?
[22:00:21] <jmkasunich> there are four "things": AF, FH, FO, and SO
[22:00:26] <petev> via gcode
[22:00:31] <jmkasunich> each can be individually disabled/enabled by g-code
[22:00:35] <SWPadnos> ie, g-code can disable FO, FH, and AF, so none can be used reliably for spindle-related feed hold
[22:01:01] <jmkasunich> IMO, spindle-on should not return success until the spindle is at speed
[22:01:05] <alex_joni> well.. you can use motion.enable :D
[22:01:16] <SWPadnos> I had thought about that, actually
[22:01:19] <jmkasunich> that ignores the separate issue of what happens if the spindle dies mid-cut, but so be it
[22:01:33] <petev> ok, at least thats a start
[22:01:47] <jmkasunich> the thing is, I dunno if motion commands can "not return"
[22:01:50] <petev> what happens when motion is disabled?
[22:02:00] <jmkasunich> thats basically "machine off"
[22:02:07] <jmkasunich> you don't want to go there I don't think
[22:02:08] <petev> so no servo updates?
[22:02:15] <SWPadnos> no motion happens - but I'm not sure if it leaves the motor enables o
[22:02:17] <alex_joni> jmkasunich: there is no-one reporting success I think
[22:02:20] <SWPadnos> ok - gess not
[22:02:38] <alex_joni> at least not down in the motion controller
[22:02:37] <jmkasunich> alex_joni: thats what I was afraid of
[22:02:56] <jmkasunich> in the controller, a comment returns an immediate response, no deferred responses allowed
[22:03:03] <jmkasunich> a command, not a commnet
[22:03:05] <jmkasunich> comment
[22:03:36] <petev> hmm, so sounds like nothing is suitable yet
[22:03:48] <alex_joni> it has to be done in task I'm afraid
[22:04:06] <alex_joni> and that's one pile of *beep* I'm afraid to stir too much ;)
[22:04:12] <jmkasunich> emcmot_status->spindle_at_speed
[22:04:14] <SWPadnos> it's a tough problem when you consider on-the-fly spindle speed changes
[22:04:21] <petev> I still have all that emc3 code ;-)
[22:04:33] <jmkasunich> right - constant surface speed will have the speed constantly changing
[22:04:34] <SWPadnos> and your snazzy fast interpreter :)
[22:05:25] <petev> ok, so we need two solutions
[22:05:35] <petev> one for the servo spindle, and one for all others
[22:06:03] <petev> can we break down the features that would be supported for each?
[22:06:17] <petev> then maybe it will become more clear how to solve this
[22:06:22] <jmkasunich> how did we get from "spindle at speed lockout" to servo spindles
[22:06:36] <petev> alex says he wants to do it right ;-)
[22:06:49] <jmkasunich> servo spindles are only loosly related to this
[22:06:53] <petev> so for the big picture, seems like these are the two cases
[22:06:55] <jmkasunich> one thing at a time
[22:07:03] <petev> some of the control overlaps
[22:07:14] <petev> the servo spindle solves a lot of this
[22:07:18] <jmkasunich> canonical machine command spindle-start should not return until the spindle is started
[22:07:29] <petev> true
[22:07:30] <jmkasunich> regardless of the type of spindle
[22:07:33] <alex_joni> jmkasunich: I 'think' I might be able to do that
[22:08:02] <petev> so spindle start is different than spindle at speed during a cut?
[22:08:12] <petev> can we agree to separate those?
[22:08:21] <jmkasunich> yes, they are fundamentally different
[22:08:25] <jmkasunich> startup, you wait
[22:08:30] <jmkasunich> during a cut is a fault
[22:08:35] <petev> ok, good
[22:08:50] <SWPadnos> hold on - if you change speed, then it can't be an immediate fault
[22:09:02] <jmkasunich> during a cut is sort of like following error
[22:09:06] <alex_joni> change speed = start spindle
[22:09:15] <alex_joni> it only starts from speed!=0
[22:09:16] <petev> so for non-servo spindles we need a fault input
[22:09:19] <jmkasunich> and like following error, you'd set an allowable error band
[22:09:30] <alex_joni> jmkasunich: that's external to motion
[22:09:43] <jmkasunich> petev: lets ignore the fault side for now, stick to the start/stop part
[22:09:45] <alex_joni> one fault input and a wcomp outside would do the trick
[22:10:09] <petev> ok, let's address speed change
[22:10:09] <jmkasunich> I thought we agreed to separate the startup issue from the running issue?
[22:10:17] <petev> this may be manual on some machines
[22:10:23] <alex_joni> yes, that was for running..
[22:10:23] <petev> so that need to wait as well
[22:10:59] <alex_joni> I don't see (implementation-wise) how the 2 things are that different
[22:11:03] <alex_joni> startup and during cut
[22:11:06] <petev> so start and speed change wait
[22:11:17] <jmkasunich> ok, I need some background
[22:11:23] <petev> during a cut is servo controlled or simple fault?
[22:11:36] <alex_joni> jmkasunich: what background?
[22:11:38] <jmkasunich> S3000 sets spindle speed (internal variable) to 3000 rpm, but doesn't start it, right?
[22:11:45] <jmkasunich> M something starts it
[22:11:48] <alex_joni> M3 or M4 starts it
[22:11:49] <alex_joni> right
[22:11:52] <SWPadnos> I see one difference - it's likely that there is no motion at "startup" whereas there is for a speed change
[22:11:53] <petev> what if it's already running?
[22:12:00] <jmkasunich> you can do the S before you start it, or after
[22:12:06] <alex_joni> right
[22:12:08] <jmkasunich> after = speed change
[22:12:12] <alex_joni> right
[22:12:12] <petev> yes
[22:12:46] <jmkasunich> and then we have CSS, which will be changing the speed all the time, but not by S<nnn> commands
[22:12:51] <SWPadnos> on some machines, you'll want to hold motion until the spindle is at speed (like on machines where you prompt the operator to change speed)
[22:12:51] <alex_joni> S before = startup, S after = speedchange
[22:13:02] <jmkasunich> I dunno if anybody does S words in mid-cut....
[22:13:12] <SWPadnos> depends on F changes as well
[22:13:20] <jmkasunich> SWPadnos: s/some/all/ I think
[22:13:29] <alex_joni> jmkasunich: maybe on lathe work?
[22:13:45] <alex_joni> but that's irrelevant
[22:13:58] <jmkasunich> crude CSS by doing part of a cut, then an S word, more cut, another S word, etc?
[22:13:58] <SWPadnos> I'm not sure that nobody will want to do a continuous motion during a spindle sped change
[22:14:08] <SWPadnos> speed
[22:14:29] <SWPadnos> I agree that it seems not too useful, but I don't know enough to rule it out
[22:14:58] <jmkasunich> I can also bet you that the minute we stop all motion during even a start from zero speed, somebody's gonna say "how come I can't rapid over to the part while the spindle's coming up to speed"
[22:15:02] <alex_joni> * alex_joni wonders if we can move this conversation to the next weekend
[22:15:06] <petev> I don't think you would want feed to stop during a change for crude CSS on a lathe
[22:15:22] <SWPadnos> heh - yep
[22:15:31] <petev> jmk: should only effect G1, 2, 3 etc.
[22:15:34] <petev> not G0
[22:15:43] <SWPadnos> those kinds of things all have to be possible in "machine logic" config, not policy in motion
[22:15:46] <petev> G0 is not supposed to be cutting, so it shouldn't matter
[22:16:00] <jmkasunich> SWP is right about policy though
[22:16:02] <SWPadnos> that's true - traverse vs. feed
[22:16:36] <alex_joni> the problem is that where you can do the policy thing you might not have the realtime machine data to do it
[22:16:48] <alex_joni> I'm thinking CANON or task
[22:16:50] <jmkasunich> the other complication... what seems to be to be the "obvious" implementaton for start from zero (the start canon command doesn't return until at speed) can't make the disctinction between G0 and G1
[22:17:16] <petev> true
[22:17:19] <SWPadnos> that would be solved by an at-speed input ;)
[22:17:25] <jmkasunich> no it wouldn't
[22:17:30] <alex_joni> SWPadnos: how?
[22:17:30] <petev> why?
[22:17:36] <SWPadnos> err - nevermind :)
[22:17:45] <jmkasunich> the "don't return until at speed" behavior would be using the at-speed input
[22:17:55] <SWPadnos> actually, the spindle-at-speed input would be aprecondition for feed moves, not a postcondition for S words
[22:18:04] <jmkasunich> ah-ha!
[22:18:06] <jmkasunich> right
[22:18:11] <petev> jmk: I take it motion has no concept of machine mode?
[22:18:24] <alex_joni> petev: we're talking AUTO now
[22:18:24] <SWPadnos> so you could do as many commands as you want, as long as they aren't feeds
[22:18:31] <alex_joni> e.g. running program
[22:18:39] <alex_joni> but the other 2 modes are also allowed/present
[22:18:57] <petev> I think the pre-condition thing might be the answer
[22:19:11] <petev> then it really doens't matter mode, etc.
[22:19:12] <jmkasunich> if you are in manual, you can do anything - jog with spindle off, jog with spindle on, it doesn't care
[22:19:12] <SWPadnos> that's still a policy (though itone
[22:19:41] <petev> but you still shouldn't be able to feed with it off
[22:19:48] <jmkasunich> using spindle-at-speed as a precondition for cutting moves should do the trick
[22:19:55] <petev> so that kind of policy can be a pre-condition I think
[22:20:05] <jmkasunich> then in hal, you implement your policy as to what "at speed" means
[22:20:07] <alex_joni> void STRAIGHT_TRAVERSE(double x, double y, double z,
[22:20:07] <alex_joni> double a, double b, double c)
[22:20:07] <alex_joni> {
[22:20:07] <alex_joni> double vel, acc;
[22:20:07] <alex_joni> EMC_TRAJ_LINEAR_MOVE linearMoveMsg;
[22:20:08] <alex_joni> ...
[22:20:16] <alex_joni> void STRAIGHT_FEED(double x, double y, double z, double a, double b,
[22:20:16] <alex_joni> double c)
[22:20:16] <alex_joni> {
[22:20:16] <alex_joni> EMC_TRAJ_LINEAR_MOVE linearMoveMsg;
[22:20:20] <alex_joni> ..
[22:20:25] <jmkasunich> if you are doing CSS or in-cut changes, you just have to have a wide tolerance for "at-speed"
[22:20:27] <alex_joni> (sorry bout the paste).. just a short point
[22:20:48] <alex_joni> TASK who could do the pre/post conditions doesn't know about G0/G1
[22:20:59] <alex_joni> it only knows about linear moves with a certain speed
[22:21:04] <alex_joni> same goes for motion
[22:21:14] <jmkasunich> the code you just pasted - where is that? interp? task?
[22:21:18] <alex_joni> CANON
[22:21:31] <alex_joni> interp calls those calls
[22:21:50] <jmkasunich> interp calls canon which calls task?
[22:21:57] <SWPadnos> Fest topic 1: how much old stuff can we rip out without pissing off the "established users"?
[22:22:01] <alex_joni> it's a bit more complicated
[22:22:17] <jmkasunich> interp calls canon which queues stuff for task?
[22:22:28] <alex_joni> task runs interp cyclically, which calls CANON which puts NML on a queue, which task reads, and sends to various places
[22:22:35] <alex_joni> yeah that
[22:22:53] <petev> yeah, I always thought those two should be separate
[22:22:57] <SWPadnos> and pre/postconditions are where?
[22:23:02] <alex_joni> SWPadnos: TASK
[22:23:05] <alex_joni> on the last part
[22:23:05] <jmkasunich> pre and post conditions are done when pulling things off the queue, right?
[22:23:10] <alex_joni> right
[22:23:21] <alex_joni> s/done/doable/
[22:23:28] <jmkasunich> something that we talked about with Fred when we were at NIST 2 years ago....
[22:23:44] <jmkasunich> the existing design has pre and post condition attached to each queue entry
[22:23:54] <jmkasunich> the suggestions was that they _be_ queue entries
[22:24:12] <jmkasunich> IOW, traverse would queue the move only, and feed would traverse a precondition, then the move
[22:24:14] <SWPadnos> hmmm - "block until X" queue entries
[22:24:17] <alex_joni> well.. the conditions are hardcoded in task based on the element in the queue
[22:24:35] <SWPadnos> that discussion does represent a change
[22:24:43] <SWPadnos> back to Fest topic 1 :)
[22:24:43] <alex_joni> jmkasunich: right.. sounds like the proper way to fix it
[22:24:50] <jmkasunich> Fred thought so
[22:24:54] <alex_joni> wonder who will want to do that :D
[22:24:58] <SWPadnos> Fred is elected
[22:25:01] <jmkasunich> * jmkasunich goes back to FPGA work
[22:25:25] <petev> has anyone done substantial work on task since EMC1?
[22:25:28] <SWPadnos> damn. I have to read back through that conversation
[22:25:38] <jmkasunich> what conversation?
[22:25:40] <alex_joni> petev: I added couple of bits here and there
[22:25:50] <alex_joni> but nothing substantial afaik
[22:25:56] <jmkasunich> nothing of this scale anyway
[22:25:57] <petev> last time I looked at that code, I just wanted to toss it and start from scratch
[22:25:59] <SWPadnos> the FPGA / mesa conversation
[22:26:10] <SWPadnos> -it
[22:26:14] <petev> the task code
[22:26:19] <petev> and interp too for that matter
[22:26:27] <SWPadnos> (... just wanted to toss ... ) ;)
[22:26:26] <jmkasunich> that reminds me, SWPadnos I'd like to brainstorm with you (later) about some of that stuff
[22:26:38] <SWPadnos> sounds good to me
[22:26:52] <alex_joni> petev: emc3?
[22:27:03] <jmkasunich> 2.2? 2.3?
[22:27:03] <petev> that's what started it
[22:27:14] <alex_joni> jmkasunich: we talked about machine runlevels a while ago
[22:27:16] <petev> there were so many issued that couldn't be fixed easily
[22:27:32] <alex_joni> I think that was also a task limitation
[22:27:35] <SWPadnos> HAL refactor and new interp and lions and tigers and bears ...
[22:27:41] <jmkasunich> oh my
[22:27:54] <petev> the HAL isn't broken
[22:27:54] <alex_joni> * alex_joni wonders if jmkasunich remembers
[22:28:00] <jmkasunich> trying not to
[22:28:06] <petev> I don't see a pressing need for a refactor there
[22:28:11] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunLevels
[22:28:57] <petev> so, I guess there is no way to fix this basic spindle issue?
[22:29:13] <jmkasunich> petev: no perfect ways, lots of imperfect ones
[22:29:18] <petev> I think it's pretty serious and we need to figure something out
[22:29:20] <alex_joni> petev: there is a way to 'hack' it to work as you want it to
[22:29:22] <jmkasunich> in your case, who's g-code are you gonna be running?
[22:29:35] <petev> jmk: like what? I don't think anything gcode can disable is acceptable
[22:29:44] <jmkasunich> if yours, just don't use the "disable feedhold" code, and use feedhold to hold off motion during spindle spin-up
[22:29:58] <alex_joni> jmkasunich: I think motion needs an spindle at speed input no matter what
[22:30:15] <alex_joni> the problem is what to do with it :)
[22:30:25] <petev> agreed
[22:30:37] <petev> probably needs a fault for the non-servo model as well
[22:30:46] <petev> but that's another issue
[22:30:47] <alex_joni> 1). cheap & easy solution: use it like a FO=0
[22:31:01] <alex_joni> nothing outside motion knows about it
[22:31:18] <alex_joni> people just scratching heads why the machine isn't moving..
[22:31:44] <alex_joni> 2). fix it more properly.. which will result in a cascade of other things to fix
[22:32:30] <alex_joni> anyways.. I'm travelling tomorrow.. gotta get some sleep
[22:32:42] <petev> ok, get some rest
[22:32:57] <petev> I'm going to take the kids to the park and think about this some more
[22:32:56] <alex_joni> petev: I still think this is best addressed on the mailing list.. maybe there are some other strong ideas out there
[22:33:24] <alex_joni> good night all
[22:33:31] <SWPadnos> I think some input from the likes of Ray and Jon would be a good thing
[22:33:40] <SWPadnos> night Alex - have fun on your trip
[22:34:01] <alex_joni> SWPadnos: it's a worktrip.. not that much fun I'm afraid
[22:34:10] <SWPadnos> well, have fun anyway :)
[22:34:14] <alex_joni> I'm adding a linear 3m axis to a 8-axis robot
[22:34:24] <SWPadnos> that sounds like fun
[22:34:34] <alex_joni> yeah, except when you're missing some cables & stuff
[22:34:34] <SWPadnos> unless some jerk foreman is breathing down your neck to get it done yesterday
[22:34:41] <alex_joni> and that
