Back
[00:17:04] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[03:47:13] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[08:31:55] <micges> there is a typo in emcmodule.cc, line 885:
[08:31:58] <micges> PyErr_Format(PyExc_ValueError,"Spindle direction should be STATE_ESTOP, STATE_ESTOP_RESET, STATE_ON, or STATE_OFF");
[10:02:51] <micges> as you probably know in trunk after change source of soft limit value from ini to stat buffor caused incorrect extend preview of machine
[10:08:03] <micges> while running program in trunk, on mdi page when you selected command in history and hit enter, that command will be executed after end of program(dangerous!)
[11:39:17] <BigJohnT> does the Live CD ever get updated with newer versions of the manuals?
[11:42:02] <cradek_> every so often it is remade with updated packages [including emc2] but usually we just expect people to run the updates after installing.
[11:42:07] <cradek_> cradek_ is now known as cradek
[11:43:27] <BigJohnT> I was just loading the live CD on a computer and noticed that there was no real starting point for a newbee
[11:46:07] <BigJohnT> a "Getting Started" meun item and some more work on the Getting Started Guide I think would cover that area...
[11:47:07] <cradek> I can help you get that added to the menu. it only requires a new file in the emc2 package. then it will show up with the updates, and eventually make its way onto a new cd
[11:47:21] <BigJohnT> I've been testing all the things in the getting started menu with a fresh computer to see what is missing
[11:47:23] <BigJohnT> thanks
[11:48:00] <cradek> that's a good plan. a fresh look helps.
[11:48:18] <BigJohnT> the getting started is in 2.2.x and trunk now
[11:48:36] <cradek> I better get ready for work. I'll read back later.
[11:48:43] <BigJohnT> me too
[12:11:21] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: fix typo noted by micges
[12:14:41] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: fix bug noted by micges: could use mdi history while program running
[12:18:33] <jepler> micges: I don't understand the third problem you are reporting, regarding changing soft limits. Doing this *should* change the red dashed lines, because those indicate the machine's soft limits. There *is* a bug that the lines don't move right away, but wait until you do something like click in the window, jog an axis, or so forth.
[12:18:48] <jepler> bbl
[12:23:06] <micges> jepler: I noticed delay after changing soft limit in preview, I understand why it is
[12:25:09] <micges> 3rd problem is no regarding to limits, when you will be online I will write steps to reproduce
[12:28:40] <micges> jepler: Ignore above
[12:34:24] <micges> I've downloaded trunk today and after loading sim/mm config soft limit is -+254, and in preview red line is indicating about many tousands
[12:45:10] <micges> jepler: your fix in axis.tcl didn't work
[12:51:51] <jepler> micges: ah, I understand the problem now
[12:52:03] <jepler> (limits)
[12:55:30] <micges> cool
[12:57:27] <jepler> huh -- this is weird. when I try to run involute.py, I get the message 'cannot do g1 with zero feed rate' 'near line 4' -- but there's an F-number set on the first line of the program
[13:00:13] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix problem reported by micges: soft limits display was wrong on mm machines
[13:03:12] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: continue fixing bug noted by micges: enter in mdi history listbox would send mdi command even when the list was deactivated
[13:13:39] <micges> jepler: all fixes works
[13:33:14] <jepler> micges: great, thanks for testing them
[13:34:09] <micges> np
[13:37:55] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: make plot update immediately when soft limits change
[13:39:41] <micges> jepler: in my axis I've done it the same way (last fix)
[13:40:15] <jepler> micges: are you using that feature (set soft limits at runtime)?
[13:41:34] <cradek> how do I do that?
[13:41:52] <micges> yes, about month or so, but was hard to think it together with preview ;)
[13:42:11] <jepler> cradek: well, there's no user interface for it yet
[13:42:30] <micges> It was half done, but now I backported it from trunk and works great
[13:42:38] <jepler> c = emc.command(); c.set_max_limit(axis, value)
[13:42:41] <jepler> or set_min_limit
[13:42:55] <cradek> does it let you expand them, or only reduce?
[13:43:00] <jepler> you can do either
[13:43:44] <cradek> I think it should allow reduce and revert, but never expand past the originals
[13:44:08] <jepler> the underlying NML message has always allowed anything
[13:44:37] <cradek> I understand. it might be something to handle in the gui.
[13:44:55] <SWPadnos> it ought to allow either - on a lathe, you'd set the limits based on the chuck you normally use, but if you take that off and mount something to the backplate, you'd want to be able to use the extra room
[13:45:13] <SWPadnos> or on jmkasunich's mill - remove the tailstock and you can expand limits
[13:45:19] <SWPadnos> (mill/lathe)
[13:45:59] <cradek> it's sure possible I'm wrong
[13:46:22] <SWPadnos> as always, there are (at least) two ways of handling it :)
[13:46:44] <cradek> each axis has a fixed travel - seems like there is a real maximum that you won't ever want to exceed, no matter the fixtures
[13:47:09] <SWPadnos> yep, and if you set your soft limits that way, you'd only want to reduce them
[13:47:18] <BigJohnT> yep
[13:47:34] <SWPadnos> if you set your soft limits to the maximum "always safe" area, then you'd want to be able to expand
[13:48:57] <SWPadnos> same mentality as referencing tool length to some value and using negative offsets
[13:50:16] <cradek> hm, I've changed the behavior of some configs. Previously, [TRAJ]*VELOCITY were ignored in free mode/trivkins, but I made the free mode planner honor them. the problem is that it defaults to 1.0 if not specified.
[13:50:29] <cradek> I meant [TRAJ]*ACCELERATION
[13:50:49] <cradek> maybe it should default to 1e+99, just like [TRAJ]*VELOCITY, so the axis limits are used
[13:52:02] <SWPadnos> hmmmm
[13:52:07] <jepler> 1 megabyte really isn't a very big framebuffer is it
[13:52:15] <SWPadnos> don't unspecified axis limits default to the TRAJ limit?
[13:52:19] <SWPadnos> heh
[13:53:26] <cradek> no, it looks like the axis values also default to 1.0
[13:53:36] <cradek> (although I think I remember the behavior you're talking about)
[13:54:34] <micges> jepler: I think there is a typo in last commit:
[13:54:34] <micges> self.stat.actual_position != o.last_limits
[13:54:56] <jepler> micges: argh, I think you're right
[13:55:06] <micges> should be limits != o.last_limits
[13:55:36] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix typo noted by micges
[13:55:51] <jepler> oops, I committed something unrelated
[13:56:09] <jepler> shouldn't hurt -- it reduces checking the error buffer from every 20ms to every 200ms (50 vs 5 times per second)
[13:56:17] <CIA-36> EMC: 03cradek 07TRUNK * 10emc2/src/emc/ini/initraj.cc: for configs that don't specify ACCEL values in TRAJ (which were previously ignored), let the axis values apply instead of using a very low default.
[13:56:56] <micges> jepler: shouldn't hurt, I have 10 times per second about year and it's ok
[13:59:16] <SWPadnos> ok good - it's not just me. I was wondering what magic was accomplished by checking to see if the position was on (all?) the limits
[13:59:52] <rayh> Fascinating note in IMService Newsletter. "The cnPOD basic control panel uses the EMC2 motion controller, which appears to offer the best motion control available for the hobby and small business budget."
[14:00:09] <SWPadnos> sure, *NOW* it appears to be the best :)
[14:00:36] <SWPadnos> hmmm - the motion controller huh?
[14:00:37] <cradek> aww shucks
[14:00:57] <micges> ok, end work for today
[14:00:59] <micges> bbl
[14:01:01] <jepler> see you micges
[14:01:07] <SWPadnos> I knew they were using the TP to create 1ms-sampled toolpaths
[14:01:32] <SWPadnos> I guess that's part of the motion controller, huh
[14:01:42] <rayh> It did seem that Fred was a bit quieter this workshop.
[14:01:49] <SWPadnos> heh
[14:02:03] <SWPadnos> he let his toolchanger do the talking (or something like that)
[14:02:33] <rayh> Sounds like they are running it black box with a usb connection.
[14:03:13] <rayh> That ought to trash a lot of our ability.
[14:03:21] <SWPadnos> the split they had was that a PC-based program would generate positions meant for 1ms intervals, and the ncpod would get those in bulk and "play them back"
[14:03:51] <SWPadnos> so the same problems exist with FO or threading, AFAIK
[14:04:33] <rayh> There is also a stand alone option with SD card. Uses only a cycle start button.
[14:04:43] <SWPadnos> hmmm. true
[14:04:44] <cradek> yes my understanding is the emc2 code is completely in the PC
[14:07:24] <rayh> He is even advertising multiple stand alone ncPODs with a single supervisor PC for loading programs.
[14:08:21] <SWPadnos> well, I guess all we need is the source code then :)
[14:10:18] <skunkworks_> cradek: you did good ;)
[14:10:36] <rayh> It would be interesting to see how the stand-alone box would behave with RTnet and a multi tasking GUI.
[14:13:03] <SWPadnos> well, it's USB, so it wouldn't connect to RTNet :)
[14:14:01] <rayh> right I was thinking ethernet
[14:14:25] <SWPadnos> I can't tell if you can just copy a G-code file to the SD, or whether it's got to have position sequences on it
[14:14:31] <SWPadnos> either way, it could run standalone
[14:14:34] <rayh> which I assume would be on the mobo they use.
[14:15:04] <SWPadnos> the PC would have ethernet, but the ncpod just has an FPGA or microcontroller on it
[14:15:13] <SWPadnos> (ca't tell, it's under a heatsink)
[14:15:16] <SWPadnos> can't
[14:15:33] <rayh> ah. Okay
[14:15:52] <SWPadnos> probably a microcontroller, it can only do 75000 steps/sec, and has no encoder inputs
[14:16:13] <rayh> How do they connect the SD?
[14:16:20] <SWPadnos> there's an SD card slot
[14:16:33] <SWPadnos> I can't see the bottom - the photo is only of the top
[14:16:52] <SWPadnos> there may be other components, but for the most part it looks ike a single chip and a bunch of connectors
[14:17:29] <SWPadnos> which is the same stupid design they had on the deskCNC controller revs 1 and 2: microcontroller pins connect directly to I/O connectors, no filtering or protection
[14:18:04] <jepler> that's "hobbyist"
[14:18:10] <SWPadnos> yeah, it should be
[14:18:12] <rayh> sounds like Fred
[14:18:41] <SWPadnos> even power goes straight to the chip
[14:18:59] <SWPadnos> no filter, no ferrites, I don't even see a cap
[14:20:14] <SWPadnos> (this is why I never get around to designing/selling CNC related products - I'm too paranoid to be able to make anything that's price competitive :) )
[14:22:47] <rayh> I know the problem.
[18:10:48] <skunkworks_> where is the picture of this controller?
[18:10:56] <cradek> google ncpod
[18:11:09] <SWPadnos> yep - ncpod.oemtech.com
[18:11:20] <SWPadnos> or something like that
[18:11:59] <skunkworks_> duh - for some reason I thought it was a imservice device
[18:12:18] <SWPadnos> they resell it in the SYS-5 CNC controller
[18:12:26] <SWPadnos> but it's hard to find out anything about it
[18:12:29] <SWPadnos> (from them)
[18:13:07] <skunkworks_> matt!
[18:13:14] <skunkworks_> oh - he left..
[18:13:18] <SWPadnos> s/^/bye /
[18:13:20] <SWPadnos> :)
[18:16:08] <skunkworks_> funny - emc2 TP(or whatever) and mach front end.
[18:16:22] <SWPadnos> not quite
[18:16:33] <SWPadnos> if you use gcodecompiler, that's the front end
[18:17:00] <SWPadnos> if you use Mach, it just uses the Mach plug-in scheme to send positions to the ncpod (instead of the software step generators)
[18:17:16] <fenn> gcc -o chips
[18:17:21] <skunkworks_> I like the discussion on gecko list about the hexapod.
[18:17:28] <SWPadnos> I think the device just plays back 6-axis positions, whether it's from USB or the SD card
[18:17:34] <SWPadnos> heh - yeah
[18:17:48] <SWPadnos> "Mach can do that"
[18:17:51] <SWPadnos> "no it can't"
[18:17:53] <skunkworks_> someone was sure to mention that mach will run a hexapod also - it has 6 axis.
[18:17:55] <SWPadnos> "EMC can do that"
[18:17:58] <SWPadnos> "really?"
[18:21:12] <cradek> while I have no doubt emc2 can run a hexapod much better than mach could, I would be surprised if anyone trying it would say it works well
[18:21:44] <SWPadnos> yeah, there are some joints/axes and teleop/coord/jog/home/free ... gotchas (from what I understand)
[18:23:07] <cradek> huh, I always was irritated by mutt's behavior when I reply to a message, then postpone it, then later finish it, then send it -- it doesn't mark the original with 'r' (replied to). but (unsurprisingly, I guess) you can set that flag with 'w' 'r' anytime you want.
[18:23:31] <SWPadnos> damn mutts
[18:25:59] <skunkworks_> but people have actually run a hexapod with emc...
[18:26:02] <skunkworks_> :)
[18:27:48] <SWPadnos> and with Mach
[18:28:33] <SWPadnos> but the DROs would do weird things, and I'm not sure what the G-code had to look like
[18:28:48] <SWPadnos> it wasn't full forward/inverse kinematics, that's for sure
[18:45:45] <cradek> http://www.frets.com/FRETSPages/Machining/Safety/LatheSafetyPix/lathesafetypix06.jpg
[18:48:59] <skunkworks_> hmm. that looks scary
[18:49:40] <cradek> better tighten that jacobs chuck real tight
[18:50:14] <skunkworks_> self centering?
[18:50:17] <skunkworks_> ;)
[18:50:28] <SWPadnos> http://www.albatron.com.tw/English/product/ipc/8600Go-256_Zoom.htm
[18:50:39] <SWPadnos> damn. how'd they know what I wanted to test that for?
[18:52:08] <alex_joni> haha
[18:52:23] <alex_joni> you can still test emc2 with it
[18:52:28] <alex_joni> maybe they don't like the BDI
[18:52:42] <SWPadnos> oh, could be :)
[19:04:51] <jepler> SWPadnos: that's funny
[19:05:12] <SWPadnos> thank you thank you - I'm here all week
[19:21:44] <rayh> Are we saying EMC doesn't run a hexapod correctly?
[19:26:52] <jepler> emc could do much better at controlling machines with nontrivial kinematics. Two main items come to mind: inifile confusion between joint-related and axis-related items, and dynamically staying within joint constraints when executing cartesian moves.
[19:27:53] <jepler> until recently the axis preview/backplot was largely useless for gcode with rotational moves but that's had some improvements recently
[19:28:30] <skunkworks_> I have an elitist view of emc and cradek tries to ground me..
[19:29:20] <rayh> Ah okay I can understand those limitations.
[19:30:26] <rayh> My experience with the nist related Stewart platforms is that it was quite good.
[19:30:32] <rayh> at the motion stuff.
[19:31:16] <rayh> I thought maybe that we'd lost something from 97 to now.
[19:32:23] <skunkworks_> only brain cells.
[19:32:39] <skunkworks_> * skunkworks_ is speaking for himself
[19:33:37] <rayh> I know that feeling.
[19:34:14] <rayh> jepler, singularity avoidance would be way high on my list of hexapod fixes.
[19:34:20] <skunkworks_> http://www.intertek-etlsemko.com/portal/page/cust_portal/ITK_PGR/OUR_SERVICES_PG/EMC_TESTING_PG
[19:34:53] <jepler> as soon as skunkworks_ gets his puma motors turning, we'll head up north for a mini-workshop
[19:35:09] <jepler> skunkworks_: you'll be paying for accomodation and meals, naturally
[19:35:22] <skunkworks_> jepler: would the geometry setting need to be set for the puma?
[19:35:24] <jepler> I know it's not exactly a hexapod, but at least it's not trivkins
[19:36:23] <skunkworks_> I was thinking of playing with trunk and watch the cone match the simulation of the final joint.. (if i understand it right)
[19:36:56] <rayh> Sounds like a lot of fun.
[19:37:24] <skunkworks_> :) mount it to the back of dads truck.
[19:37:26] <cradek> I agree
[19:37:44] <cradek> but for me, you'll just have to pay for gas for the bus
[19:37:47] <cradek> 'just'
[19:37:53] <skunkworks_> heh
[19:39:28] <SWPadnos> that's about like "just" paying for gas for the Jeep from here :)
[19:56:09] <skunkworks_> I'll send you guys some hydrogen generators..
[20:06:26] <alex_joni> jepler: I'm sure skunkworks_ will make room for your tent
[20:26:06] <jepler> alex_joni: I'm like SWPadnos -- I require comfortable surroundings
[20:26:45] <SWPadnos> wow:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813135091
[20:27:12] <SWPadnos> just add hard disk
[20:27:16] <jepler> bah -- not even an X2 ? I don't want it.
[20:27:27] <SWPadnos> $60 including CPU and memory ...
[20:27:31] <SWPadnos> and it has a parallel port
[20:27:59] <cradek> wow
[20:28:04] <alex_joni> jepler: how about cradek's bus?
[20:28:08] <SWPadnos> yeah, that's what I said ;)
[20:28:10] <cradek> that would make a great machine controller
[20:28:19] <alex_joni> if it works
[20:28:20] <SWPadnos> maybe it would, maybe it wouldn't :)
[20:28:23] <cradek> 512M is a little lean but probably fine
[20:28:32] <SWPadnos> if I order from newegg soon, I'll add one int
[20:28:35] <SWPadnos> -t
[20:35:05] <cradek> jepler: the jog speed slider on my hnc config goes down to the kind-of-silly 0.0003 in/minute and takes many seconds of holding , or . to go from one end to the other. is there a way I can coerce it into having fewer steps?
[20:35:43] <SWPadnos> aren't there min and max settings in the ini?
[20:35:56] <cradek> I think there is max only
[20:36:05] <SWPadnos> oh. nevermind
[20:38:17] <jepler> cradek: the low end of the slider is based on the inifile SCALE -- I think the lowest number is supposed to be one count per two seconds
[20:38:29] <jepler> with your machine's scale .. well .. maybe that's too small
[20:38:32] <cradek> oh, that would do it
[20:39:33] <cradek> that's ok, I don't care about the low end much. but if the key shortcuts would traverse faster it would be nice - I don't think that's peculiar to my odd machine
[20:43:06] <rayh> I believe that 0.0003 was in the code because a zero feedrate drifted.
[20:43:51] <SWPadnos> this shouldn;t be based on any old code, it's an ASXIS function to decide what the jog speed should be
[20:43:56] <SWPadnos> gah
[20:44:19] <cradek> SWPadnos: less coffee
[20:44:26] <SWPadnos> more more more more
[20:44:30] <SWPadnos> more or less
[20:44:34] <rayh> I know I did put a tiny value in someplace.
[20:44:56] <SWPadnos> cradek, actually, it's more like "less stuff between me and the keyboard" :)
[20:47:21] <skunkworks_> * skunkworks_ has the same problem
[20:48:03] <skunkworks_> http://www.electronicsam.com/images/desk.jpg
[20:48:11] <cradek> hm, my red dashed soft limit lines are gone
[20:48:17] <skunkworks_> hasn't changed much other than 2 flat pannels
[20:48:45] <SWPadnos> cool, looks like I'd be right at home
[20:49:00] <SWPadnos> man. consumer product lifecycles are really annoying
[20:49:30] <SWPadnos> my fine atomic watch band broke but it's semi-custom, so I can't find a generic replacement
[20:50:12] <SWPadnos> a replacement band (if they were in stock) is $23.00, a replacement battery will be ~$5.00 soon, but a replacement watch (if they were still made) would only be $29.00
[20:50:31] <SWPadnos> I should just use a rubber band or something
[20:50:57] <cradek> plastic watch?
[20:51:52] <SWPadnos> partly
[20:52:16] <SWPadnos> waterproof, atomic synch, digital and analog, had a leather band ...
[20:52:27] <SWPadnos> (Casio WVA104H)
[20:52:37] <SWPadnos> http://www.partshelf.com/ps-wva104hla-8av.html
[20:53:39] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[20:53:39] <CIA-36> EMC: new inifile items [DISPLAY] MIN_VELOCITY MIN_LINEAR_VELOCITY MIN_ANGULAR_VELOCITY
[20:53:39] <CIA-36> EMC: These set the approximate lowest value available on the jog speed sliders.
[20:53:39] <CIA-36> EMC: Because of the granular, exponential nature of the jog slider, the exact
[20:53:39] <CIA-36> EMC: requested value may not be the lowest value.
[20:53:42] <CIA-36> EMC: Order of preference: MIN_xxx_VELOCITY, then MIN_VELOCITY, then value inferred
[20:53:44] <CIA-36> EMC: from [AXIS]SCALE
[20:53:50] <jepler> cradek: ^^^ whiner
[20:54:07] <cradek> heh
[20:54:09] <cradek> cool, thanks
[20:54:25] <cradek> that affects the number of steps too?
[20:54:48] <cradek> trying...
[20:54:59] <jepler> I think so -- my recollection about how that worked didn't seem to match reality
[20:56:04] <jepler> I thought that there were a fixed number of steps and the values were distributed exponentially along those steps. but apparently the ratio between successive items is what is fixed, and so the number of total steps depends on the ratio between min and max values or the ratio of their logs or something
[20:56:19] <jepler> anyway .. mumblemumble .. maybe you can get what you want this way
[20:58:37] <SWPadnos> does it clip to the min/max or refuse to change if the new value would be outside the bounds?
[21:03:10] <cradek> I think it is using the inifile value as ipm, not ips
[21:03:30] <cradek> it does not seem to affect the number of steps
[21:04:07] <jepler> hmmmm really?
[21:05:09] <cradek> I set MIN and MAX to 0.1, 1.0 and I got 0.1 ipm to 60 ipm, with still a lot of steps
[21:07:22] <jepler> you're right about MIN being (incorrectly) in dist/minute not dist/second
[21:07:45] <jepler> but you do get a varying number of steps depending on the distance between them -- when the scale goes from 12 to 72 it's 64 steps, and when it goes from 60 to 72 it's 16 steps.
[21:08:29] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: treat MIN_xxx_VELOCITY as units per second, not per minute, for consistency
[21:08:41] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: ditto
[22:55:13] <jmkasunich> 16 steps to go from 60 to 72 is pretty fine
[22:55:30] <jmkasunich> 10-20 points per decade is probably enough
[22:55:42] <jmkasunich> * jmkasunich goes away for a while
[23:01:06] <CIA-36> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: make each keyboard increment on the jog speed sliders twice as large
[23:08:46] <jepler> there are a lot more orders of magnitude from 1/1024000 to 300 than there are from 1/4000 to 30
[23:09:00] <jepler> the latter being more like what I tested the jog slider against
[23:10:10] <SWPadnos> the scope-like 2-5-10 sequence may be good
[23:14:26] <SWPadnos> is this for jog increment or jog velocity? (or both?)
[23:24:43] <jepler> velocity
[23:25:44] <SWPadnos> ok. it seems to me that something based on resolution is useful only at speeds that are well below an interesting fraction/multiple of a user unit
[23:26:08] <SWPadnos> ie, below 0.0001, something based on N counts/sec may make sense
[23:26:32] <SWPadnos> above 0.0001 (or a similar decade value), the number of counts is no longer interesting
[23:28:27] <CIA-36> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Getting_EMC.lyx: added content
[23:31:16] <BigJohnT> jepler: MIN_VELOCITY etc. are AXIS only ini items?
[23:38:29] <jepler> BigJohnT: yes
[23:40:55] <BigJohnT> cool, you want me to add that to the docs?
[23:41:49] <SWPadnos> BigJohnT, in your vast traversals of the docs, have you seen any (semi-)comprehensive list of ini file settings?
[23:42:13] <BigJohnT> just in the integrators manual in the config section
[23:42:16] <SWPadnos> there used to be a list, waaaaay back in the early EMC1 days
[23:42:18] <SWPadnos> ok
[23:42:28] <BigJohnT> I keep adding them as I find them
[23:42:36] <SWPadnos> ok, cool,
[23:42:38] <SWPadnos> -,
[23:44:02] <CIA-36> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: some ini additions mostly
[23:53:56] <CIA-36> EMC: 03bigjohnt 07v2_2_branch * 10emc2/debian/extras-sim-Ubuntu-8.04/usr/share/applications/ (4 files): added getting started to menu (I think) and changed a few tool tips
