Back
[00:41:44] <alex_joni> g'night all
[00:42:12] <jmkasunich> cradek: you around?
[00:42:17] <cradek> yes
[00:42:32] <jmkasunich> try emc -v, and pick you favorite config
[00:42:50] <jmkasunich> then look at the output
[00:43:03] <jmkasunich> for a line "Running HAL config file <blah>
[00:43:25] <jmkasunich> are there two slashes in a row before the filename?
[00:43:39] <alex_joni> * alex_joni noticed that a while ago..
[00:43:43] <cradek> Running HAL config file /etc/emc2/sample-configs/sim//core_sim.hal
[00:43:45] <alex_joni> yet it doesn't hurt
[00:43:56] <jmkasunich> well, that is where dave's goes south
[00:43:57] <alex_joni> I think it's the trailing / on the dirname
[00:44:09] <jmkasunich> it says "can't find <name with 2 slashes>
[00:44:13] <cradek> the slashes are a red herring
[00:45:04] <jmkasunich> how so?
[00:45:16] <cradek> extra slashes don't hurt anything
[00:45:21] <jmkasunich> ok
[00:45:53] <alex_joni> except webnames
[00:47:35] <jmkasunich> but thats still the spot where hes going south
[00:47:52] <cradek> then the path (not the slashes) is wrong
[00:48:09] <jmkasunich> yeah, I've got him looking at that
[03:59:06] <cradek> I have to admit I missed the diffs in the emails
[10:05:06] <Lerneaen_Hydra> logger_devel: bookmark
[10:05:06] <Lerneaen_Hydra> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-01#T10-05-06
[11:49:41] <rayh> logger_devel, bookmark
[11:49:41] <rayh> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-01#T11-49-41
[12:37:29] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[12:53:37] <rayh> SWPadnos, what conclusions did we come to concerning halconfig if any yesterday/
[13:03:12] <SWPadnos> I don't think we got as far as conclusions
[13:03:22] <SWPadnos> but we can try now, if you like
[13:04:06] <SWPadnos> actually, I think there were some things that came out of the discussion yesterday:
[13:04:31] <SWPadnos> 1) halconfig needs to be able to deal with HAL as it is now, because it isn't going to change before release
[13:04:53] <SWPadnos> 2) things will be better once everything is changed to comply with the new naming conventions
[13:20:27] <rayh> I can see this.
[13:21:12] <SWPadnos> I figured as much ;)
[13:21:45] <rayh> The only thing that bothered me about the new naming conventions was the ambiguous use of -
[13:21:59] <SWPadnos> in the new scheme, - is just part of a word
[13:22:09] <SWPadnos> (like hyphenation)
[13:22:24] <SWPadnos> can you use - in tcl names, or does that cause problems?
[13:22:25] <rayh> to separate words within a field and to designate a range of
[13:22:38] <rayh> no problems with tcl.
[13:22:38] <SWPadnos> no ranges in HAL
[13:22:40] <SWPadnos> ok
[13:23:05] <rayh> yes 0-3 is a range over which the parameter operates.
[13:23:23] <SWPadnos> but there would be 4 separate pins for that
[13:23:51] <rayh> no in the hal_introduction jmk shows an example of a single parameter frequency which does that.
[13:24:15] <SWPadnos> that's fine, because that's only one parameter, which affects all 4 outputs
[13:24:31] <rayh> but the dash means something else in that context.
[13:24:36] <SWPadnos> stepgen.00-03.pulse-width, for instance
[13:24:41] <rayh> than it does in other contexts.
[13:24:58] <SWPadnos> ok - I thought you were talking aboiut the new scheme, not "what we got now"
[13:25:15] <rayh> I am talking bout the new
[13:25:25] <rayh> but enough of my nit picking.
[13:25:27] <SWPadnos> in the new scheme, you would ignore dashes
[13:25:48] <SWPadnos> so you'd end up with something like 00-03 as a "word part" of some HAL parameters
[13:26:00] <SWPadnos> that could, of course, be problematic
[13:26:11] <SWPadnos> since 00-03 is actually "minus three"
[13:26:15] <rayh> Not if I am trying to explain the language of hal. Only if I am building a tree widget.
[13:26:26] <SWPadnos> right
[13:27:31] <SWPadnos> hmmm - those do throw a wrench in my plans though
[13:27:33] <rayh> As HEAD is, halconfig can save tuning values in the ini,
[13:27:56] <rayh> and it can save a netlist of current hal
[13:28:13] <rayh> it can not save hal changes to existing hal files.
[13:28:50] <rayh> It can also read a netlist for writable parameters.
[13:30:02] <SWPadnos> hmm
[13:30:17] <SWPadnos> I can't load my univstep config for testing.
[13:30:19] <rayh> I don't believe that I can build a hal change saving system using current variables.
[13:30:59] <rayh> right. that part is broke till we/i figure out how to handle ppmc names.
[13:31:09] <rayh> I guess that is the first task.
[13:31:17] <SWPadnos> are you thinking of something that could for instance add pins to a signal, in the hal file where the signal is created?
[13:31:24] <SWPadnos> no - I mean I can't run emc with that config
[13:31:36] <rayh> why?
[13:32:17] <SWPadnos> pin "axis.0.index-pulse-in" not found
[13:32:44] <rayh> oh. that was aparently changed in a lot of places.
[13:32:59] <SWPadnos> heh - not in my USC config ;)
[13:33:00] <rayh> I commented them out in m5i20
[13:33:03] <SWPadnos> ok
[13:33:21] <rayh> said I'd deal with em later but never did.
[13:33:40] <rayh> * rayh goes looking for the change
[13:34:02] <SWPadnos> hmmm - those are the same in both the stock univstep and my config
[13:34:38] <SWPadnos> strange - I thought the tool prep loopback was added to all the configs
[13:38:13] <rayh> axis.0.index-enable is the only index pin available today in head.
[13:38:35] <rayh> It may be that jmk changed the name of the pin when he got it working last week.
[13:38:46] <SWPadnos> I'm looking for the change that removed index-pulse-in from all the axes
[13:38:48] <SWPadnos> could be
[13:39:25] <SWPadnos> yep - removed index-pulse-in, added index-enable
[13:40:15] <rayh> okay that explains it. is it grep -r time on the configs directories
[13:40:31] <SWPadnos> I'm not sure. it seems weird to have index-enable, but no index
[13:40:39] <SWPadnos> nothing to enable
[13:41:20] <rayh> I though it a bit strange which is why I simply commented out the links.
[13:41:56] <SWPadnos> yep - just did that in my config. I'll ask JMK about it tonight
[13:42:13] <SWPadnos> not sure what he was thinking (and I haven't read the encoder canonical interface yet)
[13:42:40] <SWPadnos> ok - so back to the tree building problem
[13:50:20] <SWPadnos> hey wait. it looks like the problem with univstep is that the stepgen and encoder both get INPUT_SCALE from the ini file
[13:52:37] <rayh> I get blinking limit switches here. Drives me nuts.
[13:52:50] <rayh> Guess I'll have to shut down and add a parport card.
[13:53:03] <SWPadnos> stick in a bunch of pull-upts
[13:53:05] <SWPadnos> ups
[13:53:43] <rayh> only happens on three and four axes. looks like a com failure.
[13:54:02] <SWPadnos> the inputs are all in the same two bytes
[13:55:12] <rayh> I ran this for weeks without any pull up.
[13:58:00] <SWPadnos> ok. now I'm confused about this.
[13:58:18] <SWPadnos> I commented out all references to input_scale in the .hal files
[13:58:42] <SWPadnos> there is no pin or parameter that contains input_scale in its name
[13:58:59] <SWPadnos> and I still get the same error when trying to run halconfig on my univstep config
[13:59:14] <SWPadnos> Error in startup script: window name "label-0-input_scale" already exists in parent
[13:59:41] <rayh> That is the same message I get.
[14:00:03] <SWPadnos> the only thing I didn't comment out was the actual INPUT_SCALE settings in the ini
[14:00:29] <rayh> I think halconfig get's the list of tuning widgets to make from reading [ in the hal files.
[14:00:35] <SWPadnos> halconfig does ignore lines with # at the start, right?
[14:00:53] <rayh> Um, I don't think so.
[14:00:57] <SWPadnos> oops
[14:01:01] <SWPadnos> that would be a good thing ;)
[14:01:51] <rayh> I didn't think there were # in any of the varibles in axis sections.
[14:01:58] <rayh> I've never seen em.
[14:02:14] <rayh> but then I guess someone should be able to put them in there if they want.
[14:02:16] <SWPadnos> if I comment out a setting, halconfig shouldn't try to set it
[14:02:52] <rayh> halconfig tries to set any ini var that it finds a reference to in a hal file.
[14:03:09] <SWPadnos> right, but a commented line in the hal file means it's not actually referenced
[14:04:15] <rayh> yep. and those would show up still.
[14:04:41] <SWPadnos> I think that's what I'm seeing. I was trying to comment out some lines for testing, but they still acted like they're there
[14:05:55] <rayh> okay. I can fix that so it ignores # in hal
[14:06:14] <SWPadnos> ok. I was just trying to figure out how to do that (using regexp or something)
[14:06:41] <SWPadnos> ah - lsearch -regexp is probably what I want
[14:06:50] <SWPadnos> (just like you have it)
[14:11:12] <SWPadnos> ok. the problem here has nothing to do with HAL pin naming
[14:11:25] <SWPadnos> it's a problem with how things are set from the ini file
[14:12:58] <SWPadnos> the issue is that halconfig doesn't deal with multiple HAL parameters that are set from the same ini variable
[14:13:07] <rayh> darn can load it now.
[14:13:33] <SWPadnos> in the case of the PPMC, both stepgen.xx.scale and encoder.xx.scale are set from [AXIS_nn]INPUT_SCALE
[14:13:40] <rayh> so if there are more than one, it should simply ignore the extra.
[14:13:57] <SWPadnos> yes, or group the variables together, and only show one edit box
[14:14:09] <SWPadnos> it's not a simple question
[14:14:20] <rayh> but it is the same variable as long as we are reading and writing to the ini file.
[14:14:41] <SWPadnos> right, but the user doesn't have the ability to "unlink" the two (which may be fine)
[14:14:42] <rayh> but it should have multiple calls to halcmd
[14:14:55] <SWPadnos> we should just change the ppmc / univstep to use separate vars for those
[14:15:10] <SWPadnos> that would solve the problem
[14:15:32] <rayh> What would happen if someone used different values for these.
[14:15:38] <SWPadnos> it was just easier to make the input and output use the same value
[14:16:09] <SWPadnos> using a gecko, it probably wouldn't work, but it's conceivable that it could work with some other driver
[14:16:26] <SWPadnos> maybe
[14:17:16] <SWPadnos> one way of thinking about it (in the context of halconfig) is to have a list of ini vars, each of which has a list of all the HAL parameters that are set from that ini var
[14:17:47] <rayh> so loop through hal files and make a list
[14:17:59] <rayh> then loop again looking for params
[14:18:28] <rayh> then foreach param issue the value.
[14:18:29] <SWPadnos> or jus add any params to a list in the first loop, using the ini var name as the list index (or array - sorry)
[14:19:16] <SWPadnos> crappy pseudocode: array add bigfatarray(ininame) new_param_name
[14:19:50] <SWPadnos> damn - what a red herring that naming thing was
[14:20:00] <rayh> np
[14:20:30] <SWPadnos> at least we'll have a standard for the next version, and people like jmk know what's needed for the tillie crowd
[14:20:50] <rayh> yes.
[14:21:05] <rayh> If you look at the existing tree,
[14:22:17] <rayh> you'll see that what now shows as pin -> axis ->0 through 7 will then show as eight separate lines.
[14:22:36] <rayh> at the level immediately below pin.
[14:22:50] <rayh> It will make traversing a bitch.
[14:23:15] <SWPadnos> when wioll it look this way? (would I find the answer if I'd read the canonical naming convention document?)
[14:23:59] <rayh> I was reading hal_intro in head.
[14:24:08] <SWPadnos> ah. maybe I should do that as well
[14:24:35] <rayh> not needed for this today.
[14:24:38] <SWPadnos> weird - I have neither latex nor lyx on this (BDI-4.30) install
[14:25:37] <rayh> No paul abandoned them a while back.
[14:25:42] <rayh> In the interest of space.
[14:25:50] <SWPadnos> damn - 38M to download
[14:25:52] <SWPadnos> yep
[14:26:01] <rayh> yep
[14:26:13] <SWPadnos> jmk made a pdf last night though, right?
[14:26:26] <Lerneaen_Hydra> how far progressed are the thread-turning cababilities in emc as of now? (AFAIK all other regular 2d operations (things that don't rely on the spindle's position) work perfectly).
[14:26:51] <SWPadnos> threads look perfect to me, but I'm sure there are still some little things to be straightened out
[14:27:40] <Lerneaen_Hydra> is the specific
[14:27:44] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-cutting.jpg
[14:27:49] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-done.jpg
[14:27:52] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-check.jpg
[14:28:03] <Lerneaen_Hydra> err. sorry, are the specifications in the standard NIST Gcode files?
[14:28:16] <SWPadnos> darned good question
[14:28:38] <rayh> Yes there is a new pdf in head.
[14:29:11] <SWPadnos> damn. I can't get everything lyx depends on without doing an apt-get update
[14:29:36] <cradek> http://www.timeguy.com/cradek-files/emc/nut-test.jpg
[14:29:43] <rayh> yuck. I killed several bdi-4.30's that way.
[14:29:46] <Lerneaen_Hydra> How would I get a copy of the lathe-version of EMC, or does the current version support both mill and lathe specific codes? (by current version I mean the ones that I get from cradeks apt repositories)
[14:29:53] <SWPadnos> yeah - me too
[14:30:11] <rayh> There is no lathe spec in the NIST work.
[14:30:28] <cradek> Lerneaen_Hydra: the 4/29 testing has basic lathe functionality in it, but there are a few fixes since then in HEAD
[14:30:49] <cradek> threading really isn't intended to be in emc 2.0.0
[14:31:07] <Lerneaen_Hydra> rayh: how do you get the encoder on the spindle to adjust the motor speed if ther is no lathe-specific code?
[14:31:37] <rayh> spindle motor speed in the old emc was open loop.
[14:31:38] <Lerneaen_Hydra> cradek: I will possibly get hold of a smaller cnc lathe sometime this week, and will hopefully be able to play around with it
[14:32:20] <cradek> Lerneaen_Hydra: sounds fun
[14:32:40] <Lerneaen_Hydra> rayh: by motor speed I meant the stepper/servo motor speed so that it takes into account the non-uniform spindle rotational speed (as can be heard in the movie that cradek posted on the mailing list)
[14:33:20] <cradek> brb
[14:33:48] <Lerneaen_Hydra> I'll brb myself too
[14:35:08] <SWPadnos> rayh, would you like me to commit the change that ignores comments in hal files?
[14:46:12] <rayh> just did commit
[14:47:01] <rayh> also added it to emccalib.tcl but didn't commit yet.
[14:47:17] <rayh> want to put in the ignore second instance.
[14:47:44] <SWPadnos> ok
[14:47:53] <rayh> Lerneaen_Hydra, We may be speaking of different EMC's here.
[14:48:25] <rayh> I am thinking of the documents from NIST that describe and build the last EMC that they worked on.
[14:49:19] <rayh> All of the spindle encoding, speed control is a recent addition to that work by NIST.
[14:50:35] <cradek> Lerneaen_Hydra: I think I didn't understand your original question, could you ask it again please?
[15:06:13] <Lerneaen_Hydra> cradek: what is needed (software-wise) to get thread-turning to work (which version of emc, special configs, and so on). Or is such functionality still in a pre-release state
[15:07:09] <Lerneaen_Hydra> rayh: what I meant was the Gcode specification at linuxcnc.com, that appeared to be from NIST.
[15:09:59] <cradek> for software version, you will want to use the cvs head, because there are some bugfixes to threading there now, and lots of work will be done on it in the next few weeks
[15:10:48] <cradek> there is currently only one gcode command that does threading, and it is not mentioned in the rs274ngc specification.
[15:12:19] <Lerneaen_Hydra> cradek: that sounds.. intuitive, I take it that it will be added to an EMC-specific derivative later on? (is that code in the wiki somewhere?)
[15:12:51] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?SpindleSynchronizedMotion
[15:12:59] <cradek> very basic documentation here
[15:13:29] <Lerneaen_Hydra> cradek: how do I set EMC up to use the cvs head version? (prefferably alongside an existing version (in this case the standard apt-get version, that uses your apt reps)
[15:14:10] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Installing_EMC2
[15:14:15] <Lerneaen_Hydra> cradek: from that code I take it conical threads are not possible at the moment?
[15:14:27] <Lerneaen_Hydra> or are they?
[15:14:29] <cradek> that's described in sections 1.1 1.2 1.3 1.4 of this page
[15:14:58] <Lerneaen_Hydra> will it b0rk my current installation?
[15:15:01] <cradek> you can make multiple synchronized moves together, so you could write a conical thread with a series of G33 commands
[15:16:00] <cradek> no you can build and run HEAD separate from your installed version.
[15:17:33] <Lerneaen_Hydra> cradek: would something like this work (x is the diameter and z is the axis along the spindle)?
[15:17:35] <Lerneaen_Hydra> G21/G20 (whichever is MM)
[15:17:36] <Lerneaen_Hydra> g0 x10 z0
[15:17:38] <Lerneaen_Hydra> g33 x20 z-40 k2
[15:17:40] <Lerneaen_Hydra> g0 x22
[15:17:41] <Lerneaen_Hydra> g0 z0
[15:17:43] <Lerneaen_Hydra> g0 x11
[15:17:44] <Lerneaen_Hydra> g1 x9.9
[15:17:46] <Lerneaen_Hydra> g33 x19.9 z-40 k2
[15:17:47] <Lerneaen_Hydra> ...
[15:18:10] <jepler> oh hey .. how are you guys?
[15:18:49] <Lerneaen_Hydra> and if so where is K measured across, the hypotenuse of the movement (in this case the step/turn would be 1/sqrt(2))?
[15:19:17] <cradek> yes you should be able to do a cone that way
[15:20:06] <cradek> yes the feed is distance along the path per revolution, so if you're moving at 45 degrees you often want pitch * sqrt(2)
[15:20:27] <cradek> hi jepler
[15:20:33] <Lerneaen_Hydra> hello jepler
[15:21:07] <Lerneaen_Hydra> cradek: wouldn't is be pitch*(1/sqrt(2))?
[15:21:08] <cradek> I intend to change the K to F because K implies that the feed per revolution is the projected feed along Z, which it's not
[15:21:29] <Lerneaen_Hydra> cradek: F sounds more intuitive to me
[15:21:39] <cradek> no, because you want to move farther per revolution, so multiply by sqrt(2) (which is >1)
[15:22:14] <cradek> beware I'm only guessing what you want here
[15:22:35] <Lerneaen_Hydra> cradek: then I must be confused, is K/F measured along the hypotenuse or one of the axes?
[15:22:45] <Lerneaen_Hydra> cradek: Do I need to rebuild AXIS?
[15:22:47] <cradek> the hypot (the programmed path)
[15:23:13] <Lerneaen_Hydra> cradek: then I understand what you meant wrt 1/sqrt or not
[15:24:28] <cradek> in threading.ngc in cvs, you can see my multi-pass compound feed threading program with 45 degree synchronized exit cut
[15:26:04] <Lerneaen_Hydra> cradek: do I need to rebuild axis?
[15:26:43] <cradek> to run axis in your cvs version, you should untar the axis source under emc2/src, it will build automatically when you build emc
[15:27:14] <Lerneaen_Hydra> untar to the same dir?
[15:28:28] <SWPadnos> it should end up in a subdir, called emc2/axis
[15:28:38] <SWPadnos> oops - emc2/src/axis
[15:28:59] <Lerneaen_Hydra> SWPadnos: okay
[15:29:33] <SWPadnos> you can also make that a link to another directory that contains axis
[15:29:35] <Lerneaen_Hydra> (just to clarify, should this discussion be in emc-devel or emc, or is it irrelevant?)
[15:29:37] <jepler> re-run configure and read the messages to see whether it detected axis.
[15:31:24] <jepler> SWPadnos: so you've been building axis in this way? Any problems, except for the occasional verbosity?
[15:31:26] <cradek> hmm, using F in G33 messes with F modality, maybe that's a bad idea
[15:31:40] <SWPadnos> jepler, yep, and I haven't noticed any problems
[15:31:58] <SWPadnos> though I did notice that the revision is up to 1.4a(something)
[15:32:24] <jepler> yeah that's what you get if you're using HEAD
[15:32:53] <cradek> Lerneaen_Hydra: about your sample program: are the start and end of the angled g33 cuts both outside the work? if not you need synchronized entry/exit cuts
[15:32:55] <SWPadnos> yep - new checkout as of a day or two ago
[15:34:13] <Lerneaen_Hydra> cradek: I wasn't really envisioning any material at all in that example, just testing the way to input parameters (if that was a real program I would need lead in/out)
[15:34:23] <cradek> ok
[15:34:45] <Lerneaen_Hydra> cradek: does emc keep sync when going from one line to another?
[15:35:15] <cradek> do you mean adjacent g33 lines, or multiple passes with jogs in between?
[15:35:33] <jepler> SWPadnos: nothing new is happening on HEAD so far, but if it gets unstable you might want to switch over to the main1_3 branch.
[15:35:42] <SWPadnos> ok
[15:36:20] <cradek> for adjacent g33 lines in a program it maintains synchronization and blends the moves
[15:36:21] <Lerneaen_Hydra> both ;)
[15:36:34] <cradek> multiple passes with jogs in between resynchronize using the encoder's index pulse
[15:36:57] <cradek> exactly like how you would use a threading gauge on a manual lathe
[15:37:01] <Lerneaen_Hydra> so it's not possible to have multiple thread leads at the moment?
[15:37:17] <cradek> sure, for two starts, offset one of them half the pitch in Z
[15:37:42] <Lerneaen_Hydra> ah, ok
[15:38:30] <cradek> maybe I should make some more complex demo programs
[15:39:34] <Lerneaen_Hydra> cradek: that may be good, reading a test program is (IMO) an easy way to learn how to do things
[15:40:56] <cradek> this existing g33 command that can sync in any direction lets you do almost anything you want, with clever enough gcode programming
[15:42:11] <cradek> the only thing missing is the ability to stop/start the spindle while still synced
[15:43:21] <Lerneaen_Hydra> cradek: so in actuality the thread turning cababilities are well progressed?
[15:43:52] <Lerneaen_Hydra> cradek: any idea when thread turning is released to testing-branch?
[15:44:10] <skunkworks_wrk> Cradek: - scroll would be cool - or threads on a arc. :)
[15:44:16] <cradek> definitely no sooner than late may
[15:44:40] <Lerneaen_Hydra> threads on an arc should be possible with a CAM app
[15:44:47] <cradek> as far as I know, I'm the only one who has cut threads, but it works well. I'll let you decide if you want to call that well-progressed
[15:44:51] <Lerneaen_Hydra> if it uses line-interpolated-curves
[15:45:11] <cradek> what's scroll?
[15:45:34] <cradek> LH is right, you could thread an arc approximation if you want, but I have no idea why you would do that
[15:45:35] <Lerneaen_Hydra> however a thread-on-a-curve would be rather hard to attach to a bolt/nut ;)
[15:45:54] <cradek> a tapered thread is useful, and is easy to do already
[15:46:45] <Lerneaen_Hydra> cradek: is it possible that there would be the same bug when doing line-interpolated-cruves when doing threads in the same manner (bad accel. when going from one line to another)
[15:47:39] <cradek> sure
[15:48:07] <SWPadnos> hmmm - freqgen is actually a frequency generator, rather than a "step generator", right? (ie, takes a rate as input, not a position)
[15:48:08] <cradek> but like the other glitch you saw, in practice it probably won't affect the finish of the work
[15:48:20] <cradek> SWPadnos: yes
[15:48:58] <Lerneaen_Hydra> I was thinking that it would affect the surface much more as now we want a very even spacing between the threads?
[15:49:00] <cradek> talking about line-interpolated threading, I may try to cut a fusee:
http://mvheadrick.free.fr/photos/uklf.html
[15:49:37] <Lerneaen_Hydra> that would be a real PITA to make manually...
[15:49:44] <SWPadnos> ok. I'm editing hal_introduction, and was considering changing the short description to "frequency generator"
[15:50:14] <cradek> Lerneaen_Hydra: the english made them for 200 years by hand using a "fusee engine"
[15:50:48] <Lerneaen_Hydra> cradek: A machine made for just making them? well then it's probably far easier (I was thinking manual lathe and hard tools)
[15:51:00] <cradek> right, a special machine
[15:51:43] <Lerneaen_Hydra> cradek: EMC2 dies and says "Can't execute DISPLAY program /home/emc/cvs/emc2/bin/axis", it seems axis didn't compile. (I tried to run axis sim)
[15:52:08] <cradek> Lerneaen_Hydra: did you put the axis source tree inside emc2/src?
[15:52:15] <Lerneaen_Hydra> yes
[15:52:31] <cradek> did you run configure after that?
[15:52:35] <Lerneaen_Hydra> in a directory called emc2-axis-1.2rc3
[15:52:58] <cradek> I think you have to call it axis.something
[15:53:20] <cradek> http://www.makingthemodernworld.org.uk/stories/manufacture_by_machine/03.ST.01/img/IM.0424_zp.jpg
[15:53:20] <Lerneaen_Hydra> oh, is that the newest version of axis or is it outdated?
[15:53:31] <cradek> (fusee engine and a huge clock fusee)
[15:53:46] <Lerneaen_Hydra> what were fusee's used for?
[15:54:32] <cradek> in that image the clock's spring is wound inside the barrel on the right. As you wind it, the string pulls harder, and the chain winds up the fusee (decreasing the radius) to equalize the force
[15:54:46] <cradek> err sPring pulls harder
[15:55:26] <cradek> so as the clock runs down, the force coming from the spring stays just the same
[15:56:09] <cradek> the english used these in pocket watches with hand-made chains so fine they fit through a needle eye
[15:56:12] <Lerneaen_Hydra> oh.. that's rather complex. *me really hopes that the inclination is linear and not logarithmic or something)
[15:56:25] <SWPadnos> x^2
[15:56:37] <SWPadnos> spring force is a square law
[15:56:43] <Lerneaen_Hydra> cradek: how does one make a chain that size in the 1800's, I wonder
[15:56:44] <cradek> I think it was usually matched to the spring experimentally
[15:56:58] <SWPadnos> very small files and a magnifying glass
[15:57:06] <cradek> Lerneaen_Hydra: one link at a time, I think usually women made them
[15:57:11] <SWPadnos> and endless hours of labor
[15:57:26] <cradek> probably the links were stamped and finished by hand, but I don't know for sure
[15:57:33] <SWPadnos> cradek, have you seen the big catalog of exceedingly expensive watches?
[15:57:36] <Lerneaen_Hydra> argh...
[15:57:44] <SWPadnos> I don't remember what it's called
[15:57:56] <cradek> SWPadnos: I'm sure I've seen many of those :-)
[15:58:07] <SWPadnos> these were in the $200k and up range
[15:58:21] <cradek> that's a bit out of my league
[15:58:35] <SWPadnos> mine too, but the book was at a local coffee shop
[15:58:43] <cradek> nice pictures I bet
[15:58:46] <SWPadnos> very nice
[15:58:57] <SWPadnos> I'll look up the name the next time I go there
[15:59:02] <SWPadnos> the book is pretty impressive
[16:01:17] <cradek> somewhere I have a picture of a chain out of one of my watches under the microscope, but I can't find it
[16:01:47] <cradek> I put it through a needle and set it on a dime for scale
[16:02:09] <SWPadnos> heh
[16:03:50] <skunkworks_wrk> cradek: scroll would be a lead cut from say the senter of a disk out. (you would see them in a 3 jaw chuck - what you turn to make all of the teeth move in and out the same)
[16:03:55] <skunkworks_wrk> center
[16:04:13] <cradek> right, of course
[16:04:34] <Lerneaen_Hydra> so a thread just along the X axis?
[16:04:49] <skunkworks_wrk> right
[16:05:17] <cradek> sure, you can already do that
[16:05:21] <Lerneaen_Hydra> that should be very possible at the moment, assuming i've understood that
[16:05:37] <Lerneaen_Hydra> *understood everything so far
[16:06:01] <cradek> but doing that on a cnc mill is probably better if your diameter is very big
[16:10:34] <jepler> Lerneaen_Hydra: To put the axis source directory inside the emc2/src directory requires axis 1.3a2 or newer
[16:10:41] <jepler> Lerneaen_Hydra: it won't work with 1.2
[16:11:06] <jepler> Lerneaen_Hydra: if you have axis 1.3a2, what message did you get when you re-ran configure? It should say something like
[16:11:10] <jepler> checking for AXIS source... will build axis from axis
[16:11:12] <jepler> or "from axis-1.3a2"
[16:11:34] <jepler> whatever the directory name is
[16:12:15] <cradek> oops I forgot about that
[16:16:10] <cradek> aha
[16:16:17] <cradek> http://timeguy.com/cradek-files/emc/fusee.jpg
[16:16:24] <cradek> this is a watch I repaired
[16:16:31] <cradek> http://timeguy.com/cradek-files/emc/dime.jpg
[16:16:51] <cradek> picture of the chain, needle, dime
[16:17:51] <cradek> http://timeguy.com/cradek-files/emc/fusee2.jpg
[16:18:01] <cradek> after repair, running
[16:26:13] <SWPadnos> what do people think about me adding siggen.0.time and siggen.0.tmax to the hal demo section? (I'm not sure if they were left out on purpose)
[16:26:27] <SWPadnos> hal demo section of hal_introduction.lyx
[16:26:46] <SWPadnos> err - "A Simple Example" section
[16:27:39] <cradek> I doubt much of anything is left out on purpose
[16:27:46] <SWPadnos> ok. :)
[16:28:05] <SWPadnos> I think the time and tmax parameters are optional though, through some compile-time switch
[16:29:16] <Lerneaen_Hydra> jepler: Ah, ok. I had a 1.2 version
[16:29:18] <SWPadnos> hey - I could just read the notes about that ;)
[16:29:28] <Lerneaen_Hydra> where would I get 1.3a2 or newer?
[16:29:36] <jepler> the axis website axis.unpy.net
[16:31:18] <Lerneaen_Hydra> is the cvs snapshot semi-stable, runnable, or completely dead (in genereal)
[16:31:32] <Lerneaen_Hydra> (by dead I mean not-able-to-run)
[16:31:52] <cradek> we never leave it broken
[16:31:56] <jepler> .. for long
[16:32:03] <cradek> it's generally quite good
[16:32:08] <jepler> but right now there's nothing in the CVS snapshots that's not in 1.3a2
[16:32:28] <jepler> soon I want to do some destabalizing things in the HEAD of axis cvs, so it may be not very usable for awhile
[16:33:49] <Lerneaen_Hydra> is it usable right now?
[16:34:09] <cradek> yes
[16:34:18] <SWPadnos> works for me (tm)
[16:37:43] <jepler> which reminds me .. I should release 1.2.3 since it does have one important bugfix (the 0 vs 360 degree arc thing)
[16:37:54] <jepler> er, 1.2.2
[16:38:46] <Lerneaen_Hydra> jepler: is there a gui-to-change-toolpath-color-tool in the axis roadmap?
[16:39:44] <jepler> Lerneaen_Hydra: No. You have to use the X Resource Database
[16:40:15] <Lerneaen_Hydra> X Resource Database? What is that?
[16:40:37] <jepler> It's a very old way to configure X programs.
[16:41:48] <jepler> from the 1.3a2 release notes:
[16:41:48] <jepler> The colors used in the the plot area can be modified by the X Resource
[16:41:48] <jepler> Database. For an example light-background configuration, execute
[16:41:48] <jepler> xrdb -merge doc/axis_light_background
[16:41:48] <jepler> before starting emc.
[16:49:13] <Lerneaen_Hydra> that sounds like a very bulky way of changing the colors
[16:51:10] <jepler> the biggest problem with the X Resource Database is that the creators of every widget set more modern than Motif and Tk either didn't know about it or pretended it didn't exist.
[16:56:05] <Lerneaen_Hydra> logger_devel: bookmark
[16:56:05] <Lerneaen_Hydra> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-01#T16-56-05
[16:56:42] <Lerneaen_Hydra> so the X rescource is old/outdated?
[16:57:00] <SWPadnos> you know, it would be nice if halcmd would let you link a signal to multiple pins with the linksp command
[16:57:23] <SWPadnos> liek linksp X-Vel siggen.0.cosine stepgen.0.velocity
[16:57:30] <SWPadnos> like
[17:00:08] <Lerneaen_Hydra> cradek: the threading-ngc doesn't do much for me, it just runs to line 6 then stops (line 6 is the one prior to the G33 movement, could it be waiting for the index signal?) I am running sim/axis as my config
[17:33:22] <SWPadnos> I think we determined that the HAL naming convention would use <device-name>.<device-num>.<io-type>.<chan-num>.specific-name (ie, dots between each section, rather than dashes in some and dots in others)
[17:33:31] <SWPadnos> does anyone think that's not true?
[17:58:47] <cradek> Lerneaen_Hydra: yes, it's waiting for the spindle, try running "max" which has a simulated spindle encoder
[17:59:29] <jepler> SWPadnos: I'm sure in favor of regularity
[17:59:40] <SWPadnos> me too
[17:59:58] <SWPadnos> I'm editing the hal book, and wasn't sure if the canonical naming section should be changed
[18:00:17] <SWPadnos> I'll wait for jmkasunich to pop on before I change it
[18:00:22] <Lerneaen_Hydra> random cool program of the day - Baudline (www.baudline.com)
[18:01:20] <Lerneaen_Hydra> cradek: in your MAX config, it says there are three axes, what are they? I can only think of two
[18:01:38] <SWPadnos> is spindle an axis?
[18:01:46] <Lerneaen_Hydra> oh, that may be
[18:01:50] <cradek> Lerneaen_Hydra: just ignore Y, it will be hidden eventually
[18:01:58] <cradek> no, the spindle is not an axis
[18:02:05] <SWPadnos> ah - once COORDINATES is actually used ;)
[18:02:34] <cradek> yeah I think there are a lot of assumptions about the axes going in order XYZABC that should be fixed eventually
[18:02:41] <SWPadnos> yep
[18:02:44] <Lerneaen_Hydra> cradek: there are some lathes with a physical Y axis though (though such lathes are probably out of EMCs scope for a long while)
[18:03:11] <cradek> Lerneaen_Hydra: there's no reason why you couldn't use Y
[18:03:33] <cradek> assuming it's orthogonal to X/Z
[18:03:38] <SWPadnos> tool offset comes to mind, but I know 0 about lathes (especially CNC)
[18:04:30] <cradek> same here
[18:04:48] <SWPadnos> bummer, since you're writing all the code ;)
[18:05:14] <Lerneaen_Hydra> cradek: I'm thinking that EMC isn't developed to be able to do c-axis work. (slowly rotate the spindle, sub 10rpm speeds, and let a separatly powered endmill remove material (running on a subspindle))
[18:05:18] <cradek> that's part of what fest is about - getting people with different kinds of expertise together
[18:05:35] <Lerneaen_Hydra> I've done quite a bit in CNC-lathes
[18:06:01] <SWPadnos> C axis is there already, it's just a sideways mill
[18:06:56] <Lerneaen_Hydra> oh? that sounds very nice
[18:07:15] <Lerneaen_Hydra> then there shouldn't be much left WRT turning with EMC
[18:07:36] <cradek> constant surface speed and lots of gcodes
[18:07:52] <Lerneaen_Hydra> G95/G96 comes to mind though (constant rotational speed/constant surface speed)
[18:08:17] <SWPadnos> also possibly "radius" control, for those lathes that have Z (or is it X?) and Y
[18:08:19] <cradek> I intend to do that at fest
[18:08:31] <Lerneaen_Hydra> radius control?
[18:08:45] <cradek> what's radius control?
[18:09:00] <SWPadnos> my made-up name for this:
[18:09:06] <Lerneaen_Hydra> typically a lathe will have a Z axis (along the spindle) and an X axis (paralell to it)
[18:09:29] <SWPadnos> if you can move the tool horizontally and vertically, then you may want to know how far from the spindle axis you are
[18:09:58] <SWPadnos> s/parallel/perpendicular/ ??
[18:10:30] <Lerneaen_Hydra> oh, you mean if you have two axes that are perpendicular to the spindle axis
[18:10:55] <SWPadnos> yes - X and Y in this case (as you were wondering for the milling scenario)
[18:12:03] <Lerneaen_Hydra> AFAIK though it's rare to have a secondary paralell axis
[18:12:04] <SWPadnos> actually, R or D words would be great for turning
[18:12:25] <SWPadnos> (radius or diameter)
[18:12:30] <Lerneaen_Hydra> unless it's a mill with a rotating table (table rotation is C axis)
[18:12:42] <SWPadnos> sure
[18:14:43] <Lerneaen_Hydra> oh, btw, how good is the support for a 3+2 mill?
[18:15:05] <SWPadnos> good question. send me a couple of motorized rotary tables, and I'll let you know ;)
[18:15:15] <SWPadnos> (along with nice Bridgeport motor mounts)
[18:15:20] <Lerneaen_Hydra> sure thing ;)
[18:30:12] <Lerneaen_Hydra> cradek: do you know how well advanced 3+2 milling is?
[18:32:25] <cradek> combined linear/rotary moves work as described by the kramer doc, other than that I don't know how to answer your question
[19:00:04] <Lerneaen_Hydra> what is the kramer doc?
[19:00:25] <alex_joni> a document describing RS274-NGC
[19:01:20] <cradek> in summary it says that in coordinated linear/rotary moves, abc follow xyz so they start and end together, feed rates being described along the xyz path
[19:02:31] <cradek> all constraints being are during the move, of course
[19:03:07] <cradek> uh, all constraints are honored during the move
[19:06:00] <Lerneaen_Hydra> by feed rates along the xyz path, does that mean that you may get moves that have higher feedrates than specified?
[19:06:25] <alex_joni> no
[19:06:27] <Lerneaen_Hydra> if doing xyz and abc moves?
[19:06:47] <alex_joni> it means that you specify feedrates only for XYZ (Fxxx)
[19:06:59] <alex_joni> and the ABC moves will start and stop along with the XYZ moves
[19:07:05] <Lerneaen_Hydra> if I was to do:
[19:07:07] <Lerneaen_Hydra> g0 x10 y0 z0 a0 b0 c0
[19:07:08] <Lerneaen_Hydra> g1 z-20 c360 f100
[19:07:23] <alex_joni> it would go from z0 to z-20 with F100
[19:07:27] <Lerneaen_Hydra> oh
[19:07:31] <alex_joni> that would mean a certain time
[19:07:34] <Lerneaen_Hydra> that would give you a higher feedrate
[19:07:42] <alex_joni> and in that time it would want to move c from 0 to 360
[19:07:50] <Lerneaen_Hydra> or well, the tool would experience a higher feedrate
[19:08:01] <alex_joni> but if the resulting C-move would be higher than the limits specified
[19:08:15] <alex_joni> then the whole moved will be rescheduled, so the max C-feed is not exceeded
[19:08:28] <cradek> you would have to take into account the radius when programming the feed if you want a certain tooltip feed
[19:08:38] <Lerneaen_Hydra> max c-feed could still be more than the tool can take
[19:08:55] <Lerneaen_Hydra> * Lerneaen_Hydra hopes that edgecam can compensate for that
[19:09:17] <cradek> emc can't do what you want unless it knows the radius, and it doesn't
[19:09:57] <cradek> you have one axis in mm and one in degrees, that's not enough information to calculate tooltip velocity
[19:10:06] <Lerneaen_Hydra> shouldn't it be able to calculate velocity?
[19:10:17] <Lerneaen_Hydra> or rather, radius, and from that velocity
[19:10:55] <Lerneaen_Hydra> if I go to X10 then emc knows that the diameter at tooltip is 10mm
[19:11:10] <alex_joni> IF the C axis is centered around XY
[19:11:27] <Lerneaen_Hydra> and from that line I guess C isn't always
[19:11:29] <Lerneaen_Hydra> erk...
[19:11:33] <cradek> the spec only says they are parallel
[19:11:38] <Lerneaen_Hydra> that makes things more difficult
[19:17:49] <SWPadnos> I don't think the spec specifies that it's the work that rotates, either. I think you can have a pivoting head (like a Bridgeport), and still be "within spec"
[19:20:23] <jepler> that's just a matter of switching a few signs around
[19:23:15] <alex_joni> jepler: yes, but you need some knowledge to do that
[19:23:39] <alex_joni> you can't just feed some g-code to emc and assume it will do what is needed, without knowing how the machine is set up..
[19:23:44] <SWPadnos> it also changes the tooltip speed equation a lot, as well as changing how the linear axes should be handled
[19:43:45] <Lerneaen_Hydra_> logger_devel: bookmark
[19:43:45] <Lerneaen_Hydra_> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-01#T19-43-45
