Back
[00:52:05] <cradek> argh, spindle feedback is another resolver!
[00:55:55] <cradek> ... and encoder! score! (but wtf?)
[00:56:32] <cradek> encoder has a separate "lamp supply" though - not real modern.
[01:00:54] <jmkasunich> heh
[01:01:16] <jmkasunich> resolvers are absolute devices, hence no index required
[01:02:45] <cradek> the encoder says it has 'marker pulse' too
[01:03:02] <cradek> hard to guess how the crazy thing works
[01:09:26] <cradek> huh, the book thinks there's only a resolver
[01:10:36] <skunkworks> we have some encoders that have a light bulb in them
[01:11:04] <skunkworks> (same machine that has the ttl electronics)
[01:11:49] <cradek> this looks like 12v, non-differential
[01:13:10] <jmkasunich> rip and replace!
[01:13:14] <jmkasunich> us digital
[01:19:31] <cradek> wonder if anyone has used the 7i29 as a servo drive
[01:21:47] <SWPadnos> it does seem to be intended for use driving motors
[01:26:48] <SWPadnos> hey - they released the 5i23 - 400kgates, 3 I/O connectors, $229
[01:27:03] <jmkasunich> 5i20 with 2x the gates?
[01:27:40] <SWPadnos> short card ftoo
[01:27:42] <SWPadnos> yeah, more or less
[01:27:44] <SWPadnos> -t
[01:27:51] <SWPadnos> err - -f
[01:29:59] <jmkasunich> "take extreme care with servo systems. EXPECT them to run away when first tested"
[01:30:11] <SWPadnos> yeah, I liked that
[01:30:24] <SWPadnos> almost as much as "this page intentionally left almost blank" :)
[01:30:33] <skunkworks> don't you check the encoder direction before you power things up?
[01:30:43] <jmkasunich> nevah!
[01:31:18] <SWPadnos> yeah - I check it by seeing if the motor runs away
[01:32:01] <jmkasunich> actually, I always check _encoder_ direction - I make sure the encoder is working and properly scaled before I even think about hooking up the motor
[01:32:26] <SWPadnos> well, for something like a gecko, the runaway check is pretty easy :)
[01:32:34] <jmkasunich> and the first step after hooking up motor is to use HAL setp to put 1% or so on the DAC (or PWM) to see which way the motor goes
[01:32:38] <SWPadnos> for analog amps, it's a little different
[01:32:49] <jmkasunich> I'm talking about what we did on the Mazak, and what I would do with other servos
[01:33:29] <SWPadnos> yep
[01:33:46] <SWPadnos> that 7i29 looks pretty nice actually
[01:33:56] <jmkasunich> yeah, I was thinking the same
[01:34:07] <SWPadnos> it's $300 though
[01:34:38] <jmkasunich> 4KW, that is 5HPish
[01:34:52] <SWPadnos> I wonder if you can parallel them easily
[01:34:59] <jmkasunich> that pricing compares with a VFD at that power level I bet
[01:35:03] <SWPadnos> sure
[01:35:06] <SWPadnos> less even
[01:35:10] <jmkasunich> although it doesn't include the bus supply, and the VFD does
[01:35:24] <SWPadnos> and probably some controls and stuff
[01:35:34] <SWPadnos> like a knob or keypad
[01:35:36] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=59870
[01:35:44] <skunkworks> ouch
[01:37:16] <SWPadnos> heh
[01:37:54] <skunkworks> more expensive then mach.. So what does that mean? ;)
[01:38:12] <SWPadnos> well, it comes with - err - you know, stuff!
[01:38:34] <jmkasunich> GPL licencse violations no extra charge
[01:39:09] <SWPadnos> well, someone could buy it and request the source code
[01:39:19] <SWPadnos> they don't have to give it to anyone, only people who get the software
[01:40:59] <jmkasunich> true
[01:41:15] <jmkasunich> but they can't prohibit those people from redistributing it
[01:41:32] <SWPadnos> right
[01:41:39] <SWPadnos> which is why only one person has to buy it :)
[01:42:51] <SWPadnos> ok - bedtime for me. night guys
[01:42:59] <jmkasunich> goodnight
[01:43:35] <jmkasunich> I should try that "bed at a reasonable hour" thing one of these days
[01:43:56] <SWPadnos> sister and her 2 kids visiting - makes it easy to get tired
[01:45:59] <jmkasunich> hmm, the guy posting that he is the eztrol dev seems to be from synergy
[01:46:26] <jmkasunich> searching for all his posts gives 8 hits, all of which are promoting synergy
[01:47:46] <skunkworks> the plot thickens..
[01:48:24] <rayh> What's happening with EzTrol?
[01:49:02] <jmkasunich> http://www.cnczone.com/forums/showthread.php?t=59870
[01:49:11] <jmkasunich> not exactly sure what is "happening"
[01:50:07] <rayh> looking
[01:52:07] <rayh> Fascinating.
[01:52:56] <rayh> Weber wrote quite a bit of the operator stuff.
[01:53:19] <rayh> Wally, whom you met at fest wrote the QT to NML connectors.
[01:53:35] <jmkasunich> does it all obey the GPL?
[01:53:57] <jmkasunich> "obey" meaning closed portions don't link directly to GPL code, etc
[01:54:03] <rayh> I once offered the interface code to the repository but there was on interest.
[01:54:17] <rayh> on/no
[01:54:50] <rayh> There is a bit of the interface that uses hal
[01:55:34] <jmkasunich> linking thru HAL pins is explicitly permitted - the HAL lib is LGPL
[01:55:36] <rayh> There is an offer laying about to give all of the interface code to EMC2.
[01:56:13] <jmkasunich> I'm not sure how that is consistent with "nanmol" offering to sell it for $250
[01:56:25] <rayh> That would not include the Synergy CAD/CAM but the other tabs would be in there along with the graphical stuff that works a lot like the Axis interface's display.
[01:56:36] <rayh> I'm not either.
[01:56:55] <rayh> I don't believe that the folk at Weber would make such a claim.
[01:57:07] <rayh> But I'll call in the am and talk with them.
[01:57:33] <rayh> If "we" want the interface we can have it.
[01:57:54] <jmkasunich> I'm mostly just curious - who is nanmol, does he officially represent Weber, or is he just somebody spouting off
[01:58:38] <rayh> The owner of Weber is a lady named Nancy.
[01:58:55] <cradek> Is EZ-Trol Weber's product?
[01:59:02] <rayh> She would not have made such a statement without Smithy's permission.
[01:59:14] <rayh> No. It's Smithy's.
[01:59:32] <rayh> And it was not intended to be a stand alone software package.
[01:59:38] <jmkasunich> but Weber did some/all of the coding working for Smithy?
[01:59:45] <rayh> some
[02:00:09] <jmkasunich> so EzTrol basically integrates the CNC controller with the CAD and the CAM?
[02:00:13] <rayh> and of course there is the linkage to a graphical front end to Synergy CAD/CAM.
[02:00:30] <rayh> Perhaps that is what was being referred to as available for 250.
[12:21:29] <skunkworks_> logger_dev: bookmark
[12:21:29] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-07-29.txt
[12:25:22] <skunkworks_> mmmm coffee
[12:47:12] <skunkworks_> mmmm 2nd cup - even better.
[12:51:04] <rayh> yup!
[12:57:53] <skunkworks_> hey ray. How is the weather up there?
[13:01:30] <rayh> Kinda rainy today.
[13:01:48] <rayh> How bout you?
[13:01:54] <skunkworks_> cloudy
[13:02:02] <skunkworks_> a bit humid but not too bad
[13:02:33] <rayh> I suppose it will get here by afternoon.
[13:08:12] <skunkworks_> rayh: how is the high speed?
[13:08:32] <rayh> Wonderful
[13:09:00] <rayh> I've had only one outage since I got setup.
[13:09:44] <rayh> And that was a tree into a power line that fed a tower.
[13:09:56] <rayh> Since then they've put in a backup generator.
[13:11:09] <skunkworks_> heh
[13:11:12] <rayh> Right now I'm working to get setup with a high speed into a sawmill that will let me monitor any switch, PLC, or VFD from right here.
[13:11:26] <skunkworks_> nice..
[13:11:50] <skunkworks_> http://www.electronicsam.com/images/KandT/DSC02968.JPG
[13:15:34] <rayh> That is quite a beast, for a portable.
[13:16:28] <skunkworks_> it isn't that portable anymore... (it has a 20hp 3 phase motor running it)
[13:16:50] <rayh> I see that.
[13:17:15] <skunkworks_> used to have a pinto engine on it ;)
[13:18:14] <skunkworks_> I remember as a kid - the sawdust starting on fire.. ;)
[13:19:29] <rayh> Nice clear log.
[13:19:59] <rayh> We tend to get a lot of iron stain at the heart.
[13:37:45] <skunkworks_> ah - you're near the iron range..
[13:38:00] <SWPadnos> Iron Mountain is close by ... :)
[13:38:18] <SWPadnos> isn't it Iron county?
[13:48:04] <skunkworks_> yes
[13:48:31] <skunkworks_> Good morning SWPadnos
[13:50:45] <rayh> Yes +-17 degrees on a mag compass
[13:51:43] <skunkworks_> I would think the iron content of the wood would look pretty
[13:52:34] <skunkworks_> rayh:
http://www.cnczone.com/forums/showthread.php?t=59870
[13:52:39] <skunkworks_> it is webber systems\
[13:56:19] <rayh> It does make for some nice grain. But comercial folk want "whitest."
[13:57:55] <rayh> I see the weber stuff. I'll have to talk with 'em.
[14:09:57] <SWPadnos> hiya
[14:11:06] <skunkworks_> How is the sister?
[14:11:14] <SWPadnos> which one?
[14:11:21] <skunkworks_> the one staying with you
[14:11:30] <SWPadnos> oh, that one :)
[14:11:46] <SWPadnos> it's been surprisingly quiet
[14:11:52] <skunkworks_> heh
[14:11:57] <SWPadnos> (she's fine)
[14:12:11] <SWPadnos> it is amazing how different it is being in a house with no kids vs. one with kids
[14:12:37] <skunkworks_> a few db lower?
[14:12:53] <SWPadnos> several decades lower
[14:13:05] <SWPadnos> a couple of B, for sure ;)
[14:28:39] <pmbdk> a quick question... :-)
[14:28:58] <pmbdk> why do we need interpolation in the trajectory code?
[14:30:25] <pmbdk> is this because there can be a difference in the traj and the servo period?
[14:32:30] <jepler> pmbdk: these days it is best to configure systems with the servo period and traj period equal
[14:33:14] <pmbdk> ok... So the interpolator is not used?
[14:33:36] <jepler> pmbdk: the interpolator works on joint coordinates, so having traj = 10*servo (the old typical setup) allowed the kinematics functions to be run 1/10 as often. apparently this was important for iterative heaxpod kinematics on machines of that vintage.
[14:34:16] <cradek> I think now they aren't even separate threads, so you cannot have this advantage no matter how you configure it
[14:34:19] <pmbdk> ok... sounds reasonable... My fast machine is also "slow" when computing hexapod leg lengths...
[14:37:06] <jepler> cradek: it can still lower the average time spent in the realtime servo thread
[14:37:18] <cradek> true.
[14:37:36] <jepler> cradek: but you're right that the full benefit may not exist any longer
[14:39:29] <pmbdk> btw, last time I read the rs274ngc doc, I think I saw something about ellipses (not circles)... My g-code knowledge is very limited, but I assume that everything is ellipses in g-codes not circles (?), is this also how it is implemented in emc?
[14:39:46] <jepler> emc's gcode has only circles, no ellipses
[14:40:45] <cradek> iirc, there is an ellipse canon call defined in ngc, but none of emc has ever implemented it
[14:41:40] <jepler> circles and lines are nice for trajectory planning, because the obvious xyz=f(t) parameterization is constant velocity. ellipses, splines, and other primitives don't have simple constant-velocity parameterizations.
[14:41:40] <pmbdk> ok, i don't even know if any g-code producers actually uses ellipses... :)
[14:42:14] <pmbdk> but I would assume that if I would ever _make_ an allipse, it would be a nice thing to have... :)
[14:42:16] <cradek> I don't think it's by any means common
[14:42:59] <cradek> I think four-tangent-arc approximations are fine for a lot of applications
[14:44:15] <pmbdk> guess so... it all depends on the accuracy....
[14:44:39] <pmbdk> just browsing thorught the trajectory planner....
[14:44:45] <jepler> IMO the "biarc" method for fitting arcs to arbitrary curves works nicely
http://axis.unpy.net/01171767993
[14:46:01] <pmbdk> does blending mean that two segments are milled as one?
[14:47:13] <jepler> it means that emc overlaps the acceleration portion of the next primitive with the deceleration portion of the previous primitive.
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl
[14:48:14] <jepler> this works nicely (keeps very near the requested feed rate) as long as each primitive is long enough that, planned on its own, the machine could accelerate from a stop to the requested feed rate
[14:48:32] <jepler> (actually, accelerate from a stop to the requested feed rate and back to a stop)
[14:50:29] <pmbdk> does g64 continous mode really mean sacrifice path following accuracy?
[14:50:39] <cradek> jepler: love that velocity profile in your last pic
[14:51:17] <cradek> pmbdk: with finite acceleration, you cannot make a sharp corner without stopping. so yes, all blending necessarily sacrifices path following.
[14:52:04] <cradek> in emc2 the corners are rounded internally. there are other possible schemes too, like making an outside loop, but that's CAM territory
[14:53:33] <pmbdk> ok I see; I was confusin continous with exact path mode
[14:54:24] <pmbdk> so my question is then: how do we implement exact path mode?
[14:55:37] <cradek> G64 P[tiny] will get you virtually exact path
[14:57:42] <pmbdk> i'm just thinking about what happens if I want to mill something not-circular...
[14:58:05] <pmbdk> i guess this would be modelled as a lot of small circular arcs
[14:58:26] <cradek> yes you have to approximate shapes with either lines or arcs (preferably biarcs so it is smooth)
[14:59:14] <pmbdk> yes, but if these arcs are very small (in order to accomodate strct accuracy requirements) wouldn't blending be a problem?
[14:59:40] <cradek> not a problem - but it may cut slower than the requested feed.
[15:00:11] <cradek> to our dismay there are always tradeoffs aren't there.
[15:01:00] <pmbdk> ok, I see, so you take care of being able to stop within one arc?
[15:01:10] <pmbdk> or segment
[15:01:46] <cradek> yes that's what makes the path get slower as the segments get short
[15:01:58] <pmbdk> nice... :)
[15:02:20] <cradek> the motion is still smooth, just slower.
[15:02:43] <pmbdk> so the only benefit of having a "true" exact path mode is that it could run segments with many small sub-segments faster
[15:03:22] <pmbdk> so no need for me to write a new planner... :-)
[15:03:40] <pmbdk> there's nothing for me to do... :)
[15:04:13] <cradek> a new planner that could go full speed through short segments when the machine constraints allow it would be very happily received.
[15:04:43] <skunkworks_> that would require more 'read ahead'?
[15:04:58] <pmbdk> well I guess the benefits would be negligible
[15:05:10] <pmbdk> skunkworks: yes...
[15:05:14] <cradek> yes you have to know a lot about the upcoming path to know how fast you can go 'here'
[15:05:39] <skunkworks_> I remember you guys having discusions about this before and how messy it gets with FO
[15:05:40] <cradek> like driving on a foggy day!
[15:05:51] <cradek> yes it's really not a simple problem.
[15:05:54] <pmbdk> you basically need to read ahead until you know you can stop the machine until the last read segment
[15:06:35] <cradek> yes, but then if I hit pause or feedhold, maybe it has to continue for a dozen more blocks before it can get stopped
[15:06:46] <pmbdk> I read i nice article on it a year ago or so; it's not really a big problem; requires some housekeeping though
[15:06:47] <cradek> which might be fine
[15:07:01] <cradek> you just get different tradeoffs of course
[15:07:47] <pmbdk> cradek: the only reason why pause would be affected would be due to the higher feedrate
[15:07:59] <jepler> it would also be important to retain the property that acceleration constraints are obeyed no matter how the feed override control is manipulated
[15:08:12] <skunkworks_> I remember trying to wrap my head around it back in the early 90's.. I gave up. ;)
[15:08:15] <pmbdk> if you need to be able to pause faster you would need to decrease the feedrate anyhow...
[15:08:52] <rayh> I spoke with Weber.
[15:09:10] <pmbdk> the article i read waas describing the methodology for varying acc+vel limits
[15:09:59] <rayh> They are working toward the release of a GUI front end very much like the geometric CAD/CAM part of Smithy's EZTrol
[15:10:29] <rayh> No linkage to EMC2 but there will be an EMC2 post.
[15:10:51] <rayh> Sorry to interrupt.
[15:11:07] <rayh> * rayh goes off to work.
[15:11:18] <skunkworks_> ah - thanks ray
[15:11:21] <cradek> interesting, rayh
[15:11:46] <cradek> I watched a smithy video showing the 2.5d cam features of ez-trol. it's interesting.
[15:12:09] <skunkworks_> 250 for a nice cam/cad for ubuntu that works decent might be a good thing..
[15:12:22] <pmbdk> ez-trol...googling....
[15:12:28] <rayh> I certainly like it.
[15:12:35] <rayh> But then I'm biased.
[15:12:39] <skunkworks_> heh
[15:12:45] <cradek> skunkworks_: I still haven't messed with sheetcam but it's available now.
[15:12:54] <cradek> it's 2.5d dxf-based just like ez-trol seems to be
[15:12:54] <skunkworks_> I see that.. neither have I
[15:13:25] <cradek> I have REALIZE which does the same for me but better (IMO, but probably only since I wrote it)
[15:14:00] <skunkworks_> yeh - there are a few 'free' options that work for most things..
[15:14:36] <cradek> pmbdk: I think it's very new - it has poor exposure on the web so far
[15:15:49] <pmbdk> hmmm, can't find anything except
http://www.smithy.com/product_eztrol.php?cid=11&scid=16&pid=7
[15:16:00] <pmbdk> doesn't really show anything
[15:17:14] <rayh> I looked for EZ-Trol and didn't find much either.
[15:23:29] <pmbdk> just found the article: "Algorithms for time–optimal control of CNC machines along curved tool paths" by Sebastian D. Timar*, Rida T. Farouki, Tait S. Smith, Casey L. Boyadjieff
[15:24:26] <pmbdk> there are probably a bunch of other articles out there
[15:37:58] <pmbdk> this is based on nurbs, so it would probably require a lot of modifications, but is still shows the principle... :-)
https://www.uwspace.uwaterloo.ca/bitstream/10012/3770/1/Thesis_Master_UWmargins06.pdf
[15:39:45] <BigJohnT> cradek: I've been using sheetcam for linux, so far ok
[15:46:21] <cradek> do you have to start with a dxf to use it?
[15:46:56] <BigJohnT> yes or some other format I forget what that is
[15:48:05] <cradek> ok, so you can't just draw a part in it, that's what I was wondering
[15:48:13] <BigJohnT> no
[15:48:33] <BigJohnT> strictly cam
[15:48:35] <cradek> when I briefly tried it, I just sort of stared at the blank screen wondering what to do. none of the icons were 'draw a thing'
[15:49:41] <BigJohnT> lol, yes you have to import a drawing... each operation must be on a separate layer
[15:51:46] <cradek> "Teach-in mode for manual operation and programming: In addition to full manual control of the machine such as axes motions in rapid, feed and jog mode, the system allows an operator to manually operate the machine through the control system and convert that motion into a program's logic steps."
[15:51:56] <cradek> this is an interesting idea
[15:52:15] <BigJohnT> my anilam does that
[15:52:50] <cradek> BOSS has MDI-learn but it's hard to use.
[15:53:14] <cradek> (I think it's the only way to enter a program at the panel)
[15:53:32] <BigJohnT> my anilam is conversational and I've never tried the learn function
[15:56:29] <BigJohnT> * BigJohnT is off to the fab shop
