Back
[01:16:03] <cradek> jmkasunich: ed's latest report is very interesting...
[01:16:15] <cradek> I think I'm going to go cut a flowsnake
[01:16:26] <jmkasunich> if by interesting you mean I'm gonna joing him in pounding my head on the table, then yes
[01:16:57] <jmkasunich> I gotta wonder if he really knows all there is to know about his drive's timing requirements
[01:17:16] <jmkasunich> IIRC, he told me that the drives on his sherline are not standard - he hacked on them
[01:17:37] <jmkasunich> I think he has a pic reading the step/dir signals
[01:18:40] <jmkasunich> I'd bet a fair amount that neither the old stepgen nor the new one actually violated any of the constraints as speced by the parameters
[01:19:04] <jmkasunich> velocity, accel, setup and hold time, step length, and step spacing
[01:19:26] <cradek> that seems likely to me too
[01:20:01] <jmkasunich> the thing is, you could cut a hundred flowsnakes, and not prove anything
[01:20:13] <jmkasunich> he's (air)cut a few himself for that matter
[01:20:49] <cradek> true. but isn't there some value to trying the new stepgen on known-good hardware?
[01:21:02] <jmkasunich> yes, by all means !
[01:21:53] <jmkasunich> I'm just looking at the ed issue while disregarding everything else
[01:21:55] <cradek> building...
[01:21:58] <cradek> right I understand
[01:22:04] <jmkasunich> 1) old stepgen works for many people on many hardwares
[01:22:24] <jmkasunich> 2) old stepgen doesn't work for ed on eds hardware
[01:23:12] <jmkasunich> 3) new stepgen seems to be nicer, not worse, at avoiding "bobbles" (even though said bobbles are within the allowed limits and therefore should not cause lost steps)
[01:23:37] <jmkasunich> 4) soon we hope to be able to say that the new stepgen works for at least one person
[01:23:53] <jmkasunich> 5) new stepgen doesn't work for ed, on eds hardware, in almost the same was as the old stepgen
[01:30:48] <cradek> I see what he means about the rhythm this program has...
[01:31:12] <jmkasunich> are you doing the funky flowsnake dance?
[01:31:16] <cradek> yes
[01:31:27] <jtr> video! video!
[01:31:37] <cradek> it keeps the velocity up at about 10, impressive
[01:31:46] <cradek> the high accel on this little machine is nice
[01:32:03] <jmkasunich> you are using your maxvel and accel values, right? and your step timings?
[01:32:07] <cradek> it can do 30, but I keep it at 20
[01:32:08] <cradek> yes
[01:32:33] <cradek> unsuprisingly, it went up at the end...
[01:32:33] <jmkasunich> I have no idea if his specs have anything to do with it - I did my runs using his numbers
[01:32:53] <petev> is there anything we can do with the build system to make the "failed to remake makefile 'Makefile'" error easier to find?
[01:33:01] <petev> it's usually some include that can't be found
[01:33:08] <cradek> petev: make -d will show it pretty quick
[01:33:08] <petev> but you get no indication of what it is
[01:33:27] <cradek> make -d |tail -100 is even better
[01:33:35] <petev> yeah, that prints a ton of stuff and you still can' figure out what make is looking for
[01:33:38] <cradek> it'll be right at the end
[01:33:43] <jmkasunich> 3 periods / 57uS steplen, 4 periods / 77uS space, 20 periods / ~400uS dir setup and hold
[01:33:51] <jmkasunich> 0.44 in/sec, 2.2 in/sec^2
[01:34:36] <jepler> petev:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FailedToRemakeMakefile
[01:34:53] <jmkasunich> heh, there is a wiki page for everything
[01:34:57] <cradek> wow, no kidding
[01:36:09] <petev> jepler, I just wish I saw such a nice reason why it failed as in your example
[01:36:21] <petev> I see nothing on my build, except the failure message
[01:36:22] <jmkasunich> although that page doesn't tell how to solve the problem (assuming the header was removed on purpose, and you don't want to just replace it)
[01:36:57] <jmkasunich> petev: you used --debug=m,b ?
[01:37:19] <petev> used -d, haven't tried that your option yet
[01:37:27] <petev> running after clean right now
[01:37:34] <jmkasunich> thats on the wiki page
[01:37:45] <petev> and I didn't delete any headers eiither
[01:37:45] <jmkasunich> will probably result in output like on the wiki page
[01:37:56] <petev> ok, will try next if it fails
[01:37:58] <cradek> petev: misspelling an include will do it too
[01:38:08] <petev> yeah, that's what I suspect
[01:38:22] <jepler> I generally use: make -o removed-or-typoed-header-name
[01:38:36] <jepler> though you can also: rm -rf depends; make
[01:39:00] <jepler> petev: I added an item to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions about the m5i20 change you checked in earlier. Did I correctly describe the change?
[01:39:03] <petev> I guess I used the big hammer with make clean ;-)
[01:39:15] <jepler> "The m5i20 "encoder" pins now match the HAL canonical encoder interface. The -cnt-latch, -pos-latch, -idx-latch, and -latch-index pins have been removed. The standard encoder pin -index-enable has been added. The behavior of the -position and -count pins now match the HAL canonical interface."
[01:39:40] <petev> yes, that's what's supposed to happen
[01:39:41] <jepler> petev: also I saw in the diff that you may have had a typo on a pin name in a comment: + * bit m5i20.<boardId>.enc-<channel>-enable-index
[01:39:47] <jepler> (shold be index-enable, I think)
[01:40:05] <petev> ok, let me check
[01:41:59] <jepler> -reset-count also seems to be different than the canonical encoder interface -- it's bidirectional, so you'll have trouble hooking it up to most things, and the name is wrong
[01:42:33] <petev> the index-enable typo is in a comment
[01:42:40] <petev> reset-count is bi-dir
[01:42:49] <petev> didn't realize this wasn't the standard name
[01:42:52] <petev> what should it be?
[01:43:25] <jepler> petev: I usually refer to
http://linuxcnc.org/docs/devel/html/hal/general_ref/ for answers to questions like that
[01:43:42] <jepler> (BIT) reset - When True, force counter to zero.
[01:43:57] <petev> yeah, looks like some other drivers need fixing too
[01:44:05] <petev> I just looked at some of the other code
[01:44:09] <jepler> it should also be input, not io
[01:44:27] <jmkasunich> I think only the software encoder counter and the ppmc driver are canonical at the moment
[01:44:55] <petev> jepler, why input if it's self clearing?
[01:45:10] <jepler> petev: canoncal encoder reset is also not self-clearing, it's persistent
[01:45:19] <jepler> the count output is held at 0 as long as reset is TRUE
[01:45:31] <petev> oh, that answers that
[01:47:30] <cradek> jepler: should axis be idle when it's not updating anything on the screen?
[01:47:54] <jepler> cradek: yes, I thought that it was.
[01:48:11] <cradek> it sure isn't here, and emc is badly starved for segments when running this program
[01:48:25] <cradek> axis 50%, Xorg 50% while it's cutting
[01:48:36] <cradek> and when it stops, axis 40% Xorg 5%
[01:48:42] <jepler> cradek: yuck
[01:49:58] <jepler> cradek: while milling it will be updating all the time, since the coordinates are changing
[01:50:08] <cradek> this program has a LOT of segments...
[01:50:32] <jmkasunich> swp and I were guessing at how many the other night
[01:50:44] <jmkasunich> never did decide on the answer
[01:50:51] <jmkasunich> 3072 maybe? or 768?
[01:51:17] <cradek> they are about .003-5 long in the reduced version I'm using
[01:51:30] <cradek> and it goes through them fast...
[01:51:46] <jepler> eek I have a lot of debug information flying by
[01:53:25] <jepler> cradek: I know my computer is much faster than yours, but while milling flowsnake I get xorg 10-15%, milltask 5-10%, axis 3-5%
[01:53:33] <jepler> with debug turned off that is
[01:53:58] <petev> got a warning on line 948 of saicanon.cc
[01:54:03] <petev> is anyone editing that now?
[01:54:10] <jepler> if I hit p, xorg and axis drop to 0%
[01:54:13] <jmkasunich> not here
[01:54:15] <jepler> not me
[01:56:28] <petev> ok, I'll look at it as soon as I finish with this stuff
[02:02:03] <jtr> Ed's articles on his stepper mods are available online:
[02:02:20] <jtr> ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2004/169/Nisley_169.zip
[02:02:33] <jtr> ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2004/171/Nisley171.zip
[02:03:43] <jtr> There's a third article, volume 191, June '06 - Stepper failure - death by disconnection
[02:04:11] <jtr> that one's not online.
[02:05:12] <jtr> Found them here:
http://www.dtweed.com/circuitcellar/xnisleye.htm
[02:07:18] <jmkasunich> * jmkasunich reads
[02:09:02] <petev> did that compile farm error happen right in the middle of commits?
[02:09:20] <jmkasunich> probably
[02:09:26] <petev> ok
[02:09:37] <jmkasunich> whenever possible its best to commit in one big lump
[02:09:52] <petev> I had a bunch of different comments though
[02:09:53] <jmkasunich> the farm checks for new commits every 5 mins, and starts a build if it sees one
[02:09:58] <petev> what's the best way to handle that?
[02:10:29] <jmkasunich> if they are unrelated and having the farm get one but not another won't break things, there is no problem
[02:10:53] <jmkasunich> but if one commit changes foo, and other changes bar, and there is some interdependency, the farm might try a build with only foo
[02:11:16] <petev> yes, they were related, but I wanted to describe the changes to each file
[02:11:20] <jmkasunich> I haven't looked at the log yet, does it splain what happened?
[02:11:39] <petev> it looked like the commit for the one file wasn't there yet
[02:11:53] <jmkasunich> then it will fix itself soon
[02:12:21] <jmkasunich> its already building again
[02:12:26] <petev> ok
[02:13:06] <jtr> I think I was wrong - I see the download files that went with the article, but not the article itself.
[02:13:22] <jepler> jtr: same here
[02:13:51] <jmkasunich> I didn't get that far, distraced by something else
[02:15:15] <jtr> sorry for this distraction. I've got the first two around here somewhere, but not the third - let the subscription lapse.
[02:16:21] <jtr> When I find them, I'll get them to you. Bedtime now.
[02:18:55] <jmkasunich> the farm is happy again ;-)
[02:19:07] <petev> good
[02:21:24] <cradek> back
[02:21:25] <jmkasunich> oh - half happy anyway - I didn't realize two slots had failed
[02:23:33] <petev> what failed?
[02:23:56] <jmkasunich> BDI-4.51, and dapper
[02:24:13] <jmkasunich> the BDI-4 one is taking longer to rebuild, not surprising since its a VM
[02:24:40] <petev> I don't see an error in the dapper log
[02:24:49] <petev> isn't it slot 7?
[02:24:54] <jmkasunich> thats because dapper rebuilt already, and passed
[02:25:00] <petev> oh
[02:25:22] <jmkasunich> and BDI-4 just passed now
[02:25:30] <jmkasunich> (there is a message in #emc to that effect)
[02:25:36] <petev> that saicanon error is a signed/unsigned in compare with a strlen
[02:26:26] <petev> you want me to add a type cast?
[02:26:47] <cradek> jepler: even when I turn off everything in the View menu
[02:27:16] <petev> it's in GET_EXTERNAL_PARAMETER_FILE_NAME so I don't want to change the param as it's an API call
[02:27:27] <jmkasunich> petev: error? or just warning?
[02:27:34] <petev> just warning
[02:28:05] <jmkasunich> don't strictly need it, but I like code to compile clean, so real warnings are easier to see
[02:28:06] <jmkasunich> I'd cast it
[02:28:24] <petev> ok, will do
[02:32:00] <jmkasunich> I think ed sent me copies of the two stories about his changes to the sherline driver
[02:32:18] <jmkasunich> but I don't know what I did when them - may have deleted them
[02:32:26] <cradek> I don't even know what the original driver box is like
[02:32:46] <jmkasunich> he said something about the copyrights being owned by the magazine, not him, and not to spread the files around, so I didn't...
[02:32:53] <jmkasunich> should ahve saved backup copies tho
[02:40:17] <jmkasunich> I do have my reply to him after he sent them...
[02:40:43] <jmkasunich> seems his sherline drives are unipolar full step (or maybe half-step)
[02:42:16] <cradek> jepler: I don't think hungry mode is working. milltask isn't fighting for its share, it sits at 3% and it should be 33%
[02:42:27] <jepler> cradek: hmph
[02:42:28] <cradek> jmkasunich: surely not full step
[02:42:40] <jepler> * jepler has been working on upgrading 'comp':
http://pastebin.ca/394166
[02:43:26] <cradek> jepler:
http://timeguy.com/cradek-files/emc/starving.png
[02:44:08] <cradek> jepler: this is the tc queue depth
[02:44:18] <jepler> cradek: huh -- yuck
[02:44:23] <cradek> I don't understand how it gets 5-10 at a time in one servo cycle
[02:44:52] <cradek> but it chews right through them and doesn't have any more for a while
[02:45:09] <jepler> I see that
[02:45:13] <jmkasunich> 1 sec per div
[02:45:24] <jmkasunich> you sure thats happening in one cycle (did you zoom in?)
[02:46:07] <cradek> http://timeguy.com/cradek-files/emc/starving2.png
[02:46:15] <jepler> cradek: is that what's on debug-s32-1 by default, or do i have to change it?
[02:46:26] <cradek> I can check it in if you want
[02:46:34] <jmkasunich> "yes" would have suficed ;-)
[02:46:40] <jepler> just show me the change and I'll make it locally
[02:46:44] <jepler> well -- whatever you want
[02:47:28] <cradek> I'll check it in - I like having this
[02:47:52] <jmkasunich> if you like it a lot, why don't we make it a real param instead of a debug one?
[02:48:09] <cradek> oops, too late
[02:49:30] <cradek> oh hmm, I bet that's updated at traj cycle, not servo cycle
[02:49:43] <cradek> that explains how there are 5 at a time
[02:49:57] <jmkasunich> well, I think I'm gonna do something novel, and go to bed before 11pm
[02:50:11] <cradek> I have traj/servo=10
[02:50:25] <cradek> goodnight jmkasunich
[02:50:31] <cradek> I cut several flowsnakes successfully
[02:50:38] <jmkasunich> air cut I assume?
[02:50:44] <jmkasunich> or do you have pretty engravings now?
[02:50:44] <cradek> no, on PCB stock
[02:50:59] <cradek> several about 1" diameter
[02:51:07] <jmkasunich> ooohhh... photos required ;-)
[02:51:20] <cradek> microscope required
[02:51:39] <jmkasunich> macro
[02:51:44] <jmkasunich> jepler can shoot them
[02:51:52] <jmkasunich> (photos not required _today_)
[02:52:00] <cradek> maybe I need a faster computer.
[02:52:33] <cradek> or at least a newer matrox card
[02:52:37] <cradek> (like max has)
[02:52:47] <jepler> jmkasunich: see you jmkasunich
[02:52:49] <jmkasunich> goodnight
[02:53:33] <jepler> I think I'll commit this 'comp' stuff before I go to bed
[02:53:48] <jepler> arrays and dotted names are a nice improvement
[02:53:52] <jepler> IMO
[02:53:59] <cradek> cool
[02:54:05] <cradek> I bet arrays and loops will be nice
[02:54:19] <jepler> cradek: did you look at the pastebin then?
[02:54:46] <cradek> yes
[02:54:51] <cradek> I saw a for loop...
[02:55:56] <cradek> ok when I make traj=servo, the plot makes more sense
[02:56:43] <petev> is there still interpolation when traj != servo ?
[02:56:51] <cradek> yes
[02:57:01] <cradek> cubic
[02:57:06] <petev> cool
[02:57:09] <cradek> important for kinematics where the calcs are slow
[02:57:16] <petev> right
[02:57:53] <petev> how is the TP doing vel calcs now? Does it work back from 0 vel at the end of look ahead?
[02:58:48] <cradek> it runs each segment with trapezoidal profile, overlapping their acceleration phases to blend the motion
[02:59:32] <petev> but how does it determine what max vel it can reach? kinda like driving and being able to stop by the distance you can see with your headlights
[03:00:08] <petev> if a super sharp corner came up and you were going too fast, you would have a problem
[03:00:42] <petev> seems like that's the reason for lot's of look ahead on complex 3D stuff with short segments
[03:01:02] <cradek> each segment does come to a stop within accel constraints. but the next one has already started, so the machine doesn't decel
[03:01:10] <cradek> yeah I know all about it...
[03:01:19] <petev> so I think getting lots of segments into the motion queue is very important
[03:01:52] <cradek> brb
[04:18:15] <ve7it> ve7it is now known as LawrenceG
[12:17:18] <cradek_> cradek_ is now known as cradek
[13:55:16] <jepler> in the canonical encoder interface, should "velocity" be held at 0 while reset is TRUE?
[13:58:19] <cradek> I don't think the reference implementation (encoder.c) does that
[13:58:27] <cradek> but I'm not sure if that's the question you're asking or not
[13:58:53] <alex_joni> the question was should
[13:59:48] <alex_joni> I see arguments for both ways
[14:02:56] <jepler> it turns out that pluto lets velocity be nonzero while reset is TRUE
[14:03:28] <cradek> I'm not sure I even understand when reset would be used
[14:07:51] <skunkworks> cradek: are the changes you made to the que in trunk?
[14:12:55] <alex_joni> yes, since last night
[14:13:16] <alex_joni> and backported to 2.1.x .. so it will be in 2.1.3
[14:29:56] <SWPadnos> jepler, it seems that one could expect zero velocity when an encoder is reporting no position change
[20:42:38] <jepler> loadrt and count=3 personality=2,5,3
[20:42:47] <SWPadnos> yay!
[20:42:55] <jepler> loads 3 'and' gates: and.0 has 2 inputs; and.1 has 5 inputs; and.2 has 3 inputs
[20:43:06] <cradek> coool
[20:43:13] <alex_joni> very nice
[20:43:13] <jepler> up to 16, in this case
[20:43:19] <SWPadnos> awesome. I've been thinking about that for some time, but (as you know) I'm too lazy to code it :)
[20:43:27] <jepler> http://pastebin.ca/395137
[20:43:38] <alex_joni> personality=16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16 ?
[20:44:32] <SWPadnos> that return should probably be a break
[20:44:38] <SWPadnos> or continue
[20:44:45] <SWPadnos> or something
[20:45:11] <SWPadnos> can you make a FUNCTION(_#) ?
[20:45:23] <SWPadnos> to get separate functions for each
[20:45:30] <alex_joni> I think they are separate
[20:45:33] <SWPadnos> (or _.#)
[20:45:43] <SWPadnos> ok, then the personality loop isn't needed
[20:45:53] <alex_joni> that one is for the number of inputs imho
[20:46:17] <jepler> SWPadnos: no
[20:46:36] <SWPadnos> ok
[20:46:55] <SWPadnos> do you automatically get multiple functions unless you use singleton?
[20:47:10] <alex_joni> yup
[20:47:13] <jepler> that example gives 3 functions: and.0, and.1, and.2
[20:47:15] <alex_joni> the ones you addf
[20:48:28] <SWPadnos> hmmm. interesting. I don't immediately see how the correct personality variable gets found
[20:48:50] <SWPadnos> I'm sure it'll be more apparent once I see comp / the generated C code :)
[20:49:12] <jepler> I'm working on the second, more complicated example :-P
[20:49:20] <alex_joni> jepler: what's that?
[20:49:34] <jepler> alex_joni: 'personality' can turn pins on and off altogether, not just set the size of an array pin
[20:49:55] <SWPadnos> ah
[20:49:58] <jepler> for instance, for a parport driver, personality=0 might select input mode, 1 and 2 would select output and "X" modes
[20:50:30] <alex_joni> jepler: yeah, I got that
[20:50:39] <alex_joni> was just wondering what your second example would be
[20:50:56] <SWPadnos> parallel port ;)
[20:51:07] <alex_joni> another mindfart.. do you need the num_chan param at all?
[20:51:20] <SWPadnos> not really :)
[20:51:38] <alex_joni> I'm not sure how the array parsing works for insmod
[20:51:39] <SWPadnos> I had thought of just changing the num_chan to an array myself
[20:51:40] <alex_joni> been a while..
[20:51:59] <alex_joni> SWPadnos: not sure you get the nr. of elements in the array though
[20:54:34] <jepler> you don't
[20:54:38] <jepler> you have to have some sentinel value such as 0 or -1
[20:55:25] <alex_joni> jepler: right.. that's what I was afraid of :(
[20:56:02] <alex_joni> SWPadnos: wwjjd ?
[20:56:16] <SWPadnos> that's no big deal, since in C you'd initialize the array to the sentinel value
[20:56:22] <SWPadnos> yeah - saw it :)
[20:56:38] <alex_joni> SWPadnos: you can't initialize de array
[20:56:50] <alex_joni> err.. you can.. sorry, I'm beeing stupid
[20:57:52] <SWPadnos> what you can't do, which is part of my excuse for not making these changes to C versions of the components, is have an arbitrary number of them - the array size limits you
[20:58:27] <SWPadnos> I had considered just using a string as the initializer, but then realized that the max string length would still be an arbitrary limitation (though a larger one)
[20:58:41] <alex_joni> and you need to parse it.. which is a PITA
[20:58:55] <jepler> this doesn't escape having arbitrary limits ... e.g., 16 instances, up to 16 input pins each
[20:58:55] <SWPadnos> not so bad with decimals, but ugly
[20:59:11] <jepler> because it has to lay everything out in a struct
[20:59:20] <SWPadnos> right - as usual, I over-think and do nothing, while you rapidly do something useful :)
[20:59:58] <alex_joni> yet, you somehow manage to make a living
[21:00:09] <SWPadnos> hmmm - do I?
[21:00:19] <SWPadnos> I haven't died yet, which is good :)
[21:00:50] <alex_joni> indeed.. you don't seem like the regular AI IRC bot.. so I assume you're alive :P
[21:01:22] <SWPadnos> error: Norman, coordinate
[21:04:00] <jepler> http://pastebin.ca/395164
[21:04:57] <SWPadnos> interesting
[21:05:06] <jepler> http://pastebin.ca/395169 http://pastebin.ca/395171
[21:05:35] <alex_joni> jepler: 164 is for 2 pinned components?
[21:05:48] <jepler> 164?
[21:06:03] <alex_joni> 395164
[21:06:14] <alex_joni> guess not.. seen the next one
[21:06:17] <SWPadnos> no - that's the one loaded in the other ones
[21:06:42] <SWPadnos> interesting - that supports multiple outptus from a single set of inputs
[21:07:04] <SWPadnos> the only thing needed now is selective inversion (inputs and outputs) :)
[21:07:05] <alex_joni> SWPadnos: that was exactly my question..
[21:07:07] <jepler> yeah -- it demonstrates both the use of personality to enable/disable pins (here, the outputs) and to set array sizes (here, the inputs)
[21:07:39] <alex_joni> why don't the components have all outputs (and, or, xor) by default
[21:07:46] <alex_joni> then you simply select the one you want
[21:07:46] <SWPadnos> pin reduction
[21:07:54] <alex_joni> or maybe even more than one
[21:08:03] <alex_joni> feels easier to use imo
[21:08:04] <SWPadnos> you could just load 16 x 16 pin modules, but that would be confusing
[21:08:15] <jepler> the example is somewhat contrived, I'll admit
[21:08:25] <SWPadnos> you don't need more than one output, since you can connect it to multiple inputs
[21:08:35] <SWPadnos> (output of the same type)
[21:08:39] <alex_joni> SWPadnos: I agree
[21:08:47] <alex_joni> I didn't say it should be of the same type
[21:09:00] <alex_joni> in-0 .. in-15, outputs: and, or, xor
[21:09:09] <SWPadnos> ok, so a bit output and an int output that's 0 or 1?
[21:10:20] <SWPadnos> (the posted example has individual selection of and, or, and not by oring together the 0x100, 0x200, and 0x400 bits for and, or, and xorr outputs respectively)
[21:10:43] <SWPadnos> jepler, two questions which you may have already answered:
[21:11:14] <alex_joni> darn, I totally missed that .. :(
[21:11:59] <SWPadnos> 1) the code references and, or, and xor - does that mean that the line of code with "or" in it will be removed from the comp output if personality & 0x200 ==0?
[21:12:32] <jepler> SWPadnos: this condition is evaluated at runtime, every time: if(personality & 0x400) xor = x;
[21:12:36] <SWPadnos> 2) can you check constraints so that if for example personality&0xFF00 ==0, the module refuses to load
[21:13:00] <SWPadnos> ok, but xor only exists if personality&0x400 ??
[21:13:11] <SWPadnos> so the storage is always there, but the pin may not be created?
[21:13:12] <jepler> the pin 'xor' is only created when the 'pin ... if personality' condition is satisfied
[21:13:26] <jepler> the storage is always there (the instance structure layout is fixed)
[21:13:46] <SWPadnos> ok - so there are no C problems with undefined variables or anything - good :)
[21:14:08] <jepler> I will probably add some easy way to check if a personality is valid .. right now you could use extra_init() to check and error
[21:14:14] <SWPadnos> ok
[21:14:47] <jepler> but I imagine something like: option valid_personality personality & 0xff <= 16;
[21:15:06] <jepler> (additional parens may be necessary there, I forget my order of operations:-P)
[21:15:11] <SWPadnos> heh
[21:15:56] <SWPadnos> is "personality" a keyword or a variable name?
[21:17:18] <jepler> umm
[21:17:34] <jepler> the only name you can use in that way in the declaration section is "personality"
[21:17:42] <jepler> in that sense it's a kind of keyword
[21:17:49] <SWPadnos> ok, so it's a special variable name :)
[21:19:44] <alex_joni> how about split_personality?
[21:19:57] <SWPadnos> or personality_disorder
[22:13:24] <SWPadnos> howdy Ray - how goes it?
[22:19:07] <rayh> Hi Steven
[22:19:16] <rayh> Keeping more than busy enough.
[22:20:13] <SWPadnos> heh
[22:28:14] <rayh> I worked with the SAI that Matt's been fixing.
[22:28:39] <rayh> It yields a very nice listing of the "cards" that are stacked by the interpreter.
[22:29:03] <alex_joni> I think you can see that with canterp too
[22:29:18] <SWPadnos> yep. there are even some regression tests that use it (made for checking cutter comp changes)
[22:29:54] <rayh> I was thinking about SWPadnos's thoughts on canon and primitives.
[22:30:13] <SWPadnos> cool
[22:30:19] <alex_joni> didn't know he has any
[22:30:19] <alex_joni> :D
[22:30:43] <rayh> I do have questions about canon's ability to handle parametric programming?
[22:31:01] <SWPadnos> parametric in what way?
[22:31:16] <rayh> nurbs to start
[22:31:39] <rayh> arc segments defined by equasions.
[22:31:44] <SWPadnos> ok
[22:31:50] <SWPadnos> I have my mother working on some of the math
[22:31:58] <SWPadnos> we'll see if anything comes of that :)
[22:32:06] <rayh> We don't at present have any lower level code that can see anything but arcs and lines.
[22:32:33] <SWPadnos> someone did some NURBS work - can't remember who
[22:32:38] <rayh> so if the interpreter expands a nurb into a set of lines and arcs we are okay as is.
[22:32:45] <alex_joni> xemet did I think
[22:32:50] <SWPadnos> I was thinking that as well
[22:32:54] <rayh> right
[22:33:07] <alex_joni> and jepler did some work too in that area
[22:33:12] <SWPadnos> jepler has spline code that makes lots of arcs. I'm not sure if Xemet's code does the same
[22:33:27] <rayh> I'd a whole lot rather see us edit canon to meet growing needs than bypassing it.
[22:33:51] <SWPadnos> NURBS have the advantage of being of definable order, but I think that makes them harder to deal with at the lower levels
[22:33:55] <SWPadnos> yes
[22:34:20] <SWPadnos> I asked my mother to look for a 3rd-order type of equation that meets our needs
[22:34:41] <SWPadnos> specifically, one that you can solve an equation for length
[22:34:47] <SWPadnos> instead of doing integration
[22:35:09] <rayh> If active line is handled by task, we may need to add a var to canon commands that reflect the line each canon command is produced fron.
[22:35:35] <SWPadnos> "line" has no meaning for non-text input formats
[22:35:35] <jmkasunich> turning nurbs or other splines into arcs is not an optimal solution
[22:35:56] <jmkasunich> nurbs are inherently 3-d, arcs are 2d
[22:35:57] <SWPadnos> additionally, I think xemet's code uses multiple lines to define control points, then one to execute
[22:36:00] <SWPadnos> yes
[22:36:26] <SWPadnos> the example I gave my mother (a decidedly non-practical mathematician) was a sine wave
[22:36:34] <rayh> You can add a third to an arc but it is planar.
[22:36:46] <SWPadnos> arcs are second order, I think he meant :)
[22:37:10] <SWPadnos> I'm not sure if a cubic is as far as we would need to go or not
[22:37:47] <SWPadnos> obviously some high-order NURBS path could be desired by the user, but that should be able to be split into several third order segments (I think)
[22:39:11] <SWPadnos> the idea isn't necessarily to make all sorts of functions available, it's to increase the amount of information a single command transfers
[22:39:11] <jmkasunich> SWPadnos: no, I meant 2D
[22:39:17] <SWPadnos> ok
[22:39:24] <jmkasunich> 2.5D if you want to call it that - helical is NOT the same as 3D
[22:39:31] <SWPadnos> nope
[22:39:49] <SWPadnos> can't NURBS be used in 2-space? (not that it's all that useful)
[22:40:00] <SWPadnos> ie, leave all Z = 0
[22:40:51] <jmkasunich> yes, you can define a 2d spline
[22:41:04] <jmkasunich> but being limited to 2d reduces their usefullness a lot
[22:41:31] <SWPadnos> sure - you get a 3rd-order curve in a plane
[22:41:50] <rayh> are we suggesting that we add NURB_FEED to the canon and motion coord stuff to do that?
[22:42:41] <SWPadnos> NURBS need variable amounts of data, I think (which NML can't do)
[22:42:57] <SWPadnos> unless you set a maximum number of control points and always transfer that size buffer
[22:43:38] <jmkasunich> why nurbs as opposed to other kinds of splines?
[22:43:48] <SWPadnos> no reason yet
[22:43:59] <rayh> I guess I'm not up to understanding this.
[22:44:00] <jmkasunich> some are defined by four points - fixed amount of data to pass
[22:44:02] <SWPadnos> I'm sort of waiting to see what my mother comes up with on the 3rd-order equation front
[22:44:14] <jmkasunich> then you just string them together
[22:44:17] <rayh> why not modal nurb_feed
[22:44:25] <rayh> and each point a block.
[22:45:01] <SWPadnos> I think that's what xemet added
[22:45:05] <SWPadnos> (but hasn't checked in)
[22:45:08] <jmkasunich> how some points are path points, and some are control points
[22:45:19] <jmkasunich> -how
[22:46:47] <rayh> bbiab dinner
[22:47:12] <jmkasunich> same here
[22:47:23] <SWPadnos> that makes three of us, I think
[22:55:08] <alex_joni> bye all, I should be back on sunday evening
[23:07:39] <alex_joni> alex_joni is now known as alex_joni_away
[23:14:43] <jepler> SWPadnos: yes, xemet is using the same approach I started with, but he's expanded it from cubic splines to general NURBS
[23:15:07] <jepler> while the implementation for milling turns them into arcs, that's done after the CANON calls which do pass the nurbs information
[23:16:34] <jepler> the current CANON calls confine NURBS to the XY plane, and the implementation in terms of arcs confines them to "some plane", even if the limitation at the canon layer is lifted
[23:18:09] <jepler> so while arcs are fine in terms of giving any desired accuracy for a planar NURBS curve, they are not fine in terms of allowing general XYZ movement
[23:18:49] <jepler> that's one reason my excitement about the approach waned, the other being the difficulties of doing an emc-appropriate adaptive subdivision
[23:18:51] <cradek> if it would help, I bet I/we could generalize arcs
[23:19:04] <jepler> cradek: the biarc method doesn't work for nonplanar curves
[23:19:13] <cradek> oh
[23:19:14] <jepler> AIUI
[23:19:40] <jepler> * jepler disappears again
[23:57:36] <rayh> Thanks for that nice summary, jepler.
