Back
[00:06:30] <rayh> I trust that folk will fix my reboot post where y'all see the need.
[00:11:05] <SWPadnos> I can't believe you told people they should count
[00:11:08] <SWPadnos> the nerve!
[00:15:23] <rayh> And start with the Arabic 0
[00:17:14] <rayh> How you doing this evening, SWPadnos
[00:17:59] <SWPadnos> just fine. you?
[00:18:12] <rayh> Good.
[00:18:33] <SWPadnos> great. did I hear earlier that you had frost last night? (or something close to it)
[00:19:03] <rayh> Yes a fairly hard frost. And snow in the air.
[00:19:13] <rayh> Tough on gardens.
[00:19:33] <SWPadnos> hmmm. I thought it seemed cooler today
[00:19:46] <SWPadnos> I wonder hoe the robin's eggs will do
[00:19:48] <SWPadnos> how
[00:20:15] <rayh> I'd bet they protect them.
[00:20:51] <SWPadnos> I'm sure they'll try
[00:21:38] <rayh> We had a nest several years ago less than 4 feet from the kitchen window.
[00:21:59] <SWPadnos> cool
[00:22:41] <rayh> Interesting to watch.
[00:24:21] <SWPadnos> yeah. I think the first egg was laid an hour or two after I was asking Jymmm about moving it
[00:25:57] <rayh> Really. Did you make the move?
[00:26:03] <SWPadnos> nope
[00:26:13] <rayh> Walk around?
[00:26:23] <SWPadnos> we'll just bring the hose around from the back if we need to water anything in the front :)
[00:27:23] <rayh> You put a web cam on it?
[00:27:28] <SWPadnos> nope
[00:27:38] <SWPadnos> I'm not sure I have one I can stick out there
[00:28:39] <rayh> I had an old B&W surveillance cam complete with waterproof enclosure and windshield wiper.
[00:28:56] <rayh> Tilt, pan, and zoom.
[00:29:06] <SWPadnos> heh - nothing like that here
[00:29:29] <rayh> I used the tilt and pan for something else with emc and tossed the camera.
[00:29:32] <SWPadnos> I have a small digital camera with a C-mount lens on it, which is sitting on bare boards :)
[00:29:39] <SWPadnos> kind of the opposite of weatherproof
[00:29:56] <rayh> Enclosure time.
[00:30:15] <SWPadnos> well, you need 6 axis control for a camera: pan, tilt, dutch, zoom, focus, and iris
[00:30:40] <SWPadnos> Ihave enclosures but the opacity isn't good for a camera
[00:31:16] <BigJohnT> good night
[00:31:23] <SWPadnos> see you
[03:56:26] <cradek> wow, jepler finished the naive arc detector tonight
[10:09:36] <fenn_> fenn_ is now known as fenn
[11:53:25] <cradek_> cradek_ is now known as cradek
[12:08:16] <skunkworks_> yikes
http://www.cnczone.com/forums/showpost.php?p=457118&postcount=7
[12:10:24] <rayh> What you thinking on that, skunkworks_?
[12:11:00] <alex_joni> funny :)
[12:11:33] <skunkworks_> I am suprised I guess.
[12:12:12] <skunkworks_> seems a bit poorly implimented.
[12:12:29] <rayh> Ah okay. The "workaround" for Mach sounds like a real kludge.
[12:13:05] <skunkworks_> like FO was an afterthought.
[12:13:08] <jepler> well -- it certainly simplifies a few things in the trajectory planner if the control derates accel at 100% FO and increases both accel and vel proportionally at >100%FO.
[12:13:42] <skunkworks_> I call that cheating ;)
[12:25:36] <jepler> it's just a different trade-off. if users like the advantages you can get (pre-planning probably makes >1 segment lookahead easier, for instance) then I don't see anything wrong with it.
[12:26:13] <jepler> sigh. launchpad automatically closed my question "how can I improve my users' experience with apport".
[12:26:20] <jepler> (because nobody had "answered" it)
[12:28:55] <skunkworks_> I understand. SWPadnos thoughts on mach's FO not taking effect until all the pre-read segments are done maybe is wrong then. They just dynamically change the accel and feed after the fact. (if I am understanding it right)
[12:31:02] <rayh> I fail to see the value of 5% accel if I set fo to that value.
[12:31:37] <rayh> And I am in "willing to learn" mode this morning!
[12:32:00] <jepler> hah
[12:32:27] <cradek> true, it only sounds vaguely useful if you stay very near 100%
[12:32:49] <cradek> I'm sure whoever wrote it knew it was a painful but necessary tradeoff
[12:32:54] <skunkworks_> exactly..
[12:32:56] <rayh> 100% of the machine's ability?
[12:33:06] <cradek> no 100% of FO in mach
[12:33:15] <rayh> Not 100% of some assigned feedrate.
[12:33:47] <jepler> here's one possible justification at low FO: With that scheme, at 5% the program will stay on the exact same path as if you were at 100%. Useful if you want to run it and see if the path clears some obstruction on your table. Compared to our system where it'll stay nearly on the exact path at 5% but maybe diverge wildly at 100% if you have a low inifile accel.
[12:34:10] <jepler> (exact path != exact same path)
[12:34:24] <cradek> very true jepler
[12:34:47] <rayh> Wildly as in 0.01 or so?
[12:34:49] <skunkworks_> Although we are making assumptions. maybe feed is the only thing changed < FO 100% and > FO 100 the accel and feed are increased. (if that works)
[12:34:50] <cradek> but at 101% that same path becomes impossible for the machine to follow ... uh-oh
[12:35:22] <skunkworks_> scratch that.
[12:35:46] <alex_joni> now toss adaptive-feedrate override in there
[12:35:54] <skunkworks_> (I have morning brain)
[12:36:21] <rayh> Seems like the thought is that max-vel is also overridden by FO >100%
[12:36:34] <cradek> skunkworks_: it's impossible to know exactly how closed software works, but the simplest implementation of FO is to "scale time" on the preplanned path
[12:36:37] <rayh> So that you could push feedrate faster than the machine was capable of.
[12:36:46] <cradek> rayh: yes I'm certain you are right.
[12:37:02] <cradek> I remember seeing this on steve stallings's demo machine a couple years ago.
[12:37:18] <rayh> Really!
[12:37:27] <cradek> I recall thinking wow, we fixed that in emc a long time ago :-)
[12:37:40] <jepler> heh
[12:37:55] <jepler> except you may have thought "I"
[12:37:57] <rayh> Yea. It worked when the code was still at nist.
[12:37:57] <cradek> jepler: I recall you're the one who noticed it
[12:38:03] <cradek> yes, "I", haha
[12:38:21] <rayh> Must have broken it someplace along the way.
[12:39:48] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457169&postcount=9
[12:39:53] <cradek> iirc, emc1's FO would violate velocity but not accel constraints at >100%
[12:40:01] <skunkworks_> another reply (why he wants to try emc2)
[12:40:47] <rayh> I don't seem to remember it being much of an issue because no one was thinking about serious contouring or cutting near max vel.
[12:42:44] <cradek> on my BOSS it scales the velocity up to 125%. even the rapids and jogs scale up. not a very smart implementation I guess.
[12:43:12] <cradek> wonder why I'm chatting instead of getting ready for work.
[12:43:37] <rayh> Avoidance?
[12:43:53] <cradek> http://www.cnczone.com/forums/showpost.php?p=457169&postcount=9
[12:43:54] <rayh> I think that's what it is here.
[12:44:27] <cradek> the sad thing about this post is he spent months on this problem, apparently without knowing what was really going on.
[12:44:44] <cradek> if he had known 'the accel scales too' he may have been able to work around it.
[12:44:48] <skunkworks_> I am sure everyone told him it was a hardware issue
[12:45:05] <rayh> We never do that;)
[12:45:54] <skunkworks_> heck no. ;)
[12:45:58] <jepler> on a related note, I see that aaron moore has now said he gets bad behavior at all speeds with mach as well.
[12:49:38] <alex_joni> jepler: it does sound like a PSU problem for aaron moore
[12:49:43] <alex_joni> but his troubleshooting is really chaotic
[13:01:51] <rayh> I'm still stuck on MAX_VEL as the upper limit of the motion of any axis.
[13:02:00] <rayh> 3-Mar-2000 FMP added fault to axis status; clipped axis jog vel to
[13:02:00] <rayh> AXIS_MAX_VELOCITY[] global
[13:03:49] <rayh> I do see a lot of fiddling with the velocity code back then. But it seems clear that intent is that an axis max vel is as fast as it was permitted to go under any circumstance.
[13:08:11] <rayh> 3-Mar-2000 FMP changed STRAIGHT_FEED to limit feed rate to axis max
[13:08:11] <rayh> velocities, as was done for STRAIGHT_TRAVERSE below.
[13:08:49] <SWPadnos> skunkworks_, when FO takes effect has nothing to do with how badly it affects accel :)
[13:09:30] <SWPadnos> I wonder if 125% somehow magically overflows some integer value that's used deep down in the step generation code
[13:12:08] <skunkworks_> Heh
[13:12:21] <SWPadnos> as cradek said, if you look at it as a "when does the next step pulse get output" question, then scaling everything in time makes a lot of sense
[13:12:53] <jepler> seems like it would end up depending on SCALE and such stuff
[13:13:29] <SWPadnos> yep
[13:14:07] <SWPadnos> and there are also 3 "max pulse rate" settings (I think), it's not continuously variable
[13:14:23] <jepler> bored now
[13:14:43] <jepler> somebody go find the new arc-related bugs I wrote yesterday
[13:15:19] <SWPadnos> I think they're in the code you wrote yesterday :)
[13:15:59] <skunkworks_> I suppose it is exponentally harder to combine multible arcs within the Px.xxx tollerence?
[13:16:03] <jepler> yeah but I dunno how to make the bugs manifest
[13:16:24] <SWPadnos> no, it's only geometrically harder ;)
[13:16:54] <alex_joni> jepler: tried torture.py ?
[13:16:57] <jepler> skunkworks_: the code doesn't combine arcs .. it turns tiny and nearly-straight arcs into two straight lines, then applies the existing line-related simplification code to them
[13:18:01] <skunkworks_> SWPadnos: funny. :)
[13:18:37] <cradek> jepler: I will review the code later, as if that can give you any more confidence
[13:19:09] <jepler> cradek: thanks for the offer -- I appreciate it
[13:20:30] <skunkworks_> jepler: I understood that from your explaination yesterday. I guess this does also fix the arc-line-arc issue.
[13:20:31] <jepler> somebody could also follow the given example to add support for G18/G19 arcs
[13:20:41] <jepler> skunkworks_: yes, I think it should
[13:23:59] <SWPadnos> is anyone else here a member ofthe geckodrive Yahoo group?
[13:25:20] <skunkworks_> yes
[13:25:33] <skunkworks_> I don't think I have ever posted there though.
[13:25:49] <SWPadnos> well, there's a thread about EMC2, and I want to respond to it, but I'd like someone else to read it through
[13:26:02] <SWPadnos> in fact, I think it's based off a commend you made on cnczone :)
[13:26:04] <SWPadnos> comment
[13:26:52] <skunkworks_> oh - crap.
[13:26:58] <skunkworks_> what did I do now ;)
[13:27:27] <SWPadnos> heh. Mariss started out a long post with this quote:
[13:27:29] <SWPadnos> "Emc2 does motion within itself. Any hardware that moves motion outside of emc isn't a good match. It would make emc2 not emc2 . Emc2 only requires 'dumb' cards that count encoders and maybe a few dac's, adc's or PWM if your build requires that. Emc closes the pid loop within software."
[13:27:38] <SWPadnos> I think I remember where that came from ;)
[13:27:45] <skunkworks_> actually - that is me quoting you... ;)
[13:28:03] <SWPadnos> yeah, me or somebody :)
[13:28:08] <skunkworks_> well - the first part anyways.
[13:28:16] <SWPadnos> yep
[13:31:13] <rayh> I'm of the impression that this came from some stuff Matt was suggesting regarding the rabbit.
[13:31:21] <SWPadnos> I don't think so
[13:31:39] <rayh> There was a two track approach to what the rabbit did.
[13:31:47] <SWPadnos> most of those discussions were too long ago to be relevant (unless Matt recently mailed Mariss privately)
[13:32:06] <rayh> No I don't think Mariss forgets.
[13:32:37] <SWPadnos> I've probably stirred that pot more - I've mentioned several times that the Rabbit is an impediment to G100 uptake in the EMC2 world, and that I might just make an ARM board to replace it :)
[13:32:38] <skunkworks_> I probably am out replaying to that.. (as I am the one that started it) ;)
[13:32:57] <rayh> IMO the EMC approach is the ability to determine what software might be running out there.
[13:33:07] <SWPadnos> I'm replying to it - just wanted others to read it
[13:33:48] <SWPadnos> well, from a certain perspective, we do have a deficiency in EMC2 - we can't use smart devices
[13:34:20] <SWPadnos> even though the motion controller essentially does exactly what a smart device would want - it outputs new positions every milllisecond
[13:34:21] <rayh> Sure we can, or should be able to. As long as we have access to what the smarts are and do.
[13:34:46] <SWPadnos> we shouldn't need access - it's like a stepper motor, but we only need to output the positions, not all the steps
[13:36:09] <rayh> Sorta but only sorta.
[13:36:13] <SWPadnos> yeah
[13:36:57] <rayh> If I can compile an EMC stepper module and run it outboard. Okay.
[13:37:18] <rayh> At least that way I know what it does or is supposed to do.
[13:37:22] <SWPadnos> well, if we could use any of the USB-connected devices, that would be great
[13:37:35] <SWPadnos> but there would be limitations to what you could do with one of those
[13:38:06] <skunkworks_> his comment about his stepper servo is mute I think.. emc will run it just fine as it will probably be step and direction input
[13:38:07] <rayh> Yea. The cost in terms of ability is the killer there.
[13:38:27] <SWPadnos> though it would probably do what 90+% of CNC users need
[13:38:39] <SWPadnos> skunkworks_, he gets corrected by Les Newell later :
[13:38:41] <SWPadnos> :)
[13:38:52] <rayh> Is this multi axis?
[13:39:16] <rayh> And does it do traj planning out there?
[13:39:25] <SWPadnos> oh, I know the tradeoffs :)
[13:39:43] <SWPadnos> and yes, they're all 4 or 6 axis, and they keep the axes synchronized
[13:39:54] <rayh> If yes then we have the same killer loss of override and such.
[13:39:59] <SWPadnos> but not to a spindle, or an MPG (unless that code is built into the end device)
[13:40:04] <SWPadnos> right
[13:40:18] <SWPadnos> but FO taking effect this millisecond isn't a huge problem for a lot of people
[13:40:33] <SWPadnos> I think it's icky, so I'll stick with EMC2 (when I get to the retrofit ;) )
[13:40:34] <rayh> How long ago did he promise this with the rabbit device?
[13:40:49] <SWPadnos> Steve Hardy promised it a looooong time ago ;)
[13:40:58] <SWPadnos> and the SmoothStepper is having the same problem
[13:41:26] <rayh> The factories in China that I visited sure could not get it to go.
[13:41:44] <SWPadnos> nope, I don't think anyone has it working, though I haven't checked the ncPod
[13:42:05] <rayh> Last I heard they had retreated to a totally dumb thing with parport.
[13:42:15] <SWPadnos> ncPod?
[13:43:54] <rayh> what is an ncPod?
[13:44:25] <SWPadnos> oh - that's the USB-connected device that uses a modified EMC2 planner to spit out 1ms positions, which are fed down the wire to the controller
[13:44:40] <SWPadnos> http://ncpod.oemtech.com/
[13:45:30] <rayh> Fred Smith and company?
[13:45:57] <SWPadnos> I think so
[13:47:31] <rayh> I tend to refer back to the NIST coffee cup for guidance on these sorts of things.
[13:47:36] <SWPadnos> I'm not sure they're selling it, actually
[13:47:39] <SWPadnos> heh
[13:47:47] <SWPadnos> I agree - we've got the better way
[13:47:51] <rayh> Sense -> Model -> Act
[13:48:06] <rayh> and do it at local, regional, and global levels.
[13:48:48] <SWPadnos> sure. so you could have a USB-connected multi-axis motion controller at one level, but you can't expect RT communications back to the PC
[13:49:34] <rayh> Right but the PC level must be an adequate supervisor.
[13:49:42] <SWPadnos> yep
[13:54:56] <rayh> I would personally hate to give up the halscope ability at the base thread level.
[13:55:22] <jepler> it just becomes a black box in the way that the pwm inside mesa is a black box .. you have to trust that it's working properly
[13:55:32] <SWPadnos> me too, but I think that doesn't impact most CNC users (or even most EMC2 users)
[13:56:04] <rayh> But it would be possible to run that level of data into a xxx at that level and then pass it and read it at the supervisory level.
[13:56:46] <SWPadnos> it may be possible, but maybe not. the reason to use a hardware step generator is because the PC can't twiddle the bits fast enough
[13:57:10] <SWPadnos> so if you want to see when each bit got twiddled, you'd need enough bandwidth for all those "base periods"
[13:57:18] <rayh> With mesa we do have the advantage of being able to look if we want to.
[13:57:21] <SWPadnos> heh
[13:57:29] <SWPadnos> or pluto - don't forget pluto!
[13:57:52] <rayh> Sure and ppmc
[13:58:04] <SWPadnos> well, we can't look in there
[13:58:38] <rayh> We can't look at the code in there but we can look at the effect of the code.
[13:59:06] <rayh> There are all kinds of levels of distributed tasks here.
[13:59:06] <SWPadnos> true, though not at a halscope level - we can't look at the step/dir pins in HAL
[13:59:10] <SWPadnos> sure
[14:00:03] <rayh> Clear up to the "black box" emc thing.
[14:00:41] <SWPadnos> ok - I know there are a lot of reasons for wanting the PC in direct control of everything. can we make a list?
[14:01:03] <rayh> I can make my MiniITX behave like a step generator.
[14:01:25] <SWPadnos> flexibility is one thing - we can change the way the machine works, both with HAL and with software changes
[14:01:41] <SWPadnos> things that should be RT, like feed override, are another
[14:02:14] <SWPadnos> synchronizing motion with an external device (MPG, spindle, axis to axis)
[14:02:25] <SWPadnos> homing
[14:02:27] <SWPadnos> probing
[14:02:41] <rayh> Some would argue that since the human has a hand on the override it is not inherently rt.
[14:02:52] <SWPadnos> non-trivial kinematics
[14:03:06] <SWPadnos> it's RT, but not on a millisecond timescale
[14:03:15] <SWPadnos> maybe 0.1 second lag is OK
[14:03:19] <cradek> is there any way to home to index on a servo machine with mach?
[14:03:28] <rayh> Sure.
[14:03:39] <jepler> cradek: last year we heard a guy explain how he did it, but it's a hack
[14:03:40] <SWPadnos> make a PLC that does it
[14:03:46] <rayh> That was not to the mach question. I know nothing re mach.
[14:04:01] <rayh> Except that it's about 740mph.
[14:04:04] <SWPadnos> I think he used external hardware to AND together the index and the home switch
[14:04:07] <jepler> cradek: roughly, the switch sets the input to the PC and the index pulse unsets it, so that mach just acts like there's a switch
[14:04:21] <jepler> more like a SR flip-flop than an AND, I think
[14:04:25] <SWPadnos> ok
[14:04:30] <cradek> so you home slow enough that mach can respond before you've moved on to the next count
[14:04:46] <jepler> unless there's some bit of clever I don't remember, I think that's true
[14:04:49] <SWPadnos> same as EMC - it's just parallel port input and output at that stage
[14:04:58] <cradek> got it, just curious
[14:04:58] <rayh> You'd have to or there would be uncertainty
[14:05:09] <SWPadnos> EMC can only do things faster with hardware assist
[14:05:33] <jepler> emc can do index homing to the individual encoder count even if it's faster than SERVO_PERIOD
[14:05:54] <SWPadnos> but not faster than BASE_PERIOD
[14:05:59] <rayh> and probing the same I think.
[14:06:07] <SWPadnos> ah - ok. I'm not sure where Mach detects the inputs
[14:06:47] <jepler> I *think* that probing happens at servo rate. index is the only thing that can capture a position between SERVO_PERIODs.
[14:07:06] <jepler> (whether at BASE_PERIOD accuracy or the accuracy of the hardware encoder counter in mesa/ppmc/pluto/etc)
[14:07:17] <rayh> This is a case where the "local" level has to pass an actual position value to the regional level
[14:07:40] <rayh> Oh. It used to. If I remember right.
[14:07:59] <rayh> It would keep track of the base loop when it sensed the probe close.
[14:08:11] <rayh> and then pass that up.
[14:08:53] <rayh> But then that was long ago and far away in a visit to Fred's office.
[14:08:58] <SWPadnos> that may have been something that changed very early in the HAL cycle
[14:09:19] <SWPadnos> the probe input is connected to motion, not to any of the things that run in the base thread
[14:09:38] <rayh> darn
[14:09:53] <SWPadnos> it may make sense for the canonical encoder to have a "latch" input, which will latch a separate count when activated
[14:10:10] <rayh> I'm beginning to think that my understanding of things is way obsolete.
[14:10:20] <SWPadnos> actually, that can be done with sample+hold components (which already exist)
[14:10:21] <jepler> you could change stepgen/encoder/HAL abstract position feedback to have a "capture position" that is like index but driven by some other signal. in the case of software stepgen/encoder that could be another signal in HAL; in the case of hardware encoder counters it would have to be a signal outside of HAL
[14:10:27] <SWPadnos> heh
[14:10:32] <SWPadnos> jinx :)
[14:10:34] <jepler> SWPadnos: no, because stepgen doesn't update its position output in the fast thread
[14:10:56] <SWPadnos> ah, true - it would have to output counts at least
[14:17:13] <cradek> a machine that's busy swinging a probe around doesn't move very many steps/counts in a millisecond
[14:17:35] <cradek> I'm not sure more complexity would gain you much probing precision
[14:18:53] <SWPadnos> for my machine, 1 count/ms is 1/40 inch/sec or 1.5 IPM
[14:18:59] <SWPadnos> that seems a little slow, but it may not be
[14:19:36] <cradek> you could sure do a fast probe and then a slow one at <1.5 ipm
[14:20:05] <SWPadnos> yep
[14:24:24] <cradek> but at 10ipm (with a perfect probe) you could still get a probe result within 0.00015
[14:26:25] <rayh> Keep trying.
[14:27:04] <cradek> is my math wrong? I would sure not be surprised.
[14:27:17] <rayh> at 5ipm you could get 0.000075
[14:27:29] <rayh> No there's nothing wrong with your math.
[14:28:03] <cradek> how fast do people usually swing probes rayh?
[14:29:04] <rayh> I'm being a bit light hearted here. My concern is not with the speed at which a user could do something.
[14:29:37] <rayh> It's the ability to do something at the resolution of the device they create.
[14:30:47] <rayh> If we twiddle with the numbers between servo and base threads then we twiddle with the resolution that probing can see.
[14:31:41] <cradek> I can't argue that it wouldn't be nice to have something like index for probing, with position captured at the lowest possible level.
[14:31:46] <rayh> But I can see your point that all we have to do is slow down the probe speed and we increase resolution
[14:32:43] <cradek> it's very hard to do since it requires low level support which would have to go in hardware devices. also I think the numbers show that the improvement we would get in return is pretty small.
[14:33:00] <cradek> * cradek shrugs
[14:34:17] <cradek> now that we finally have index homing working consistently on all (?) our interfaces, it would suck to stir the pot again :-)
[14:34:23] <jepler> here's a sketch of how it would work: add axis.N.position-capture-in (float in). add .capture (bit in) and .position-capture-out (float out) to stepgen/encoder. if you are using something with position-capture-out, hook that to position-capture-in. otherwise, just hook the regular position feedback to it. probably pluto/ppmc/mesa would not be able to add position-capture-out without revising firmwares.
[14:34:50] <jepler> the implementation is left as an exercise for someone who wants to get this last little bit of precision in probing :-P
[14:34:58] <cradek> heh
[14:37:03] <rayh> I can see that. And since back then all we had for hardware was stg and parport and both were unusually dumb, it was easier to see everything in the innermost loop.
[14:38:40] <rayh> or at least extrapolate position from something happening at the lowest level.
[14:40:45] <rayh> fascinating. Thanks for the lesson guys.
[14:41:40] <cradek> jepler: you left in a debug fprintf
[14:42:05] <jepler> cradek: sigh, do I ever not do that?
[14:42:21] <cradek> I decline to say
[14:43:49] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: remove debugging prints
[14:46:42] <cradek> jepler: I think you missed TLO
[14:47:13] <jepler> cradek: OK
[14:48:44] <cradek> also it seems possible that you will violate constraints since the centripetal test is avoided
[14:49:12] <jepler> I don't understand
[14:49:30] <jepler> when the chord_deviation test passes, you get two lines and zero arcs so there is no centripetal acceleration
[14:50:14] <cradek> oh forget it, I see that flush_segments() calculates new vel/acc
[14:51:26] <cradek> ok I think TLO is the only problem I see. you handled helixes and 'extra' axis moves
[14:51:56] <cradek> of course I haven't even run this yet...
[14:52:08] <cradek> :q
[14:52:11] <cradek> dangit
[14:52:19] <jepler> what an odd face
[14:52:28] <cradek> ha
[14:52:28] <jepler> is it the emoticon for "man eating escargot"?
[14:52:36] <cradek> yes, must be
[14:57:57] <BigJohnT> I hope I never bump into the man eating escargot out in the woods...
[15:00:48] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc:
[15:00:48] <CIA-32> EMC: naive cam arc detection must take into account the tool offset
[15:00:48] <CIA-32> EMC: also introduce (but don't yet use) some new functions to apply/unapply the
[15:00:48] <CIA-32> EMC: various offsets to coordinates. Once these are used through emccanon.cc,
[15:00:48] <CIA-32> EMC: adding a new offsetlike thing would only require changing one location.
[15:01:42] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot1_log.txt
[15:02:12] <jepler> argh
[15:02:31] <CIA-32> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[15:02:46] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[15:02:51] <jepler> yeah yeah I know
[15:02:55] <SWPadnos> heh
[15:03:39] <cradek> jepler: DID YOU KNOW IT'S GOING TITS UP
[15:03:42] <cradek> haha
[15:03:55] <SWPadnos> boobies!
[15:03:58] <SWPadnos> oops - sorry
[15:05:42] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: as any fool can tell you, it's best to compile first then commit second, not the other way around
[15:08:04] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build PASSED
[15:08:26] <cradek> what's the opposite of ... oh forget it
[15:08:52] <SWPadnos> remember this forever ?
[15:09:19] <CIA-32> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build PASSED
[15:09:19] <cradek> of "tits up", I was going to ask
[15:09:23] <SWPadnos> heh
[15:09:27] <cradek> TITS ARE BACK DOWN NOW
[15:09:41] <cradek> but I doubt that's actually funny except to a junior high kid (and me)
[15:09:48] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
[15:09:49] <SWPadnos> me to, me too!
[15:09:51] <SWPadnos> too
[15:10:22] <SWPadnos> tits up would be recumbent, so I guess tits down is prone
[15:26:52] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457237&postcount=20
[15:27:47] <skunkworks_> maybe mach isn't all sunshine and light. ;)
[15:28:35] <BigJohnT> :)
[15:37:49] <skunkworks_> this would be cool :)
http://www.cnczone.com/forums/showpost.php?p=457245&postcount=37
[15:38:07] <skunkworks_> I don't have a use for it at the moment but - does that really matter? ;)
[15:43:39] <BigJohnT> that would be cool to have
[15:44:12] <SWPadnos> yeah. I've wanted that for a while
[15:44:26] <SWPadnos> but there are a lot of problems with backing up through G-code
[15:44:33] <SWPadnos> (if you want a general solution)
[15:45:16] <skunkworks_> I wouldn't know were to start anyways.. :)
[15:45:41] <skunkworks_> I wonder if cncpro really does 150k steps per second.
[15:46:05] <cradek> jepler: NCD doesn't work on arcs other than g17 plane
[15:46:06] <skunkworks_> anyways - can't surf with it ;)
[15:46:34] <jepler> cradek: you mean it does the wrong thing, or that it does nothing? the latter is what I expect.
[15:46:45] <cradek> sorry, does nothing, I get the full arc
[15:47:07] <skunkworks_> <jepler> somebody could also follow the given example to add support for G18/G19 arcs
[15:47:13] <cradek> doh
[15:47:20] <skunkworks_> oops - too slow
[15:54:15] <jepler> cradek: is it OK or is it a bug that STRAIGHT_PROBE doesn't use getStraightVelocity?
[15:54:30] <jepler> errrrr
[15:54:40] <jepler> it does but it's also doing something else..
[15:54:44] <jepler> n/m
[15:59:14] <SWPadnos> hmmm. can you probe an arc?
[15:59:17] <SWPadnos> in an arc
[15:59:28] <SWPadnos> like a probing G2/G3
[15:59:29] <cradek> no
[15:59:32] <SWPadnos> bummer
[15:59:53] <SWPadnos> that would be cool for checking something that's supposed to be circular
[15:59:55] <cradek> could sure be done if anyone cared.
[16:03:45] <CIA-32> EMC: 03cradek 07TRUNK * 10emc2/debian/changelog: interp change
[16:06:08] <cradek> I bet there's a lot missing from trunk's changelog...
[16:06:15] <jepler> I'm sure you're right
[16:15:09] <jepler> cradek: did you have a reason in mind that 'systems.ngc' doesn't specify G20 or G21? or was it just an oversight?
[16:15:52] <cradek> surely oversight
[16:16:44] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/nc_files/systems.ngc: specify units as inches
[16:17:33] <CIA-32> EMC: 03cradek 07TRUNK * 10emc2/nc_files/3dtest.ngc: do these as full circles
[16:26:26] <jepler> well that is an interesting shape to get!
[16:26:34] <BigJohnT> if your probing an arc how could you tell if the circle is round unless you stop every increment and to a line probe ?
[16:27:39] <jepler> good question
[16:27:49] <skunkworks_> use it as a no-go gauge?
[16:28:28] <skunkworks_> go - no go
[16:30:55] <BigJohnT> keep making bigger circles till it touches somewhere ?
[16:31:38] <SWPadnos> if you've just machined a circle, you can probe around it at low speed (and no cutting force) to see if it's out of round
[16:34:25] <cradek> jepler: which is an interesting shape?
[16:34:33] <jepler> cradek: oh, I wrote a bug
[16:34:41] <jepler> it made a helix where it should have made an arc
[16:36:21] <BigJohnT> http://www.cnczone.com/forums/showthread.php?p=457270#post457270
[16:36:47] <BigJohnT> :)
[16:40:15] <cradek> I don't understand how a machine could fail to cut a round circle but then be trusted to probe a round circle
[16:41:41] <SWPadnos> Cutting forces and speed could have an effect
[16:42:06] <cradek> I suppose so
[16:42:19] <SWPadnos> it could also be something that you didn't just mill on the same machine
[16:42:54] <cradek> quite true.
[16:45:07] <jepler> you could do one probing move just inside the circle in the mode which starts out of contact and doesn't error if it stays out of contact, then do the same a bit further out where it is OK to start in contact and doesn't error if it stays in contact. if either time the probe trips, you've found that it's out of round
[16:45:12] <jepler> is that what you're thinking?
[16:45:37] <SWPadnos> yep, something like that
[16:45:58] <SWPadnos> and you'd know where the problem is, since you get the coordinates of the error
[16:46:32] <cradek> I don't think a probe can generally be dragged along a part in contact with it
[16:47:04] <cradek> and imagine the cut stops early. the probe would snap off.
[16:47:06] <jepler> surely hypothetical probes can
[16:47:28] <cradek> I guess I can't argue with that.
[16:47:30] <jepler> that's why you do the inside probe first -- you know the circle is at least as big as the deflection your probe can handle
[16:47:40] <cradek> ok
[17:17:25] <BigJohnT> talk about service
http://www.cnczone.com/forums/showthread.php?t=58497
[17:23:26] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457294&postcount=22
[18:51:51] <BigJohnT> everyone must be working...
[18:54:45] <SWPadnos> shhhh. I'm trying to sleep
[18:55:55] <jepler> sounds great, mariss. why not open-source the verliog source code so that anyone can improve the drive? </never in="1 million years">
[18:56:18] <jepler> (I am sure it's very easy to toast a 203v if you incorrectly revise the cpld configuration though)
[18:56:27] <SWPadnos> and/or a motor
[19:06:51] <skunkworks_> SWPadnos: nice replies :)
[19:07:00] <SWPadnos> thanks - working on the last one (for now)
[19:08:15] <BigJohnT> too noisy to sleep around here...
[19:08:17] <skunkworks_> you should post the fusee video for wayne..
[19:08:38] <SWPadnos> heh
[19:08:48] <SWPadnos> I like my example of an MPG, or 6 :)
[19:09:23] <skunkworks_> right. I also like you you're planting the seed for maris to try out hal.
[19:09:31] <SWPadnos> heh -sneaky, huh?
[19:09:47] <SWPadnos> I'd love it if he'd stick Mach and EMC2 on an o-scope too
[19:09:51] <SWPadnos> he may be surprised
[19:10:10] <jepler> I have no idea how that experiment would turn out
[19:10:24] <jepler> you are hoping that emc2's pulsetrain is much more regular?
[19:10:40] <SWPadnos> I know for sure that it is
[19:10:47] <jepler> you've performed the experiment?
[19:10:50] <SWPadnos> also the spindle PWM is much better
[19:10:52] <SWPadnos> yes
[19:11:01] <jepler> ah then I bow to your actual knowledge :-P
[19:11:03] <SWPadnos> heh
[19:11:26] <SWPadnos> I'm not sure that the hardware was identical, but they were very similar machines
[19:11:28] <skunkworks_> bah - who needs actual knowledge..
[19:11:56] <SWPadnos> and the EMC2 machine wasn't well optimized - we didn't replace the onboard video, for example
[19:12:12] <BigJohnT> yea, I just guess 1/2 the time you just have to know when I'm guessing
[19:12:24] <SWPadnos> (and I couldn't figure out, in 5 minutes or less with no internet connection, how to change the driver on 8.04)
[19:13:01] <skunkworks_> so - recently?
[19:13:06] <SWPadnos> last month
[19:13:11] <SWPadnos> at Tormach
[19:13:36] <SWPadnos> or maybe that was this month,. I don't remember
[19:14:02] <skunkworks_> you where in WI?
[19:14:07] <SWPadnos> yep
[19:14:11] <skunkworks_> cool
[19:14:22] <SWPadnos> kinda. actually the weather was fine :)
[19:21:00] <skunkworks_> did you get them excited about emc?
[19:21:16] <skunkworks_> I would think rigid tapping would be a nice addition to thier system
[19:21:18] <SWPadnos> theywere interested anyway. that's why I was there
[19:21:47] <SWPadnos> I'm not sure they'll be able to do rigid tapping - there's only the single pulse for feedback
[19:25:44] <skunkworks_> what do they use that for? spindle rpm feedback?
[19:26:02] <SWPadnos> Mach does threading with single pulse feedback
[19:26:22] <SWPadnos> they do use it for an RPM readout as well
[19:27:47] <skunkworks_> (are we talking lathes?
[19:27:48] <skunkworks_> )
[19:28:00] <skunkworks_> I didn't know tormach had lathes for some reason
[19:28:04] <SWPadnos> yes. rigid tapping in Mach requires a floating tap holer
[19:28:20] <SWPadnos> you may get a chance to see it at CNC workshop
[19:28:56] <SWPadnos> Mach may try to do rigid tapping with single pulse feedback - I'm not sure
[19:29:48] <BigJohnT> you guys should demo a thread mill at the CNC workshop
[19:32:40] <SWPadnos> got one?
[19:40:05] <skunkworks_> pfff - anyone can treadmill.. That is just a helix. ;)
[19:40:13] <skunkworks_> or threadmill even
[19:42:28] <cradek> not true. last year a guy was excited about switching to emc because he had a job that required a thread mill but his software could not do helixes.
[19:42:37] <cradek> I forget his name unfortunately
[19:43:09] <cradek> heck I even got BOSS to do a helix ... once
[19:43:17] <SWPadnos> I wonder if TurboCNC can't do helixes or something
[19:43:20] <cradek> you have to do it in polar mode or something
[19:43:42] <BigJohnT> I can get one
[19:44:18] <cradek> SWPadnos: I also forget what software he was currently using. seems like it was a dos program.
[19:44:32] <BigJohnT> what size?
[19:44:49] <SWPadnos> ok. that could be TurboCNC, and Mariss mentioned one called CNCPro or something
[19:45:06] <SWPadnos> BigJohnT, something small enough for a Sherline, but big enough for a Mazak :)
[19:45:30] <BigJohnT> they start at 4-40 and go up from there
[19:46:12] <BigJohnT> they are pretty much the same price till you pass 1/4-20
[19:46:38] <cradek> that would have to be a 1/4 shank then if you hope to use it in both machines
[19:46:47] <cradek> assuming we will have a 1/4 collet
[19:47:11] <cradek> hey does anyone remember if that chuck was ER40? I could bring my collets.
[19:47:51] <BigJohnT> the 1/4-20 is a 3/16 shank
[19:48:25] <BigJohnT> the 5/16-18 has a 1/4" shank
[19:55:05] <BigJohnT> I have to order a few end mills just let me know if you want to try a thread mill...
[19:55:24] <BigJohnT> If you don't break it I'll use it after you finish the show
[19:59:00] <SWPadnos> cool - the new SheetCAM will be available for Linux
[19:59:23] <BigJohnT> SWPadnos: where did you hear that?
[19:59:39] <SWPadnos> so says Les Newell, on the Gecko list about a minute ago
[20:00:12] <BigJohnT> I guess all my bugging him for the last few months got him to finish it LOL
[20:00:16] <SWPadnos> heh
[20:01:02] <cradek> http://www.cnczone.com/forums/showthread.php?t=9500
[20:01:47] <SWPadnos> cool
[20:02:43] <BigJohnT> I think he is running is in wine
[20:02:59] <SWPadnos> he was, but Les just said there would be a Linux version
[20:03:15] <SWPadnos> if he meant a version that's wine friendly, then I'm less happy :)
[20:06:12] <BigJohnT> when I e-mailed him the other day he said he was working on it...
[20:11:36] <BigJohnT> anyhow you guys let me know on the thread mill... I'll most likely place an order tomorrow or friday for some tooling...
[20:12:44] <cradek> thanks BigJohnT
[20:14:50] <BigJohnT> np, just need to know what size you want
[20:15:16] <BigJohnT> http://www.lakeshorecarbide.com/index.asp?PageAction=VIEWPROD&ProdID=9
[20:15:32] <BigJohnT> http://www.lakeshorecarbide.com/index.asp?PageAction=VIEWPROD&ProdID=7
[20:15:57] <cradek> eek those are not cheap
[20:25:38] <BigJohnT> np
[20:35:00] <BigJohnT> just pick the one you want my business is footing the bill :)
[20:35:45] <cradek> let me look tonight to see what the threads are in the part we may be making.
[20:36:06] <cradek> unless you have digital machinist magazine - I think there's a drawing in there.
[20:40:16] <BigJohnT> no, I don't have it
[20:40:30] <cradek> ok I'll find mine tonight, thanks again
[20:40:44] <BigJohnT> keep in mind the depth of cut of the thread mills is limited
[20:41:10] <cradek> ok
[20:41:15] <cradek> I think this part is 1/2
[20:41:18] <BigJohnT> but just think how cool it would be to mill out a blind hole and put threads all the way to the bottom
[20:41:41] <cradek> yeah. I may make one (single point) to try out for fun
[20:41:45] <BigJohnT> the 1/4-20 will do 0.5 thread lenght
[20:42:58] <BigJohnT> * BigJohnT is going home and sit on the porch and rub my girlfriends head and sip on some wine it is a lovely day...
[20:43:16] <BigJohnT> If I can just keep her from licking me all the time...
[20:44:17] <alex_joni> TMI TMI