Back
[00:03:58] <LawrenceG> anybody know if there is a sim version/config of classicladder?
[00:25:01] <jepler> LawrenceG: demo_sim_cl, I think
[00:28:07] <LawrenceG> jepler, thanks
[00:39:52] <cradek> jmkasunich: neat. hope they're good.
[00:40:08] <jmkasunich> so do I
[02:38:49] <jmkasunich> I'm looking forward to milling the port - its the first contour milling I've done
[02:39:19] <jmkasunich> just did a dry run of the program, then ran it again with a piece of 1/8" al sheet instead of a casting
[02:39:41] <jmkasunich> that gave me an outline I could compare to the engine block port - they match pretty well
[02:41:07] <SWPadnos> cool
[02:41:15] <SWPadnos> what kind of stepover did you end up with?
[02:41:51] <jmkasunich> right now I'm using 0.050 sideways
[02:42:05] <jmkasunich> after each level is cut, I go down 0.0375
[02:42:27] <jmkasunich> each level is a little smaller than the previous, to give a nice smooth flow pattern
[02:42:59] <SWPadnos> 1/4 ball end mill?
[02:43:04] <jmkasunich> 1/8"
[02:43:19] <SWPadnos> oh. I'd expect that to scallop a bit, but maybe the diagonal helps
[02:44:16] <jmkasunich> the bulk of the cutting is near the side of the cutter, so the geometry helps reduce the scallops
[02:44:30] <jmkasunich> they might get bigger near the bottom of the hole, as the sides get less steep
[02:44:43] <SWPadnos> yeah, it's a 30 degree angle downward
[02:45:19] <jmkasunich> http://jmkasunich.com/pics/port-2.png
[02:45:41] <SWPadnos> damn. can't zoom ;)
[02:45:43] <jmkasunich> the path at the top is the uncompensated port shape, traced 0.1" above the flange
[02:46:00] <jmkasunich> I'm gonna post the .ngc, but I suspect you aren't running AXIS at the moment
[02:46:06] <SWPadnos> hold off a sec
[02:46:55] <SWPLinux> ok, how about now? :)
[02:47:08] <jmkasunich> http://jmkasunich.com/pics/port-2.ngc
[02:49:27] <SWPLinux> cool. is that a roughing pass on top then finish the whole way?
[02:49:49] <jmkasunich> the thing at the very top will be removed - its a pass with no offset, high enough that it cuts air
[02:50:11] <jmkasunich> then I do 20 levels, at 0.0375 each, total depth 0.75"
[02:50:28] <jmkasunich> the first 10 levels have three passes, with stepover of 0.050
[02:51:02] <jmkasunich> once I get deeper, I go to only two passes, I won't be removing as much material down there, as my contour blends with the cored one
[02:51:30] <jmkasunich> I suspect that I'll be cutting a lot of air, but the dry run only took 10 mins
[02:51:55] <jmkasunich> if it gets annoying, I can reduce the number of levels where I do 2 passes
[02:52:03] <jmkasunich> and can even go to only 1 pass near the bottom
[02:52:11] <cradek> that looks very cool
[02:52:53] <jmkasunich> I still have to do the code (and toolchange) for drilling the mounting holes
[02:54:01] <cradek> this makes my project look like child's play
[02:54:21] <jmkasunich> jepler's offs made this almost child's play
[02:54:39] <jmkasunich> I can't imagine doing it any other way
[02:54:59] <jmkasunich> the g-code is 1026 lines ling
[02:55:02] <jmkasunich> long
[02:55:41] <jmkasunich> I just had to do a little hacking so I could offset the pattern to the side as it goes down
[02:55:58] <jmkasunich> and compute the offset amount as a function of Z to get the curve I wanted
[02:56:21] <jmkasunich> double t = 0.0625;
[02:56:21] <jmkasunich> double s = 0.050;
[02:56:21] <jmkasunich> double z = -0.0375 * i;
[02:56:21] <jmkasunich> double o = 1.77-sqrt(1.777*1.777 - z*z);
[02:56:25] <jmkasunich> t = tool radius
[02:56:28] <jmkasunich> s = stepover
[02:56:30] <jmkasunich> z = z
[02:56:37] <jmkasunich> o = offset for contouring
[02:57:11] <jmkasunich> the actual offset passed to jeff's code is the sum of N*s + t + o, where N depends on the pass, 2, then 1, then 0
[02:57:43] <cradek> that's really neat.
[02:57:48] <SWPLinux> hmmm. does highlighting as described here work for you guys?
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Highlighting_In_Gedit
[02:57:55] <cradek> it's exciting that you did it with all free software.
[02:57:57] <jmkasunich> just spotted a typo, I wonder if thats why the hole seemed to be a few thou bigger than the block port
[02:58:19] <jmkasunich> cradek: well, almost all
[02:58:25] <cradek> SWPLinux: I don't use gedit so didn't mess with it
[02:58:37] <jmkasunich> I drew the original port outline from measurements of the block using easycad
[02:58:45] <cradek> ah
[02:58:46] <SWPLinux> I'm pretty sure it used to work, but it doesn't seem to on jmk's code, using sim on 7.10
[02:58:50] <jmkasunich> then picked off arc endpoints and lines
[02:59:01] <jmkasunich> then fat-fingered that data into jeff's program
[02:59:44] <cradek> I like ed nisley's approach of graph paper and calculator. he must be more brave/patient/? than I am
[02:59:54] <jmkasunich> me too
[03:00:10] <jmkasunich> easycad does a really nice job of drawing fillets, then telling me where they intersect the lines
[03:00:18] <SWPLinux> draft / measure / type in manually? :)
[03:00:38] <cradek> yeah I assume you'd get better at it after a while, if you did it manually.
[03:00:50] <jmkasunich> SWPLinux: that is reasonable if you are only doing the base path and letting the g-code do the offsets and such
[03:00:56] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/ (epp.c epp.h Submakefile): this adds a simple userspace driver for epp
[03:00:57] <jmkasunich> insane if you have to do it for every pass
[03:01:24] <SWPLinux> heh - yep
[03:02:00] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: This makes programming the 7i43 work.
[03:02:25] <jmkasunich> my base path has 6 lines and 9 arcs - not unmanagable by any means
[03:04:38] <jmkasunich> goodnight
[04:26:58] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: Duh, make it not so slow.
[05:19:10] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/ (bfload.c epp.c epp.h): pull out the parport setup code into the epp library
[08:54:59] <alex_joni> jepler: there are some changes on AXIS which I would like to discuss sometimes with you
[08:55:11] <alex_joni> (I am a bit worried about changing it myself ;)
[08:55:49] <alex_joni> the main thing is that AXIS currently reads some things from the ini file directly, and I would like for these to go through task (with proper NML messages to get a certain key/section)
[08:56:30] <alex_joni> right now I got stumbled upon AXIS also having things hardcoded like axis limits and joint limits (reading them from [AXIS_*] MIN_LIMIT, etc..)
[12:20:52] <cradek_> cradek_ is now known as cradek
[12:28:21] <jepler> alex_joni: until you have a way to retrieve a cartesian work volume, you should simply disable all the code related to reading information about min/max limits in axis.
[12:31:30] <alex_joni> do you only use it for that?
[12:31:47] <alex_joni> (I mean, it isn't used for joint limits or something like that.. right?)
[12:31:47] <jepler> I think so
[12:31:55] <jepler> when jogging in joint space? no,.
[12:32:05] <alex_joni> ok, I'll hack away and see how bad I can break it ;)
[12:32:22] <alex_joni> but remember that you told me so (when I come around screaming for help :)
[12:32:36] <alex_joni> <- obviously kidding
[15:31:13] <rayh> Is there any thought about updating the lyx docs to 1.5.3 with the 8.04 lts?
[15:32:36] <SWPadnos> I think I might remember a discussion about that - the issue may be that there's no supported version of 1.5.3 on 6.06
[15:32:47] <jepler> rayh: We have to stay on the present version for two reasons. First, as long as we build packages on dapper, we have to be able to build pdf documentation for that version. second, the lyx to html conversion software I wrote only parses the old file version.
[15:32:49] <SWPadnos> if I'm not confusing that with something else entirely
[15:33:10] <jepler> I haven't used newer versions of lyx; is there some feature that you're dying to have?
[15:38:46] <rayh> There are some really nice things related to the handling of graphics but mostly I was thinking of building the docs with the new release.
[15:39:16] <rayh> Perhaps I should try and see what the pdf stuff does from the new with the old docs.
[15:39:37] <rayh> If that works we'd have a start at it.
[15:41:14] <jepler> as far as I am aware, the docs will build fine using 1.3.7-format files on newer lyx versions
[15:41:47] <jepler> I have built pdfs using the existing makefiles as a part of the package building process, but I have never looked at the results
[15:43:28] <rayh> Okay.
[15:43:57] <rayh> I suppose mostly what I was thinking was what would happen to the 1.3 files when folk start editing using 1.5.3
[15:44:39] <rayh> from a standard 8.04 EMC2 install
[15:45:13] <jepler> here's what will happen: if someone commits a .lyx file which is not "\lyxformat 221" (the format written by lyx 1.3.6), it will break building the html documentation on any system, and it will break building pdf documentation on dapper systems.
[15:46:21] <rayh> Is there a cvs branching procedure that would take care of that?
[15:47:02] <SWPadnos> I think it's more of a package building procedure
[15:47:55] <SWPadnos> and it would be difficult to keep documentation in sync if there's a "new-docs" branch - someone had to backport changes using an older lyx install (which may not be able to load the newer files)
[15:47:57] <jepler> until we decide to end support for dapper, we simply should continue using 1.3.x-compatible files
[15:48:00] <rayh> Sure. I can see those kinds of problems.
[15:48:32] <cradek> I wonder if you could install dapper's lyx on newer systems with a whole mess of dependency problems
[15:49:04] <jepler> I don't see what value there is in writing documentation that we can't convert to HTML for use on the linuxcnc.org website, and that we can't package for new releases of the software on Dapper.
[15:49:08] <SWPadnos> the better approach would be to install newer lyx on the older systems (with all the problems that brings)
[15:49:08] <rayh> We'd better make that pretty plain to developer folk when we release the 8.04 version.
[15:49:17] <SWPadnos> if you're going to work at it, you might as well have the new features
[15:50:04] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/src/emc/sai/saicanon.cc: with lookahead, these debugging comments obscure the real regressions
[15:50:04] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/ccomp/mill-line-arc-entry/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:04] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/ccomp/mill-g90g91g92/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:06] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/ccomp/lathe-comp/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:09] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/ccomp/mill-zchanges/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:12] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/interp/flowsnake/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:15] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/interp/cam-nisley/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:18] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/tests/oword/sub.0/expected: with lookahead, these debugging comments obscure the real regressions
[15:50:23] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/rs274ngc.hh: with lookahead, these debugging comments obscure the real regressions
[15:51:15] <rayh> I did build a lyx 1.5.3 for 6.06 a while back.
[15:51:18] <cradek> SWPadnos: depends which is easier.
[15:51:29] <SWPadnos> heh
[15:51:31] <jepler> rayh: the wiki already notes "You should use only the version of lyx that is available for ubuntu 6.06 dapper drake, which is lyx version 1.3.7.", and docs/src/README also talks about version numbers. I don't know how to make it any plainer.
[15:52:09] <rayh> Sure. Not trying to be critical here. Just thinking out loud about one of the few areas I know anything about.
[15:52:21] <jepler> don't forget that we use custom software to convert lyx to html, and that would also require changes when we change lyx versions. I have no idea how extensively the lyx format has changed, it might be some simple stuff or it might be like writing the whole thing again
[15:53:26] <jepler> bbl
[15:56:10] <cradek> rayh: have you used cutter comp extensively on any other controls?
[15:56:47] <rayh> No not a lot. What are you thinking?
[15:57:21] <cradek> I'm wondering if allowing Z-only moves with comp on is peculiar to EMC or if it's widely allowed
[15:58:26] <SWPadnos> why would Z-only not be allowed?
[15:58:45] <rayh> I believe that it is widely allowed but I don't know.
[15:59:14] <cradek> mostly because it requires a deeper lookahead and is not strictly needed, and I bet everyone wants to not do things that are harder
[15:59:17] <rayh> I know that Synergy has a z entry to offset as a standard ability.
[16:00:12] <SWPadnos> for pocketing, it's easy to think about an XY positioning move (which applies comp), then a slow Z plunge into the pocket, then the profile moves in XY
[16:00:32] <rayh> Right that is exactly the mover
[16:00:38] <SWPadnos> the Z plunge could have XY added, but I don't think it should be required
[16:02:51] <cradek> I agree
[16:03:50] <cradek> but still the thing I'd like to know is what is "generally" allowed on other controls
[16:04:04] <cradek> I could try my BOSS (I've never used comp on it)
[16:04:31] <rayh> I could look at the fagor books I've got.
[16:05:22] <cradek> that would be nice if you could
[16:07:13] <rayh> phone brb
[16:35:12] <rayh> Mitts 50 says "The nose radius compensation command controls the compensation from that block in which G41 or G42 is commanded. A maximum of five blocks of program are preread and tool radius interference check is made for the shape in the three blocks during which nose radius compensation is made. The compensation plane, movement axes and next advance direction vector are based on the plane selection command -- g17-19.
[16:35:44] <rayh> That is the mill definition.
[16:36:53] <rayh> It looks like it allows for compensation in any move.
[16:40:52] <SWPadnos> is it just me, or is there some confusion regarding "5 blocks maximum preread" and "interference check ... in the three blocks ..."?
[16:41:39] <rayh> It does seem a bit like jinglish.
[16:41:47] <SWPadnos> or something :)
[16:42:00] <rayh> The mitts 500 book uses the same drawings but adds this.
[16:42:53] <rayh> The tool path is calculated by the intersection point arithmetic system and, as a result, excessive cut amounts on the inside of corners are avoided
[16:44:37] <rayh> Ah. This book says "up to five blocks of the program..., and a check for interference do to the tool diameter is made based on the shape of the THIRD block ahead.
[16:45:01] <SWPadnos> interesting
[16:45:08] <SWPadnos> so why read the next two? :)
[16:45:37] <rayh> I do not know.
[16:51:11] <rayh> The next section talks about 3-dimensional cutter compensation and shows the effect of "surface normal vectors."
[16:51:38] <rayh> These are entered using ijk values in the g41 command.
[16:52:02] <SWPadnos> interesting
[16:52:16] <SWPadnos> I think that can only work for linear moves, but it's an interesting idea
[16:52:48] <SWPadnos> maybe it can work for arcs as well, but I think I'd get a headache if I think about it too much
[16:53:10] <rayh> They are showing an xyz arc and the tool cutting the surface.
[16:53:28] <SWPadnos> XYZ arc?
[16:53:56] <rayh> But at the same time they list a g01 command for motion.
[16:54:00] <SWPadnos> is that a tilted arc or a helix?
[16:54:02] <SWPadnos> heh
[16:54:15] <SWPadnos> lots of short lines == "a circle!" :)
[16:54:38] <SWPadnos> hmmm. $100 for a Baldor 2HP washdown motor, shipped.
[16:55:24] <rayh> single phase?
[16:55:31] <SWPadnos> 3-phase, new
[16:56:03] <rayh> Nice. TEFC or TENV?
[16:56:29] <SWPadnos> hmmm. dunno
[16:57:17] <SWPadnos> looks like TEFC
[16:57:58] <SWPadnos> this model:
http://www.emd-inc.com/inventory/details.cfm?item=1041303840
[17:02:48] <rayh> Fantastic if you've got a 145TC mount
[17:03:38] <SWPadnos> heh
[17:03:42] <SWPadnos> I wonder what the BP has
[17:04:01] <SWPadnos> though the shaft size is smaller than the BP I think - it's 7/8 and I thought the BP had 1" or 1-1/4"
[17:06:28] <rayh> Frame size should tell you if there is a difference.
[17:07:31] <SWPadnos> I haven't removed my BP motor, but I know it's a 1.5HP. even so, an adapter plate isn't a hard thing to make (if the shaft is long enough)
[17:10:11] <rayh> Darn. I've got a couple BP motors loose but they are 30 miles away from here.
[17:11:03] <rayh> They are face mount but I don't know the size of the ring or bolt circle.
[17:11:18] <rayh> Got problems with the BP motor
[17:12:27] <SWPadnos> no. just something else to do to the machine before I actually do the retrofit ;)
[17:12:39] <rayh> Ah. Okay.
[17:13:02] <SWPadnos> the manual starter croaked the last time I tried to use the machine, and the spindle doesn't sound as good as I remember
[17:13:16] <SWPadnos> I think sitting in the hot/cold/hot/cold ... garage isn't so good for the machine :(
[17:13:31] <rayh> I've got a couple 3 hp that fits my moog. I'll check mounting and shaft diameter when I get a chance.
[17:13:52] <SWPadnos> this is a series 1 manual machine. I haven't looked at the motor size
[17:15:21] <SWPadnos> ok. I just checked it. it says frame size 145TY
[17:21:53] <rayh> So the shaft size should be the same.
[17:22:07] <SWPadnos> one would think so
[17:22:43] <rayh> I'm not acquainted with the ty frame.
[17:25:22] <SWPadnos> ah. "When a ?Y? appears as a part of the frame size it means that the motor has a special mounting configuration. It is impossible to tell exactly what the special configuration is but it does denote that there is a special non-standard mounting."
[17:25:52] <rayh> Okay.
[17:26:22] <rayh> Uniquely Bridgeport
[17:27:06] <SWPadnos> yp
[17:27:08] <SWPadnos> yep
[17:27:32] <SWPadnos> there is a mounting plate between the motor and the machine, so I could replace that if needed
[17:28:01] <rayh> Ah. Is this a timing belt drive?
[17:28:33] <SWPadnos> vari-speed, so yes, it has some sort of belting
[17:28:48] <SWPadnos> but not a timing belt I imagine
[17:29:20] <rayh> More like the snowmobile type vari-speed i suspect
[17:29:54] <SWPadnos> I don't know exactly how the sheaves work. I haven't had to take that apart yet (and I don't relish the thought of doing so)
[17:31:25] <rayh> probably spring loaded at both ends and the center just takes up between the two belts.
[17:31:34] <rayh> Need a vfd on it.
[17:31:53] <SWPadnos> yeah. I have the VFD already
[17:31:59] <SWPadnos> even have an enclosure for it
[17:32:58] <rayh> Great. Now an encoder on the spindle and you're good togo.
[17:33:42] <SWPadnos> yep :)
[17:33:51] <SWPadnos> plus the hydraulic back gear changer ... :)
[17:34:03] <SWPadnos> (or non-hydraulic - whichever)
[17:34:12] <cradek> meat-powered
[17:34:18] <SWPadnos> I have that already
[17:34:29] <cradek> can't wait to rigid tap on mine
[17:34:43] <SWPadnos> "dear meat. please turn the knob until the spindle speed is 2300RPM"
[17:35:10] <rayh> If I remember right you have to spin the tool a bit to get the backgear to engage right.
[17:35:18] <cradek> more like "dear meat: pleas hook up the damn air compresser again and wait for it to fill, then push the increase button until it says 2300RPM"
[17:35:20] <SWPadnos> a little bit, yes
[17:35:31] <SWPadnos> heh. not on my manual machine :)
[17:35:36] <cradek> I wish I had a knob instead
[17:35:39] <SWPadnos> I just have a little crank and a back gear change lever
[17:36:32] <cradek> I should see if I can take that silly air motor off
[17:36:54] <rayh> We spun the mazak spindle slowly during gear change.
[17:37:31] <SWPadnos> yep
[17:37:32] <cradek> yep I also have to do that on mine. even going into high gear.
[17:38:58] <cradek> I rarely use low gear, even with the 2.5" face mill. it goes down to 500 (I think?) in high
[17:39:57] <rayh> We mostly used low for tapping.
[17:43:13] <SWPadnos> with a VFD, low gear is the better one to use if possible, since motor power is reduced when you run at <60 Hz
[17:43:47] <SWPadnos> at higher speeds, you get full power (VFDs make the power output curve kind of like a stepper)
[17:44:01] <cradek> for rigid tapping I think you'd want to go slower in high gear, so you can reverse faster
[17:44:49] <cradek> mine coasts for a LONG time when shutting off in low gear, probably over 5 seconds
[17:47:54] <SWPadnos> that's not a powered decel though, is it?
[17:48:53] <cradek> nope, coast
[17:49:11] <cradek> but no matter, it'll take longer in low
[17:49:13] <SWPadnos> I think with a VFD, low gear powered braking would be much better
[17:49:29] <SWPadnos> the motor has more torque to decel the spindle
[17:50:18] <cradek> but isn't the inertia of the spindle effectively increased the same amount?
[17:50:39] <cradek> in fact maybe there's a square?
[17:50:41] <SWPadnos> uh - I don't think so
[17:50:55] <cradek> I'm anxious to try it now
[17:50:56] <SWPadnos> in low gear, the motor moves faster relative to the spindle
[17:51:14] <SWPadnos> so there's less reflected torque from the spindle to the motor (the load torque is lower)
[17:51:18] <SWPadnos> that is a square law
[17:51:29] <cradek> oh, hmm you may be right
[17:51:30] <SWPadnos> that means that the motor can accelerate the spindle faster
[17:51:34] <SWPadnos> or I'm not :)
[17:51:44] <cradek> no more than one of us is right
[17:51:48] <SWPadnos> I usually get things right or exactly the opposite :)
[17:53:19] <cradek> http://article.gmane.org/gmane.linux.distributions.emc.user/3384/match=tapping+gear
[17:53:56] <cradek> first match for 'tapping gear'...
[17:54:05] <cradek> I don't see anything else useful
[17:54:53] <SWPadnos> interesting. I wonder who's right :)
[17:55:03] <cradek> no more than one of us :-)
[17:55:14] <cradek> the other possible right answer would be that the gear makes no difference
[17:55:21] <SWPadnos> "at most one of us" :)
[18:13:36] <cradek> http://www.cnczone.com/forums/archive/index.php/t-22822.html
[18:14:39] <SWPadnos> I'm suspicious that these are all examples of running a machine without active deceleration
[18:15:19] <cradek> http://www.cnczone.com/forums/showpost.php?p=414949&postcount=3
[18:15:37] <cradek> sure could be.
[18:15:49] <SWPadnos> I could be neglecting the effect of the back gear spinning faster, which might be a significant source of inertia
[18:16:48] <seb_kuzminsky> i sent some email to the emc-dev list about an hour ago and haven't seen it come out yet, is that much lag normal?
[18:17:14] <SWPadnos> it's sporadic. sometimes things will show up in seconds, sometimes in hours
[18:17:17] <cradek> no, it is usually fast. but sometimes sourceforge is constipated.
[18:17:26] <cradek> I recommend not resending
[18:17:35] <seb_kuzminsky> i'll wait
[18:17:35] <cradek> they rarely lose message, but sometimes they are delayed
[18:17:40] <cradek> messages
[18:17:45] <seb_kuzminsky> thx
[18:18:03] <jepler> Is "well don't do that, then" ever a valid response to a bug report? (re the latest stepconf bug)
[18:18:21] <cradek> that's spelled "Doctor doctor!".
[18:18:32] <cradek> (and, probably no)
[18:19:30] <SWPadnos> it is stupid, but still would be a surprise if I had an axis moving and it never stopped because I hit a down-arrow on the GUI
[18:19:57] <jepler> I wonder what the smallest allowed acceleration should be
[18:20:07] <SWPadnos> that's a very good question
[18:20:20] <cradek> http://www.cnczone.com/forums/showpost.php?p=308417&postcount=2
[18:20:24] <cradek> here's someone saying the opposite
[18:20:30] <SWPadnos> you could do some circular calculations based on the excursion and velocity settings
[18:21:41] <cradek> interesting, I had planned to try a test like this on the mazak:
http://www.cnczone.com/forums/showpost.php?p=308502&postcount=5
[18:23:13] <jepler> SWPadnos: down arrow? are we looking at the same problem report?
[18:27:40] <SWPadnos> I assume that the user set the accel to 0 when the axis test was running (assuming that's possible :) ), and the axis kept moving because it couldn't decelerate
[18:28:18] <cradek> I'm trying to not think that's funny
[18:28:30] <SWPadnos> it is funny, but also surprising
[18:33:37] <CIA-30> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: do not allow acceleration to go down to 0 in Test Axis (fixes SF#1938763)
[18:33:37] <CIA-30> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: do not allow acceleration to go down to 0 in Test Axis (fixes SF#1938763)
[18:34:26] <CIA-30> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: from branch: zero accel is bad
[18:39:14] <cradek> jepler: AXIS used to cause the splash screen to dismiss. In trunk I think this has stopped working.
[18:39:34] <jepler> cradek: yeah I know it used to dismiss the splash screen too
[18:40:18] <jepler> hm, works for me on india
[18:41:06] <jepler> oh, you are one of the people who has to "xhost +`hostname`" aren't you
[18:41:22] <cradek> no
[18:41:49] <cradek> I did have one machine in my xhost. I took that out and it fixed it.
[18:41:58] <jepler> well, that's why
[18:42:02] <cradek> thanks
[18:42:16] <jepler> X server insecure (must use xauth-style authorization); command ignored
[18:42:31] <jepler> ^^ this error is happening, but being suppressed
[18:42:40] <cradek> right, had I seen that, I would have remembered that tk feature
[20:05:26] <CIA-30> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix several regressions
[20:11:39] <SWPadnos> oops
[20:12:30] <cradek> the only one left is where someone turns the spindle off with comp still applied
[20:12:58] <cradek> I think I need to forbid everything that's not motion or feed rate change, while comp is on
[20:13:05] <SWPadnos> oh - that was my oops, not a comment on your fix :)
[20:13:33] <SWPadnos> I accidentally clicked the "send in HTML" option instead of "send as plain text" for my last response to the dev list
[20:13:50] <cradek> SWPadnos: dude, fix your mailreader so you don't send html-only to the lists
[20:13:56] <cradek> heh
[20:13:59] <cradek> read, then type?
[20:14:02] <cradek> me? never
[20:14:46] <SWPadnos> heh
[20:15:18] <cradek> <small>but then I don't see any reason for html mail ever...</small>
[20:15:43] <SWPadnos> yeah, I'm pretty much agreed on that point
[20:16:02] <SWPadnos> but my mailer supports it, which allows me to mis-click on occasion
[20:16:03] <SWPadnos> lucky me!
[20:16:25] <SWPadnos> hey -do you have a few minutes to read my EMC2 paper?
[20:16:38] <SWPadnos> it's about 10 pages of actual content
[20:16:40] <cradek> you have to click something with the mouse to send a message?
[20:16:50] <SWPadnos> sometimes. I use a GUI after all
[20:17:11] <cradek> yeah, send it (or a link) to me
[20:17:15] <SWPadnos> I can also hit enter if I haven't switched focus between hitting "send" and the options coming up
[20:17:19] <SWPadnos> ok. I'll mail you a PDF
[20:17:33] <SWPadnos> (can't publish it until after the conference blah blah ...)
[20:17:49] <cradek> I'll try not to leak it then
[20:18:01] <SWPadnos> Oh good. thanks
[20:23:02] <SWPadnos> one thing - if you have access to a system with RT on it, can you try the HAL example? I don't know that I got it completely right
[20:23:18] <SWPadnos> (I only have sim at the moment, so parport is problematic)
[20:23:24] <CIA-30> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/comp.lyx: fix the sincos example to work (thanks awallin)
[20:23:51] <SWPadnos> ok. bbiab. breakfast time
[20:24:07] <CIA-30> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/hal/comp.lyx: from TRUNK: fix the sincos example to work (thanks awallin)
