Back
[00:05:44] <cradek> yes
[00:05:54] <cradek> just got back
[00:07:11] <jmkasunich> did you see my mail to the board list about "board business"?
[00:07:20] <cradek> yes
[00:07:24] <jmkasunich> (been having mail probs, it hasn't appeared here yet)
[00:07:29] <cradek> it's not you
[00:07:36] <cradek> sf mails were taking over an hour earlier today
[00:07:53] <cradek> well, I guess it could also be you :-)
[00:08:00] <jmkasunich> I sent that one a lunchtime I think, and its still not here
[00:08:30] <jmkasunich> switch to the board chan?
[00:08:33] <cradek> yes
[00:09:36] <SWP_Away> SWP_Away is now known as SWPadnos_
[00:09:50] <SWPadnos_> hi there
[00:10:02] <jmkasunich> hi steve
[00:10:34] <SWPadnos_> did you see the change I committed to core_servo.hal?
[00:10:45] <jmkasunich> I think so
[00:11:10] <SWPadnos_> pid.n.maxoutput = [AXIS_n]MAX_VELOCITY
[00:11:18] <SWPadnos_> fixed the following errors I was getting
[00:11:28] <jmkasunich> damn... my att mail is slow, I saw it on my yahoo acct, but don't have that window open right now
[00:11:36] <jmkasunich> sounds good
[00:12:04] <SWPadnos_> it was a real pisser to search for 6 hours to find a configuration change "bug" ;)
[00:33:04] <SWPadnos_> jmkasunich: still around?
[00:33:10] <jmkasunich> yeah
[00:33:19] <SWPadnos_> two questions for you
[00:33:53] <SWPadnos_> first, I was thinking about the PID parameter problem (default output limit of 1, but max_velocity default to 1.2), and thought about overshoot
[00:34:34] <SWPadnos_> does it make sense to allow the pid block to overshoot the axis max_velocity, to give it a chance to "catch up" to a requested step change in velocity?
[00:34:50] <jmkasunich> that whole topic is a mess
[00:35:05] <jmkasunich> I thought the people with problems were running steppers anyway?
[00:35:48] <SWPadnos_> well - you still need PID with steppers (and the USC), becuase the actual step rate (quantized) won't necessarily match the (float) requested rate
[00:36:07] <jmkasunich> the usc isn't steppers ;-)
[00:36:22] <SWPadnos_> neither is stepgen
[00:36:35] <jmkasunich> stepgen uses core-stepper.hal
[00:36:42] <jmkasunich> no PID loop
[00:37:00] <SWPadnos_> but there should still be some ability to dither between the two closest attainable rates, to get the requested rate as an average
[00:37:02] <jmkasunich> so it is distinct from USC steppers and all others that use core-servo.hal
[00:37:11] <jmkasunich> yes
[00:37:30] <jmkasunich> with core-servo, the pid loop does the dithering as it constantly corrects for errors
[00:38:06] <SWPadnos_> stepgen just does it internally, since it already knows how many steps it has output
[00:38:17] <jmkasunich> with core-stepper, there is an internal loop that is part of stepgen, and it does whatever dithering is needed
[00:38:19] <SWPadnos_> (using a non-pid method, I know)
[00:38:20] <jmkasunich> yes ;-)
[00:38:28] <SWPadnos_> right ;)
[00:38:41] <SWPadnos_> kind of an artifact of DDS, actually
[00:38:51] <jmkasunich> I was assuming the problems people were reporting were with stepgen
[00:39:00] <jmkasunich> and assumed some problem with that internal loop
[00:39:16] <SWPadnos_> right - I was thinking the same thing with the PPMC stepgen
[00:39:20] <jmkasunich> it's non-trivial, basically a little trapezoidal TP of its own
[00:39:33] <SWPadnos_> that's why it took so long to find where the (damned) limit of 1 IPS came from
[00:39:47] <jmkasunich> skunkworks over on the other channel is talking about one of those bugs
[00:39:56] <jmkasunich> I want to go over there and see if I can replicate it
[00:40:15] <SWPadnos_> ok
[00:40:30] <jmkasunich> it may well be related to this conversation
[00:48:05] <SWPadnos_> sorry - was afk for a mo - I'll read back
[01:55:04] <SWPadnos_> hey petev - trying to not pollute that channel
[01:55:29] <SWPadnos_> they aren't called that, but the construction of a stepper is basically what you would have with a 2-phase AC motor
[01:56:23] <SWPadnos_> microsteppers try to approximate a sinewave (or triangle / trapezoid) into the two phases, 90 degrees apart (instead of 120, like 3-phase AC)
[01:57:48] <SWPadnos_> hey cradek - got a sec, or are you fixing a dead computer? :)
[01:59:07] <petev> swp: I don't realy understand what a 2 phase system is. 2 wires is one phase, 3 wires is 3 phases
[01:59:30] <SWPadnos_> 2-phase is two sets of 2 wires (each pair gets one phase)
[02:00:08] <jmkasunich> actually, you could do two phase with 3 wires
[02:00:10] <SWPadnos_> you can do 3-phase that way as well - 3 separate coils, each with 2 wires (rather than the delta or wye connections usually used)
[02:00:21] <SWPadnos_> sure - common, phase A, phase B
[02:00:38] <jmkasunich> the real difference is the phase relationships
[02:00:45] <jmkasunich> 2 phase has 90 degrees between phases
[02:00:51] <jmkasunich> 3-phase has 120
[02:01:08] <SWPadnos_> right, and you get the other two 90-degree "corners" by reversing current direction
[02:01:18] <SWPadnos_> which is unnecessary once you have 3 or more phases
[02:01:33] <jmkasunich> 3 phase systems almost always reverse current too
[02:02:04] <SWPadnos_> yes
[02:03:12] <petev> so you really have more phases with 4 wire, but some are just 0 volts so you are ignoring them?
[02:03:22] <jmkasunich> 4wire?
[02:03:40] <petev> yes, swp says two separete coils
[02:03:42] <jmkasunich> you mean 3phase with neutral distribution, or 4 wire steppers?
[02:03:46] <petev> that's 4 wires
[02:04:17] <SWPadnos_> steppers have two coils, 90 degrees apart
[02:04:18] <jmkasunich> a 4 wire stepper has two windings oriented 90 degrees to each other (90 electrical degrees)
[02:04:43] <jmkasunich> each winding at some point in the cycle has positive and negative current
[02:04:54] <jmkasunich> hence H bridges in the drive
[02:04:59] <jmkasunich> however, if you don
[02:05:02] <petev> to me, the phase we are talking about is the potentials between each pair of wires
[02:05:14] <SWPadnos_> and is essentially the same construction (brushless, "manual" commutation, sequenced activation) as a BLDC servo
[02:05:24] <jmkasunich> don't want H bridges, then you can center tap each winding, and power one half at a time
[02:05:48] <petev> so with 4 wires, you get 6 phase relationships, correct?
[02:06:04] <jmkasunich> the number of wires is irrlevant
[02:06:10] <jmkasunich> its the number and orientation of the coils
[02:06:35] <petev> so when you say phase, you are talking about the coils in the motor then?
[02:06:38] <jmkasunich> yes
[02:06:40] <petev> ok
[02:06:45] <SWPadnos_> sorry - this is a big tangent to my (mostly accurate, but not absolute) statement that people use fake encoders with steppers all the time ;)
[02:06:52] <jmkasunich> you can have a two phase motor with 3, 4, 6, or 8 leads
[02:06:59] <petev> got it
[02:07:56] <SWPadnos_> jmkasunich: can I ask you my halcmd wuestion now? (there seems to be a lull in #emc)
[02:08:04] <jmkasunich> shoot
[02:08:27] <SWPadnos_> ok - remember that I was going to add filtering and/ or owner name printing in show?
[02:08:35] <jmkasunich> yeah
[02:08:40] <SWPadnos_> but you said that you were going to makesome changes, so I should hold off
[02:08:45] <jmkasunich> yeah
[02:09:02] <SWPadnos_> I'm assuming that you haven't made those changes (the multiple long mights with a hot USC getting in the way)
[02:09:09] <jmkasunich> yeah
[02:09:12] <jmkasunich> ;-)
[02:09:24] <SWPadnos_> what are you planning, in a nutshell?
[02:09:47] <jmkasunich> long term (weeks, maybe months, but hopefully in an incremental way....)
[02:09:56] <jmkasunich> move metadata out of shmem
[02:10:21] <SWPadnos_> ah right - and make userspace calls that can ask for the data using a library
[02:10:23] <jmkasunich> extend the api to support listing, without halcmd actually knowing about and traversing the lists
[03:09:14] <petev> jmk: did you try out that ngc parser I emailed?
[03:09:22] <jmkasunich> no
[03:09:27] <SWPadnos_> me either - sorry
[03:09:36] <petev> what do you think about the expressions it allows?
[03:09:48] <jmkasunich> sorry, but I can't even keep up with the motion control parts of emc
[03:09:49] <petev> should we limit their use?
[03:10:03] <jmkasunich> I'm really out of my depth talking about the interp in any but the most general terms
[03:10:05] <petev> yeah, there's a lot to be done
[03:10:20] <petev> this is pretty general
[03:10:26] <jmkasunich> like skunkworks following errors.... :-(
[03:10:28] <petev> it's about what's valid in the g-code
[03:10:46] <jmkasunich> cradek: you still listening?
[03:10:52] <cradek> yes
[03:10:53] <petev> the grammar kramer gives seems a bit crazy
[03:11:21] <petev> I recognize his grammar to the best of my understanding of it right now
[03:11:34] <petev> but I'm not sure its the best
[03:11:53] <petev> it supports logical OR, XOR, and AND
[03:12:02] <petev> but there is not logical invert
[03:12:11] <petev> also there are no relational ops
[03:12:21] <cradek> I thought all the variables are floating point
[03:12:27] <cradek> how can you do logical operations on them?
[03:12:34] <petev> and it allows the use of expressions just about anywhere you would expect a number
[03:12:47] <petev> you can do logical on floating point
[03:12:52] <petev> true is non-zero
[03:13:13] <cradek> oh, they're logical, not bitwise
[03:13:16] <petev> yes
[03:13:19] <cradek> gotcha
[03:14:02] <petev> so what do we all think about the g-code that should be accepted?
[03:14:21] <petev> are we going to include all the ngc grammar plus lermman stuff?
[03:14:25] <SWPadnos_> anything that may be in the field today must be accepted
[03:14:27] <jmkasunich> I'm dead serious pete, I'm not qualified to discuss it
[03:14:30] <petev> or should we keep it simple?
[03:14:54] <petev> I ran 3D_chips no prob, but it's basic
[03:15:13] <petev> I think some of the stuff in Kramer's grammar is not even implemented
[03:15:16] <SWPadnos_> what do you get out of the program?
[03:15:25] <petev> then there is the M100 stuff
[03:15:33] <petev> wo where does that leave it?
[03:15:41] <petev> if there are errors, it reports them
[03:15:48] <SWPadnos_> ok
[03:15:48] <petev> it doesn't do anything else yet
[03:15:53] <SWPadnos_> otherwise nothing- got it
[03:15:58] <SWPadnos_> can I see the source?
[03:16:09] <petev> sure, you guys all want a copy?
[03:16:45] <SWPadnos_> heh - deafening silence ;)
[03:16:58] <petev> yeah, I guess that means no
[03:18:43] <petev> ok, just sent you a tarball, including my slickEdit project file ;-)
[03:18:58] <SWPadnos_> ooooohh - slickedit
[03:19:05] <SWPadnos_> too bad I don't have that ;)
[03:19:07] <petev> yeah, I like it in vi mode
[03:19:27] <SWPadnos_> ok - it didn't spit out any errors on a 1.6M NC file I have
[03:19:32] <petev> if you want to build the source, you will need to apt-get antlr and libantlr-dev
[03:19:45] <petev> you can also use it command line to test stuff
[03:19:47] <SWPadnos_> (though it is significantly slower on the 500 MHz celeron than on the 1.4GHz Opteron
[03:19:52] <SWPadnos_> 1.6GHz, that is
[03:20:04] <petev> It's compiled with debug for testing
[03:20:17] <petev> maybe optimization will make a difference
[03:20:29] <petev> how does the current EMC compare between the two machines?
[03:20:52] <SWPadnos_> unknown - I only have it in VMWare on the big machine
[03:21:00] <petev> it's a top down LL(1) parser and top down LL(2) scanner
[03:21:16] <petev> and it uses bit sets for lexing and parsing
[03:21:23] <petev> should be pretty decent
[03:21:23] <SWPadnos_> pardon me while I go get all my textbooks ;)
[03:21:38] <petev> and the code really follows the grammar since it's top down
[03:21:42] <SWPadnos_> I haven't used any of this stuff in ages
[03:21:49] <petev> you can pretty much jump in at any rule
[03:22:01] <petev> yeah, I had to brush up a bit too
[03:22:17] <petev> did you get the source?
[03:23:16] <SWPadnos_> I did
[03:23:39] <SWPadnos_> ok - so the version of rs274ngc with the source is a debug compile, and the other isn't?
[03:23:45] <petev> if you install the antlr packages and run make, you will see the cpp code
[03:24:02] <petev> no, the one I sent you was debug too
[03:24:17] <petev> I added the ngc to indicate which flavor of 274 it was
[03:24:22] <SWPadnos_> hm - they're different sizes, by over 1M
[03:24:22] <petev> that's what NIST called it
[03:24:30] <petev> hmm
[03:24:40] <SWPadnos_> the first was 879K, the second is 2M
[03:24:43] <petev> maybe the one didn't have symbols
[03:25:05] <SWPadnos_> ok
[03:25:06] <petev> neither were optimized
[03:25:52] <SWPadnos_> hm - why is the Makefile executable?
[03:26:00] <SWPadnos_> among others...
[03:26:06] <petev> oh, it's a samba/windows thing
[03:26:15] <SWPadnos_> ah - OK
[03:26:19] <petev> any time I write a file from doze, it's +x
[03:26:24] <petev> I need to fix that
[03:26:44] <SWPadnos_> ok - I didn't realize that you had done it on a windows machine
[03:26:59] <petev> my IDE (slickEdit) is doze based
[03:27:05] <jmkasunich> cooties
[03:27:13] <SWPadnos_> I thought they had a Linux version
[03:27:16] <petev> I'm compiling on the linux box
[03:27:24] <jmkasunich> ;-)
[03:27:24] <petev> they might, but I don't have it
[03:27:35] <petev> I should try eclipse
[03:27:44] <petev> just too used to slickEdit
[03:27:46] <SWPadnos_> I talked to them at Embedded Systems in SF
[03:27:55] <petev> was it good?
[03:28:43] <SWPadnos> maybe, but their website java just crashed my other machine
[03:28:52] <petev> yuk
[03:29:02] <SWPadnos> can't ecen ping it
[03:29:04] <SWPadnos> even
[03:30:10] <SWPadnos> OK - it was them - they have versions for win, lin, irix, aix, solaris, mac, and HP-UX
[03:31:21] <petev> dang, I changed the samba umask and sent HUP to daemons, but still setting +x
[03:32:07] <petev> oh well, maybe it will work after a reboot
[03:37:16] <SWPadnos_> well - that was exciting
[03:37:26] <petev> what happened?
[03:37:46] <SWPadnos_> I clicked on a menu item onthe slickedit website, and the machine locked up hard
[03:37:54] <SWPadnos_> didn't even respond to pings
[03:38:00] <petev> ooh, that's not good
[03:38:13] <petev> that shouldn't happen from just the browser
[03:38:30] <petev> maybe you need to do a clean install of 4.30 as well
[03:38:39] <petev> starting to sound like my old install
[03:38:40] <SWPadnos_> nope - I think there's a problem with the Java installation on this machine - possibly a 32/64 bit interaction
[03:38:47] <petev> hmm
[03:38:49] <SWPadnos_> this isn't a BDI at all
[03:38:51] <petev> I hate java
[03:38:58] <SWPadnos_> it's a dual-processor opteron
[03:39:02] <petev> too many non-compatible options for linux
[03:39:06] <jmkasunich> the problem is with the website - too much crap
[03:39:21] <SWPadnos_> that too, but I agree that the crap shouldn't crash the OS
[03:39:56] <petev> so, did you look at the grammar?
[03:40:18] <SWPadnos_> no - the machine crashed ;)
[03:40:22] <petev> ahh
[03:40:43] <SWPadnos_> so I rebooted, and decided to take a shit :)
[03:40:47] <petev> what is the goal for lines/sec on what speed machine?
[03:40:51] <petev> nice
[03:40:55] <SWPadnos_> thanks
[03:40:58] <SWPadnos_> I feel better
[03:41:27] <SWPadnos_> well - there are some pathological cases that I think would be good to use for setting goals
[03:41:45] <petev> on my 1GHz C3 (which is about a 600MHz celeron), I get about 4700/sec with debug code
[03:43:11] <petev> what's the typical rate for the TP in EMC now?
[03:43:40] <petev> is there any point to sending down more than one canonical motion command per TP cycle?
[03:44:02] <SWPadnos_> that's not a me question - I can never keep straight what's at the servo rate vs. the task rate vs. the (etc etc) rate
[03:44:17] <petev> jmk, you there?
[03:44:35] <SWPadnos_> no, but Les has had problems with high speed planning, and he's not even at "HSM" speeds
[03:44:46] <petev> what is high speed?
[03:45:00] <SWPadnos_> one sec - I'll send you a link
[03:45:04] <petev> ok
[03:45:21] <SWPadnos_> http://www.datrondynamics.com/products.htm
[03:45:33] <SWPadnos_> watch the videos of the MiniRaptor
[03:45:49] <SWPadnos_> or the VelociRaptor
[03:46:01] <petev> where are you looking?
[03:46:15] <SWPadnos_> there's a table about a screen down
[03:46:54] <petev> where are the videos?
[03:47:02] <SWPadnos_> one sec
[03:47:27] <SWPadnos_> http://www.datrondynamics.com/VideoZone/Videos340kb/HighSpeedH.wmv
[03:47:35] <petev> the velociRapto is 1,000"/min
[03:47:47] <SWPadnos_> yes - cutting speed
[03:48:11] <petev> can it rapid faster?
[03:48:18] <SWPadnos_> I think so
[03:48:45] <SWPadnos_> but nonetheless, 1000 in/min is pretty fast for machining
[03:49:17] <petev> I like the way the coolant is going on/off
[03:49:25] <SWPadnos_> yep
[03:49:34] <petev> what kind of cutter it that, looks tapered
[03:49:40] <SWPadnos_> it's a pretty damned slick $35k machine
[03:49:46] <petev> yeah
[03:50:06] <petev> the spindle speed is crazy
[03:50:58] <SWPadnos_> the whole machine is a bit crazy
[03:51:13] <petev> is it mostly for Al and softer?
[03:51:23] <SWPadnos_> the thing about HSM is that at some high speed, the chips start taking the heat away for you - they become the coolant
[03:51:43] <petev> I think that's true even at low speed
[03:51:47] <SWPadnos_> I don't think so
[03:51:55] <petev> the cutters are designed to heat the material, not themselves
[03:52:06] <SWPadnos_> well - at low speed, they hang onto the work or the tool long enough to transfer heat away
[03:52:10] <petev> at least that's what the cutter mfgs claim
[03:52:29] <SWPadnos_> yes - well, they would say that ;)
[03:52:42] <petev> so is this what les was trying to acheive?
[03:52:52] <SWPadnos_> not that fast, but yes
[03:53:05] <petev> how many TP cycles/sec to you think are needed for 1000ipm?
[03:53:15] <SWPadnos_> he has a big machine with a lot of mass and power, and wants to machine at 400-600 IPM, I think he said
[03:53:24] <petev> that's about 17 "/sec
[03:53:38] <SWPadnos_> well - again being pathological, consider a CAM post that outputs line segments instead of arcs
[03:53:49] <petev> sure, that's worst case
[03:54:08] <SWPadnos_> and you want .003 max deviation (or even better)
[03:54:13] <petev> sure
[03:54:37] <SWPadnos_> you're at around 300-350 * 17 lines/sec
[03:54:47] <petev> how do you get that?
[03:54:59] <petev> what's the min radius a machine could run at that speed?
[03:55:21] <SWPadnos_> well - 17 inches/sec / 0.003 arc segments (though that's not necessarily the max deviation)
[03:55:28] <SWPadnos_> the segments may be longer
[03:55:39] <SWPadnos_> 1/0.003 is 333
[03:55:42] <petev> seems like you need the min radius, then figure the coord for 0.003 error
[03:56:08] <SWPadnos_> I'm just getting an approximation
[03:56:18] <petev> yeah, but it seems way off
[03:56:29] <SWPadnos_> heh - approximate ;)
[03:56:39] <petev> your radius would be tiny for a move that small to have 0.003
[03:56:59] <petev> approximate would be nice if it wasn't a few orders of mag off ;-)
[03:57:14] <SWPadnos_> but 4700l/sec is definitely fast enough anyway, since it's in the ballpark of the worst -case incorrect approximation ;)
[03:57:42] <petev> yeah, but the machine has to run the TP and servo too
[03:57:46] <petev> that was just for the interp
[03:57:56] <SWPadnos_> sure
[03:57:59] <petev> I can get it faster with optimized code
[03:58:05] <petev> but it's a good start
[03:58:16] <SWPadnos_> well - that's what the extra orders of magnitude are for ;)
[03:58:42] <petev> so, does it make any sense to send more than one canonical motion per TP cycle?
[03:59:16] <SWPadnos_> out of my league at the moment, I'm afraid
[03:59:35] <petev> ok, I don't think it does, as how would it get processed?
[03:59:38] <SWPadnos_> but yes, I think so
[03:59:49] <petev> can the TP process mulitple points per iteration?
[03:59:59] <petev> I guess that's what we need to know
[04:00:03] <SWPadnos_> I don't think so now, but it should
[04:00:07] <petev> yep
[04:00:20] <petev> put it on the list for jmk ;-)
[04:00:28] <SWPadnos_> there was discussion of sending splines to the planner as well, so there could be more information transferred per cycle
[04:01:04] <petev> yeah, did you follow any of the eliptical motion stuff?
[04:01:28] <petev> how would that be ot help? would it get implemented at the servo rate?
[04:01:33] <petev> sounds ugly to me
[04:01:55] <SWPadnos_> I was following, and I think ellipses are an excellent idea
[04:02:08] <petev> so how would they work?
[04:02:15] <SWPadnos_> that's the hard part
[04:02:19] <petev> I can see it at a high level, but not in motion
[04:02:27] <SWPadnos_> to get axis-aligned ones is easy, but off-axis would be a pain
[04:02:44] <SWPadnos_> oh - ellipses are easy, even in integer math
[04:02:48] <petev> I don't think it makes sense at the low level
[04:03:05] <petev> you would have to put it in the servo thread for it to help
[04:03:21] <SWPadnos_> just calculate a circle, and scale the minor axis down by b/a
[04:03:23] <petev> right now the servo gets all lines, doesn't it?
[04:03:33] <SWPadnos_> no - the planner gets circles
[04:03:41] <petev> yeah, but PID, and everything else don't understand that
[04:03:46] <SWPadnos_> actually - the call is an ellipse in the emc source
[04:03:49] <petev> right, the TP gets it
[04:03:57] <petev> and makes a list of points for servo
[04:04:05] <SWPadnos_> PID only understands commanded position, and it doesn't matter how the command is calculated
[04:04:10] <petev> yes
[04:04:20] <petev> so at the motion level, it's all small lines
[04:04:43] <SWPadnos_> yes - it will end up being that way, but only because of discrete time quantization
[04:04:52] <petev> so the only gain is if there it a bottleneck to the TP
[04:04:59] <petev> it/is
[04:05:07] <SWPadnos_> if you could get the servo or TP rate to 1 microsecond, you'd have a smoother circle
[04:05:19] <SWPadnos_> no
[04:05:29] <petev> yes, but I think doing more than lines at servo is a bad idea
[04:05:31] <SWPadnos_> well - maybe
[04:05:47] <SWPadnos_> I don't think so
[04:05:52] <petev> why?
[04:06:06] <SWPadnos_> consider what happens if a line needs to end in the middle of a servo period
[04:06:18] <petev> you want PID positions to be adjusted by the servo thread?
[04:06:26] <SWPadnos_> PID has nothing to do with it
[04:06:41] <SWPadnos_> they're at different levels
[04:06:45] <petev> I think that's ugly, if you want stuff to end in the middle of a period, run it faster
[04:06:56] <petev> motion gives PID the position command
[04:07:05] <SWPadnos_> (and I don't fully understand how they're put together, so I think I shouldn't try to explain it ;) )
[04:07:10] <petev> if it doesn't adjust at servo rate, then it's just a line
[04:07:27] <petev> we need jmk
[04:07:32] <jmkasunich> who me?
[04:07:35] <petev> yes
[04:07:45] <SWPadnos_> no - if I command a move of 0.0035 inches, and the speed is 60 IPM, I shouldn't have to double the servo rate to get it
[04:07:58] <petev> can you explain why you would want eliptical motion if there is no bottle neck to TP
[04:08:06] <SWPadnos_> (60IPM = 1 IPS = 0.001/ms)
[04:08:18] <jmkasunich> if you command a move of 0.0035 inches, what you get depends on the moves that precede and follow it
[04:08:28] <petev> right
[04:08:43] <petev> it blends 3 points, no?
[04:08:45] <SWPadnos_> do moves have to start and end on a TP cycle?
[04:08:53] <jmkasunich> they shouldn't
[04:08:56] <SWPadnos_> (ie, at the edge of a cycle)
[04:09:01] <petev> no, servo cycle I would think
[04:09:10] <jmkasunich> no, they shouldn't
[04:09:27] <petev> shouldn't on servo or TP?
[04:09:36] <jmkasunich> let me throw out a thought experiment, ok?
[04:09:45] <jmkasunich> first assume absolutely no time quantization
[04:09:45] <petev> if the velocity is updated on servo, then they have to send on servo, correct?
[04:09:55] <petev> uhh, how
[04:10:06] <jmkasunich> let me finish - this is a thought experiment
[04:10:07] <SWPadnos_> think math - continuous time
[04:10:12] <petev> ok
[04:10:43] <jmkasunich> with no time quantizaiton, you can calculate exactly when each segment should start and end, and you could also have closed form functions for position as a function of time
[04:10:57] <petev> ok
[04:11:14] <jmkasunich> those functions would have discontinuous slopes (velocities) if you don't do blending, but we don't care yet
[04:11:25] <petev> ok
[04:11:34] <jmkasunich> now, take that position(t), and call it a signal (just use one axis, say X)
[04:11:45] <petev> ok
[04:11:57] <jmkasunich> still continuous time, pass that signal thru a lowpass filter
[04:12:05] <petev> ok
[04:12:18] <jmkasunich> make the bandwidth of the filter be 500Hz
[04:12:36] <jmkasunich> now you can sample the signal at 1KHz (nyquist) and do whatever you want with it in discrete time
[04:12:47] <jmkasunich> the filter got rid of the high frequency stuff
[04:13:00] <petev> well, are you saying the bandwidth of the machine is much lower than of the control?
[04:13:05] <petev> this I see
[04:13:06] <jmkasunich> because as soon as you go to sampling, you simply cannot pass high frequency stuff
[04:13:11] <jmkasunich> yes, that too
[04:13:18] <SWPadnos_> but machine dependent
[04:13:21] <jmkasunich> yes
[04:13:24] <petev> let's assume the machine is infinite bandwidth
[04:13:30] <petev> I don't see that
[04:13:43] <petev> if PID is converting position error to velocity
[04:13:45] <jmkasunich> don't see what?
[04:14:00] <petev> how can velocity go to 0 in between a servo period
[04:14:01] <SWPadnos_> the VelociRaptor has higher bandwidth than a Bridgeport with 20 oz-in steppers
[04:14:10] <petev> forget that
[04:14:11] <jmkasunich> heh
[04:14:38] <petev> if velocity only changes on servo period, how can it go to 0 at other times?
[04:14:43] <SWPadnos_> it can't, at the moment
[04:15:04] <petev> so then motion has to end on a servo period, unless we consider machine bandwidth
[04:15:14] <petev> true?
[04:15:20] <jmkasunich> no
[04:15:23] <SWPadnos_> motion has to end on a servo period because of machine bandwidth
[04:15:34] <SWPadnos_> (emc machine)
[04:15:41] <jmkasunich> well, real motion must start/emd on a servo period
[04:15:49] <petev> no, assume the machine bandwidth is infinite, with infinite acceleration
[04:15:57] <jmkasunich> but remember, real motion is a low-pass filtered version of the ideal path
[04:15:58] <SWPadnos_> emc machine == pc
[04:16:14] <petev> no, I meant machine == iron
[04:16:17] <jmkasunich> the ideal path can have bends at any time, not just servo time
[04:16:19] <petev> motors, etc.
[04:16:39] <SWPadnos_> right - the fact that emc can't make changes to motion inside a servo period is what makes it a low pass filter
[04:16:40] <jmkasunich> quite an assumption, but OK
[04:16:42] <petev> jmk: with infinite machine bandwidth?
[04:17:21] <petev> so what have we agreed to?
[04:17:31] <jmkasunich> I don't know
[04:17:35] <petev> that it's the low pass of the iron, motors, etc.?
[04:17:48] <jmkasunich> that is one lowpass
[04:17:49] <petev> if that weren't the case, could motion end between a servo period?
[04:18:02] <SWPadnos_> yo uhave an ideal signal with infinite bandwidth, you pass it through the controller (emc) which has a finite bandwidth, and then on to the machine, which should have even lower bandwidth
[04:18:10] <jmkasunich> the iron "filter" is the dominant pole in the system
[04:18:16] <petev> yes
[04:18:30] <SWPadnos_> if the iron hads more bandwidth than the controller, then you need a faster controller
[04:18:34] <jmkasunich> if the pole caused by the servo rate is lower than the iron pole, then you should raise the servo rate until it isnt
[04:18:40] <petev> swp: exactly
[04:19:12] <SWPadnos_> woohoo - we agree (I think)
[04:19:15] <jmkasunich> but for any but the most exotic machines, the iron bandwidth is in the 10s of Hz
[04:19:16] <petev> so, that being the case, why do we want to deal with more than linear moves at the servo rate?
[04:19:32] <petev> why not just up the TP rate so we can keep division of labor clean?
[04:19:44] <jmkasunich> I must of missed something
[04:19:57] <petev> we started with the request for eliptical commands
[04:19:59] <jmkasunich> I never suggested that you would want more than linear moves at the servo rate
[04:20:11] <petev> and I didn't see any value unless there was a bottle neck to the TP
[04:20:23] <SWPadnos_> I did, but it's probably my lack of understanding / mental block on al lthe different <X> rates in emc
[04:20:35] <petev> swp: suggested eliptical moves at servo rate
[04:20:46] <SWPadnos_> at TP rate, I think I meant
[04:20:49] <jmkasunich> well part of the value has absolutely nothing to do with rates
[04:20:58] <petev> I see value in the GUI
[04:21:05] <petev> but not at the lower levels
[04:21:07] <SWPadnos_> but not by calculating 100 short moves every TP cucle
[04:21:09] <SWPadnos_> cycle
[04:21:20] <jmkasunich> its also lookahead
[04:21:37] <jmkasunich> take skunkworks machine
[04:21:48] <jmkasunich> he has a maxV of 300ipm, 5ips
[04:21:52] <petev> if the TP gets fixed so that it can process multiple point per period, then arent arcs and lines enough?
[04:21:52] <jmkasunich> and a max accel of 1 ips
[04:22:10] <SWPadnos_> that's the thing - the path shape is calculated at the servo rate, but the shape is decided at the TP rate (more or less)
[04:22:18] <jmkasunich> so if he's scooting along at 5ips, he needs to start slowing down 5 seconds before a right angle turn
[04:22:44] <petev> ok
[04:22:54] <jmkasunich> if he does a 40 inch straight line as a single move, no problem
[04:23:12] <jmkasunich> but what if he does it as 1000 moves that are .040 long each
[04:23:35] <petev> I don't follow
[04:23:45] <jmkasunich> (all parallel to each other, followed by another line off at right angles to the rest)
[04:23:46] <petev> wont the TP just blend them and get the same result?
[04:24:02] <jmkasunich> how far ahead can the TP look?
[04:24:08] <petev> ah, so there is the look ahead issue
[04:24:11] <jmkasunich> today, it blends adjacent moves only
[04:24:19] <petev> ok, that sucks
[04:24:43] <jmkasunich> if it sees 500 parallel lines, it doesn't know that number 501 is a right angle turn and it needs to slow down when it gets to number 150 in order to make the turn
[04:24:43] <petev> so what are some of the proposed solutions?
[04:24:54] <petev> yep
[04:25:04] <SWPadnos_> that's partly due to the fact that it can only accept one move per cycle though, isn't it?
[04:25:09] <jmkasunich> obviously some form of deep lookahead
[04:25:28] <jmkasunich> partly
[04:25:29] <cradek> fwiw, that's already written but buggy
[04:25:34] <jmkasunich> I take that back
[04:25:48] <SWPadnos_> I think paul started that at Fest or at Les' place, right?
[04:25:50] <jmkasunich> the "accept one move per cycle" is a different issue
[04:26:03] <jmkasunich> I'm not sure which one paul attacked
[04:26:04] <petev> that's the buffer prob, right?
[04:26:09] <jmkasunich> or how successfull he was
[04:26:21] <SWPadnos_> "the" buffer problem - an optimist ;)
[04:26:36] <petev> right now I thought we couldn't send more than one motion command per TP cycle
[04:26:41] <jmkasunich> I just gave you the "lookahead" pathological case
[04:26:46] <jmkasunich> now heres the buffer one:
[04:26:49] <petev> the only way it gets more points is from an arc, no?
[04:26:50] <SWPadnos_> h
[04:26:52] <SWPadnos_> heh
[04:27:04] <jmkasunich> straight parallel moves, no right angle turn at the end, no need for lookahead
[04:27:11] <petev> ok
[04:27:14] <SWPadnos_> collinear
[04:27:17] <jmkasunich> but the programmer decided to programm 0.0005" segments
[04:27:38] <petev> well, that's just plain stupid
[04:27:40] <jmkasunich> at 5ips, you gotta feed 10,000 of them to the interp
[04:27:45] <petev> yep
[04:27:50] <jmkasunich> I said patholocgal
[04:27:57] <SWPadnos_> that's CAM - great, but sometimes stupid
[04:28:01] <jmkasunich> now assume he's milling a smooth curve
[04:28:12] <jmkasunich> they're not quite collinear
[04:28:22] <petev> yep
[04:28:26] <jmkasunich> but still close enough that there is no need to slow down at the junctions
[04:28:33] <petev> ok
[04:29:01] <jmkasunich> so he programs a lot of em, cause he wants to track that curve really well
[04:29:22] <petev> well should depend on the radius of the curve
[04:29:40] <cradek> petev: you'd be surprised at the crap paths that come out of cam software
[04:29:46] <jmkasunich> yep
[04:29:51] <petev> not mine ;-)
[04:30:23] <SWPadnos_> just look at a DXF where they used lines instead of curves (or text)
[04:30:26] <cradek> heh, mine's pretty bad
[04:30:27] <jmkasunich> another way of looking at this goes back to my "signals and bandwidth" approach
[04:30:32] <petev> DXF is not CAM
[04:30:50] <jmkasunich> another thought experiment:
[04:30:53] <SWPadnos_> no, but the idea of linear approximations of curves is similar
[04:31:01] <jmkasunich> suppose you have a 1" diameter circle
[04:31:07] <petev> ok
[04:31:12] <jmkasunich> circumference 6.28"
[04:31:17] <petev> yep
[04:31:22] <jmkasunich> assume a milling speed of 6.28" per second
[04:31:26] <petev> ok
[04:31:28] <jmkasunich> so you mill the circle in 1 second
[04:31:32] <petev> yep
[04:31:42] <jmkasunich> and assume you want to just keep going around and around, no entry or exit
[04:31:51] <petev> ok
[04:31:52] <jmkasunich> so X and Y position are 1Hz sinewaves
[04:32:02] <petev> ep
[04:32:03] <jmkasunich> not a lot of bandwidth needed there, is there?
[04:32:07] <petev> no
[04:32:19] <SWPadnos_> except...
[04:32:20] <jmkasunich> now approximate the circle as a square
[04:32:35] <petev> ok
[04:32:53] <jmkasunich> now X and Y positions are flat, then linear down, then flat, then linear up
[04:32:57] <SWPadnos_> infinite bandwidth needed
[04:33:00] <petev> yep
[04:33:03] <jmkasunich> now what is the bandwidth?
[04:33:06] <SWPadnos_> infinite bandwidth needed
[04:33:46] <jmkasunich> adding more segments reduces the magnitude of the high frequency componets (because there is a smaller change in velocity at each point) but increases the frequency (more per circle)
[04:34:04] <petev> ok
[04:34:11] <cradek> I'm still stuck back on the 1" diameter circle with 6.28" circumference
[04:34:20] <SWPadnos_> heh
[04:34:23] <petev> 2*PI*D
[04:34:30] <SWPadnos_> 2*pi*r
[04:34:39] <cradek> petev: not where I come from!
[04:34:40] <jmkasunich> oops, my bad
[04:34:45] <petev> oops
[04:34:53] <cradek> sorry, it's irrelevant but I thought it was funny that you all let it past
[04:35:14] <jmkasunich> I did that on purpose, to see if you were awake!
[04:35:14] <SWPadnos_> it was just an experiment
[04:35:21] <jmkasunich> (yeah, right)
[04:35:23] <SWPadnos_> if tested, we would have revised the theory
[04:35:51] <cradek> goodnight guys...
[04:35:55] <jmkasunich> I forgot where I was going with that (if I ever knew)
[04:35:56] <SWPadnos_> I think you did it to see if you were awake ;)
[04:35:58] <jmkasunich> godnight
[04:36:01] <SWPadnos_> night
[04:36:08] <petev> gnight
[04:36:22] <jmkasunich> it keeps coming down to bandwidth
[04:36:35] <jmkasunich> suppose you actually wanted to make an octagon, not a circle
[04:36:39] <SWPadnos_> as you decrease the number of samples, you increase the amount of information you need to convey per sample
[04:37:03] <jmkasunich> true
[04:37:04] <petev> ok, so relate this to the eliptical motion, I'm not seeing it
[04:37:38] <jmkasunich> what is the ideal number of segments to break an elipse or other smooth curve into?
[04:37:59] <petev> hmm, trade of error for bw
[04:38:02] <petev> of/off
[04:38:07] <jmkasunich> (trick question)
[04:38:21] <SWPadnos_> any time you have a non-linear motion, you would need (servo_rate) lines of G-code per second to get the same precision that just sending an ellipse to the servo controller would do
[04:38:41] <SWPadnos_> or the appropriate curve
[04:38:48] <jmkasunich> ideally, you have a mathematical representation of the path, and you sample it at the servo rate
[04:38:51] <petev> swp: but you are mixing division of work
[04:39:05] <petev> jmk: yes
[04:39:11] <jmkasunich> essentially, the "ideal number of segments" is one per servo period
[04:39:12] <SWPadnos_> no - the servo controller already does the sampling
[04:39:33] <SWPadnos_> the PID is also done at the same rate, though it could be different
[04:39:45] <petev> so, why not just have the TP give a queue of points to the servo thread?
[04:39:47] <jmkasunich> ignore PID
[04:39:56] <jmkasunich> we're trying to make a signal called Xposition
[04:39:58] <petev> it can calcualte them in batches
[04:40:10] <SWPadnos_> because you'd have to send 1000 commands per second, every second, if you aren't doing straight lines
[04:40:11] <jmkasunich> we need to bandwidth limit that signal, so the PID (and the machine) can follow it
[04:40:17] <petev> yes, queues of pose for servo
[04:40:58] <jmkasunich> pete: what you are talking about is the essence of trajectory planning
[04:41:07] <jmkasunich> taking a continuous path and sampling it
[04:41:09] <petev> kinda
[04:41:26] <petev> but why not change the position command to PID on each cycle it needed?
[04:41:39] <petev> follow an arbutray shape
[04:41:43] <petev> arbitrary
[04:41:45] <SWPadnos_> PID and position command are two different things
[04:41:52] <jmkasunich> but you are talking about sending that "continuous" path to the trajectory planner as a series of segments
[04:41:58] <jmkasunich> IE, already sampled
[04:41:59] <petev> PID takes position command
[04:42:08] <petev> jmk:yes
[04:42:27] <petev> could handle the sample part by sayinng what servo cycle to update on for lines
[04:42:36] <petev> that would save queue mem
[04:42:38] <SWPadnos_> right - and also takes feedback, and mixes it all up to get a velocity command (or torque, etc)
[04:42:39] <jmkasunich> but the sampling in the g-code file is almost certainly wrong for the servo rate
[04:42:51] <SWPadnos_> hold on a sec - consider this:
[04:42:54] <jmkasunich> swp: forget about PID, and velocity, and torque, and all that
[04:43:07] <petev> no, TP busts it up and makes a queue for servo
[04:43:10] <jmkasunich> that is trivial signal processing, it can be characterized with a bode plot or whatever
[04:43:34] <SWPadnos_> that was my point - it has nothing to do with position commands from the planner or the servo loop
[04:43:49] <petev> swp: assume the PID is perfect
[04:43:53] <SWPadnos_> (except that it's calculated at the same rate, in the servo loop)
[04:43:58] <jmkasunich> the position commands out of the planner are the signal we care about
[04:44:01] <SWPadnos_> roght - so - think about this:
[04:44:05] <petev> we need a new position each servo cycle for optimum performance
[04:44:22] <jmkasunich> we need a new position each servo cycle, period
[04:44:26] <SWPadnos_> given an elliptical path (or circular or whatever), emc will need to calculate N line segments
[04:44:38] <SWPadnos_> N is the servo rate * the total time for the move
[04:44:39] <petev> yes, but now it's the same position until the TP runs again
[04:44:50] <jmkasunich> ?
[04:45:01] <jmkasunich> you mean because the TP runs slower than the servo rate?
[04:45:05] <petev> yes
[04:45:21] <SWPadnos_> why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command?
[04:45:23] <petev> I'm saying let the TP calc poses for the servo rate in batches
[04:45:37] <jmkasunich> first, I consider that a distraction... nowhere is it written in stone that the TP needs to run slower than servo
[04:45:50] <jmkasunich> that was a NIST decision, driven in part by CPU horsepower limits
[04:46:02] <petev> but CPU limits are real
[04:46:09] <petev> we need a real solution
[04:46:35] <SWPadnos_> I'll ask again - given that there will *always* be a new position command every servo period (even if it's the same as the last one),
[04:46:37] <jmkasunich> second, there is an interpolater that does cubic splines between the TP output points, generating intermediate positions at the servo rate
[04:46:37] <SWPadnos_> why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command?
[04:47:29] <petev> swp: first, why limit the shape with formulas in the servo thread
[04:47:44] <petev> second, the servo thread needs to be tight to limit jitter
[04:47:49] <jmkasunich> to avoid "resampling"
[04:48:11] <SWPadnos_> I'd ask that the other way around - why limit the formulas that the servo thread can handle?
[04:48:11] <jmkasunich> breaking a shape up into short segments is a form of sampling
[04:48:33] <SWPadnos_> sure - it all depends on having an efficient calculator, but you need that anyway
[04:48:33] <petev> aren't we always sampled at the servo rate?
[04:48:44] <jmkasunich> but that sampling rate is almost never gonna match the sampling rate that you need at the servo stage
[04:48:48] <petev> somebody calcs the position
[04:49:24] <petev> I don't follow, TP knows the servo rate, why can't it calculate pionts for each servo period based on whatever blending and Q them
[04:49:25] <jmkasunich> pete: if you tell me to do a circle by drawing 500 straight lines, you have sampled that circle
[04:49:33] <SWPadnos_> yes - you need blending as well, and that shouldn't be in the servo calc
[04:49:39] <petev> yes
[04:49:53] <jmkasunich> pete: the cubic interpolator does what you are talking about
[04:50:02] <jmkasunich> the TP generates points at the TP rate
[04:50:04] <SWPadnos_> if your CAM program outputs a series of line segments that take 1.3 servo periods each, there's a problem
[04:50:07] <petev> jmk: I don't see how motion is changed between servo periods, so it's always sampled
[04:50:26] <petev> jmk: I know, I was considering a change to get better performance
[04:50:30] <jmkasunich> I think we're having at least three conversations at the same time
[04:50:36] <SWPadnos_> heh - one each ;)
[04:50:38] <petev> ok, you lead
[04:50:46] <jmkasunich> that won't help
[04:50:59] <jmkasunich> not if I'm not talking about the same subject you are
[04:51:03] <jmkasunich> (and I think I'm not)
[04:51:20] <SWPadnos_> the original (ish) question was about having ellipse commands in the interp, and how the ellipses get doen to the motors
[04:51:27] <petev> ok, I'm still on the value of eliptical commands
[04:51:29] <SWPadnos_> down
[04:51:47] <SWPadnos_> command as in G-code, or command as in TP->servo?
[04:51:53] <jmkasunich> ok, lets try this tack...
[04:52:00] <jmkasunich> the guy wants an elipse
[04:52:04] <petev> ok
[04:52:14] <jmkasunich> one approach is to tell his cam program he wants an elipse
[04:52:22] <SWPadnos_> (if he has one)
[04:52:22] <jmkasunich> and let the program generate a bunch of straight lines
[04:52:33] <jmkasunich> right?
[04:52:39] <petev> ok, we all agree that sucks, correct?
[04:52:43] <SWPadnos_> that's one way, yes
[04:52:47] <jmkasunich> at that point, he has sampled that elipse
[04:52:55] <petev> yes, at the wrong rate
[04:52:59] <jmkasunich> most likely
[04:53:06] <SWPadnos_> right
[04:53:29] <jmkasunich> thats why an elipse command is good - you can send it to the trajectory planner and let the TP sample it at the right rate
[04:53:41] <SWPadnos_> so when you run that program, you'll get a machine that jerks all over the place, and gives you an approximation of the approximation of an ellipse
[04:53:47] <petev> yes, but we were debating how far down it had to go
[04:53:55] <jmkasunich> heh, exactly swo
[04:53:57] <jmkasunich> swp
[04:53:58] <petev> the command that is
[04:54:04] <SWPadnos_> ok - so command = TP->servo
[04:54:17] <SWPadnos_> not G6 or whatever
[04:54:28] <petev> swp: thinks elipse goes to servo
[04:54:36] <petev> I think to TP with poses for servo
[04:54:46] <SWPadnos_> I'm asking what you mean by "an ellipse command"
[04:54:46] <jmkasunich> we might be using the term servo loosly
[04:55:10] <petev> swp: a new g-code or whatever
[04:55:34] <SWPadnos_> ok - I think the value of that is obvious, from the sampling point of view that jmk brought up
[04:55:42] <petev> yes
[04:55:50] <jmkasunich> to me, "servo" is the block(s) that are responsible for making the machine follow a sampled position command (a signal)
[04:55:54] <SWPadnos_> it's also a hell of a lot easier for one-offs at the machine
[04:56:04] <jmkasunich> servo never sees "commands", it only sees signals
[04:56:10] <petev> jmk: i think of servo as the PID rate
[04:56:17] <SWPadnos_> yes - that's the hardware view of servo ;)
[04:56:20] <petev> exactly
[04:56:32] <petev> it sees a position to go to
[04:56:33] <jmkasunich> servo period and servo are two differnet things
[04:56:43] <petev> not formulas to calc the position
[04:56:47] <SWPadnos_> ok by me, so servo should be totally out of this discussion
[04:56:58] <petev> ok, so servo period
[04:57:03] <jmkasunich> servo period is the sample rate of the position stream
[04:57:07] <petev> yes
[04:57:09] <SWPadnos_> right - except that the shape sampler also runs at the servo rate
[04:57:15] <SWPadnos_> yep
[04:57:24] <petev> shape sampler?
[04:57:29] <petev> do you mean TP?
[04:57:36] <jmkasunich> to me, "TP" is the blocks that turn a mathematical path into a sampled stream of positions
[04:57:38] <petev> it runs slower now
[04:57:46] <petev> jmk: yes
[04:57:50] <jmkasunich> that is for historical reasons only
[04:57:56] <SWPadnos_> no - I mean the thing that quantizes the expected path into straight lines for the servo loop to follow
[04:58:08] <SWPadnos_> or consecutive positions, if you prefer
[04:58:12] <petev> swp: that's the TP AFAIK
[04:58:18] <jmkasunich> and I prefer to think of the EMC "TP" and consisting of both the slow planner (TP rate) and the interpolator (servo rate)
[04:58:37] <jmkasunich> the input to that overall TP is commands, and the output is sampled position
[04:58:50] <petev> agreed
[04:59:04] <SWPadnos_> ok I thought the TP in emc was the part that blends successive paths
[04:59:12] <jmkasunich> the EMC one happens to accomplish that in two stages, first the main TP samples at a low rate, then the interplator resamples faster
[04:59:17] <petev> no, that's the interpolator
[04:59:39] <SWPadnos_> opposite, I think - interpolator goes faster (jmk?)
[04:59:53] <petev> I agree with JMK
[05:00:07] <petev> TP is slower
[05:00:20] <jmkasunich> what the EMC folks call blending is done by the slow TP
[05:00:21] <SWPadnos_> ok - interpolator is at servo rate, planner / blender goes slower (so far)
[05:00:34] <jmkasunich> although the effect of the interpolator is to blend some more
[05:00:43] <petev> ok, now I'm confused
[05:00:48] <jmkasunich> since it uses cubic splines
[05:00:51] <SWPadnos_> also dependent on the machine mode
[05:01:02] <SWPadnos_> exact stop etc
[05:01:03] <jmkasunich> actually no, the interpolator isn't
[05:01:08] <jmkasunich> thats the main TP
[05:01:21] <SWPadnos_> yes - sorry - we were typing at the same time, I think
[05:01:40] <jmkasunich> heh
[05:01:53] <SWPadnos_> I'll shut up - jmk knows what he';s talking about (more than me, at any rate ;) )
[05:02:00] <jmkasunich> anyway, the output of the main TP is not a series of straight lines...
[05:02:13] <jmkasunich> it is a series of points, but they get connected not by lines, but by splines
[05:02:29] <jmkasunich> the interpolator does the splines part
[05:02:43] <petev> ok, so where is the blending in the TP then?
[05:02:52] <jmkasunich> on a longer time scale
[05:02:56] <petev> ahh
[05:03:03] <jmkasunich> lets do a simple examppe
[05:03:14] <jmkasunich> G1 is rapid, right?
[05:03:20] <petev> G0
[05:03:27] <jmkasunich> ok, so G1 uses feed
[05:03:27] <SWPadnos_> blending has to do with G-codes or canonical commands, interpolating is sampling the blended path
[05:03:27] <petev> I'm awake ;-)
[05:03:36] <jmkasunich> heres our program
[05:03:40] <jmkasunich> start at 0,0,0
[05:03:52] <jmkasunich> G1 F60 X1
[05:03:56] <jmkasunich> G1 F30 X2
[05:04:00] <jmkasunich> done
[05:04:14] <jmkasunich> y and z never move
[05:04:19] <petev> yep
[05:04:43] <jmkasunich> X must accel to 60ipm, then when it gets close to 1.0, it decels to 30ipm, then continues to 2.0 and decels to a stop
[05:04:48] <jmkasunich> without blending, it does this:
[05:05:14] <jmkasunich> accel to 60, cruise at 60, decel to 0 at 1.0, accel to 30, cruise at 30, decel to 0 at 2.0
[05:05:22] <jmkasunich> with blending it does this:
[05:05:47] <jmkasunich> accel to 60, cruise at 60, decel to 30, cruise at 30, decel to 0 at 2.0
[05:05:55] <petev> ok
[05:06:10] <jmkasunich> the decel from 60 to 30 is split, so half happens before reaching 1.0, and the other half after
[05:06:14] <petev> and interpolation does nothing here
[05:06:14] <jmkasunich> speed at 1.0 is 45
[05:06:43] <jmkasunich> if the accel limits are low, the actual ramping may take many servo (in fact many TP) cycles
[05:07:19] <petev> ok, so the TP is blending velocity, and the interpolator is blending position?
[05:07:54] <jmkasunich> the tp is blending commands (lines and arcs)
[05:08:08] <jmkasunich> and the interpolator is blending between subsequent TP positions
[05:08:15] <SWPadnos_> lines and arcs at a given path speed
[05:08:18] <petev> but it's blending the velocity of the commands, or the position too?
[05:08:44] <jmkasunich> they aren't independent
[05:08:53] <jmkasunich> velocity = dP/dt
[05:08:56] <petev> elaborate
[05:08:59] <petev> yes
[05:09:36] <jmkasunich> you could draw the ideal path on paper as velocities, then integrate to get position
[05:09:42] <petev> ok, one sec
[05:09:55] <petev> to clarify, what is the output of the TP?
[05:10:03] <petev> is it a position and velocity?
[05:10:15] <jmkasunich> poses (postions) at the TP rate
[05:10:30] <petev> does a pose include velocity or not?
[05:10:31] <jmkasunich> velocity is implied, by the differnece between successive samples
[05:10:34] <jmkasunich> no
[05:10:36] <petev> ok
[05:10:49] <petev> so how does the TP blend the velocity in your example?
[05:11:03] <petev> the interpolator did it then?
[05:11:03] <jmkasunich> the commands into the TP did include velocity
[05:11:09] <petev> yes
[05:11:22] <jmkasunich> damn, I need paper again
[05:11:26] <petev> ahh, so velocity at the TP sample rate
[05:11:30] <petev> I got it
[05:12:08] <SWPadnos_> heh - we need to get you a smartboard
[05:12:19] <petev> that would be cool
[05:12:24] <jmkasunich> isn't there some website where you can sketch?
[05:12:39] <petev> didn't MS net meeting have that?
[05:12:44] <SWPadnos_> there are probably collaboration programs that would let you
[05:12:49] <SWPadnos_> yes it did
[05:13:24] <petev> ok, so many TP cycles per g-code, blends both position and velocity
[05:13:38] <petev> velocity implied by position at TP rate
[05:13:42] <petev> correct?
[05:14:08] <jmkasunich> I guess
[05:14:20] <petev> I'm asking
[05:14:26] <jmkasunich> velocity coming out of the TP is implied by the distance between successive samples
[05:14:31] <petev> yes
[05:14:38] <jmkasunich> velocity going in is embedded in the commands
[05:14:42] <petev> yes
[05:14:48] <petev> we agree
[05:14:50] <jmkasunich> "line from here, to there, this fast"
[05:14:54] <petev> yes
[05:15:07] <jmkasunich> going in, there is no knowledge about how long it will take
[05:15:21] <petev> the part I wasn't clear on was that the pose out of the TP were assumes to be at each TP period
[05:15:24] <petev> I got it now
[05:15:29] <jmkasunich> (and in fact, that can change on the fly, thanks to feedrate override)
[05:15:55] <SWPadnos_> right - I knew ther ewas a problem with precalculation - I just couldn't remember it
[05:16:07] <petev> hmm, so what if the TP gets too far ahead?
[05:16:24] <petev> and the op changes feed override
[05:16:26] <jmkasunich> right - it gets messy
[05:16:31] <petev> yuk
[05:16:41] <SWPadnos_> the TP needs to redo all those queued poses
[05:16:56] <jmkasunich> there are actually ways to precalc it
[05:16:58] <petev> is that what it does now?
[05:17:08] <SWPadnos_> it's the same problem as the CAM program sampling an ellipse for you at the G-code level
[05:17:13] <jmkasunich> no, because now it doesn't do lookahead
[05:17:18] <petev> oh
[05:17:51] <jmkasunich> heres a concept (no idea if the math is tractable)
[05:18:17] <jmkasunich> given a mathematical representation of a path (either a smooth curve, or a series of straight lines)
[05:18:25] <petev> one sec
[05:18:46] <jmkasunich> you can work backwards from the end to compute the maximum velocity at any point
[05:18:46] <petev> if the TP does not look ahead, how does the interpolator get multiple points to blend?
[05:18:52] <petev> is there a lag?
[05:18:54] <jmkasunich> yes
[05:18:59] <petev> ok
[05:19:20] <petev> so that interpolator Q can have the wrong feed rate for a bit then
[05:19:37] <jmkasunich> the lag is only one TP period
[05:19:40] <jmkasunich> typically 10mS
[05:19:53] <petev> ok
[05:19:54] <jmkasunich> so if you hit feedrate overrride, the actual feed might take 10mS to change
[05:19:58] <jmkasunich> you ain't gonna notice
[05:20:17] <petev> or start to change if the interpolator is blending many points, no?
[05:20:50] <jmkasunich> the interpolator blends between 2 points, using in addition to those 2, the one that precedes them, and the one that follows
[05:20:54] <SWPadnos_> it'll start after one TP period, but take as many as necessary, determined by the machine accel parameters
[05:21:05] <jmkasunich> so at any time there are four points of TP output in storage
[05:21:14] <jmkasunich> call them 0, 1, 2, 3
[05:21:29] <jmkasunich> 3 is the newest
[05:21:35] <petev> ok
[05:21:39] <jmkasunich> the interpolator is moving between 1 and 2
[05:21:50] <jmkasunich> when it hits 2, it asks the TP for 4
[05:22:09] <jmkasunich> then it discards 0, and begins moving between 2 and 3
[05:22:25] <petev> so it can take several TP cycles for the new velocity to be commanded
[05:22:33] <petev> but not too many
[05:22:35] <jmkasunich> yes
[05:22:38] <petev> got it
[05:23:10] <jmkasunich> that lag is probably less than the lag in userspace when you hit the feedrate control
[05:23:16] <petev> sure
[05:23:53] <SWPadnos_> right - those will typically be servo periods, right?
[05:24:10] <jmkasunich> the interp is generating a point (between 2 and 3 for instance) every servo period
[05:24:22] <petev> right
[05:24:35] <petev> according to the cubic
[05:24:37] <SWPadnos_> ok, but 0-2 , 1-2 etc are every TP cycle?
[05:24:37] <jmkasunich> it evaluates a spline formule
[05:24:42] <jmkasunich> yes
[05:24:44] <SWPadnos_> ok
[05:25:31] <petev> ok, so where does the eliptical move fit in then? still seems like TP to me
[05:25:35] <jmkasunich> the t in spline(t) goes from 0.0 at 1, to 1.0 at 2, then new spline coeffs are computed for the 2 to 3 spline, and t resets to 0.0 again
[05:26:01] <jmkasunich> yes, has nothing to do with the interp
[05:26:09] <jmkasunich> interpolator, not interpreter ;-)
[05:26:16] <petev> ok
[05:26:32] <SWPadnos_> ok - and 0,1,2 are issued at the TP rate, or as necessary (ie, there's a parameter that tells the increment for T every servo period)?
[05:26:40] <petev> so that would happen at the same place as arcs now
[05:26:59] <jmkasunich> the interpolator increments it's t by the ratio between servo period and TP period
[05:27:17] <SWPadnos_> ok - so the poses are issued at exactly one per TP period
[05:27:23] <jmkasunich> for instance, if servo is 1mS, and TP is 10mS, then the interpolator incrementes its t by 0.1
[05:27:44] <petev> jmk: you lost me
[05:27:56] <jmkasunich> what do you know about splines?
[05:27:57] <petev> are you saying the cubic is normalized?
[05:27:57] <SWPadnos_> servo is the rate the interp(olator) runs
[05:28:12] <SWPadnos_> it is normalized in time
[05:28:25] <SWPadnos_> so the interpolator uses up one per TP cycle
[05:28:37] <SWPadnos_> one pose, that is
[05:28:38] <jmkasunich> the spline is a set of coefficients
[05:28:41] <petev> sure, I understand if it's normalized
[05:28:45] <jmkasunich> you put 0.0 into it, you get point1
[05:28:53] <jmkasunich> put 1.0 into it, get point 2
[05:29:00] <petev> got it
[05:29:01] <SWPadnos_> for 6 axes
[05:29:11] <jmkasunich> put 0.3 into it, get a point that is 0.3 of the way, along a smooth path between 1 and 2
[05:29:24] <SWPadnos_> along a smooth cubic path
[05:29:30] <petev> ok
[05:29:32] <jmkasunich> yes
[05:29:48] <SWPadnos_> so it can already describe an arbitrary quadratic (circle or ellipse), given the right coefficients
[05:30:02] <jmkasunich> when the interpolator gets to 1.0, it generates a new set of cofficients using the next TP pose
[05:30:13] <jmkasunich> a segment on one anyway
[05:30:20] <jmkasunich> s/on/of
[05:30:21] <SWPadnos_> yes
[05:30:32] <petev> ok
[05:30:36] <jmkasunich> you can't describe a complete circle with a spline
[05:30:49] <SWPadnos_> no, but a TP portion of one should be easy ;)
[05:30:55] <SWPadnos_> TP period
[05:30:58] <jmkasunich> one approach to trajectory planning is to describe everything in terms of splines
[05:31:47] <petev> it seems that a high enough order spline should do fine for TP period moves and give flexibity to arbitrary move commands
[05:31:49] <jmkasunich> then the RT code is easy
[05:32:22] <petev> should have put a s in front
[05:32:23] <jmkasunich> the problem is that no spline, no matter how high order, can describe a sharp corner
[05:32:40] <petev> right, but the machine can't follow that anyhow
[05:32:50] <jmkasunich> so you have to decide how much the spline can deviate from the ideal path
[05:33:13] <jmkasunich> which is speed dependent, so you are right back at not being able to precompute the splines
[05:33:51] <petev> yep
[05:34:08] <SWPadnos_> If you think about it, you see that there is exactly one pose per servo period
[05:34:13] <jmkasunich> if you could precompute splines in user space, that would be wonderfull
[05:34:18] <petev> but still seems like TP look ahead has value, it just can't generate ahead
[05:34:25] <SWPadnos_> and it doesn't matter where that pose is calculated, it still needs to be calculated
[05:34:46] <petev> swp: but servo rate stuff needs to be tight to reduce sample error
[05:35:00] <jmkasunich> swp: exactly, thats why I consider the "TP" to be the composite of the main TP and the interpolator
[05:35:03] <SWPadnos_> so, unless you plan to precalculate the entire program (not practical), you need to have a computer that is capable of calculating at the servo rate
[05:35:09] <petev> none of the HW can support captures position until we get HAL IRQ threads
[05:35:20] <petev> captured
[05:35:37] <jmkasunich> swp: you do simple math (spline interpolation) at the servo rate
[05:35:49] <petev> yes
[05:35:53] <jmkasunich> you do more complex math (main TP and especially kinematics calcs) at the TP rate
[05:36:00] <SWPadnos_> yes
[05:36:07] <jmkasunich> yeah, don't forget about kins ;-)
[05:36:13] <SWPadnos_> sure
[05:36:18] <petev> jmk: how much do you think sample jitter is effecting EMC performance now?
[05:36:22] <jmkasunich> that is done on the main TP output, to reduce the CPU load
[05:36:26] <SWPadnos_> but there's still exactly one pose per servo period
[05:36:31] <jmkasunich> not enough to matter
[05:37:14] <petev> so, what improvements can be made then?
[05:37:17] <SWPadnos_> yeah - you get 20 us jitter (worst case) on a 1ms period
[05:37:26] <jmkasunich> remember, most noise introduced by jitter is at the servo rate, and it gets filtered out by the frequency response of the PID and iron
[05:37:41] <petev> swp, servo period is less than 1ms
[05:37:53] <SWPadnos_> improve how you tell the lower levels what to do, by reducing the amount of communication overhead (to allow moretime for calculations)
[05:38:04] <SWPadnos_> setvo period is typically 1ms
[05:38:05] <jmkasunich> petev: default EMC servo rate is 1mS
[05:38:20] <petev> I thought that was TP rate, seems slow for servo
[05:38:22] <SWPadnos_> can be faster, but I haven't heard of anyone going faster than 5KHz
[05:38:26] <SWPadnos_> TP is 10ms
[05:38:30] <SWPadnos_> by default
[05:38:43] <petev> so what's the point of 5K lines/sec of g-code
[05:39:04] <SWPadnos_> well - nobody's doing HSM with emc yet - it can't keep up
[05:39:12] <jmkasunich> how about when you restart and need to fast-forward to line 1000000
[05:39:12] <SWPadnos_> it would need to be faster for that
[05:39:19] <SWPadnos_> that too ;)
[05:39:27] <petev> jmk: good point, but I like the checkpointing better
[05:39:58] <SWPadnos_> how about when you load the file in AXIs, and it runs it in sim mode for the preview plot?
[05:40:24] <petev> fyi: I'm getting 4700 lines/sec on the 1GHz C3 (which is about 600 MHz celeron) with un-optimized code
[05:40:42] <jmkasunich> what does the standard interp do?
[05:40:44] <petev> what does axis do when you load it?
[05:41:08] <jmkasunich> it "runs" the entire file to generate the preview toolpath
[05:41:08] <petev> jmk: not sure
[05:41:15] <petev> would have to build something to test it
[05:41:16] <SWPadnos_> it does
[05:41:26] <SWPadnos_> oh
[05:41:38] <petev> axis runs it through what?
[05:41:49] <jmkasunich> there are million line G-code programs, at 4700 lines/sec, that is 200 seconds to load and display the plot
[05:42:12] <jmkasunich> thru the interp, I think.... it doesn't send the commands to the machine, just notes the position and discards the command
[05:42:18] <petev> so axis asks the interp to read it, but no exec, then reads back current position?
[05:42:20] <SWPadnos_> it runs the planner, but with output disabled (the mode is there for restarting without moving, I think)
[05:42:20] <jmkasunich> (canonical commands)
[05:42:47] <petev> if that's the case, the current interp is 4 x slower than what I have now, but all the code isn't in yet
[05:42:48] <SWPadnos_> right - they pipe the canonical commands back into their program, and make the plot that way
[05:43:09] <jmkasunich> petev: how do you know its 4 times slower?
[05:43:12] <SWPadnos_> that includes communication overhead
[05:43:34] <petev> I load the same program in axis and it takes at least 4x as long
[05:43:42] <petev> yes, NML overhead too
[05:43:57] <SWPadnos_> overhead for comm/NML, and generating the 3D GL objects
[05:44:09] <SWPadnos_> and putting them into the display list
[05:44:48] <petev> true, and right now, I'm reading from the file direct
[05:44:58] <petev> later, I will read into a buffer for each line
[05:45:02] <petev> should be much faster
[05:45:30] <SWPadnos_> well - it runs a 66000 line file in 4.348 seconds on this machine
[05:45:42] <petev> axis?
[05:45:47] <SWPadnos_> no - your interp
[05:45:55] <SWPadnos_> the 879k one
[05:45:59] <petev> your machine is faster than mine I think
[05:46:07] <SWPadnos_> I hope so ;)
[05:46:15] <SWPadnos_> I just spent $4000 on it
[05:46:19] <petev> oh
[05:46:27] <petev> that beats my $400
[05:46:55] <SWPadnos_> (2x opteron, 4G ram, 300G hd, dvd+-rw-DL, Nvidia 7800GT, dual 24" LCDs)
[05:47:05] <petev> jmk: so what do you see as the major areas to improve?
[05:47:57] <SWPadnos_> hm - a little faster for the 2M one (but within the error margin, I bet)
[05:48:02] <jmkasunich> in the area that we've been discussing?
[05:48:16] <petev> yes, from interp to dac out
[05:48:39] <jmkasunich> I'd like to build a collection of all the pathological cases
[05:48:44] <jmkasunich> short parallel lines
[05:48:48] <jmkasunich> curves made of short lines
[05:48:51] <jmkasunich> etc, etc
[05:49:06] <jmkasunich> then try to architect a TP that doesn't barf all over them
[05:49:17] <SWPadnos_> 3-D lofted surfaces ...
[05:49:33] <petev> jmk: what ideas do you have? lookahead?
[05:50:07] <jmkasunich> the idea of computing splines in user space and using those as the RT primitive instead of lines and arcs is attractive
[05:50:18] <petev> BTW, why can't cubic coeff be calced in the TP each period?
[05:50:25] <jmkasunich> but I haven't studied it deeply enough to know whether it can work
[05:51:22] <jmkasunich> today, the TP takes lines and arcs and generates a series of points
[05:51:38] <petev> ok, so maybe NURBs to the TP?
[05:51:42] <jmkasunich> then generates the cubic coeffs to interpolate between the points
[05:51:46] <jmkasunich> yes
[05:51:59] <SWPadnos_> there was dscussion of NURBS
[05:52:06] <jmkasunich> I'm talking about giving the TP its commands in the form of splines in the first place
[05:52:16] <petev> yes
[05:52:16] <SWPadnos_> also quintics, and others
[05:52:24] <petev> what about the usr/RT queue for the TP?
[05:52:45] <petev> I guess if we can pass a whole spline, one per period is ok
[05:52:51] <jmkasunich> that goes pack to lookahead
[05:52:53] <jmkasunich> back
[05:53:02] <petev> yes, forgot that
[05:53:03] <SWPadnos_> that's also stuff that can be precalculated
[05:53:12] <jmkasunich> even if you are passing splines, you still need lookahead of some sort...
[05:53:27] <jmkasunich> precalc in user space is nicer than trying to do it in RT
[05:53:27] <petev> so we should fix that too so lookahead can be avialbe immediately then?
[05:53:38] <SWPadnos_> emc is a bit unique here because it actually uses feedback
[05:53:49] <jmkasunich> not relevant to the TO
[05:53:52] <petev> I assume a spline will take several TP though, so lookadhead should be available soon
[05:53:52] <jmkasunich> TP
[05:54:15] <jmkasunich> its too late for me to think straight
[05:54:18] <SWPadnos_> the other controller programs (DeskCNC, Mach, etc) don't, so they can do 500-point lookahead, and show nice smooth paths
[05:54:29] <petev> jmk, swp has a good point, what about adaptive control in the TP?
[05:54:43] <petev> if one axis is getting behind, why not have the TP slow down?
[05:54:44] <jmkasunich> I don't see the connection
[05:54:51] <SWPadnos_> but they can't correct for anything on the fly
[05:54:57] <SWPadnos_> like feed override, etc
[05:55:00] <petev> use the position error feedback at the TP level
[05:55:05] <jmkasunich> they can do feed override
[05:55:14] <petev> the op?
[05:55:17] <petev> that's too late
[05:55:31] <petev> why not have the TP do auto feed override based on error?
[05:55:48] <jmkasunich> I don't even want to think about how nasty that would be to tune
[05:55:51] <SWPadnos_> sorry - feedback was a red herring - I'm not thining straight either
[05:55:58] <SWPadnos_> thinking
[05:55:59] <jmkasunich> especially if you have non-trivial kins
[05:56:20] <petev> just put a pid loop on it
[05:56:27] <SWPadnos_> the thing is, the mentality with the other programs is "set it and forget it"
[05:56:36] <SWPadnos_> emc is "set it, then check it"
[05:56:45] <petev> it would be slick
[05:56:50] <jmkasunich> other programs assume that the motor control section will do what its told
[05:56:57] <jmkasunich> I think our TP should do the same
[05:57:00] <petev> what about torque/force control on the spindle?
[05:57:16] <petev> your thinking in the box, let's go outside the box
[05:57:21] <petev> let's build something better
[05:57:48] <SWPadnos_> but you can't precalculate, and retain the ability to do things like feed override (or pause/resume) - you have to recalculate (resample) the segments involved
[05:57:57] <jmkasunich> I can see a slower outer loop that modulates feedrate override (in RT) based on following error (vector sum of all axis probalby) or based on spindle load or something
[05:58:05] <petev> yes
[05:58:18] <SWPadnos_> yep - that's the unstallable stepper thing Mariss has been working on
[05:58:24] <SWPadnos_> it's got to be a little faster though
[05:58:43] <jmkasunich> SWP: I would never precalc to the point of sampling
[05:58:55] <petev> not familiar with what mariss is doing
[05:59:08] <SWPadnos_> ok - good :)
[05:59:13] <SWPadnos_> to jmk
[05:59:24] <petev> ok, one other thing
[05:59:43] <petev> what about feed based on spindle RPM? we need this for rigid tapping and lathe
[05:59:50] <petev> what are your thoughts?
[05:59:52] <SWPadnos_> Mariss is making a mode in the G-Rex that will sense when a stepper isn't able to keep up, and slow down all axes proportionally until it can maintain speed
[06:00:01] <petev> oh
[06:00:13] <jmkasunich> petev: that topic is good for at least an hour or too
[06:00:14] <jmkasunich> two
[06:00:16] <jmkasunich> I'm not
[06:00:22] <petev> ok, tomorrow
[06:00:31] <jmkasunich> I gotta crash
[06:00:37] <petev> gnight
[06:00:47] <SWPadnos_> I'd love to make something (a feed wizard) that takes material properties (select Aluminum, 6061-T5), and sets feeds / speeds for that material / tool combination
[06:00:53] <SWPadnos_> night jmk
[06:00:54] <jmkasunich> honestly though, that topic is probably the most important we could discuss
[06:01:00] <petev> ok
[06:01:05] <SWPadnos_> and me too I think
[06:01:19] <petev> swp: my CAM already does that and there are plenty of feed/speed calcs on the net
[06:01:20] <jmkasunich> threading has been on our to-do list for at least 3 years, probably longer
[06:01:24] <SWPadnos_> damn - how'd it get to be 2:00 again?
[06:01:40] <petev> you guys need to move west ;-)
[06:01:47] <SWPadnos_> petev: your CAM is more than either $0 or $75, I'd wager
[06:01:56] <jmkasunich> next time we're chatting, lets put our minds on the issue of threading and see what we can come up with
[06:01:58] <petev> yes, but the calcs from the net are free
[06:02:06] <petev> jmk: ok
[06:02:09] <SWPadnos_> threading - hmmm - my sheets have threads
[06:02:27] <petev> ok, we have a lot to think about
[06:02:37] <petev> I understand the motion in EMC better now
[06:02:39] <SWPadnos_> yes, and they should be available from within emc - "this is my tool, this is my material, this is the path I want - cut"
[06:02:54] <petev> maybe
[06:02:54] <SWPadnos_> yeah - me, too.
[06:03:03] <SWPadnos_> I've had a hard time "getting it" for a long time
[06:03:11] <petev> that should relaly be done in CAM, but could be nice for conversational
[06:03:13] <SWPadnos_> I'll probably forget 90% by tomorrow
[06:03:17] <SWPadnos_> yep
[06:03:33] <petev> let's put it on cradeks feature list ;-)
[06:03:33] <SWPadnos_> conversational is where Ken Lerman wants to go - wizards for lots of things
[06:03:50] <SWPadnos_> AXIS-ConversationalCAM!
[06:03:51] <petev> yeah, but I think he's taking the wrong approach
[06:03:58] <petev> why save g-code space
[06:04:05] <petev> who cares, HD are cheap
[06:04:14] <petev> just put a conversational fron end
[06:04:18] <petev> front
[06:04:19] <SWPadnos_> well - people can use the codes as well
[06:04:31] <petev> yeah, but it make interp stuff ugly
[06:04:41] <petev> look at the recovery issue with loop
[06:04:50] <petev> plus the interp will be slower
[06:04:58] <petev> and there's no standard to boot
[06:05:06] <SWPadnos_> sure - but is it easier for somebody to look at a 600 line file to make a dozen holes, or a 50-line subroutine, and a couple dozen commented calls to that sub?
[06:05:10] <petev> I'm just not convinced
[06:05:32] <petev> we can support subs as programs
[06:05:41] <petev> I don't think that's too bad
[06:05:45] <SWPadnos_> I think we need to look at as many G-code references as possible, and make a "master reference" for the language and its major variants
[06:05:51] <petev> but I'm not sold on the loops and conditionals
[06:05:58] <SWPadnos_> from that, we can choose what to implement or to not implement
[06:06:09] <petev> yeah, it's hard to get good data
[06:06:19] <petev> the most I could find are discussions on forums
[06:06:24] <petev> no manuals to download
[06:06:29] <SWPadnos_> Gene Heskett mentioned that there's a reference in Machinery's Handbook - I'll look through that
[06:06:34] <petev> ok
[06:06:45] <SWPadnos_> eBay, but some of those manuals are expensive
[06:06:56] <petev> yep
[06:06:58] <SWPadnos_> (starts on page 1217, I think)
[06:07:06] <SWPadnos_> of the 27th edition
[06:07:10] <SWPadnos_> or was it 1279?
[06:07:13] <petev> I don't have machinery handbook
[06:07:30] <SWPadnos_> oh - you should get it - has all the info your CAM hides from you ;)
[06:07:37] <petev> I have some other books by moltrecht
[06:07:51] <petev> I look for a copy cheap
[06:07:54] <SWPadnos_> I've got to get to bed. we can talk more tomorrow
[06:08:01] <petev> ok, gnight
[06:08:07] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[00:32:49] <rayh_ppmc_usc> IMO this next line in core_servo is just wrong. setp pid.0.maxoutput [AXIS_0]MAX_VELOCITY
[00:35:25] <rayh_ppmc_usc> Using the variable names from emc it should refer to [AXIS_0]MAX_OUTPUT
[01:37:31] <alex_joni> morning ray
[01:45:31] <rayh> hi alex phone
[01:54:08] <rayh_ppmc_usc> Feeling any better?
[01:54:23] <alex_joni> unfortunately no
[01:54:31] <alex_joni> a bit worse I think :/
[01:54:43] <rayh_ppmc_usc> Oh. That's not good.
[01:55:00] <alex_joni> but I'm sweating a lot, so I think it's getting out
[01:55:11] <rayh_ppmc_usc> Is this a stuffy head or just a brain ache?
[01:56:05] <rayh_ppmc_usc> that was pretty american. let me try again
[01:56:14] <alex_joni> stuffy head, muscle ache, a bit fever ;) the whole package
[01:56:30] <alex_joni> running nose, caughing..
[01:56:37] <alex_joni> I could go on ..
[01:56:48] <rayh_ppmc_usc> I get the feeling
[01:57:09] <rayh_ppmc_usc> I'll not bug you much today.
[01:57:16] <alex_joni> oh.. but you can
[01:57:21] <alex_joni> that's nice for a change :)
[01:58:39] <rayh_ppmc_usc> IMO even if we get only a half dozen sample configurations, I'd like to see them packaged in their own subdirectories.
[01:59:06] <alex_joni> I agree
[01:59:40] <alex_joni> but the stuff I had to do to support one single emc.nml was nasty, I don't really like it
[02:00:01] <alex_joni> fixing default HAL files in configs/ and further .hal files in configs/foo/ is easy
[02:00:19] <alex_joni> but configs/foo/ needs to hold a .var & .tbl files aswell
[02:06:36] <rayh_ppmc_usc> In the past, the ini file has been key to finding all of the other files.
[02:07:24] <rayh_ppmc_usc> Could the ini file use something like ../emc.nml
[02:08:53] <alex_joni> yes that is one possibility
[02:09:05] <alex_joni> and it makes a lot of difference in the code needed to support that ;)
[04:42:45] <SWP_Away> rayh: are you still around?
[04:42:49] <SWP_Away> SWP_Away is now known as SWPadnos_
[05:06:17] <rayh> Hi steve
[05:06:39] <rayh> Working on another pc this morning.
[05:06:59] <rayh> SWPadnos_: how you doing
[05:07:11] <SWPadnos_> doing fine
[05:07:28] <SWPadnos_> I noticed your comment about [AXIS_0]MAX_OUTPUT
[05:07:58] <SWPadnos_> you're probably right, but the values would be different than for emc1, so the users would still need to look at it
[05:08:36] <rayh> default for emc1 was +10
[05:08:55] <SWPadnos_> right - it's a "virtual 10V servo driver max output"
[05:09:10] <SWPadnos_> in emc2, it's user units / second
[05:09:18] <SWPadnos_> that's a direct velocity command to the hardware drvier
[05:09:19] <rayh> max velocity which it is set to now used to default to 1.2
[05:09:47] <SWPadnos_> I agree - it's a good idea to have this setting be separate from max_vel
[05:10:01] <SWPadnos_> we've been trying to figure out how to make it do that in a clean way
[05:10:16] <SWPadnos_> (expressions, fudgefactor parameters, etc)
[05:10:31] <SWPadnos_> this is clean, but it isn't directly compatible with the emc1 way of doing things
[05:11:59] <rayh> phone brb
[05:12:02] <SWPadnos_> ok
[05:20:58] <rayh> multitasking cause the phone is slow
[05:21:54] <SWPadnos_> heh
[05:28:07] <rayh> I don't see the difference between max output on emc1
[05:28:18] <rayh> and this thing that we are trying to set on emc2
[05:28:36] <rayh> I'm between runnables right now but let me try to find it.
[05:33:03] <rayh_m5i20> okay
[05:33:10] <rayh_m5i20> 04 float -W 1.20000e+00 pid.0.maxoutput
[05:33:30] <rayh_m5i20> This is not max velocity is it?
[05:34:00] <rayh_m5i20> it should be how much output do we need to achieve max vel
[05:34:19] <rayh_m5i20> It's the range of the output variable?
[05:38:56] <SWPadnos_> phone
[05:49:26] <SWPadnos_> ok - I'm back (until the phone rings again)
[05:50:33] <SWPadnos_> yes - pid.0.maxoutput is the maximum commanded speed that will be output to the hardware, in user units / second
[05:52:52] <rayh> I thought that was what we had to change to 10 in order to make stuff run
[05:53:13] <SWPadnos_> nope - it just needs to be a little higher than the axis max_velocity
[05:53:31] <SWPadnos_> equal almost works, but a little headroom helps the PID
[05:54:03] <SWPadnos_> 10 was necessary in emc1 because it was assumed that this was the voltage to output to a servo drive
[05:54:07] <rayh> So how do we tell HAL that we want +- 10 volts
[05:54:16] <rayh> or +- 7
[05:54:31] <rayh> or 0-10 volts
[05:54:38] <SWPadnos_> ah - that's where the scale parameter (in the driver) comes into play
[05:55:30] <SWPadnos_> note that HAL uses user units for everything, for as long as possible - this is different from emc1, which uses "volts" everywhere for servo output levels
[05:55:31] <rayh> Okay. And this we have to configure in each specific xxx.hal
[05:56:00] <SWPadnos_> it's machine specific
[05:56:16] <rayh> But what is the user unit for range of output signals
[05:56:25] <rayh> We don't have volts.
[05:56:31] <SWPadnos_> user units per second
[05:56:40] <rayh> No that is not at all right
[05:56:53] <SWPadnos_> it's a velocity command to the servo or stepper, so it's a velocity unit
[05:57:11] <rayh> Oh shit]
[05:57:14] <SWPadnos_> why?
[05:57:19] <rayh> we are way wrong here.
[05:57:35] <SWPadnos_> in what way?
[05:58:14] <rayh> You are telling me that hal can command usc in velocity
[05:58:23] <SWPadnos_> yes - that's what it does
[05:58:34] <rayh> Tries to fucking do.
[05:58:46] <SWPadnos_> no - does (when properly configured ;) )
[05:58:50] <rayh> That isn't JonEs work at all
[05:59:02] <SWPadnos_> nope - that's JohnK and SWP's work
[05:59:17] <rayh> Jon is expecting a signal that runs from -10 to +10
[05:59:31] <SWPadnos_> in emc1, that was true. in emc2, it's not
[05:59:52] <rayh> It is a firmware thing not a version of emc thing
[06:00:06] <SWPadnos_> that's why I mentioned that the parameters from emc1 ini files wouldn't be directly compatible
[06:00:11] <SWPadnos_> no - it's a driver thing
[06:00:26] <rayh> I don't think so.
[06:00:39] <SWPadnos_> the hardware / firmware just gets a rate or pulse width setting from the (software) driver
[06:00:58] <SWPadnos_> all scaling is done at the ppmc.x parameter level
[06:02:22] <rayh> shit.
[06:02:24] <SWPadnos_> I can tell you exactly what units and scale factors are used, starting at the motion controller, and going to the outputs on the USC
[06:02:49] <rayh> then I guess I'll go for a walk and when I get back call my customer and tell them not to use ppmc
[06:02:55] <SWPadnos_> why not?
[06:03:11] <rayh> Cause it ain't gonna tune the way they need.
[06:03:35] <rayh> Sorry not meaning to take this out on you.
[06:03:36] <SWPadnos_> the only thing missing is asymmetric limits - going faster in one direction than the other
[06:03:49] <SWPadnos_> no trouble - I'm trying to understand why there's a problem
[06:04:01] <SWPadnos_> (which I don't yet :( )
[06:04:57] <SWPadnos_> can you explain it to me?
[06:05:20] <rayh> after I recover from this shock maybe.
[06:05:58] <SWPadnos_> well - there may not need to be any shock - I think that ppmc is perfectly tunable - just not in the same units as for emc1
[06:06:55] <SWPadnos_> (I could say silly psychiatrist things like "explain it to me - let me help you", but that would be silly ;) )
[06:08:39] <alex_joni> hello..
[06:08:44] <SWPadnos_> hiya
[06:09:08] <alex_joni> what's up?
[06:09:15] <alex_joni> seen a very long talk about TP last night...
[06:09:22] <SWPadnos_> heh - yep
[06:10:17] <alex_joni> nice.. any conclusions?
[06:10:33] <SWPadnos_> yeah - nobody understands the TP ;)
[06:11:10] <SWPadnos_> petev was wondering why you sould ever want anything other than line segments for the TP, since you can approximate any shape with them
[06:11:13] <SWPadnos_> should
[06:11:30] <alex_joni> yeah.. but that makes blending a problem
[06:11:43] <alex_joni> not a problem, but you need to be able to do that properly
[06:11:51] <alex_joni> and segments might be very short
[06:11:52] <SWPadnos_> it started with a discussion about whether or not ellipse commands should be there (prompted from the user list discussion)
[06:12:00] <alex_joni> yeah.. seen that
[06:12:06] <SWPadnos_> yeah - and feed override means you have to recalculate all of them
[06:12:42] <alex_joni> right.. feed override is a pita ;)
[06:12:49] <SWPadnos_> itwas on of those "the CAM program should do that for you, so why sorry about it" things
[06:13:00] <SWPadnos_> s/on/one/
[06:13:17] <SWPadnos_> only some people's CAM program is notepad
[06:13:37] <alex_joni> yeah.. or mc ;)
[06:13:53] <SWPadnos_> sure - or maybe gedit, or kate ;)
[06:16:30] <rayh_m5i20> rayh_m5i20 is now known as rayh_ppmc_usc
[06:16:40] <SWPadnos_> heh - change of hardware ;)
[06:17:37] <alex_joni> another mutation?
[06:17:39] <rayh_ppmc_usc> 05 float -W 0.00000e+00 ppmc.0.stepgen.00.max-vel
[06:17:39] <rayh_ppmc_usc>
[06:17:50] <SWPadnos_> 0 means no user-defined limit
[06:18:00] <rayh_ppmc_usc> is the only thing that looks to be settable on the ppmc card.
[06:18:31] <rayh_ppmc_usc> cause scale is pulses per unit
[06:19:48] <SWPadnos_> ok - hold on a sec, I'm getting to the code
[06:20:56] <SWPadnos_> yes - that's the only limiting thing that gets set at the USC driver level
[06:21:33] <SWPadnos_> that should probably be split into two settings - one for forward, one for reverse
[06:21:36] <rayh_ppmc_usc> And what are the units associated with it
[06:21:51] <rayh_ppmc_usc> ipm or mmpm
[06:21:53] <SWPadnos_> user units per second (velocity)
[06:21:55] <SWPadnos_> yes
[06:22:32] <SWPadnos_> internally, the input velocity is multiplied by the scale to get the nimber of steps /second to output
[06:22:36] <SWPadnos_> number
[06:23:14] <rayh_ppmc_usc> right. I'm okay with that.
[06:23:57] <SWPadnos_> the tuning gets done at the PID block though - this is just a "hard" limit on the maximum pulse rate the driver will allow
[06:24:42] <rayh_ppmc_usc> I see that.
[06:25:19] <rayh_ppmc_usc> and it ought to be set to Max_Vel * Scale
[06:26:00] <SWPadnos_> what ought to be set to that? the max-vel parameter?
[06:26:27] <alex_joni> max-vel should be Max_vel
[06:26:35] <alex_joni> not multiplied with Scale
[06:27:03] <rayh_ppmc_usc> So we have no way of handling max ppr
[06:27:14] <rayh_ppmc_usc> scuse pps
[06:27:37] <SWPadnos_> internally, the max-vel parameter is multiplied by scale to get the max pps
[06:27:53] <alex_joni> rayh: what do you plan to do with pps?
[06:28:06] <SWPadnos_> hold off a sec alex - this is a continuation of a prior discussion
[06:28:11] <rayh_ppmc_usc> Right and that is the logical thing to use when you look at stepper motor characteristics
[06:28:51] <SWPadnos_> ok - yes, you need to calculate the max velocity from the max step rate
[06:29:12] <rayh_ppmc_usc> I don't look at velocity when I consider stepper motor and drive characteristics.
[06:29:35] <alex_joni> how about something in between?
[06:29:41] <SWPadnos_> but you need to do that anyway, because at some point, you're going to set the [AXIS_0]MAX_VELOCITY number
[06:30:05] <alex_joni> having either MAX_VEL or MAX_STEPS in the ini, and the run-script? or hal? takes care of converting one to the other
[06:30:09] <rayh_ppmc_usc> Well I guess I'll just have to rethink how I tell folk to design a stepper system.
[06:30:36] <SWPadnos_> are you thinking of stepper systems that aren't for machininn?
[06:30:42] <SWPadnos_> machining
[06:30:52] <rayh_ppmc_usc> I'm thinking of motion
[06:30:56] <rayh_ppmc_usc> not machining
[06:30:58] <SWPadnos_> ok
[06:32:38] <rayh_ppmc_usc> I can do that. It just starts at the other end of the design problem.
[06:33:15] <SWPadnos_> yeah - with this method, you have to know your final drive ratio and all to get the limit value
[06:33:37] <SWPadnos_> but the max step rate (or velocity) will also depend on that anyway
[06:33:57] <rayh_ppmc_usc> No you have to know all of that before you can begin to look at the stepper motor velocity/torque plots.
[06:34:53] <SWPadnos_> what's the design / setup process you want to use?
[06:35:07] <SWPadnos_> (or - used to use ;) )
[06:35:10] <rayh_ppmc_usc> maybe O meed a ;pmger wa;l.
[06:35:40] <SWPadnos_> um - in english? :)
[06:35:52] <rayh_ppmc_usc> I tend to tell folk you can expect to get about 12 k pps
[06:36:10] <rayh_ppmc_usc> from a parport
[06:36:44] <rayh_ppmc_usc> Now go design your axis so that it moves as fast as you want.
[06:36:51] <rayh_ppmc_usc> or need.
[06:37:15] <SWPadnos_> ok - with the USC, the motor and drive system will be the limiting factor
[06:38:08] <alex_joni> how far can the USC go? as in pulse rate?
[06:38:27] <SWPadnos_> depends on the version, but mine can do 2.5 MHz
[06:38:43] <rayh_ppmc_usc> phone
[06:38:47] <SWPadnos_> jmk's is limited to 2 MHz
[06:38:53] <SWPadnos_> ok Ray
[06:39:30] <SWPadnos_> you can't get encoders that fast, and I'd be really surprised to see any stepper that can keep up, even with pretty fine microstepping
[06:40:39] <rayh_ppmc_usc> It is not a matter of how fast the usc works
[06:40:58] <SWPadnos_> nope - was just answering alex's question
[06:41:00] <alex_joni> * alex_joni goes back to lurking mode
[06:41:26] <SWPadnos_> it sort of is, because the step rate is no longer the limiting factor in designing a stepper system
[06:41:30] <rayh_ppmc_usc> The problem is that we have a motor that has so much torque at so many pps
[06:41:44] <rayh_ppmc_usc> and we design from that.
[06:42:03] <rayh_ppmc_usc> Not from the final velocity of the system.
[06:42:39] <SWPadnos_> right - you get teh final velocity by choosing drive ratios etc, based on the performance of the stepper you've chosen
[06:43:06] <rayh_ppmc_usc> We just have to write the paper that explains this stuff different than we did.
[06:43:13] <SWPadnos_> yep.
[06:43:46] <SWPadnos_> at its simplest, this method only requires one extra divisoin (max-vel = max_pps / scale)
[06:44:10] <SWPadnos_> that calculation would have to be done anyway, so you can set the axis max_velocity in emc.ini
[06:44:27] <rayh_ppmc_usc> Now at the pid box
[06:44:34] <SWPadnos_> ok
[06:44:56] <rayh_ppmc_usc> there are no percentages?
[06:45:11] <rayh_ppmc_usc> we just shove commanded vel in
[06:45:26] <SWPadnos_> yes, in user units / sec
[06:45:38] <rayh_ppmc_usc> and get xxx out.
[06:45:53] <rayh_ppmc_usc> and xxx can not be thought of as +-10 volt
[06:46:06] <SWPadnos_> yes, also in velocity (I'm not sure how this magically turns into a torque number, for those kinds of systems)
[06:46:19] <SWPadnos_> right - velocity (or magically torque)
[06:46:33] <SWPadnos_> hold on a sec - the input to the PID is a position
[06:46:40] <SWPadnos_> in user units
[06:46:55] <rayh_ppmc_usc> okay
[06:47:13] <SWPadnos_> the output is a velocity, to correct the current position to match the commanded position
[06:47:35] <rayh_ppmc_usc> okay
[06:47:52] <SWPadnos_> (again - I'm not sure how this works with torque mode, so I'll just leave that out)
[06:48:09] <alex_joni_> hmmm.. this is new :/
[06:48:10] <rayh_ppmc_usc> No difference in that case.
[06:48:26] <alex_joni_> I guess my Centrino just overheated and shut down :(
[06:48:39] <SWPadnos_> bummer
[06:48:39] <alex_joni_> might be the fever and the fact that it's sitting in my lap ;)
[06:48:39] <rayh_ppmc_usc> oops.
[06:48:49] <rayh_ppmc_usc> I've done that.
[06:48:54] <alex_joni_> alex_joni_ is now known as alex_joni
[06:49:00] <SWPadnos_> I was just going to comment on how lucky you are that your balls didn't get fried
[06:49:23] <alex_joni> SWPadnos_: it was the other way around :D
[06:49:27] <SWPadnos_> heh
[06:49:34] <SWPadnos_> I don't want to know ;)
[06:49:58] <rayh_ppmc_usc> alex has a fever today
[06:50:11] <rayh_ppmc_usc> he thinks his balls are frying his processor.
[06:50:21] <SWPadnos_> yeah - I don't want to know ;)
[06:50:43] <alex_joni> SWPadnos_: 'image go away'
[06:50:47] <alex_joni> try that as a mantra
[06:50:49] <SWPadnos_> heh
[06:51:19] <rayh_ppmc_usc> Well at least I can understand why I am having issues with tuning.
[06:51:32] <SWPadnos_> heh - that's a good start
[06:51:35] <alex_joni> oopsy... just came in a mail from ebo
[06:51:39] <alex_joni> on the devel list
[06:51:44] <alex_joni> * alex_joni reads now
[06:52:14] <SWPadnos_> so, do you have concerns about the PID tuning?
[06:52:20] <SWPadnos_> method
[06:53:46] <rayh> yes.
[06:53:58] <rayh> wow that lag was huge
[06:54:59] <rayh> so input to pid is position and output is vel in user units.
[06:55:30] <rayh> * rayh hits his head on the table a few times to pound it in.
[06:55:47] <alex_joni> rayh: write it on the table first, that does all the difference
[06:56:32] <rayh> Good plan. I've got a permanent marker (sharpie) right here.
[06:57:41] <SWPadnos_> heh
[06:58:32] <rayh> Thanks SWPadnos_
[06:58:42] <SWPadnos_> sure - did I help?
[06:58:50] <rayh> gotta run for a bit
[06:59:00] <SWPadnos_> ok - see ya around
[06:59:10] <rayh> understanding yes approval for the approach no.
[06:59:20] <SWPadnos_> heh - OK
[06:59:47] <rayh_ppmc_usc> rayh_ppmc_usc is now known as rayh_away
[07:03:26] <SWPadnos_> hm - I don't see any ebo mails...
[07:04:43] <alex_joni> just one.. on the devel list
[07:04:47] <alex_joni> about configs
[07:05:24] <SWPadnos_> strange - when did it arrive?
[07:05:41] <alex_joni> 20 mins ago
[07:05:56] <SWPadnos_> odd - maybe the .ro mail service is vaster than .us
[07:06:05] <alex_joni> my .ro is in texas :P
[07:06:06] <SWPadnos_> faster
[07:06:10] <SWPadnos_> heh
[07:06:21] <alex_joni> just traceroute it ;)
[07:07:06] <SWPadnos_> well - I'm looking at the archives on sf (logged in), and it's not there. and I haven't gotten any mail on the devlist sonce Ray's comment in the config thread
[07:07:12] <SWPadnos_> since
[07:07:24] <alex_joni> SF has been odd with emails lately
[07:07:31] <SWPadnos_> bummer
[07:07:38] <rayh_away> rayh_away is now known as rayh_ppmc_usc
[07:07:39] <alex_joni> yesterday ray's mail took 2 hours before it got to me
[07:07:44] <rayh_ppmc_usc> I'm back
[07:07:49] <alex_joni> the one that went through SF
[07:07:58] <SWPadnos_> that was fast ;)
[07:08:01] <alex_joni> rayh_ppmc_usc: talking about bad mailings at SF
[07:08:06] <rayh_ppmc_usc> They had some real troubles yesterday.
[07:08:27] <alex_joni> yup, and SWP still reports some
[07:08:29] <rayh_ppmc_usc> something to do with their server farm
[07:08:46] <rayh_ppmc_usc> said they'd get the whole new system on line in a few days.
[07:08:57] <SWPadnos_> well - we'll see what happens. I think the default retry period is 4 hours
[07:09:29] <rayh_ppmc_usc> One of the reasons that "we" want computation in halcmd
[07:09:44] <SWPadnos_> oh - I think you can drop the quotes there ;)
[07:10:01] <SWPadnos_> everyone I've talked to has agreed that they would be good ;)
[07:10:06] <alex_joni> yeah.. you're safe ...
[07:10:10] <rayh_ppmc_usc> is so that we can do stuff like (max-vel * 1.1)
[07:10:41] <SWPadnos_> exactly -check the logs from last night to see just how much in agreement jmk and I are
[07:10:47] <rayh_ppmc_usc> Now we know that we always want that so why not in the code itself
[07:11:00] <SWPadnos_> in the PID?
[07:12:08] <rayh_ppmc_usc> Wherever that ceiling is placed on pulserate or pulse read rate
[07:12:31] <rayh_ppmc_usc> I guess that is max vel again
[07:12:35] <SWPadnos_> ok - there are several limits, at different places in the command chain
[07:12:55] <SWPadnos_> one is the motion controller - it has a maximum position that it can ask for
[07:13:17] <SWPadnos_> next is the PID
[07:13:20] <SWPadnos_> then the driver
[07:13:49] <SWPadnos_> the driver limit needs to be from the actual machine constraints
[07:13:57] <SWPadnos_> (minus some safety factor)
[07:14:33] <SWPadnos_> the motion controller should also be clamped to this max safe limit
[07:14:38] <rayh_ppmc_usc> Well max pos is irrelevant for this kind of thing
[07:15:00] <SWPadnos_> sure - motion also uses the max_vel in the TP
[07:15:28] <SWPadnos_> so, we have essentially the same number being used in 3 places
[07:15:32] <alex_joni> SWPadnos_: but sometimes the axis might fall back a bit
[07:15:35] <SWPadnos_> motion, PID, and driver limits
[07:15:36] <rayh_ppmc_usc> all we need is a bit of overhead so that we can return any buildup in following error
[07:15:42] <alex_joni> then to keep up it will need to go faster
[07:15:50] <SWPadnos_> yes, and that has to be in the PID limit, and the driver limit
[07:15:55] <SWPadnos_> but not the motion controller limit
[07:16:02] <alex_joni> and then it might hit the limit.. so maybe the TP limit needs to be a bit lower than PID limit
[07:16:14] <SWPadnos_> (so motion limit < driver / pid limit)
[07:16:20] <SWPadnos_> yes
[07:16:58] <alex_joni> actual_motion > driver > pid > tp (in terms of speed)
[07:16:59] <rayh_ppmc_usc> and since this is IMO always the case, why not allow for it in the pid code.
[07:17:09] <SWPadnos_> for testing purposes, you have the flexibility of using just the driver (no PID), and setting the output rate manually
[07:17:24] <SWPadnos_> well - the headroom needed is machine-dependent
[07:17:31] <rayh_ppmc_usc> for testing I can make that allowance
[07:17:47] <rayh_ppmc_usc> so add a headroom variable
[07:17:58] <SWPadnos_> on a closely engineered system, you wouldn't want to go beyond maybe 3-5% headroom
[07:18:20] <SWPadnos_> on a deafult install for a hobbyist, you may need 10%
[07:18:42] <SWPadnos_> yes - the headroom variable is the pid.0.max-output (though we can't use formulas yet)
[07:18:56] <rayh_ppmc_usc> Lag is usually caused by accel so I'd think that it would be the other way round.
[07:19:24] <rayh_ppmc_usc> No pid.0.max-output is exactly that
[07:19:50] <rayh_ppmc_usc> the headroom is a fudge factor that you want to put in by computation at the hal
[07:20:20] <SWPadnos_> well - right now, we can't see the motion limit in HAL
[07:20:29] <SWPadnos_> that's directly loaded from the ini
[07:20:56] <alex_joni> yeah but it could be ([AXIS_0]MAX_VEL * 0.9)
[07:21:05] <alex_joni> if calculations were supported ;)
[07:21:09] <SWPadnos_> yes - if we had formulas
[07:21:17] <rayh_ppmc_usc> it seems to me that it would be more consistent to make a param named pid.0.headroom
[07:21:17] <alex_joni> we eventually will have
[07:21:39] <SWPadnos_> it may be possible for HAL to compute the proper headroom, but it still needs to know the limit in motion
[07:21:43] <rayh_ppmc_usc> Then we don't have to edit formulas in hal
[07:21:56] <SWPadnos_> it still needs the limit that motion has
[07:22:03] <SWPadnos_> so you'd need two pins still
[07:22:09] <rayh_ppmc_usc> It already has pid.0.max-output
[07:22:11] <alex_joni> yeah... but that would be a particular fix, not a general one for different situations
[07:22:13] <rayh_ppmc_usc> doesn't it
[07:22:26] <SWPadnos_> yes it does
[07:22:34] <SWPadnos_> you'd have to add another pin though
[07:22:45] <rayh_ppmc_usc> IT is simply one additional pin for the pid loop
[07:22:57] <SWPadnos_> I'm not sure that it's better to have two pins (max-output and headroom)
[07:23:20] <SWPadnos_> when one pin can suffice, assuming that it can be set with a formula
[07:23:56] <SWPadnos_> it would be ideal to have access to the internal parameters of motion
[07:24:01] <rayh_ppmc_usc> So you gotta tell the integrator, okay open up this hal file and find line 2689 and change the ([AXIS_0]MAX_VEL 0.9) to a ([AXIS_0]MAX_VEL 1.1)
[07:24:59] <rayh_ppmc_usc> you realize that i'm being the devils advocate here.
[07:25:06] <SWPadnos_> no - just the devil ;)
[07:25:12] <alex_joni> it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM)
[07:25:13] <rayh_ppmc_usc> Right.
[07:25:26] <alex_joni> it NEEDS to be in the ini afterall
[07:25:52] <alex_joni> because probably you don't want a constant in the -hal file going to the pid.0.headroom pin
[07:25:53] <SWPadnos_> there needs to be a setting, so the integrator has to open *some* file and go to line 2689 and change something
[07:26:53] <SWPadnos_> I'll repeat my mantra: "sane defaults, but user configurable"
[07:27:07] <alex_joni> SWPadnos_: probably an integrator might beconfortable with editing the INI
[07:27:14] <alex_joni> or use a Configurator to do that ;)
[07:27:27] <SWPadnos_> sure - I have no problem with that
[07:27:49] <rayh_ppmc_usc> it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM)
[07:27:58] <rayh_ppmc_usc> could as easily be
[07:28:24] <rayh_ppmc_usc> ppmc.0.headroom [AXIS_0]HEADROOM)
[07:28:32] <SWPadnos_> actually - [AXIS_0]MAX_VELOCITY * (1+ [AXIS_0]HEADROOM)
[07:28:42] <SWPadnos_> so if you leave it out, you still egt a max vel ;)
[07:28:55] <rayh_ppmc_usc> right.
[07:29:15] <SWPadnos_> internally to HAL, it doesn't really matter what the setting is
[07:29:19] <SWPadnos_> as long as it can be set
[07:29:28] <rayh_ppmc_usc> or something like 1.5
[07:29:46] <rayh_ppmc_usc> for default so that no one will ever run out of headroom.
[07:29:49] <SWPadnos_> sure - but is that percent, or a multiplication factor?
[07:30:17] <rayh_ppmc_usc> I would do something similar for the default following error settings also.
[07:30:52] <rayh_ppmc_usc> but then that's the devil talking
[07:30:56] <alex_joni> you realize that making PID slower, it will make the overall machine run slower
[07:31:13] <SWPadnos_> well - how do you mean? setting them as a fraction of max_vel?
[07:31:37] <rayh_ppmc_usc> I'd make all of these things percent.
[07:31:41] <SWPadnos_> we haven't talked about PIDFF parameters at all. how would it be slower?
[07:31:54] <alex_joni> not PIDFF, the limiting of PID
[07:32:14] <SWPadnos_> this is a final output limit we're talking about - not a slew rate limit
[07:32:29] <SWPadnos_> it shouldn't be able to command anything faster than the machine can do anyway
[07:32:45] <alex_joni> yeah.. but G0 should go at that rate
[07:32:57] <rayh_ppmc_usc> It it doesn't, then you can not feed following error back in during a rapid.
[07:33:15] <SWPadnos_> that's why it's set to [AXIS_0]MAX_VELOCITY
[07:33:25] <SWPadnos_> and why we were discussing how to get some extra headroom in there
[07:34:15] <SWPadnos_> I got the email, btw
[07:35:07] <rayh_ppmc_usc> sodi
[07:36:04] <rayh_ppmc_usc> 2 of em in fact.
[07:36:25] <rayh_ppmc_usc> spaced about 10 minutes apart but carrying the same time stamp.
[07:36:37] <rayh_ppmc_usc> probably had to go through NRO
[07:37:08] <rayh_ppmc_usc> or whomever it is that keeps track of my email these days.
[07:38:00] <SWPadnos_> incidentally, there's nothing that stops an integrator from making up their own ini settings, like MAXPIDOUT
[07:38:12] <SWPadnos_> then making the hal file use [AXIS_0]MAXPIDOUT
[07:38:26] <alex_joni> yeah if they know that ;)
[07:38:36] <SWPadnos_> I only used max_vel because it was there in the default emc.ini
[07:38:48] <SWPadnos_> we can add emc2-related stuff to the ini file too
[07:39:20] <SWPadnos_> I didn't want to commit any changes to the ini file, just because of thing I had changed that are specific to my machine
[07:52:03] <rayh_ppmc_usc> Right. I fear for this also
[07:52:25] <rayh_ppmc_usc> I'm thinking though at we need at least a stock stepper and servo configs
[07:52:33] <rayh_ppmc_usc> that
[07:55:43] <SWPadnos_> yep - Alex and I were discussing that
[07:56:11] <alex_joni> we were all discussing that
[07:56:13] <SWPadnos_> I was thinking of making an emc_servo.ini, and changing the core_servo.hal file to match
[07:56:17] <alex_joni> I think that's clear to all..
[07:56:26] <rayh_ppmc_usc> way ahead of me. I only saw the dust
[07:56:31] <SWPadnos_> heh
[07:56:48] <SWPadnos_> I can add something like PID_MAX_OUTPUT to the AXIS_n sections
[07:56:58] <rayh_ppmc_usc> problem is what hardware do we use
[07:57:10] <rayh_ppmc_usc> okay that handles the problem
[07:57:29] <SWPadnos_> the core settings are hardware independent (in terms of the units)
[07:57:42] <SWPadnos_> that's why the units are the way they are ;)
[07:57:52] <rayh_ppmc_usc> and we just have to explain to integrators that headroom is PID_MAX_OUTPUT - Max_Vel
[07:58:03] <SWPadnos_> sure
[07:58:13] <SWPadnos_> it's gotta be explained one way or the other
[07:58:20] <rayh_ppmc_usc> You bet.
[07:58:37] <SWPadnos_> I'd change the driver output limit to be equal to the PID limit as well
[07:58:56] <SWPadnos_> so effectively, we're adding a HAL_MAX_VEL to the ini file
[07:58:57] <rayh_ppmc_usc> Yes.
[07:59:34] <rayh_ppmc_usc> That'll get those stray pulses rounded up and put back in.
[07:59:43] <SWPadnos_> heh - yep :)
[07:59:54] <rayh_ppmc_usc> speaking of texas.
[08:00:13] <SWPadnos_> it would be ideal to remove anything that doesn't pertain to emc2 from the ini file, but unfortunately, some of it will be put back on exit
[08:01:00] <rayh_ppmc_usc> do you know what those things are or is there a way to test
[08:01:16] <SWPadnos_> edit the ini file, and align all the settings
[08:01:24] <SWPadnos_> run emc and exit
[08:01:32] <rayh_ppmc_usc> ah.
[08:01:52] <SWPadnos_> when you look at the file, any rewritten settings will be NAME = VALUE - not aligned
[08:02:06] <alex_joni> SWPadnos_: except the hal ones
[08:02:43] <SWPadnos_> no - anything that gets rewritten will have changed alignment - the HAL data won't be written at all
[08:03:10] <alex_joni> I meant ini values used from HAL
[08:03:14] <rayh_ppmc_usc> Huh. I thought the read/write that emc did was a diff
[08:03:32] <SWPadnos_> the diff is for the settings file, right?
[08:03:40] <SWPadnos_> parameter file , I mean
[08:06:17] <rayh_ppmc_usc> I know that for emc if you edit the file and add or remove comments or put in tickle type variables they will stay
[08:06:28] <rayh_ppmc_usc> in the ini that is.
[08:07:09] <SWPadnos_> right - there are some things that get rewrittten (OUTPUT_SCALE, for example)
[08:07:28] <rayh_ppmc_usc> I think that it only touches the lines that it recognizes as variables that are changed
[08:07:31] <SWPadnos_> actually - that one is a pisser, because it doesn't get read, and then getw rewritten to default every time
[08:07:36] <SWPadnos_> yes
[08:07:47] <SWPadnos_> but it ignores anything else you add to it
[08:07:50] <SWPadnos_> (I think)
[08:08:00] <rayh_ppmc_usc> That's my impression
[08:08:10] <alex_joni> SWPadnos_: exactly.. because it's used by HAL not by emc (that's what I wanted to point out above)
[08:08:19] <SWPadnos_> I'm checking (call me paranoid)
[08:08:21] <SWPadnos_> ok alex
[08:10:43] <SWPadnos_> yep - MAX_PID_OUTPUT was left untouched
[08:12:30] <alex_joni> nice
[08:12:32] <SWPadnos_> alex - looking at your changes, is there a reason for only checking the first 10 chars of the nmlfile name?
[08:12:44] <alex_joni> oh.. that was a paranoid check
[08:12:52] <alex_joni> had some segfaults I fought with
[08:13:02] <alex_joni> and that wasn't the cause, just made it 10 to be sure
[08:13:08] <alex_joni> forgot to put it back afterwards
[08:13:16] <SWPadnos_> does that include the path, or just the name?
[08:13:19] <rayh_ppmc_usc> I emptied ppmc.ini and shutdown and nothing came back.
[08:13:31] <SWPadnos_> oops ;)
[08:13:39] <rayh_ppmc_usc> i had a backup
[08:13:44] <SWPadnos_> phew
[08:13:47] <alex_joni> rayh_ppmc_usc: I think the shutdown procedure looks at the file and changes the stuff there
[08:14:06] <rayh_ppmc_usc> so if we don't need a variable and leave it out then it should not come back.
[08:14:34] <SWPadnos_> only the variables that emc uses, and which have changed. are written
[08:14:42] <rayh_ppmc_usc> unless there are some trip wires in that write routine that we don't know about
[08:15:07] <SWPadnos_> I suspect that it does an inifind on any variable, and if it isn't found, it doesn't write it
[08:15:27] <SWPadnos_> otherwise you'd end up with a pretty big file after the first run
[08:15:45] <SWPadnos_> (plus, if the var isn't there, it must be at default, and you can't check for differences)
[08:16:00] <rayh_ppmc_usc> I used to make them read only but I think nowadays they change the file permissions
[08:16:37] <rayh_ppmc_usc> gotta get to town.
[08:16:48] <SWPadnos_> there's an interesting (related) feature of KDE that I was reading about recently
[08:17:08] <SWPadnos_> also related to the ebo mail
[08:17:39] <SWPadnos_> they have the ability to read a series of config files, and overwrite settings from successive files (like ebo suggested)
[08:18:18] <SWPadnos_> but you can also put a [$i] in any of the earlier files, to make parameters (or whole sections, or entire files) "immutable" - so the user can't override those parts
[08:18:44] <SWPadnos_> it's pretty slick
[08:19:19] <alex_joni> nice
[08:19:37] <SWPadnos_> it's a little elss applicable here, but still a useful concept
[08:20:14] <SWPadnos_> the integrator can make emc.ini have some sane defaults, and mark some as unchangeable (like max_velocity ;) )
[08:20:23] <alex_joni> yeah..
[08:20:29] <SWPadnos_> but there can be other setups that override other things
[08:20:31] <alex_joni> yeah = usefull concept
[08:20:42] <alex_joni> like GUI
[08:20:46] <SWPadnos_> (user foo is an idiot, so use the simplest GUI available)
[08:20:49] <SWPadnos_> yep ;)
[08:21:12] <alex_joni> you know that it will be a pita to look for the .nml and .var files ;)
[08:21:23] <alex_joni> would only work if you use absolute pathnames
[08:21:41] <alex_joni> say you have a default ini / system
[08:21:43] <SWPadnos_> hm - for the config subdir thing?
[08:21:52] <alex_joni> for the multiple configs stuff
[08:21:56] <SWPadnos_> ok
[08:22:02] <alex_joni> like ebo said
[08:22:12] <alex_joni> and like you said
[08:22:14] <rayh_ppmc_usc> Catch you guys later. Thanks for the fun. Signed user foo.
[08:22:19] <SWPadnos_> sure - there's a config file "search path"
[08:22:22] <alex_joni> bye foo
[08:22:26] <SWPadnos_> see ya foo-bar ;)
[08:22:32] <alex_joni> bar-baz
[08:22:43] <SWPadnos_> bar != baz
[08:22:52] <alex_joni> bar-baz!=0
[08:23:01] <SWPadnos_> fubar != pebcak
[08:23:03] <alex_joni> proven my case ;)
[08:23:20] <alex_joni> if bar!=baz then bar-baz exists
[08:23:29] <SWPadnos_> bar - baz always exists
[08:23:37] <SWPadnos_> given that bar and baz exist
[08:23:39] <alex_joni> :P
[08:23:48] <alex_joni> ok.. back to configs
[08:23:50] <SWPadnos_> I could write that in logic notation if you like ;)
[08:23:55] <SWPadnos_> ok
[08:24:14] <SWPadnos_> you write - I'll make some oatmeal and read in a minute :)
[08:24:24] <alex_joni> I'll wait
[08:24:33] <alex_joni> wanted to ask you about the mail I sent you..
[08:27:23] <SWPadnos_> ok
[08:27:39] <SWPadnos_> (hm - 3 minutes - I must be getting old)
[08:28:04] <alex_joni> for the oatmail
[08:28:08] <alex_joni> ?
[08:28:14] <SWPadnos_> bathroom / coffee / oatmeal
[08:28:19] <alex_joni> heh
[08:28:29] <SWPadnos_> parallel processing
[08:28:42] <alex_joni> lol
[08:28:52] <alex_joni> hope you don't mix those ... ROFL
[08:29:02] <alex_joni> accidently
[08:29:04] <SWPadnos_> nope - separate process spaces
[08:29:11] <SWPadnos_> protected OS
[08:29:17] <alex_joni> make a list for when you're older
[08:29:23] <alex_joni> really old
[08:29:31] <SWPadnos_> heh
[08:29:37] <SWPadnos_> so - back to the email ... :)
[08:30:09] <alex_joni> yes
[08:31:04] <SWPadnos_> I'd say that the need for separate NML file directories is small (basically nonexistent)
[08:31:09] <alex_joni> would the scenario described there be ok?
[08:31:28] <SWPadnos_> having a few nml files in one directory is sufficient
[08:31:28] <alex_joni> SWPadnos_: yeah, and the subdirs might just reference as ../emc.nml
[08:31:36] <alex_joni> then all those changes are not needed
[08:31:42] <alex_joni> s/all/most
[08:31:52] <SWPadnos_> yep - as long as relative paths are allowed in the ini file, I think we're covered
[08:32:23] <alex_joni> they are, and work ok
[08:32:30] <SWPadnos_> the path can be expanded, so that an absolute name is handed to the NML code
[08:32:33] <SWPadnos_> yep
[08:32:56] <alex_joni> one of the changes for make install was running from the dir where the config file is
[08:32:58] <SWPadnos_> if relative paths work for the HALFILE entries, then that's covered as well
[08:33:18] <alex_joni> yeah.. but look at the changes of emc.run
[08:33:46] <alex_joni> I look in the dir where the ini is for .hal files, but also in the original config dir
[08:34:08] <alex_joni> so common stuff (core_servo , core_stepper , classicladder , etc) can stay in emc2/configs/
[08:35:00] <SWPadnos_> I'm not sure if I like the "automagic" nature of that - all it saves you is ../core_servo.hal in the ini file
[08:35:17] <alex_joni> yes
[08:35:19] <SWPadnos_> I think it's the thing that cradek was talking about
[08:35:39] <SWPadnos_> just lt you specify all those files relative to the location of the ini, and it's all good
[08:35:45] <SWPadnos_> s/lt/let/
[08:35:52] <alex_joni> that works as it is now ;)
[08:36:04] <SWPadnos_> then your work is done ;)
[08:36:17] <alex_joni> there is still need to move the configs around
[08:36:35] <SWPadnos_> for the nmlfile, I'd use the default dir, unless the person specifies ./yaddayadda.nml
[08:37:03] <SWPadnos_> actually - that would work for the others as well - assume default dir unless a path is specified
[08:37:12] <SWPadnos_> with ./ being a valid path
[08:37:28] <alex_joni> say again please
[08:37:44] <SWPadnos_> well - the nml file is unlikely to change
[08:37:57] <alex_joni> right.. that's why I wanted that to be in the configs/ topdir
[08:38:00] <SWPadnos_> so I thought that it should be takes from the default config dir
[08:38:06] <SWPadnos_> taken
[08:38:14] <alex_joni> yes.. but that can be done in 2 ways:
[08:38:18] <SWPadnos_> but, you still should be able to specify a different one
[08:38:21] <alex_joni> 1. use ../emc.nml in your ini
[08:38:32] <alex_joni> 2. take over the changes I did
[08:38:50] <alex_joni> ahh.. you want to hardcode it inside emc2?
[08:38:53] <alex_joni> the default value?
[08:38:55] <SWPadnos_> no
[08:39:06] <alex_joni> so only change it if needed?
[08:39:30] <SWPadnos_> I think we're saying the same thing, it 's just a question of how the decision is made to take the file from a different dir
[08:39:46] <SWPadnos_> and the easiest way would be just like bash does it
[08:39:56] <alex_joni> the problem is that you've got 3 or 4 software components that do that
[08:40:01] <SWPadnos_> if you type "foo" - bash searches the path for foo
[08:40:03] <alex_joni> taking the nml file out of the ini
[08:40:07] <SWPadnos_> if you type ./foo, it doesn't
[08:40:29] <SWPadnos_> so you can explicitly override default behavior very easily
[08:40:41] <alex_joni> GUI (aka emcsh, or AXIS, or xemc..), IO (aka ioControl.cc), TASK (aka emctaskmain.cc)
[08:40:50] <alex_joni> and emc.run
[08:41:40] <SWPadnos_> I guess the question is just what the "search order" is
[08:41:53] <alex_joni> you're not hearing me ;)
[08:41:57] <alex_joni> bear with me for a while
[08:41:58] <SWPadnos_> could be
[08:42:03] <alex_joni> lets take IO
[08:42:05] <SWPadnos_> bearing ;)
[08:42:13] <alex_joni> IO needs to talk to task, right?
[08:42:29] <alex_joni> therefor it needs to open some NML channels (or listen to some)
[08:42:30] <SWPadnos_> sure -I understand that all processes need to be looking at the same NML file
[08:42:41] <alex_joni> ok.. now how is this done:
[08:43:07] <alex_joni> 1. there is a function emcGetArgs() that's called, and looks for args to the program
[08:43:18] <alex_joni> searches for -ini & the like
[08:43:39] <alex_joni> next there is a function called iniLoad() usually, which reads the ini for values it needs
[08:44:13] <alex_joni> if it finds a NML_FILE reference it replaces the DEFAULT_NML_FILENAME with it
[08:44:20] <alex_joni> then tries to read it
[08:44:38] <alex_joni> but the programs get executed from the directory where the ini is
[08:45:20] <SWPadnos_> yep - and all of those programs have to either (a) have the same complete file path specified, or (b) use the identical default behavior
[08:45:33] <SWPadnos_> (or (c) have an environment var)
[08:45:37] <alex_joni> c is bad
[08:45:44] <SWPadnos_> yes
[08:45:59] <alex_joni> a is bad too, because you can't have absolute paths in the ini
[08:46:16] <SWPadnos_> hmmm - well that leaves ...
[08:46:21] <SWPadnos_> B!!!
[08:46:27] <alex_joni> ok.. how do you mean b?
[08:46:40] <alex_joni> say you have emc.nml in the ini
[08:46:53] <alex_joni> you try to open in the same dir, and that fails
[08:46:59] <alex_joni> what will you do?
[08:47:11] <SWPadnos_> all programs that use the nmlfile have to search the same paths, in the same order, to find the nml file
[08:48:06] <alex_joni> which paths?
[08:48:19] <SWPadnos_> that's what we're trying to decide ;)
[08:48:20] <alex_joni> you don't know where you are..
[08:48:36] <alex_joni> probably should issue a pwd first, then try to see
[08:48:42] <alex_joni> but that's just as bad :(
[08:48:53] <SWPadnos_> sure you do - $0 is the executable name with full path, no
[08:49:30] <alex_joni> in ioControl.cc ?
[08:49:40] <SWPadnos_> yep - it should be the first arg
[08:49:43] <alex_joni> not scripts..
[08:49:44] <SWPadnos_> argv[0]
[08:49:55] <alex_joni> humm.. with full path? don't think so
[08:50:03] <SWPadnos_> I'm not sure about that either
[08:50:15] <SWPadnos_> but a pwd is also workable
[08:51:04] <SWPadnos_> ok - scripts don't get the full path - bummer
[08:51:23] <alex_joni> scripts don't need it
[08:51:25] <alex_joni> they know it
[08:51:35] <alex_joni> or better said they decide it based on where the ini is
[08:51:40] <SWPadnos_> ok
[08:51:41] <cradek> $0/argv[0] is the name the program was invoked as
[08:52:03] <SWPadnos_> ok - thanks (saves me from writing a "hello argv[0] program")
[08:52:28] <alex_joni> so it should have the full path
[08:52:36] <cradek> only if you ran /the/full/path/program
[08:52:37] <alex_joni> emc.run executes everything with full paths
[08:52:42] <alex_joni> yes
[08:52:51] <alex_joni> ;-) (at least it does now)
[08:53:21] <alex_joni> SWPadnos_: I am thinking this is complicating it too much
[08:53:39] <alex_joni> how about we have (by agreement) the default nml in configs/emc.nml
[08:53:48] <alex_joni> and all ini's are in configs/foo/ dirs
[08:53:50] <SWPadnos_> yeah - as long as the system works from emc.run, and you can specify both absolute and relative paths, I think that's enough
[08:54:05] <alex_joni> and reference that nml file by ../emc.nml
[08:54:24] <SWPadnos_> I think the config should work from configs/ as well
[08:54:24] <alex_joni> actually you don't need to do that, we could have DEFAULT_EMC_NMLFILE = "../emc.nml"
[08:54:48] <alex_joni> config would work, if you have a NML_FILE=emc.nml in it
[08:55:02] <SWPadnos_> unless there's a "configs/sample" or "configs/default" dir
[08:55:18] <SWPadnos_> yesp
[08:55:19] <alex_joni> in there you would either have a). no NML_FILE at all
[08:55:27] <alex_joni> or b). one that reads ../emc.nml
[08:56:52] <SWPadnos_> ah - OK. DEFAULT_NML_FILE (../nmlfile) is in scripts.run, and is overridden by an ini setting NMLFILE, if present
[08:58:40] <alex_joni> well not in scripts.run, actually inside emc (emc2/src/emc/nml_intf/emccfg.h) but you get the picture
[08:59:04] <alex_joni> right now the NML_FILE in the ini might be missing
[08:59:20] <alex_joni> components using that will try the default value before giving up
[08:59:21] <SWPadnos_> emc.run I meant. I'd think that the same thing would be needed in both the run script and the header file
[08:59:44] <SWPadnos_> so that programs use the same defaults as the script
[08:59:55] <alex_joni> the script doesn't use the nml file
[09:00:08] <SWPadnos_> it does specify it though, right?
[09:00:13] <alex_joni> the changes you've seen to the script are only to pass the nml file as an argument to the files
[09:00:19] <alex_joni> to be able to find them easier
[09:00:33] <SWPadnos_> ah - OK.
[09:01:09] <alex_joni> so I did the NML search in the emc.run script, then passed the absolute path to it as a -nml parameter to all parties involved
[09:01:16] <alex_joni> except AXIS.. didn't touch that
[09:01:18] <SWPadnos_> phone
[09:02:07] <alex_joni> ET phone.. swampy
[09:07:04] <SWPadnos_> ok - back
[09:37:10] <alex_joni> right..
[09:37:11] <alex_joni> missed that :(
[09:37:29] <SWPadnos_> heh - it's midnight - you should go to sleep ;)
[09:37:34] <alex_joni> passing the nml file seemed like a good way
[09:37:48] <SWPadnos_> yep - I agree
[09:38:15] <SWPadnos_> the only thing that happens is that you can't run the programs "manually" and expect them to find the same file (but I can live with that)
[09:38:27] <alex_joni> right
[09:40:32] <alex_joni> well.. seems afterall you agree with my changes ;)
[09:40:47] <SWPadnos_> I think so
[09:41:11] <SWPadnos_> I just didn't understand them at first (I'm not so used to the cvs diff format, or shell scripting in general ;) )
[09:41:51] <alex_joni> well.. I was a bit worried about changing functionality without talking to others ;)
[09:42:13] <SWPadnos_> that is a concern
[09:42:23] <SWPadnos_> I agree partly because I have no stake in how it works now ;)
[09:42:26] <alex_joni> well.. functionality isn't changed
[09:42:37] <alex_joni> mostly the way things get passed
[09:44:44] <alex_joni> anyways.. guess I'll bring it up on sunday
[09:44:57] <SWPadnos_> probably a good plan
[09:45:07] <alex_joni> or maybe on the dev list
[09:45:38] <SWPadnos_> yeah - that would give people a chance to look over the changes before discussing them on Sunday
[10:00:58] <alex_joni> guess I'll do that tomorrow
[10:01:01] <alex_joni> gone to bed now
[10:01:03] <alex_joni> night
[10:01:17] <SWPadnos_> ok - night
[11:26:23] <SWPadnos_> hey there, jmk
[11:26:29] <jmkasunich> hi
[11:26:47] <jmkasunich> its friday!
[11:26:54] <jmkasunich> (i get to sleep in tomorrow ;-)
[11:26:57] <SWPadnos_> woohoo - you can stay up as late as you want!! ;)
[11:27:20] <jmkasunich> not really, I have to sleep in just to catch up from all the other staying up late
[11:27:37] <SWPadnos_> heh
[11:28:02] <jmkasunich> you and pete are terrible when it comes to keeping me up late
[11:28:47] <SWPadnos_> we try ;)
[11:28:54] <jmkasunich> you succeed
[11:29:10] <jmkasunich> pete especially - he has an unfair advantage
[11:29:12] <SWPadnos_> check the logs on this channel for a nice discussion I had with Ray today ;)
[11:29:29] <jmkasunich> logger_devel: bookmark?
[11:29:29] <jmkasunich> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-02#T11-29-29
[11:30:06] <SWPadnos_> we overlooked the obvious in our discussions with skunkworks re: pid headroom
[11:30:20] <jmkasunich> what is that?
[11:30:25] <SWPadnos_> all we have to do is make a new [AXIS_n] var, called PID_MAXOUTPUT
[11:30:44] <SWPadnos_> just because emc1 dodn't have it doesn't mean that emc2 can't
[11:30:48] <SWPadnos_> didn't
[11:31:49] <jmkasunich> do you mean the axix.<number>.whatever HAL pins from the motion module?
[11:32:13] <SWPadnos_> no - since PID needs a little extra room (over the MAX_VELOCITY), make a new var in the ini
[11:32:27] <SWPadnos_> and assign that to pid.maxoutput and stepgen.maxoutput
[11:32:38] <jmkasunich> could do that
[11:32:44] <jmkasunich> why not use MAX_OUTPUT
[11:33:01] <jmkasunich> (I think that's what Ray suggested, just starting to read the log)
[11:33:05] <SWPadnos_> because then we'd have to have formulas, or PID won't be able to catch up to step inputs
[11:33:29] <SWPadnos_> so you lower max_output a little, or add a little to PID_MAX
[11:33:57] <jmkasunich> I don't think anybody is using MAX_OUTUT right now
[11:34:40] <SWPadnos_> well - I added it to the core_servo.hal file, and I thought that motion used it
[11:34:55] <jmkasunich> motion doesn't (I don't think)
[11:35:20] <jmkasunich> the path from ini file to motion is convoluted... would take some checking to confirm that
[11:35:23] <SWPadnos_> I was probably looking at it like an emc1 parameter ;)
[11:35:34] <SWPadnos_> I kjnow it used to be used there
[11:36:36] <jmkasunich> it used to limit the PID output, back when the PID was integrated with the motion module
[11:36:51] <jmkasunich> now I'm almost certain the motion module doesn't use it at all
[11:37:06] <jmkasunich> easy test: hack the hal file so the PID limits are fixed at whatever works
[11:37:17] <jmkasunich> then change the ini MAX_OUTPUT to 0
[11:37:29] <SWPadnos_> ok - I'm thinking of max_velocity, not max_output - that's what I made core_servo use
[11:38:12] <SWPadnos_> also, the PID (and possibly the various output drivers) should be able to have asymmetric limits
[11:38:45] <jmkasunich> perhaps, but that is rather specialized
[11:39:08] <jmkasunich> note: there is a HAL limit block, that lets you independently set min and max
[11:39:14] <SWPadnos_> true
[11:39:31] <SWPadnos_> though a Z axis could easily have different parameters going down vs. up
[11:39:38] <SWPadnos_> PIDFF, limits, accel, etc.
[11:40:05] <jmkasunich> the emc1 PID had a bias parameter for that kind of thing
[11:40:17] <jmkasunich> I don't recall if the HAL PID has the same
[11:40:23] <jmkasunich> could certainly be added if not
[11:40:34] <SWPadnos_> I think it does, come to think of it
[11:41:20] <SWPadnos_> yep - it's there
[11:59:59] <jmkasunich> wow, alex seems to be making this ini file thing a lot harder than it has to be
[12:00:24] <SWPadnos_> could be
[12:00:34] <jmkasunich> use the directory that contains the ini file as the current directory, paths contained within the ini file are relative to that
[12:00:36] <jmkasunich> simple
[12:00:56] <jmkasunich> you want to use the generic .nml file, say ../emc.nml in the ini
[12:01:07] <SWPadnos_> it's a matter of making all of the programs that use the NML file do that as well
[12:01:33] <SWPadnos_> (which includes all of the UIs)
[12:02:17] <jmkasunich> don't all the various binaries get the path to the ini from a command line arg?
[12:02:48] <SWPadnos_> yes, and also the location of the NML file, in a patch that Alex is testing
[12:03:24] <SWPadnos_> but he had to change emcsh.cc, emctaskmain.cc, ... to do it
[12:03:51] <jmkasunich> oh
[12:03:59] <jmkasunich> I know what to do!
[12:04:02] <SWPadnos_> emcargs.cc, iocontrol.cc
[12:04:09] <jmkasunich> get rid of NML ;-)
[12:04:12] <SWPadnos_> and he left out axis
[12:04:19] <SWPadnos_> hey - that's a good idea
[12:04:28] <SWPadnos_> and you can sleep in tomorrow! ;)
[12:04:29] <jmkasunich> lol
[12:05:25] <jmkasunich> actually, I'm planning on throwing together a preliminary version of halvcp tonight
[12:05:30] <jmkasunich> (if pete doesn't show up ;-)
[12:05:43] <SWPadnos_> maybe you should just leave the two emc channels ;)
[12:06:07] <jmkasunich> three actually, I'm also on the board channel
[12:06:13] <SWPadnos_> is pete?
[12:06:18] <jmkasunich> no
[12:06:23] <SWPadnos_> well - there you go ;)
[12:06:27] <jmkasunich> its only 4:30 out there
[12:06:57] <SWPadnos_> at least it would make it slightly harder to distract you from coding all night
[12:07:04] <jmkasunich> yeah
[12:07:15] <jmkasunich> but I've enjoyed the distractions
[12:07:34] <jmkasunich> there are few folks who really talk about these kind of details
[12:07:43] <SWPadnos_> true
[12:08:09] <SWPadnos_> it's nice to have conversations where people aren't saying "this is how it's done, you have to make it the same"
[12:08:26] <jmkasunich> that's probably a big part of it
[12:12:52] <jmkasunich> * jmkasunich hides
[12:13:08] <SWPadnos_> heh
[12:13:10] <petev> u don't want to eal with threading?
[12:13:15] <petev> eal/deal
[12:13:29] <jmkasunich> actually I do...
[12:13:36] <jmkasunich> just not until 2am ;-)
[12:13:42] <petev> I have any idea to do it easy in the HAL
[12:14:08] <petev> I think we could mod the HAL gearing comp and add a few pins to motion
[12:14:34] <petev> if the gearing would take a start count value for lock up, it should be pretty straight forward
[12:14:49] <petev> take z out of coordinated mode, hit the lock pin
[12:15:03] <petev> what do you think?
[12:15:16] <jmkasunich> I dunno
[12:15:26] <jmkasunich> it might work for rigid tapping
[12:15:31] <petev> do u think TP or HAL for starters?
[12:15:38] <jmkasunich> single point threading is more complex
[12:15:47] <petev> huh?
[12:15:49] <jmkasunich> I was thinking inside EMC proper, not in hal
[12:15:58] <petev> single piont threading doesn't nead gearing
[12:16:20] <jmkasunich> how else do you get the pitch you want?
[12:16:36] <petev> it's just a helical move
[12:16:46] <petev> doesn't have to be geared to spindle speed
[12:16:55] <jmkasunich> only if you have a servomotor on the spindle and treat it as a position controlled axis
[12:17:00] <petev> circle in x,y, linear in z
[12:17:01] <jmkasunich> that is not the norm
[12:17:17] <jmkasunich> now I'm saying huh
[12:17:38] <jmkasunich> I'm talking about single point threading on a lathe
[12:17:40] <SWPadnos_> threadmilling works that way - with helical moves
[12:17:45] <petev> with single point, the cutter only has a little point, it spins much faster than a tap would
[12:18:04] <petev> oh, I was still on a mill
[12:18:06] <jmkasunich> no, with single point, the cutter is mounted in the lathe toolpost and spins not at all ;-)
[12:18:19] <petev> single point on a lathe is the same as rigid tappin on the mill
[12:18:26] <jmkasunich> not quite
[12:18:31] <jmkasunich> multiple passes, for one thing
[12:18:33] <petev> why?
[12:18:38] <petev> ok
[12:18:55] <petev> but each pass is the same
[12:18:55] <jmkasunich> tapping doesn;t need an index pulse on the spindle encoder
[12:19:03] <jmkasunich> multipass threading does
[12:19:15] <SWPadnos_> actually, the passes are slightly different
[12:19:17] <jmkasunich> also, threading might involve more than just moving Z
[12:19:22] <petev> u don't need an index, just the start count like I mentioned
[12:19:26] <SWPadnos_> you offset by a little to increase the depth of cut
[12:19:28] <jmkasunich> tapered threads for instance
[12:19:56] <petev> so u want to gear multiple axis to spindle speed on the lathe then?
[12:20:01] <SWPadnos_> yes
[12:20:05] <jmkasunich> and if you are threading to a shoulder, you want to pull the tool out as you finish the pass
[12:20:20] <SWPadnos_> NPT threads are tapered, for example
[12:20:39] <petev> each axis could have a gear module
[12:20:56] <petev> what are the trade offs for TP vs HAL?
[12:21:14] <jmkasunich> it seems pretty specialized for HAL
[12:21:20] <petev> I see HAL as keeping things tighter, but probably limited to linear gearing
[12:21:53] <jmkasunich> the TP still has to be aware of what is going on...
[12:22:32] <petev> shouldn't it just be happy with the position feedback it see?
[12:23:01] <jmkasunich> the way I see it, a threading (or tapping) pass is an ordinary coordinated move, but instead of using time as the independent variable, it uses spindle position
[12:23:03] <petev> does the TP even look at the following error, or is that servo only?
[12:23:30] <petev> do u think the error will be acceptable that way?
[12:23:49] <SWPadnos_> the TP always uses position feedback
[12:23:50] <petev> certainly won't be good enough for gear hobbing stuff
[12:24:05] <SWPadnos_> it just gets it as steps generated for stepper machines
[12:24:40] <petev> swp: I thought from yesterday, the TP was just assumeing things went where it said to?
[12:25:01] <jmkasunich> yes and no :-/
[12:25:28] <SWPadnos_> right - sorry ;)
[12:25:37] <petev> jmk: what's the no part?
[12:25:41] <SWPadnos_> (I told you I'd forget 90% by today)
[12:25:46] <jmkasunich> emc looks at the feedback, for purposes of following error detection
[12:26:00] <jmkasunich> it also uses feedback when stopped, to set the command when it starts again
[12:26:02] <petev> right, but that's just for error, correct?
[12:26:04] <SWPadnos_> rihgt - the TP is too slow to be able to use it
[12:26:08] <jmkasunich> "stopped" = motion disabled
[12:26:23] <jmkasunich> yes, not for control
[12:26:27] <petev> so if gearing works, the TP should be happy with no error
[12:26:47] <jmkasunich> I guess I don't get what you are porposing
[12:26:50] <jmkasunich> proposing
[12:27:07] <petev> I was just thinking about putting gearing modules on the axis in HAL
[12:27:30] <petev> if we mod the gear module to take a start count, we can start the same relative to the spindle each time
[12:27:42] <jmkasunich> so you essentially disconnect an axis from the motmod axis.0.position-cmd output, and drive it from the gearing module instead
[12:27:48] <petev> yes
[12:28:00] <petev> and motion gives the start count and lock gear pin
[12:28:00] <SWPadnos_> the trouble is that there are sometimes lead-in and trail-out moves
[12:28:16] <jmkasunich> once its disconnected, TP has no idea what is going on
[12:28:27] <SWPadnos_> you would have to blend the lead-in with the "geared" output over time
[12:28:58] <SWPadnos_> (note: I proposed this idea at Fest, and was met with these concerns ;) )
[12:29:43] <SWPadnos_> you can almost do gearing just by using a PID module
[12:29:53] <petev> what are the various lead in going to look like?
[12:29:55] <jmkasunich> I don't have concrete facts yet, but I feel that threading/tapping is a machine tool operation, and should be handled by the machine tool oriented part of the SW, not the generic part
[12:29:59] <petev> swp: yes
[12:30:01] <SWPadnos_> (or the scale block)
[12:30:30] <petev> for ridgid tapping, lead in could be handled by adjusting spidle speed
[12:30:39] <SWPadnos_> It probably needs to be part of the interpolator
[12:30:44] <petev> for a lathe, I'm not sure what it looks like
[12:30:50] <jmkasunich> I think rigid tapping doesn't use leadin
[12:30:53] <petev> I always start from a groove
[12:31:06] <jmkasunich> and finish in one too?
[12:31:07] <petev> jmk: I don't use it on my machine
[12:31:07] <SWPadnos_> for the reason that John mentioned - it changes the independent variable away from "time"
[12:31:30] <petev> jmk: finish in groove or off end of part
[12:32:10] <jmkasunich> off end of part usually only happens with left-hand threads (unless you run the spindle backwards and put the tool either upside down or behind the work)
[12:32:29] <jmkasunich> but both lead-in and lead-out are issues
[12:32:30] <petev> yes, and right hand start off end and end in groove
[12:32:36] <SWPadnos_> the issue is, how does the TP handle that - there's no longer a 1:1 (or 10:1) ratio of poses vs servo cycles, since the completion rate of successive poses is locked to the spindle
[12:32:48] <petev> so what do the lead in/out moves look like?
[12:32:58] <jmkasunich> depends on the shape of the thread
[12:33:17] <jmkasunich> does your lathe have a threaded spindle nose?
[12:33:28] <petev> for a normal thread, I'm having trouble seeing how leadin is anything but slower speed
[12:33:43] <petev> my lathe is d1-4 cam lock
[12:33:49] <jmkasunich> ok, that won't help...
[12:33:51] <petev> I can thread either way
[12:34:02] <jmkasunich> lathe spindle nose threads don't end in a groove
[12:34:08] <SWPadnos_> hm - what if motion had an input that could change the increment to the spline independent variable (away from servo period / TP period)?
[12:34:23] <jmkasunich> they just smoothly retract the tool, the thread gets shallower and disappears over perhaps half a turn
[12:34:27] <jmkasunich> that is lead out
[12:34:29] <petev> oh, so you are saying the thread fades out at the beginning or end?
[12:34:40] <petev> ok, got it
[12:34:43] <jmkasunich> its a right angles to the centerline of the part
[12:35:11] <petev> sure, but that seems like a coordinated move on x with gearing on Z
[12:35:16] <petev> seems easy
[12:35:27] <jmkasunich> you probably don't need lead in and lead out on the same part, but they are kinda equivalent
[12:35:36] <petev> sure
[12:35:46] <jmkasunich> the X move has to be synced with the spindle too
[12:36:00] <petev> not as much as Z
[12:36:08] <jmkasunich> yes it does
[12:36:18] <petev> I think more error in X is acceptable
[12:36:24] <jmkasunich> say X pulls out over half a revolution
[12:36:33] <petev> ok
[12:37:01] <jmkasunich> if you are nearly done (last few passes) and you start the pullout a few degrees of spindle rotation late, that pass is gonna dig in
[12:37:35] <petev> yeah, but that seems like TP speed stuff and it will only take a little heavy or light cut
[12:37:48] <petev> if Z messes up, your threads are wavy
[12:38:20] <jmkasunich> they're both important
[12:38:49] <jmkasunich> anyway, lets think about the toolpath
[12:38:53] <petev> ok
[12:39:16] <jmkasunich> assume for now, a right hand thread, normal rotation, starting off in the air past the end of the part, and finishing near a shoulder
[12:39:25] <petev> ok
[12:39:35] <jmkasunich> initially, part is spinning, tool is sitting still, a little past the end of the part
[12:39:42] <petev> yep
[12:40:04] <jmkasunich> at some point (probably based on index pulse) we say GO!
[12:40:12] <petev> or some count
[12:40:41] <petev> but I think we say go and the gear comp syncs to the count if we use HAL
[12:40:42] <jmkasunich> the position command for Z immediately begins to go left, at a rate dependent on spindle speed
[12:40:51] <petev> ok
[12:41:14] <jmkasunich> first problem is that the commanded speed just went from zero to something without any accel
[12:41:36] <jmkasunich> so the axis is gonna fall behind and take some time to catch up and settle out
[12:41:41] <petev> there are limit in PID, no?
[12:41:52] <petev> yes, agreed
[12:42:06] <petev> but we're still in air
[12:42:12] <jmkasunich> so the initial position needs to be far enough out in the air to allow for that
[12:42:18] <petev> yes
[12:42:33] <jmkasunich> could be a problem if we were doing left hand and starting at the shoulder
[12:42:49] <jmkasunich> anyway, lets keep going
[12:42:55] <petev> ok
[12:43:04] <jmkasunich> Z stabilises, tracking the spindle, the cut begins
[12:43:11] <petev> yep
[12:43:15] <jmkasunich> if the cutting load slows down the spindle, Z tracks it
[12:43:20] <petev> yes
[12:43:30] <jmkasunich> say we're cutting a 1" long thread
[12:43:35] <petev> ok
[12:43:36] <jmkasunich> after 1", now what?
[12:43:45] <jmkasunich> we keep Z moving, and retract X
[12:43:56] <petev> if you want lead out, you start a coordinated move on X
[12:44:07] <petev> when out enough, motion dissables the gearing
[12:44:21] <petev> changes Z back to coordinated
[12:44:24] <petev> and carries on
[12:44:38] <petev> if you have a groove, no problems
[12:44:41] <jmkasunich> so you're gearing Z to spindle but not X
[12:44:50] <petev> just stop gearing and switch to coordinated
[12:44:59] <petev> yes, Z, not X
[12:45:08] <jmkasunich> true, as long as the groove is wide enough for the decel of Z
[12:45:23] <SWPadnos_> X can be geared, but only if the ratio is 0 for the bulk of the threading move
[12:45:27] <petev> that always is the case
[12:45:37] <petev> you can always slow the spindle near the end
[12:45:52] <SWPadnos_> no you can't - you don't necessarily have control of spindle speed
[12:46:04] <petev> swp: I think you gear x for tapered threads
[12:46:29] <SWPadnos_> well - you can leave X geared to the spindle, but change the gear ratio during the threading pass
[12:46:29] <petev> if you don't have spindle control, then there is nothing u can do regardless if the groove is too small
[12:46:46] <SWPadnos_> yes - if you have spindle feedback, then you're all set
[12:47:02] <petev> no, jmk says groove is too small for decel of machine
[12:47:05] <SWPadnos_> that's why you do gearing, rather than a coordinated move that includes the spindle
[12:47:16] <petev> then you have a problem if you cant change spindle speed
[12:47:40] <petev> swp: the assumpting was acel/decel too high with small groove
[12:47:45] <petev> assumption
[12:47:47] <SWPadnos_> you may be able to change the spindle speed, but the time constant will be huge, I think
[12:47:55] <SWPadnos_> ok
[12:48:06] <petev> ok, let's go on
[12:48:18] <petev> jmk: how do you compare this to TP gearing?
[12:48:49] <jmkasunich> sorry, was answering a call of nature ;-)
[12:48:52] <jmkasunich> * jmkasunich reads back
[12:49:00] <SWPadnos_> don't foget the oatmeal
[12:49:03] <SWPadnos_> forget
[12:49:33] <jmkasunich> heh
[12:50:04] <jmkasunich> I wasn't saying the groove was too narrow, I was saying it better not be to narrow
[12:50:51] <jmkasunich> but lets not talk about the groove case, lets talk about the pullout case
[12:51:05] <jmkasunich> the tool path isn't straight
[12:51:33] <SWPadnos_> that's OK, if something (motion) can change the gear ratios on the fly
[12:51:40] <jmkasunich> first it moves parallel to the part, then it turns - simplest approach would be a 45 degree bend to pull out
[12:52:19] <jmkasunich> but realistically it would be an arc, that starts tangent to Z and does a hard left
[12:52:29] <petev> yes
[12:52:33] <jmkasunich> (as viewed from the tailstock)
[12:53:16] <jmkasunich> now why can't we just program that toolpath (line followed by arc) and then follow it at a rate determined by spindle speed instead of clock time?
[12:53:37] <jmkasunich> that concept allows you to do all kind of things
[12:53:41] <petev> but this will be at TP rate, no?
[12:53:53] <jmkasunich> like tapered threads, (just program an angled line for the first part)
[12:54:00] <jmkasunich> ignore rates for the moment
[12:54:10] <SWPadnos_> see my previous suggestion regarding changing the rate that the independent variable is incremented in the interpolator
[12:54:15] <petev> hard to do as that was the motivation for HAL
[12:54:16] <jmkasunich> right
[12:54:40] <jmkasunich> right to swp, what? to pete about hal motivation ;-)
[12:54:56] <SWPadnos_> the only difficulty being that some axes may not want to be geared (most notably the spindle, if it's an axis)
[12:55:28] <petev> I see gearing on a per axis basis, not all or none
[12:55:39] <petev> in fact I thought only on Z would work
[12:55:40] <jmkasunich> I don't like the idea of gearing
[12:55:56] <petev> ok
[12:55:57] <jmkasunich> I want to be able to program an arbitrary toolpath
[12:56:09] <jmkasunich> then run that path at a speed determined by the spindle
[12:56:18] <jmkasunich> instead of by the clock
[12:56:30] <petev> ok, so how do we run the interpolator at various times based on spindle count?
[12:56:44] <SWPadnos_> that's actually useful for non-threading apps, such as removing material at a constant rate
[12:56:51] <petev> yes
[12:57:01] <petev> but I don't see the implementation
[12:57:11] <jmkasunich> yeah, where you change spindle speed as the diameter changes, but maintain constant feed per rev
[12:57:19] <SWPadnos_> yep
[12:57:21] <SWPadnos_> there are two things that have to be done
[12:57:25] <SWPadnos_> (at least ;) )
[12:57:46] <SWPadnos_> one: make the spline calculation rate variable - that's pretty easy
[12:57:53] <jmkasunich> it goes back to the TP (the overall thing, not just the slow thread that EMC calls the TP)
[12:57:54] <petev> don't follow
[12:58:16] <petev> swp: I would think that spindle count would take the place of time
[12:58:18] <jmkasunich> TP input, a path, defined in mathematical terms
[12:58:23] <jmkasunich> TP output, samples on that path
[12:58:24] <SWPadnos_> two: make sure that there aren't any nasty problems if the interpolator isn't executing TP poses at the expected rate of exactly one per TP cycle
[12:58:37] <petev> jmk: yes
[12:59:02] <SWPadnos_> yes - spindle speed would take the place of time, but that means that there needs to be a way of dynamically changing this value
[12:59:08] <jmkasunich> SWP: can we pretend for an evening that there is no interpolator, and that the TP runs at the servo rate?
[12:59:18] <SWPadnos_> since you don't *always* want to use that
[12:59:20] <SWPadnos_> jmkasunich: sure
[12:59:33] <SWPadnos_> but then you have a different can of worms
[12:59:50] <jmkasunich> ok, what does the TP do? it evaluates X(t), Y(t), Z(t), etc for various values of t
[13:00:02] <jmkasunich> usually t does 0.001, 0.002, 0.003, 0.004
[13:00:25] <jmkasunich> but it could do 0.0013, 0.0025, 0.0032, 0.0041, 0.0044, 0.0045, 0.0045
[13:00:42] <petev> hang on
[13:00:43] <jmkasunich> IOW, motion would slow down and stop, if you slow down and stop t
[13:00:48] <SWPadnos_> yes
[13:00:55] <petev> I see the TP sampling the desired path and making pose
[13:01:06] <petev> if that's at servo rate, I don't see an issue
[13:01:19] <SWPadnos_> hey - we're supposed to forget that it's two pieces right now ;)
[13:01:24] <petev> if not, it's the interpolation between these points that seems to be tricky
[13:01:30] <petev> swp: I know
[13:02:00] <SWPadnos_> [20:28] jmkasunichSWP: can we pretend for an evening that there is no interpolator, and that the TP runs at the servo rate?
[13:02:03] <jmkasunich> given the CPU power we have today, I'd like it to be one piece
[13:02:46] <SWPadnos_> that may actually help, due to no overhead between the parts
[13:03:13] <jmkasunich> I think the real reason for the slower TP wasn't because the TP couldn't keep up
[13:03:25] <jmkasunich> it was because they were doing kinematics on the TP output
[13:03:38] <jmkasunich> and for some machines, the kinematics are an iterative thing, very slow
[13:03:42] <petev> so kinematis for a robot are slow?
[13:03:43] <SWPadnos_> ok
[13:03:50] <petev> for a mill/lathe, who cares
[13:03:58] <jmkasunich> depends on the geometry
[13:04:00] <SWPadnos_> you may need successive approximations for something like a hexapod
[13:04:11] <jmkasunich> if there is a closed form solution, not bad at all, even if the math is comples
[13:04:15] <petev> for a standard mill/lathe
[13:04:17] <jmkasunich> complex
[13:04:18] <SWPadnos_> a hexapod may be a mill/lathe
[13:04:33] <jmkasunich> SWP: don't be a brat
[13:04:40] <jmkasunich> you know what he's talking about ;-)
[13:04:41] <petev> swp: if axis=joint
[13:04:44] <jmkasunich> trivkins
[13:05:03] <SWPadnos_> heh
[13:05:28] <petev> jmk: continue
[13:05:34] <SWPadnos_> NIST had a really cool hexapod milling machine - they made the titanium case for the Declaration of Independence with it
[13:05:44] <jmkasunich> I didn't know that
[13:05:54] <jmkasunich> I like the robocrane
[13:06:05] <jmkasunich> I want to build one of those that hangs from my basement ceiling
[13:06:11] <SWPadnos_> yeah - the one for ship fixing?
[13:06:50] <jmkasunich> yeah, although that one is too slow because people need to stand on it
[13:06:56] <SWPadnos_> heh
[13:07:02] <SWPadnos_> anyway - back to lathes
[13:07:06] <SWPadnos_> or threading
[13:07:13] <jmkasunich> I saw a video of a robocrane holding a welding torch
[13:07:17] <jmkasunich> yes, back
[13:07:29] <SWPadnos_> (you have to watch NOVA to see the hexapod)
[13:07:56] <jmkasunich> * jmkasunich doesn't watch much TV, but NOVA is good, I should watch that
[13:08:38] <jmkasunich> anyway, I would like to move toward a TP where t can come from either the clock or the spindle interchangably
[13:08:58] <petev> but TP period is still constant?
[13:09:08] <jmkasunich> sampling period is constant, yes
[13:09:28] <petev> ok, I guess that would work if spindle variation wasnt too great
[13:09:45] <jmkasunich> it would work regardless
[13:09:45] <petev> other wise it seems like some pose could be close and others far
[13:09:51] <petev> why?
[13:10:02] <petev> seems like error could increase for pose far apart
[13:10:15] <jmkasunich> poses are always 1mS apart
[13:10:22] <jmkasunich> or whatever the servo rate is
[13:10:22] <petev> probably not an issue with any decent spindle
[13:10:46] <petev> yes, I was looking at distance between pose, not time
[13:11:10] <jmkasunich> even at 300ipm, 1mS = 0.005
[13:11:18] <jmkasunich> granted, you want a lot better than 0.005 when threading
[13:11:25] <petev> yes
[13:11:34] <jmkasunich> but you aren't likely to thread at 300ipm
[13:12:04] <petev> that doesn't sound all that fast for coarse threads
[13:12:09] <jmkasunich> lemme see.... 20tpi
[13:12:13] <petev> but let's continue
[13:12:24] <jmkasunich> 5 inches/sec, = 100 turns/sec = 6000 rpm spindle
[13:12:54] <petev> yes, not unreasonable for 20 TPI on AL
[13:13:05] <petev> have you seen a Hardinge thread?
[13:13:18] <jmkasunich> no
[13:13:28] <petev> they thread unbeleivably fast
[13:13:33] <petev> it's scary
[13:13:42] <jmkasunich> to do that, you don't just need 300ipm, you need mondo accel and decel too
[13:13:51] <jmkasunich> IOW, a high bandwidth machine overall
[13:14:01] <jmkasunich> so maybe you ip the servo rate to match
[13:14:10] <jmkasunich> s/ip/up
[13:14:15] <petev> yes
[13:14:29] <petev> but even the manual HLV threads scary fast
[13:14:40] <petev> it has some built in stop mechanism
[13:15:00] <jmkasunich> throws out the halfnuts without the machinist sweating bullets?
[13:15:04] <petev> there is also a cam on the compound to move X quickly
[13:15:48] <jmkasunich> heh, IOW, they program the toolpath (including pull out) with steel
[13:16:01] <petev> ok, so you think that jitter on the distance between pose is not a problem for a normal spindle?
[13:16:30] <jmkasunich> spindles have huge inertia compared to axis drives
[13:16:36] <petev> yes
[13:17:08] <jmkasunich> the challenge is probalby the accel/decel at start and finish, during the threading pass any change in spindle speed over a period of 0.001 seconds will be negligable
[13:17:22] <jmkasunich> even if there is significant slowdown over the complete pass
[13:17:40] <jmkasunich> of course, rigid tapping has the opposite problem
[13:17:42] <petev> ok, so some minimal spindle inertia is an assumption then
[13:17:50] <jmkasunich> yes
[13:18:00] <jmkasunich> everything has inertia ;-)
[13:18:08] <petev> I just think about a sherline and it seems it has almost none
[13:18:30] <jmkasunich> relative to the size of cut it takes, it has enough
[13:18:35] <petev> ok
[13:18:37] <jmkasunich> you only make shallow cuts
[13:18:48] <petev> never used one, looks like a toy
[13:19:10] <jmkasunich> sizewise, it is a toy
[13:19:31] <jmkasunich> I've made chips bigger than some of the parts folks make on sherlines
[13:19:33] <petev> so it doesn't seem that hard to take T from the spindle count instead of time
[13:19:37] <petev> yep
[13:20:22] <jmkasunich> the problem is getting the TP to accept T as a variable, instead of a constant stairstep
[13:20:36] <petev> why? how is the code done?
[13:20:44] <petev> isnt it just a var down there?
[13:20:50] <jmkasunich> (including when T goes backwards - getting the tap back out after a rigid tapping pass)
[13:20:51] <SWPadnos_> I don't think that should be a big issue
[13:20:53] <jmkasunich> nothing is that simple
[13:21:12] <jmkasunich> now we have to admit that there are two parts to the TP again (bummer)
[13:21:24] <SWPadnos_> the second part of the rigid tapping pass should be a move in the opposite direction
[13:21:32] <jmkasunich> no
[13:21:52] <jmkasunich> the tapping pass is a single move, from outside the work to finished depth
[13:22:07] <jmkasunich> Z is syncd to the spindle
[13:22:10] <SWPadnos_> don't you have to reverse the spindle?
[13:22:16] <jmkasunich> and you need to stop the spindle when you reach finish depth
[13:22:22] <petev> yes
[13:22:39] <jmkasunich> then you reverse it, T goes backwards, and you "reverse time" and do the toolpath backwards
[13:22:46] <jmkasunich> but you never unsync from the spindle
[13:23:13] <petev> yes
[13:23:16] <SWPadnos_> or, you remain synced, but make a "reverse path" move, so you're still going forward in pseudo-time
[13:23:31] <jmkasunich> huh?
[13:23:35] <SWPadnos_> heh
[13:23:48] <SWPadnos_> I knew I shouldn't have said "pseudo-time ;)
[13:24:10] <SWPadnos_> it's two moves, with a synchronized IO operation in the middle
[13:24:15] <SWPadnos_> move down
[13:24:27] <SWPadnos_> change spindle speed (off / reverse)
[13:24:31] <SWPadnos_> move up, still in sync
[13:24:51] <jmkasunich> it can't be two moves with a spindle change in the middle - there is no middle
[13:24:52] <SWPadnos_> t never needs to go backwards
[13:25:06] <SWPadnos_> ?
[13:25:15] <jmkasunich> if you are tapping fast, you may already be slowing down the spindle before the tap even enters the work
[13:25:25] <SWPadnos_> is the spindle under emc control?
[13:25:32] <jmkasunich> the move needs to slow down, stop, and accel backwards at the same rate as the spindle
[13:25:41] <petev> whats wrong with running T backwards?
[13:25:55] <jmkasunich> for rigid tapping, it would need to be under at least loose control of EMC
[13:26:10] <jmkasunich> and EMC needs to know its accel limitations to it can make it stop a the right spot
[13:26:30] <SWPadnos_> running t backwards isn't a problem, until you need t he previous pose that you were working from
[13:26:37] <jmkasunich> running T backwards has other advantages - backing up in wire edm's when the wire shorts to the work, for instance
[13:26:58] <jmkasunich> heres where I want to get radical
[13:27:01] <jmkasunich> new TP time!
[13:27:14] <SWPadnos_> negative PERIOD!
[13:27:25] <jmkasunich> input to TP is still a mathematical expression of the desired path
[13:27:34] <jmkasunich> but instead of line or arc, it is splines
[13:27:45] <jmkasunich> not one spline per TP period
[13:27:55] <jmkasunich> each spline would be as long as possible
[13:28:26] <jmkasunich> limited only by the fact that you can't perfectly fit a spline, so eventually you need to break it up into shorter ones to get a better fit
[13:28:38] <SWPadnos_> right
[13:28:40] <jmkasunich> splines are calculated in user space
[13:28:45] <jmkasunich> queued
[13:28:50] <jmkasunich> sent to RT
[13:29:05] <jmkasunich> and all the RT does is evaluate the spline polys for various values of T
[13:29:15] <jmkasunich> when you reach the end of one spline, start the next
[13:29:27] <jmkasunich> but save the old one
[13:29:50] <jmkasunich> so if you need to back up, you decrement time, when it goes below 0, you switch to the previous coefficients
[13:30:08] <jmkasunich> an interseting question is how many to save
[13:30:11] <petev> so where are the canned cycles implemented then? not in canonical, but in the TP?
[13:30:14] <jmkasunich> it would be nice to be able to save them all
[13:30:22] <SWPadnos_> yep - but you run into similar buffer length problems as before
[13:31:10] <petev> if the splines come from user space, why not just have canonical play them back?
[13:31:13] <jmkasunich> even if you were issuing hundreds of splines per second, modern PCs could easily queue several thousand, and keep several thousand old ones around after they are "used"
[13:31:17] <petev> it knows if it's a canned cycle
[13:31:42] <jmkasunich> canned cycles have always been in the cannonical/interp side, not the TP
[13:31:50] <jmkasunich> I wouldn't change that
[13:32:02] <petev> yes, so canonical knows how many splines to save
[13:32:11] <petev> for rigid tapping, etc.
[13:32:24] <petev> why save them in the TP?
[13:32:45] <jmkasunich> well the TP needs to be able to access them without waiting for user space code
[13:32:50] <SWPadnos_> so you can go backwards
[13:33:11] <petev> no, cannonical sends them down and they Q
[13:33:16] <jmkasunich> here is a far-fetched concept (just a concept, not what I want to do)
[13:33:28] <petev> canoical repeates them in reverse for the back up part
[13:33:48] <jmkasunich> suppose you run the interp on an entire g-code program, and generate a file (on disk) that consists of thousands of splines, that mathematically represent the desired toolpath
[13:33:58] <petev> ok
[13:34:10] <jmkasunich> load that file into memory
[13:34:18] <jmkasunich> and just work your way thru it...
[13:34:25] <petev> ok
[13:34:25] <jmkasunich> you can go as slow or fast as you want
[13:34:30] <jmkasunich> you can even back up
[13:34:38] <jmkasunich> all the way to the beginning if you want
[13:34:41] <SWPadnos_> you can use a jog wheel to move along the toolpath ...
[13:34:45] <jmkasunich> yes
[13:35:02] <petev> so maybe we need a two way between the TP and user space
[13:35:05] <jmkasunich> in practice, there would be a couple levels of cachine - first from disk to user space, then from user space to RT
[13:35:17] <petev> yes
[13:35:26] <jmkasunich> but if we think of the "queue" as actually being a pointer into a very long sequence...
[13:35:29] <SWPadnos_> and you need a way of dealing with I/O and other things in there as well
[13:35:57] <jmkasunich> insert I/O commands between the splines, or in a parallel array
[13:36:16] <SWPadnos_> hey - there's that synchronized queue again ;)
[13:36:29] <petev> why not just have a file on canonicals, one of which is a spline
[13:36:40] <petev> on/of
[13:37:04] <jmkasunich> I want everything as splines
[13:37:13] <SWPadnos_> it's probably better if the fast RT code only has to deal with one type of calculation
[13:37:18] <petev> ok, so get rid on arc and line
[13:37:22] <jmkasunich> anyway, this is just a thought experiment right now
[13:37:24] <SWPadnos_> you can optimize the hell out of it
[13:37:25] <petev> but you still need other canonicals
[13:37:43] <jmkasunich> right - resolve arcs and lines into splines in user space
[13:37:46] <SWPadnos_> a spline can describe an arc or line
[13:37:52] <petev> yes
[13:38:10] <petev> I might be able to do this in the new interp if we want to
[13:38:16] <petev> however, consider this
[13:38:24] <jmkasunich> notice that feedrate override is easy now, just change your T
[13:38:25] <petev> what about cutter compensation?
[13:38:41] <petev> this will be tougher with splines
[13:38:54] <SWPadnos_> not if it's in the G-code to begin with
[13:38:59] <jmkasunich> g-code will (at least for now) issue only lines and arcs
[13:39:05] <SWPadnos_> you just make a compensated path
[13:39:10] <petev> ok, well that's different
[13:39:19] <jmkasunich> cutter comp is applied first, you now have corrected lines and arcs, then you spline it up
[13:39:24] <petev> if g-code is still arc/line no prob
[13:39:40] <petev> I'm thinking nurbs from CAM
[13:39:42] <SWPadnos_> though you're right - it would be ideal to be able to replace a broken tool with a different diameter, and keep on trucking
[13:39:57] <jmkasunich> good point
[13:40:00] <jmkasunich> damn....
[13:40:00] <petev> or a sharpened tool that's undersized
[13:40:12] <SWPadnos_> (after backing up a little to actually cut the part you missed ;) )
[13:40:20] <petev> yep
[13:40:26] <jmkasunich> I was really liking the idea of precomputing the entire path
[13:40:37] <jmkasunich> although I glossed over something....
[13:40:41] <SWPadnos_> heh
[13:40:46] <petev> I think we still need to do it on the fly
[13:40:51] <jmkasunich> this concept handles feedrate override nicely, however
[13:40:53] <petev> not that big a deal though
[13:41:31] <SWPadnos_> it also handles jog / pause / resume nicely
[13:41:41] <jmkasunich> if your path consists of lines and arcs that are co-linear at the joints (arcs tangent to the adjacent line or arc) then you can spline it up easily
[13:41:58] <jmkasunich> but if it contains a line followed by a non-parallel line, that is an infinitely sharp corner
[13:42:11] <jmkasunich> and no spline can track it, only approximate it
[13:42:11] <petev> yes
[13:42:16] <petev> yes
[13:42:31] <jmkasunich> no machine can cut it either, unless you are in exact stop mode
[13:42:37] <petev> yes
[13:42:39] <SWPadnos_> you need to take a cue from a program like Corel Draw
[13:42:57] <SWPadnos_> you can do arbitrary splines, but a node can also be considered a "corner"
[13:43:15] <petev> you mean between splines?
[13:43:22] <SWPadnos_> you would have the option of either doing a stop, then accel at a corner, or rounding it somewhat
[13:43:24] <SWPadnos_> yes
[13:43:38] <jmkasunich> EMC defines three modes (but only implements 2 I think)
[13:43:40] <jmkasunich> exact stop
[13:43:43] <jmkasunich> exact path
[13:43:51] <jmkasunich> continuous contouring
[13:44:03] <petev> yes
[13:44:10] <jmkasunich> exact stop stops between each segment, even if they are tangent
[13:44:16] <SWPadnos_> yep - you can decide what to do at a disjoint based on the mode
[13:44:42] <jmkasunich> exact path stops when needed, but for colinear lines or tangent arcs it keeps going
[13:45:08] <jmkasunich> continuous contour keeps going at the commanded speed and deviates as needed from the ideal path
[13:45:33] <petev> is there an error limit for continuous?
[13:45:56] <jmkasunich> I don't think so - the error is a function of the speed you commanded with an F word
[13:46:05] <SWPadnos_> well - the simple but stupid way of doing that would be to generate three different sets of splines around any disjoint. one for each of those modes
[13:46:37] <jmkasunich> its really only 2 modes
[13:47:14] <jmkasunich> you either stop at a joint, or you make the tightest turn possible given the commanded speed
[13:47:16] <SWPadnos_> no - I think it's three - in exact stop, you emit 4 control points per segment
[13:47:18] <jmkasunich> only two choices
[13:47:33] <jmkasunich> in exact stop, you stop even when you don't have to
[13:47:38] <SWPadnos_> that guarantees a stop at every point
[13:47:44] <jmkasunich> in exact path, you stop only when you have to
[13:47:50] <jmkasunich> in continuous, you don't stop
[13:48:00] <jmkasunich> but the math only has to deal with stop, and not-stop
[13:48:11] <petev> ok, so something else dawns on me
[13:48:12] <SWPadnos_> in exact path, any change from exactly collinear moves would generate a stop, no?
[13:48:19] <jmkasunich> yes
[13:48:22] <SWPadnos_> ok
[13:48:42] <petev> how does gcode specify the lead in lead out on a lathe and have it geared to spindle?
[13:48:48] <petev> it's not a canned cycle
[13:48:49] <jmkasunich> note another thing - any path can be made non-disjoint
[13:49:09] <SWPadnos_> sure - if you don't mind some rounding or stopping ;)
[13:49:37] <jmkasunich> what I mean is that you can compute arcs that will join the non-tangent lines
[13:49:50] <jmkasunich> yes, that gives you rounding
[13:50:45] <jmkasunich> I think I would approach the rounding thing by doing exactly that
[13:51:15] <jmkasunich> for any given tangential speed and lateral accel limit, you can easily compute the minimum radius
[13:51:46] <jmkasunich> so when you have two lines that join at an angle, you can calculate the radius of the arc that blends them
[13:51:53] <SWPadnos_> sure, but that changes with feedrate override
[13:51:59] <SWPadnos_> or jog mode
[13:52:02] <jmkasunich> then it is geometry to calculate where the lines should be cut off and the arc spliced in
[13:52:12] <jmkasunich> shhhh, you weren;t supposed to say that!
[13:52:16] <SWPadnos_> sorry
[13:52:29] <petev> ok, but how does gcode specify the lead in/out on a lathe and have it geared to spindle?
[13:52:45] <jmkasunich> jogging is single axis (or you talking about using a jogwheel to control "time")?
[13:52:59] <SWPadnos_> jogwheel = time
[13:53:02] <jmkasunich> pete: you keep changing the subject
[13:53:21] <jmkasunich> I'm not sure, but I think there are g-codes that change the sync mode
[13:53:22] <petev> yes, but this seems like a big issues we forgot about
[13:53:30] <jmkasunich> so you would have:
[13:53:47] <jmkasunich> g1 F1 Xsomething Ysomething (last normal move)
[13:54:06] <jmkasunich> G33 (I think that is the sync g-code, it actually also takes arguments)
[13:54:21] <jmkasunich> G1 F1 X something Y something (first part of toolpth
[13:54:23] <petev> ok, I never saw anything like that, I'll search
[13:54:27] <jmkasunich> G1 more tooplath
[13:54:42] <jmkasunich> G2 more toolpath, doesn't ahve to be all lines
[13:54:49] <jmkasunich> G33 sync mode off
[13:54:55] <jmkasunich> G1 non-sync toolpath
[13:55:24] <jmkasunich> I think Paul added G33 to the interp in the lathe fork,and I think that was merged into HEAD
[13:55:30] <jmkasunich> but it might be ifdefed out
[13:55:54] <SWPadnos_> hm - that's not quite what Machinery's Handbook says
[13:56:01] <jmkasunich> ok
[13:56:09] <jmkasunich> what I just told you I got second or third hand
[13:56:21] <petev> swp: what does the book say?
[13:56:23] <SWPadnos_> ok - lemme type in what the Book says ;)
[13:56:34] <SWPadnos_> it's ot definitive for threading
[13:56:38] <petev> scan and ocr, cut /paste
[13:56:42] <SWPadnos_> here are the G-codes:
[13:56:50] <SWPadnos_> G33 = thread with constant lead
[13:56:59] <SWPadnos_> G34 = thread with increasing lead
[13:57:06] <jmkasunich> grep interp source for G33
[13:57:07] <SWPadnos_> G35 = thread with decreasing lead
[13:57:38] <SWPadnos_> I'm looking through the text for desciptions of threading commands
[13:57:57] <jmkasunich> #define NCE_G33_NOT_SUPPORTED 200
[13:58:05] <jmkasunich> so it is parsed, but then does nothing
[13:58:25] <jmkasunich> pete: you've been reading Kramer, is there a canonical for threading?
[13:58:53] <petev> no, there's a canonical to sync with spindle
[13:59:09] <jmkasunich> that would be the one I think
[13:59:20] <SWPadnos_> START_SPEED_FEED_SYNCH
[13:59:23] <SWPadnos_> page 50
[13:59:46] <SWPadnos_> no threading found, except for G84
[13:59:50] <SWPadnos_> rigid tapping
[13:59:51] <petev> there are also some for spindle force/torque
[14:00:18] <petev> I see some references on the net to G33, G34, G35
[14:00:26] <SWPadnos_> interesting - G94 / G95 are supposed to be for feedrate as a function of time vs. spindle rotations
[14:01:03] <petev> http://www.answers.com/topic/g-code-1
[14:01:40] <jmkasunich> pete: you have a URL for the kramer paper? I seem to have lost it
[14:02:02] <petev> http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdfhang
[14:02:22] <jmkasunich> without the hang ;-)
[14:02:32] <petev> sorry
[14:02:33] <jmkasunich> * jmkasunich saves to disk for next time
[14:02:37] <petev> http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf
[14:02:50] <jmkasunich> no prob, I recognised it before I even pasted it
[14:03:20] <petev> dang doze to X paste stuff
[14:03:44] <jmkasunich> pete needs a linux box
[14:03:58] <petev> ksirc is running on linux
[14:04:03] <petev> X to it from doze
[14:04:18] <jmkasunich> oh, but you are sitting in front of the doze box
[14:04:19] <jmkasunich> got it
[14:04:23] <petev> yep
[14:05:47] <jmkasunich> well those canonical commands are wonderfully vague
[14:05:48] <petev> u see the canonicals about spindle force/torque?
[14:05:53] <petev> yes
[14:06:17] <petev> I think they may have been implemented one time for the K&T retro at GM
[14:06:31] <petev> I wonder what happened to that code
[14:06:36] <jmkasunich> hmmm, there is an orient spindle canonical
[14:06:42] <petev> yes
[14:06:51] <petev> for single point, tool change, etc.
[14:07:21] <petev> sometimes you use a single point to cut an internal groove
[14:07:28] <jmkasunich> we did spindle orient on the Mazak, but obviously without the canonical
[14:07:43] <petev> you need to orient so you can move x,y before z retract
[14:07:49] <jmkasunich> or to withdraw a boring head without scratching the bore
[14:07:58] <petev> yeah, a lot of the canonicals are bypassed with direct NML
[14:08:01] <petev> yes
[14:08:21] <jmkasunich> I wonder what g-code(s) invoke orient anyway>
[14:08:22] <jmkasunich> ?
[14:08:38] <petev> I think it's part of canned cycles
[14:08:51] <petev> my old BP has a bore cycle that uses orient
[14:09:06] <petev> it stops and you have to orient in manually, then continue ;-)
[14:10:45] <petev> so I guess all this stuff is non-standard again and kramers doc doesn't define enough detail on how g-codes or canonicals should work
[14:11:46] <jmkasunich> yep
[14:11:49] <petev> do you see the elipse feed? that one's not implemented either
[14:11:56] <jmkasunich> yep
[14:12:01] <petev> cutter comp is bein done in the interp now too
[14:12:09] <petev> I think it belongs in canonical
[14:12:24] <jmkasunich> I'm much happier talking about how to implement threading in the TP than about how to specify it in g-code or canonicals
[14:12:54] <petev> I think we can just use the canonical for spindle sync, not sure about the g-code
[14:14:05] <jmkasunich> we have to define in more detail exactly what the canonical means
[14:14:16] <jmkasunich> there is no scale factor there, it is strictly on/off
[14:14:26] <petev> yes
[14:14:31] <jmkasunich> so how is thread pitch specified
[14:14:56] <jmkasunich> I think paul's interpreter G33 stuff expects an argument to G33 that is the pitch
[14:15:01] <petev> probably why it's not implemented ;-)
[14:15:55] <jmkasunich> since I want to be able to sync arbitrary toolpaths to the spindle, I'd favor using F words
[14:16:28] <jmkasunich> when sync is off, F words set speed in ipm, or inches/sec, or mm/sec, or whatever
[14:16:52] <SWPadnos_> the standard is to use a K word for the thread pitch
[14:17:00] <jmkasunich> when sync is on, F words set speed in inches per rev, or mm per rev, or something
[14:17:08] <petev> so if we have F and S, what else do we need? just counts per rev from INI or something
[14:17:11] <SWPadnos_> G33 Z-1 K0.0625
[14:17:26] <jmkasunich> where did you find that?
[14:17:27] <petev> hmm
[14:17:34] <petev> swp: how does the lead in/out work?
[14:18:00] <SWPadnos_> yep - G94 means units/sec, G95 means hundredths of a unit per revolution
[14:18:04] <SWPadnos_> it doesn't ;)
[14:19:04] <petev> swp: are these fanuc conventions that are described?
[14:19:10] <SWPadnos_> they seem to assume that the "geared" axes will by synched to a particular spindle orientation as well
[14:19:22] <petev> yes, must be
[14:19:40] <SWPadnos_> not sure - they have a combination of EIA nad ISO specs
[14:20:00] <jmkasunich> the orientation is needed for multi-pass threading
[14:20:05] <petev> yes
[14:20:08] <SWPadnos_> and some non-standard codes, but no names mentioned
[14:20:26] <SWPadnos_> yep - I remember some discussion of this at Fest
[14:22:08] <SWPadnos_> they don't say much more about threading.
[14:22:13] <jmkasunich> well, my interest is in the implementation of the TP
[14:22:32] <jmkasunich> the job of getting threading working is gonna need to be split up
[14:22:51] <jmkasunich> interpreter, canonicals, task, RT, etc all are involved
[14:25:37] <petev> ok, I'll take a shot at the canonicals when I get there
[14:25:45] <petev> I look at the cutter comp stuff too
[14:25:59] <petev> gotta give the kids a bath, be back in a few
[14:26:02] <jmkasunich> ok
[14:26:12] <jmkasunich> * jmkasunich needs to do some coding
[14:26:22] <jmkasunich> this is probably a good point to stop talking ;-)
[14:26:49] <SWPadnos_> man!
[14:26:57] <jmkasunich> ?
[14:27:20] <SWPadnos_> (stopping early :) )
[14:28:02] <jmkasunich> heh
[14:31:01] <SWPadnos_> I can probably help with the halcmd stuff, if you can check in or email (or dcc) a header file or something
[14:31:28] <jmkasunich> what stuff?
[14:31:47] <jmkasunich> I was talking about halvcp (the virtual control panel stuff)
[14:32:02] <SWPadnos_> nevermind - you said vcp eariler - that's the HAL-ified control panel stuff
[14:32:06] <SWPadnos_> right
[14:32:33] <jmkasunich> you have some time and want to do something with halcmd? I have a suggestion...
[14:32:41] <SWPadnos_> uh-oh ;)
[14:32:45] <jmkasunich> heh
[14:32:52] <SWPadnos_> shoot
[14:32:52] <jmkasunich> totally up to you...
[14:33:14] <jmkasunich> newthread <name> <period> [nofp]
[14:33:36] <SWPadnos_> hm - rather than load threads blah blah
[14:33:41] <jmkasunich> the problem with this is that you need to be in kernel space to actually start a thread
[14:34:20] <jmkasunich> you guys gave me some ideas about how to do that (helper kernel thread) but I'm not thinking anything so complicated right now
[14:34:32] <jmkasunich> you can also do it with the threads components
[14:34:50] <SWPadnos_> do you know what's involved with the obvious corollary function - delthread?
[14:34:50] <jmkasunich> loadrt threads name1=<name> period1=<period>
[14:35:21] <jmkasunich> at least for now, you won't be able to delete a thread
[14:35:48] <SWPadnos_> ok - I know it's like that now - was wondering what the expected complexity of making it possible is
[14:36:04] <jmkasunich> that will require work at the HAL API level to make it happen, its at least as complex as the newsig
[14:36:11] <jmkasunich> needs to be done in kernel space
[14:36:26] <SWPadnos_> ok
[14:36:35] <jmkasunich> but the hack using loadrt threads can probably be coded in one evening
[14:36:42] <jmkasunich> that's why I brought it up
[14:36:57] <SWPadnos_> sure - just loadrt threads / unloadrt threads (like linkpp)
[14:37:14] <jmkasunich> once we have newthread (even if its a hack) we can chop the thread creation code and "period" parameters that are in nearly every HAL componnent
[14:37:39] <jmkasunich> get rid of a lot of duplicate code
[14:37:45] <SWPadnos_> I'll take a look, and see if it fits with my "style meter" :)
[14:37:51] <jmkasunich> ok
[14:38:00] <SWPadnos_> (I don't like hacks, when the right thing might not be too much harder)
[14:38:33] <jmkasunich> in this case, the right thing is much more complex (and actually the leading edge of a major rewrite)
[14:38:53] <SWPadnos_> then itll probably pass the style check
[14:39:21] <jmkasunich> once there is a helper thread running in kernel space, I want most of the HAL API to use that thread, and all the internal metadata can live in ordinary kmalloc kernel memory instead of shared memory
[14:39:51] <jmkasunich> the long term plan is to use a proper implementation of newthread to get the kinks out of the helper thread idea
[14:39:59] <jmkasunich> then move over the rest of the API
[14:40:03] <jmkasunich> the finally move the metadata
[14:42:52] <SWPadnos_> OK - I was thinking about a module that sets up a "hidden" slow thread, looking at shmem for commands every once in a while
[14:43:07] <jmkasunich> polling?
[14:43:10] <SWPadnos_> yep
[14:43:19] <SWPadnos_> slow poll - it's for userspace control anyway
[14:43:24] <jmkasunich> that would be slow when you are executing a .hal file with a crapload of lines in it
[14:43:33] <jmkasunich> and a waste of CPU the rest of the time
[14:43:50] <SWPadnos_> the CPU isn't an issue - poll every 100 ms or so, and it takes almost nothing
[14:44:01] <jmkasunich> I thought we were talking about having the kernel thread block on a semaphore
[14:44:02] <SWPadnos_> also, allow a queue of functions to be placed by userspace
[14:44:13] <SWPadnos_> sure - that can be done as well
[14:44:34] <jmkasunich> that way reaction to a userspace request is instant, and it wastes no time at all the rest of the time
[14:45:11] <SWPadnos_> one minor point - you do realize that a semaphore is also polling, it's just the task executive that does the poll
[14:45:21] <SWPadnos_> so you save the context switches
[14:45:26] <jmkasunich> src/rtapi/rtapi,h describes semaphores as implemented in rtapi
[14:45:29] <jmkasunich> I don't think so
[14:45:31] <SWPadnos_> but it's still polled
[14:45:36] <jmkasunich> I think it is tied to the scheduler
[14:45:40] <SWPadnos_> I'll take a look there to make sure
[14:46:38] <jmkasunich> when the user task releases the sem, the scheduler is told: suspend the current task (user process) and re-evaluate priorities, run the highest runnable task (which will now be the helper thread)
[14:47:12] <jmkasunich> aww, fart!
[14:47:19] <jmkasunich> looks like sems are RT only
[14:47:25] <SWPadnos_> ah - OK.
[14:47:39] <jmkasunich> I bet that is a RTLinux limitation, I think RTAI has symmetrical user/RT sems
[14:48:14] <jmkasunich> damn-n-shit
[14:48:21] <SWPadnos_> I can look at that stuff - you are hereby released from "Steve Support" for the evening - have fun coding vcp ;)
[14:49:11] <jmkasunich> ok
[14:56:50] <petev> just caught up here, I thought the RTAI sems worked from user space too
[14:57:36] <SWPadnos_> so jmk mentioned - he said that it may be an RTLinux limitation
[14:57:51] <SWPadnos_> not necessarily RTAI
[14:58:05] <petev> yeah
[14:58:10] <jmkasunich> right - RTAPI is designed to hide the differences between the two
[14:58:21] <jmkasunich> as such, it is the least common featureset
[14:58:28] <SWPadnos_> out of curiosity, do we still need that?
[14:58:34] <jmkasunich> damn I hate snow
[14:59:00] <jmkasunich> just took the dog outside, we must have 16"
[14:59:05] <SWPadnos_> heh
[14:59:15] <SWPadnos_> I thikn we have .017" now
[14:59:29] <jmkasunich> it was funny watching him try to take a dump in snow that is belly deep on him
[14:59:50] <jmkasunich> shitting uphill
[15:00:03] <SWPadnos_> heh
[15:00:05] <jmkasunich> back to RT...
[15:00:08] <SWPadnos_> like pissing in the wind
[15:00:22] <jmkasunich> RTLinux is basically BDI-2.xx
[15:00:38] <jmkasunich> so if we go to RTAI only, we abandon that BDI-2.xx users
[15:00:46] <jmkasunich> s/that/the
[15:00:57] <SWPadnos_> (could be that user -you never know ;) )
[15:01:14] <jmkasunich> I think cradek said the other night (when he tried emc2 for the first time) that he was running RTLinux
[15:01:28] <petev> yes, he did
[15:01:35] <jmkasunich> I don't think he had BDI-2, I think he might have done his own install
[15:01:39] <petev> but with a newer kernel he built
[15:01:47] <SWPadnos_> ok - if it's not acceptable to drop RTLinux suport, that's fine - I just thought the question should be asked
[15:02:06] <jmkasunich> I agree it should be asked, and in a wider forum than this
[15:02:09] <petev> let's find out for sure if it's an RTLinux issue
[15:02:17] <petev> I don't really care for RTLInux myself
[15:02:48] <jmkasunich> my knowledge of RTLinux is at least 2+ years old, from when I was writing RTAPI
[15:02:57] <jmkasunich> I don't use it
[15:03:18] <jmkasunich> but I doubt I put that note in rtapi.h for nothing
[15:03:21] <SWPadnos_> I thought that it was also proprietary (from Timesys or someone)
[15:03:37] <jmkasunich> fsmlabs
[15:03:46] <jmkasunich> they patented some of the underlying tricks
[15:03:49] <SWPadnos_> right - OK
[15:04:07] <petev> that's what prompted adeos
[15:04:08] <jmkasunich> there is a GPL version, but the patent flap is why most free SW folks use RTAI
[15:04:12] <petev> the patent issue
[15:04:54] <SWPadnos_> ok - and we're also considering (way in the future) using stock 2.6 with Ingo's RT patches
[15:05:07] <jmkasunich> yep
[15:05:36] <SWPadnos_> that certainly would limit the number of distros that could be used (since all the BDI 2.xx were kernel 2.4 afaik)
[15:05:52] <SWPadnos_> and many of the BDI 4.xx as well
[15:05:56] <jmkasunich> BDI-2.xx were 2.2 I think
[15:06:05] <jmkasunich> BDI-TNG and Live were 2.4
[15:06:10] <SWPadnos_> ok - even more out of date, and difficult to upgrade
[15:06:32] <jmkasunich> BDI-4.xx were all 2.6, differnet minor versions and different RTAIs
[15:06:56] <SWPadnos_> I thought that BDI4 before 4.16 or so were 2.4 as well
[15:07:15] <jmkasunich> I don't think so
[15:07:32] <jmkasunich> I think the whole purpose of the 4.xx series was to move to a modern kernel
[15:07:38] <cradek> I use the free rtlinux
[15:07:44] <SWPadnos_> ok
[15:07:52] <petev> jmk: just to close things on the TP, you're thinking to just run it at servo rate and avoid the interpolator issues?
[15:07:56] <cradek> I never was able to figure out how to build an rtai kernel and have it work right
[15:07:59] <petev> cradek: why?
[15:08:01] <cradek> although I only tried once
[15:08:02] <SWPadnos_> how would you like to switch to Adeos / RTAI?
[15:08:17] <jmkasunich> cradek: does today's free RTLinux support userspace/RT semaphores, or only RT/RT?
[15:08:19] <cradek> because I installed it a year ago and it was easy and works perfectly
[15:08:33] <cradek> I have no clue
[15:08:46] <jmkasunich> figured I'd ask...
[15:08:52] <petev> cradek: for RTAI, you only need the adeos patch
[15:09:03] <petev> RTAI is not part of the kernel path
[15:09:13] <petev> at least for the newer versions
[15:09:16] <cradek> what's the hal patch then?
[15:09:23] <SWPadnos_> I think it may be more compiler version sensitive
[15:09:32] <cradek> maybe
[15:09:34] <petev> that's old, adeos is the new way
[15:09:42] <jmkasunich> petev: on the TP issue, I don't know... depends on kins and other issues
[15:09:42] <cradek> I can't believe they still recommend 2.95
[15:09:43] <petev> RTHAL is gone
[15:09:48] <jmkasunich> don't want to go there now
[15:09:52] <petev> jmk: ok
[15:10:15] <jmkasunich> cradek: I think more recent versions of RTAI work with later compilers
[15:10:36] <cradek> I did try to use rtai once; I got a system that didn't work right and then I installed rtlinux since I had done it before once
[15:10:39] <jmkasunich> the recommendation is one of those "so-and-so got bit by this 3 years ago, so lets play it safe" things
[15:11:04] <cradek> jmkasunich: jepler found it on their web site a week ago when we were talking about this
[15:11:21] <jmkasunich> hmmm
[15:11:24] <cradek> but anyway
[15:11:32] <cradek> I'll switch if I have to, but I'll probably bitch some
[15:11:39] <jmkasunich> paul compiled the most recent BDI-4.30 with gcc 3.something
[15:11:50] <cradek> ok
[15:11:55] <SWPadnos_> I think that Paul got Adeos to compile using 3.3 or 3.4 for BDI 4.30 (though I could be wrong)
[15:11:59] <cradek> maybe it works fine
[15:12:04] <petev> I have 3.5 on mine
[15:12:10] <cradek> I'm pretty sure I used 3.2.2 for everything on my systems
[15:12:21] <jmkasunich> I have no intention of dropping support for RTLinux - it came up because we'd like to use user/RT semaphores, and it seems that the verison of RTLinux I wrote RTAPI for doesn't do that
[15:12:26] <petev> sorry, 3.3.5
[15:12:31] <cradek> jmkasunich: I see
[15:13:06] <SWPadnos_> yep - 3.3.5 on BDI 4.30, though I haven't compiled any kernels or anything with it
[15:13:08] <jmkasunich> if it turned out that nobody was using RTLinux, we might consider it
[15:13:09] <cradek> jmkasunich: it's just that I trust my rt machine now, and I can run emc1 and emc2, which is more than most of the developers can say!
[15:13:18] <jmkasunich> heh
[15:13:30] <petev> jmk: we could always have a thread kludge module for RTLinux, although it would suck to maintain the code
[15:14:01] <jmkasunich> any kluging should be done in rtlinux_rtapi.c, or not done at all
[15:14:14] <jmkasunich> correction, rtl_rtapi.c
[15:14:14] <petev> agreed, but that would be tough
[15:14:52] <jmkasunich> then we don't use user/RT semaphores
[15:15:12] <petev> hard to do the helper thread properly without it
[15:15:40] <jmkasunich> there are other approaches
[15:15:44] <jmkasunich> just none as nice
[15:15:54] <jmkasunich> what I really want is a system call, not a helper thread
[15:16:09] <jmkasunich> if it wasn't for the hassles of /dev nodes, I'd use an ioctl
[15:16:14] <petev> yeah, but that probably means a kernel compile
[15:16:24] <SWPadnos_> just a driver module, I think
[15:16:43] <jmkasunich> /dev/hal ioctl doesn't need a kernel compile
[15:16:51] <petev> swp: I meant for sys calls
[15:16:54] <petev> http://piglet.uccs.edu/~chow/pub/rtl/doc/html/MAN/rtl_index.4.html
[15:17:19] <SWPadnos_> ah - yes, you do need to add to the syscall table
[15:18:29] <jmkasunich> those RTL docs seem to indicate that the sem calls are still realtime only
[15:18:47] <petev> where do you see that?
[15:19:09] <jmkasunich> click on sem_init, there is (REALTIME) in bold first line
[15:19:40] <petev> http://piglet.uccs.edu/~chow/pub/rtl/doc/html/susv2/xsh/pthread_mutex_init.html
[15:20:48] <jmkasunich> whats the difference between a mutex and a semaphore
[15:21:00] <petev> a mutex is a sem with count of 1 max
[15:21:09] <petev> may also have priority inheritance
[15:21:19] <petev> it's all we need for this if it will work
[15:21:42] <jmkasunich> I wonder if that is supported by the version of RTL that is on BDI-2.xx
[15:21:50] <petev> don't know
[15:21:56] <jmkasunich> if so, rtl_rtapi.c should be re-written to use it
[15:22:02] <petev> yes
[15:22:21] <jmkasunich> if not, we might consider a rtl<version>_rtapi.c that works with newer versions
[15:22:52] <jmkasunich> * jmkasunich looks at the ./configure output from the 2.2 farm slot
[15:23:18] <SWPadnos_> well - you need to have the support in all versions that you want to maintain compatibility with
[15:23:20] <jmkasunich> that slot runs BDI-2.18, kernel 2.2.18-rtl3.0
[15:23:40] <SWPadnos_> so if there's one version of RTLinux that won't give you the functionality you need, you can't use it for halcmd
[15:25:05] <SWPadnos_> I note that the mutex page says nothing about realtime or kernel - it's a userspace thing only (from my perusal of the page)
[15:25:38] <jmkasunich> that page is straight from the posix specs
[15:25:41] <petev> swp: then why is it in the RTLinux docs?
[15:25:45] <jmkasunich> it's under a rtl directory tree, but...
[15:25:50] <petev> hmm
[15:25:59] <SWPadnos_> because it's supported in userspace
[15:26:03] <jmkasunich> look at the top of the page
[15:26:10] <jmkasunich> Single Unix Spec
[15:26:50] <jmkasunich> so the question is does RTL let you create one in userspace and then block a RT task on it
[15:27:09] <SWPadnos_> I'm looking for that answer
[15:27:58] <petev> the title of hte page is RTLinux man page index
[15:28:23] <petev> I don't know why they would discuss Posix stuff if it weren't related to the RTLinux
[15:29:10] <jmkasunich> that site isn't even officially related to RTLinux
[15:29:23] <petev> no, I'm looking on fsmlabs now
[15:29:36] <jmkasunich> oh, but the URL you posted was elsewhere
[15:30:11] <petev> http://www.fsmlabs.com/fsmlabs-lean-posix-for-rtlinux.html
[15:33:00] <jmkasunich> if either of you wants to hack rtl_rtapi.c to use mutexes, I'm willing to try to compile it on the compile farm that is running BDI-2
[15:33:33] <jmkasunich> there is a semaphore example in src/rtapi/examples/sem, that could be hacked to test user/RT sems
[15:33:34] <SWPadnos_> I'll look it over before agreeing to that ;)
[15:33:51] <jmkasunich> no prob
[15:33:54] <petev> the docs of fsm suck
[15:34:11] <jmkasunich> remember, I was just asking about the quick and dirty hack, not the helper thread approach
[15:34:27] <SWPadnos_> yep - they fail to mention that RTLinuxFree is available for kernel 2.6
[15:34:47] <SWPadnos_> I remember. I'd still like to pursue the "correct" approach
[15:34:52] <jmkasunich> they probably fail to mention anything good about the free version
[15:35:14] <SWPadnos_> yes
[15:35:20] <petev> RTL Threads
[15:35:20] <petev> In order for the realtime system to be able to use Linux, we provide three three standard interfaces between realtime tasks and Linux. The first is a device interface called RTfifos (illustrated below),r the second is shared memory, and the third uses the pthread signal mechanism to allow realtime threads to generate soft interrupts for Linux. A simple A/D application might consist of a single periodic thread that collects data from a A/
[15:35:44] <petev> doesn't sound like it has usr/RT sems or mutext
[15:35:44] <jmkasunich> that doc is ancient
[15:35:49] <SWPadnos_> that's RT <-> kernel, not RT <-> userspace
[15:35:59] <SWPadnos_> right
[15:36:01] <jmkasunich> it also talks about 66MHz boxes as being fairly fast
[15:36:15] <petev> yeah, there is nothing newer on there
[15:36:21] <petev> maybe in a download somewhere
[15:36:39] <jmkasunich> most support and docs for the free version are hosted by the comminuty
[15:36:44] <jmkasunich> the company abandoned it
[15:36:57] <jmkasunich> someday I'll learn to spell
[15:37:32] <jmkasunich> hey cradek: where did you get your RTLinux, and the docs to install it?
[15:37:38] <petev> I thought fsm still sells RTLinux, what was abandoned?
[15:37:50] <jmkasunich> the version that you don't have to pay for
[15:37:51] <SWPadnos_> they do sell it, it's the free version they're not too hot on
[15:37:57] <petev> ah
[15:38:05] <SWPadnos_> they do link to RTLinuxFree.com though
[15:39:20] <petev> thre is a version for 2.6 kernel
[15:39:41] <SWPadnos_> yep, but it's hard to find that out from FSM ;)
[15:39:55] <petev> yep
[15:40:30] <petev> u can't even see the files if u don't register, what a crock
[15:40:49] <SWPadnos_> that's why a lot of people aren't happy with Victor Yodaiken
[15:41:12] <petev> yep, they probably stick the sales guys on you after u register
[15:41:31] <jmkasunich> nobody@nowhere.com....
[15:41:43] <jmkasunich> (unless the mail you a registration key or something)
[15:43:12] <petev> I have nothing against a guy making money, but it burns me when a project is started open source and everyone contributes code, ideas, etc. then someone takes it commercial
[15:43:39] <petev> I was using some doze HTPC code and everyone was contribution ideas and plugins and waiting for version 2
[15:43:41] <SWPadnos_> and even worse, patanted
[15:43:52] <petev> then the guys starts a company and takes it commercial
[15:44:00] <petev> thatnks for all the free ideas and dev work
[15:44:02] <petev> nice
[15:44:27] <SWPadnos_> the ADEOS people were very careful to implement something other than what Yodaiken did
[15:45:26] <petev> yep
[15:52:08] <petev> my buddy is having the sudo gethostbyname() problem
[15:52:21] <petev> he says his /etc/hosts is ok
[15:52:25] <petev> any other ideas?
[22:04:19] <alex_joni> morning