Back
[02:19:26] <SWPadnos_> huh - I wonder if that's why I sometimes can't boot the liveCD
[02:19:30] <SWPadnos_> (SATA)
[02:19:51] <jmkasunich> you saw that too?
[02:19:54] <SWPadnos_> I don't think so actually
[02:19:56] <SWPadnos_> yes
[02:20:04] <jmkasunich> I thought it did support SATA, but never really tried
[02:20:10] <SWPadnos_> I'm pretty sure I have an emc2/6.06 install on a SATA drive
[02:20:18] <jmkasunich> my main box is SATA, but I'm using stock dapper there
[02:20:27] <SWPadnos_> ah, I was going to ask about that
[02:20:28] <jmkasunich> the shoptask is older, and uses pata
[02:20:57] <SWPadnos_> I guess it could be a 120G I had lying around
[02:21:20] <SWPadnos_> I used a normal hard disk for developing the power supply stuff, and I'm pretty sure it's a 300G SATA drive
[02:21:26] <skunkworks> I have put dapper on a few sata sytems
[02:21:45] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:22:08] <SWPadnos> me too for dapper, it's the liveCD we're wondering about
[02:25:15] <cradek> I don't have access to any sata cdrom drives
[02:25:34] <cradek> I'm pretty sure it would install on sata disk.
[02:25:52] <skunkworks> ah - ok. I don't know if I have booted on sata cdrom.
[02:25:56] <SWPadnos> I can try it out in a sec. I've got the little embedded box apart for that purpose
[02:32:37] <SWPadnos> oh - I was at Micro Center and they had slim jewel cases cheap, so don't buy any for liveCDs :)
[02:35:56] <SWPadnos> crap. there's only one SATA power connector on that power supply
[02:49:41] <SWPadnos> hmmm. well, it boots and gets to the desktop, but there were some squashfs errors
[02:50:02] <SWPadnos> I don't want to install it to the hard drive in the machine because it's got data on it
[03:09:55] <SWPadnos> so, has anyone noticed that it's getting fairly close to the time when the CNC workshop website should have been updated already?
[03:15:23] <LawrenceG> hi guys.... 6.06 live boots fine on old pata cdrom,.... just doesnt work on the sata cd drive box.... not sure why
[03:15:37] <SWPadnos> it does work here
[03:15:54] <SWPadnos> this is a 2.1.x CD, but I think it's the same kernel
[03:16:12] <SWPadnos> 2.6.15-magma
[03:23:53] <LawrenceG> yeh... this image is one I just downloaded from the linuxcnc site a few days ago 2.6.15-magma
[03:24:19] <SWPadnos> can you try a stock Dapper disc?
[03:24:52] <SWPadnos> I have had issues booting on some machines - can't tell you what caused them at the moment
[03:24:57] <LawrenceG> I will see if I can find one... I think I have a dapper server disk around here
[03:25:12] <SWPadnos> it looks like SATA isn't the issue, though support for the particular chipset could be
[03:26:11] <LawrenceG> Its not a big deal... this box is not my controller box... I was just interested to see what the latencies looked like on the new m/b and E8400 cpu
[03:26:33] <SWPadnos> yeah, it would be interesting
[03:26:57] <SWPadnos> I just booted up on an intel chipset embedded board with a core 2 Duo
[03:27:17] <SWPadnos> it's OK with the stock kernel, but not great. something like 16000 max latency
[03:27:20] <LawrenceG> I will be right back after a reboot...
[03:27:39] <SWPadnos> ok
[03:39:32] <LawrenceG> back
[03:39:41] <SWPadnos> so I see :)
[03:41:07] <LawrenceG> stock 6.06 server boots to menu, I did get emc2 live cd to boot, but had no mouse action.... wonder if its a timing issue of something like this m/b is too new to be supported
[03:41:33] <LawrenceG> will see what happens when 8.04 hits the street
[03:41:50] <SWPadnos> the beta sure seems good. you could try it
[03:42:10] <SWPadnos> I think there are experimental packages for it, but you'd need to install to check latency
[03:42:17] <LawrenceG> obviously stock 8.04 beta runs on here... I installed a couple of days ago
[03:42:38] <SWPadnos> ok, in that case you can install the experimental packages (if they exist :) )
[03:42:45] <LawrenceG> looks pretty good.....
[03:43:03] <SWPadnos> yeah, it does
[03:43:08] <LawrenceG> I have got emc2 sim built onthis box for previewing gcode
[03:43:22] <LawrenceG> just not the realtime stuff
[03:44:26] <LawrenceG> beta had the web browsers broken for the morning.... 1 update crashed web browsers... about lunch time it was back working with new browser updates
[03:44:28] <SWPadnos> ok, it looks like there aren't RT packages for 8.04 yet. oh well
[03:44:39] <SWPadnos> except sim that is
[03:45:21] <LawrenceG> no problem..... shoptask is very happy running 6.06
[03:46:01] <LawrenceG> I should go update the sf feature request
[03:47:11] <SWPadnos> it's not really an EMC feature though
[03:49:39] <LawrenceG> something to watch for when building next live cd.... I can be a tester to see how it acts on new hardware
[03:50:34] <SWPadnos> here's a question for you: how can we make the distinction between the liveCD and EMC2 proper, while still offering the liveCD for ease of installation?
[03:51:17] <SWPadnos> ie, convince users that upgrading is much better than downloading a new liveCD, that the version of EMC2 on the CD doesn't really matter since it's only there to make RT installation easier, etc.
[03:51:39] <SWPadnos> (well, there are other uses, but still :) )
[03:53:40] <LawrenceG> The live cd makes it very easy for new installs or testing new hardware..... I havent tried taking a live cd into future shop... wonder if they would let me boot it?
[03:54:12] <SWPadnos> heh - dunno. people get paranoid even if you tell them you can unplug the hard drive before booting
[03:55:15] <LawrenceG> yea... getting into the boot to change the boot order can be fun.... even costco has all there display computers password protected
[03:55:40] <SWPadnos> they don't have all the power cords protected though ;)
[03:55:57] <SWPadnos> I wonder if they have the BIOS protected like they have Windows protected
[03:56:21] <LawrenceG> the ones I tried did :}
[03:57:10] <SWPadnos> bummer
[03:58:35] <SWPadnos> ok. bedtime here. see you later
[03:58:44] <LawrenceG> goodnight
[09:10:42] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: remove comment, it has been fixed
[09:19:57] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/emcmotglb.c: remove an older reference for num_joints (unused ..)
[09:35:45] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emcglb.h: reenable EMC_AXIS_MAX
[11:17:01] <sCOTTo> hey BigJohnT
[11:17:25] <sCOTTo> got any extra info on the cad to step thing i was askin about?
[11:20:33] <BigJohnT> nope do you
[11:21:10] <sCOTTo> nope not really - i have some industry friends looking int o it for me :)
[11:22:00] <BigJohnT> if they find out anything post it in the #cam channel
[11:22:07] <sCOTTo> sure
[11:22:11] <sCOTTo> i will do that
[12:31:32] <alex_joni> good morning y'all
[12:36:52] <BigJohnT> morning alex
[12:45:32] <skunkworks> alex_joni: looks like your going to town.
[12:45:50] <BigJohnT> and another one
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
[12:47:30] <alex_joni> BigJohnT: ?
[12:47:55] <BigJohnT> drilling speed and feed calculator
[12:48:07] <BigJohnT> opps wrong channel
[12:48:15] <alex_joni> aha, nice :)
[12:48:17] <alex_joni> n/m
[12:49:50] <BigJohnT> while your here alex a couple of questions about getting the trunk
[12:50:32] <BigJohnT> if I have used the live cd to install and have cvs installed
[12:51:14] <BigJohnT> do I start with "export CVS_RSH=ssh"
[12:51:35] <BigJohnT> and what does that do?
[12:54:10] <skunkworks> you need to start here
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#On_Ubuntu_6_06_from_source
[12:54:38] <skunkworks> 3.1
[12:55:06] <BigJohnT> does that trash my current 2.2.4?
[12:55:18] <skunkworks> the installed version?
[12:55:20] <skunkworks> no
[12:55:21] <BigJohnT> yes
[12:55:40] <skunkworks> this creates a run-in-place version in your home directroy
[12:56:45] <BigJohnT> I have universe respository enabled
[12:57:04] <BigJohnT> what does this line do "sudo apt-get build-dep emc2"
[12:58:10] <alex_joni> it grabs all packages needed to satisfy the build dependency for emc2
[12:59:26] <BigJohnT> so I do the above and "sudo apt-get install build-essential" then do the cvs?
[12:59:49] <alex_joni> you probably need to apt-get install cvs too
[13:00:04] <BigJohnT> I have cvs installed from the last attemp
[13:00:07] <BigJohnT> attempt
[13:06:29] <BigJohnT> I guess I'm slow this morning but does sudo apt-get build-dep emc2
[13:06:29] <BigJohnT> sudo apt-get install build-essential
[13:06:29] <BigJohnT> install EMC?
[13:15:26] <cradek> build-dep means install all the other packages necessary to build the stated package
[13:15:50] <cradek> build-essential is a package that pulls in the system compiler and other essential things for compiling stuff
[13:16:07] <BigJohnT> ok, thanks
[14:53:27] <alex_joni> hi chris
[14:53:40] <cradek> hi
[14:53:48] <alex_joni> what's up?
[14:54:25] <cradek> trying to convince my partners-in-crime to go out for breakfast
[14:54:52] <cradek> how's your day?
[14:55:03] <cradek> it's sure a nice weekend here. 60 degrees but windy
[14:55:12] <alex_joni> pretty ok.. too bad most of it is soon over, and I didn't get to do much
[14:55:29] <alex_joni> it's colder then the last few days here (about 12C) and not sunny
[14:56:09] <cradek> well I hope you had some kind of fun anyway.
[14:58:25] <alex_joni> * alex_joni tries to decide if sleeping late is fun
[14:58:30] <alex_joni> hmm.. I think it surely is :D
[14:58:36] <cradek> sure it is
[16:06:50] <alex_joni> hmm.. wonder if this is usefull at all
[16:07:06] <alex_joni> emctaskmain checks newly received commands against XYZ bounds
[16:07:25] <alex_joni> it doesn't check ABC, UVW
[16:07:37] <alex_joni> so I think we either want to check all, or none
[16:13:09] <SWPadnos> rotaries could be "interesting" due to wraparoubnd
[16:13:11] <SWPadnos> -b
[16:13:38] <SWPadnos> UVW should be checked the same as XYZ, if they're assumed to be parallel axes
[16:13:39] <alex_joni> yeah, I think it's not a good idea to check
[16:13:49] <SWPadnos> well, that depends
[16:13:55] <alex_joni> it's rather better to let the code that has a clue about this to check it
[16:14:03] <alex_joni> SWPadnos: motion does the check anyways
[16:14:08] <SWPadnos> if there is a way (or a way can be added) to provide limits for rotaries, then they should be checked
[16:14:31] <alex_joni> SWPadnos: what I mean is that the check in task (and it's not the only one) is a redundant one
[16:14:36] <fenn> (dont mix up rotary joints with rotary axes)
[16:14:40] <SWPadnos> but then you start a move toward a limit, but the machine stops when it's about to move too far
[16:14:41] <alex_joni> and atm it's busted for nontrivkins
[16:14:42] <SWPadnos> ok
[16:15:08] <alex_joni> it checks the linear endpoint against the joint limits
[16:15:22] <fenn> i'm of the opinion that a cube work envelope is not very useful
[16:15:27] <alex_joni> so it checks if X[mumble] is between joint[0].min and .max
[16:15:35] <alex_joni> fenn: I agree
[16:15:53] <SWPadnos> it's quite useful, but certainly not universal
[16:16:03] <alex_joni> SWPadnos: it's _very_ restricted
[16:16:09] <fenn> its only useful for putting your robot in a square box
[16:16:15] <SWPadnos> sure, and that matters for some types of machine :)
[16:16:26] <fenn> and even then, it might hit the wall with an elbow or something
[16:16:30] <alex_joni> and it doesn't guarantee that a move inside the box is even valid
[16:16:52] <alex_joni> you still have singularities and whatnot
[16:17:11] <alex_joni> so moving from one ok position to another ok position inside the valid cube space, might not be possible
[16:17:19] <alex_joni> (you might get joint limits along the path)
[16:17:32] <SWPadnos> oh sure, I understand it isn't useful for all machines, but it is certainly very useful for some machines
[16:17:44] <fenn> why not just use joint limits?
[16:17:56] <alex_joni> fenn: that's a bit harder to do
[16:18:11] <alex_joni> you need to simulate the move (while feeding positions through kins)
[16:18:19] <alex_joni> and see if any joint limits aren't exceeded
[16:19:18] <fenn> * fenn points at the gobs of spare processing power
[16:19:32] <alex_joni> fenn: at least I haven't found another plausible way to do it
[16:19:39] <alex_joni> fenn: I'm not saying it won't work..
[16:19:44] <fenn> you can build up a map beforehand
[16:20:02] <fenn> map of configuration space
[16:20:11] <alex_joni> you still have to do it to limit speeds so that joint speeds aren't exceeded
[16:20:39] <alex_joni> (do the simulated move, compute fastest joint speeds, check against the max allowable, and scale the move accordingly)
[16:20:49] <fenn> right
[16:21:02] <alex_joni> of course there's still FO in the picture
[16:21:08] <fenn> FO can bite me
[16:21:21] <alex_joni> * alex_joni kinda agrees
[16:21:27] <alex_joni> FO: please bite fenn
[16:21:31] <SWPadnos> FO is still possible that way
[16:21:48] <alex_joni> SWPadnos: just not increasing FO.. only 0..1
[16:21:52] <SWPadnos> you can calculate the max allowable vector velocity (F rate), then clip to that
[16:21:59] <SWPadnos> sure, you can do increasing as well
[16:22:13] <SWPadnos> you calculate the max allowed F word for a segment
[16:22:17] <alex_joni> if the move would exceed the joint vels, and you scaled it to joint max..
[16:22:37] <SWPadnos> apply all scaling (FO/AF/whatever) to the programmed rate, and clip to that max
[16:22:39] <alex_joni> SWPadnos: ah, ok.. I was thinking of the case when the g-code F-word would exceed joint limits
[16:22:56] <alex_joni> SWPadnos: right, that's quite close to how it's done currently
[16:23:02] <SWPadnos> what you have is a dynamic limit, not an ini-stated limit
[16:23:06] <SWPadnos> yep, the same
[16:23:22] <alex_joni> SWPadnos: right, that's quite close to how it's done currently (in canon..)
[16:23:25] <SWPadnos> yep
[16:24:00] <SWPadnos> I think this calls for additional functions in kins, but I'm not sure how those would get linked to canon
[16:24:05] <alex_joni> ok, since you guys are quite familiar with the concepts .. maybe you could look at the changes I had lately (just to see if I missed some joint/axis confusion..)
[16:24:36] <alex_joni> SWPadnos: obviously userspace->motion->kins->motion->userspace is out of the question
[16:24:40] <SWPadnos> I'll try to make the time to do that, but I can't guarantee anything for the next few weeks unfortunately
[16:24:45] <SWPadnos> right
[16:25:07] <alex_joni> so it needs to be some runtime thingie
[16:25:34] <SWPadnos> I wonder if a .so can be made with the same kins source as the .ko is made
[16:25:53] <alex_joni> might be.. you might need some wrapper functions and whatnot
[16:25:58] <SWPadnos> yeah
[16:26:10] <SWPadnos> and both need to be specified (and need to match) in the ini
[16:26:17] <SWPadnos> or some other program to load both needs to be there
[16:26:27] <alex_joni> loadusr something :)
[16:26:42] <SWPadnos> just make sure you have the same something as the loadrt ;)
[16:27:06] <alex_joni> this might be actually very rarely used, so for the beginning even compiling it in might be ok
[16:27:23] <alex_joni> (just for prototyping purposes)
[16:27:33] <SWPadnos> well, I'd want to add derivative functions to the KINS interface
[16:27:39] <alex_joni> maybe a python binding or some sorts
[16:27:40] <SWPadnos> KINEMATICS_ALL
[16:28:02] <SWPadnos> they would be needed at the motion level for accel limiting
[16:28:13] <SWPadnos> and at the canon level for the same thing :)
[16:28:42] <SWPadnos> because motion doesn't know about the ini limits, but CANON does (if I understand the code correctly)
[16:29:43] <alex_joni> "motion doesn't know about the ini limits" <- which limits?
[16:29:55] <SWPadnos> hmmm - well, I'm not sure actually
[16:30:01] <SWPadnos> joint limits do go to motion
[16:30:03] <alex_joni> it surely knows about the joint limits
[16:30:33] <alex_joni> and it would be quite easy to send AXIS limits (defined in the ini) down there.. but just like the box space.. I'm not sure how much good that does
[16:30:40] <SWPadnos> I guess both modules know the limits - motion so it can prevent overdriving the hardware, and canon so it can only provide valid moves
[16:30:58] <alex_joni> I agree
[16:31:01] <SWPadnos> oh right - canon needs to operate with both joint and cartesian limits
[16:31:14] <alex_joni> right, and motion only with joint limits
[16:31:21] <SWPadnos> so it does need to know the joint derivatives
[16:31:22] <alex_joni> and for moves it gets a max_something for this move
[16:31:23] <SWPadnos> yep
[16:31:38] <alex_joni> so FO won't bust things
[16:32:38] <SWPadnos> heh - you could just about do this stuff by just sending the "controlling joint" in the command. "for this move, joint 3 is the critical one - use it for limit calculations"
[16:32:55] <alex_joni> that will rarely be the case
[16:33:17] <alex_joni> at least on puma you have multiple joints which are the critical one along one move
[16:33:20] <SWPadnos> on the contrary - I believe there will almost always be exactly one joint that is the constraining factor
[16:33:31] <alex_joni> nope ;)
[16:33:37] <SWPadnos> sometimes two joints might be "tied"
[16:33:41] <SWPadnos> hmmmmmmmmmmmm
[16:33:47] <alex_joni> if you have a longer move it changes
[16:33:54] <alex_joni> based on the carthesian position
[16:34:30] <SWPadnos> yes, but in the end, if you have checked the entire move, one joint will have the lowest ratio of attainable vs. requested vel
[16:34:47] <alex_joni> sure
[16:35:04] <alex_joni> but.. in the first section you can't use that.. because another joitn might be close to it's limits
[16:35:11] <SWPadnos> but I see the point - you can't check only one at all points along a particular path
[16:36:13] <SWPadnos> actually, maybe you can. say the factor calculated was 0.73x max speed for one joint, and that was the lowest of all joints. if you always remain below that, you're guaranteed to always be below the thresholds for the other joints
[16:36:24] <SWPadnos> by definition, because that 0.73 was the lowest factor calculated
[16:36:36] <SWPadnos> it's not optimal, but it will always be correct
[16:37:10] <alex_joni> ok, I can see that
[16:37:14] <alex_joni> but what's the advantage?
[16:37:35] <SWPadnos> you only need to do derivatives with respect to one joint in RT
[16:37:47] <SWPadnos> rather than checking all and "voting"
[16:37:56] <SWPadnos> probably not an issue
[16:38:00] <alex_joni> but you already have the carth. sepeed
[16:38:04] <alex_joni> speed even
[16:38:08] <SWPadnos> FO/AF ...
[16:38:13] <SWPadnos> done in realtime
[16:38:23] <SWPadnos> jogging along the path (eventually ;) )
[16:38:32] <alex_joni> I mean.. nowadays you already have the carthesian speed
[16:38:39] <alex_joni> it gets calculated by TP I think
[16:38:55] <alex_joni> so you only have to clamp that agains a max admissable carth. speed
[16:38:59] <alex_joni> calculated by canon
[16:39:28] <SWPadnos> does canon/TP do that correctly for SCARA? (for the entire path)
[16:39:34] <alex_joni> I think so
[16:39:39] <alex_joni> because it plans in carth.
[16:40:01] <alex_joni> and only afterwards it generates joint positions
[16:40:19] <SWPadnos> I think I was talking about calculating a limit on cart speed due to joint limits
[16:41:35] <alex_joni> I thought we said we already did that in userspace :)
[16:44:31] <alex_joni> hmm.. I just remembered that jeff already made .so's out of the HAL code when compiling with --enable-simulator
[16:44:54] <alex_joni> I think the same mechanism can be used for kins too
[16:44:59] <SWPadnos> oh yes, so he did
[16:50:10] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/ini/ (emcIniFile.cc iniaxis.cc iniaxis.hh inijoint.cc): (log message trimmed)
[16:50:10] <CIA-30> EMC: - reenable iniAxis* used for reading additional things from AXIS_X, Y, .. sections
[16:50:10] <CIA-30> EMC: in the ini.
[16:50:10] <CIA-30> EMC: these are things like:
[16:50:10] <CIA-30> EMC: * carthesian HOME position
[16:50:12] <CIA-30> EMC: * MIN/MAX limits (for box shaped workspace limiting)
[16:50:16] <CIA-30> EMC: * MAX_VEL/ACC for carthesian speed/accel limiting
[16:52:09] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/ (emc.hh emcops.cc):
[16:52:09] <CIA-30> EMC: * add taskintf functions for setting Axis related things (min/max position, max vel/acc..)
[16:52:09] <CIA-30> EMC: * change EMC_JOINT_LINEAR to EMC_LINEAR (same for ANGULAR): sometimes used for AXES too
[16:53:13] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/emctaskmain.cc: add a comment about some wrongly done limit checks
[16:54:03] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/taskintf.cc: add functions related to axis things (min/max limits, max vel/acc)
[16:55:13] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/ (emcrsh.cc emcsh.cc): replace EMC_JOINT_LINEAR with EMC_LINEAR (same for ANGULAR), sometimes used for axes-related things too
[16:55:14] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: replace EMC_JOINT_LINEAR with EMC_LINEAR (same for ANGULAR), sometimes used for axes-related things too
[16:55:45] <fenn> do people often do FO more than, say, 120%?
[16:55:53] <alex_joni> fenn: unlikely
[16:55:58] <fenn> oops scrollback heh
[16:56:10] <alex_joni> it means they need to change something in the ini :)
[16:56:27] <fenn> so you could just do moves so that 100% joint limit is at 120% FO
[16:56:55] <alex_joni> fenn: I'm not so worried about these specifics
[16:56:55] <fenn> if they are insane and need 100% all the time, set max FO to 1.0
[16:57:32] <alex_joni> they can even disable FO from g-code.. so it shouldn't be that much of an issue
[16:58:09] <alex_joni> ok, so the issue atm is to add the following:
[16:58:29] <alex_joni> an extension to canon which can be loaded dynamically at runtime (in order to chose different kins)
[16:59:21] <alex_joni> before queueing a new command from interp, canon will send it to a motion planner which simulates it, and returns the max speeds/accels encountered for all joints during the simulation
[17:00:01] <alex_joni> canon then will scale the speed accordingly so that max joint speeds aren't violated (if it was below it can scale up, otherwise down)
[17:00:18] <alex_joni> canon then sends the move to motion with the max carthesian allowed speed
[17:00:41] <alex_joni> motion then checks the current speed (programmed + FO's of various sorts) against the max allowed and clamps
[17:05:03] <alex_joni> I wonder if I should disagree with myself..
[17:08:29] <fenn> sounds good to me
[17:08:46] <alex_joni> added it here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JointsVsAxes
[17:16:00] <jmkasunich> gad zooks
[17:16:20] <jmkasunich> I'm not even awake yet and you guys are already at it
[17:16:37] <alex_joni> it's after 8pm here..
[17:16:43] <alex_joni> not much sunshine left
[17:16:56] <jmkasunich> its 1pm here
[17:18:05] <awallin_emc> hmh, I'm getting a servo jump with G33.1. seems to come just when the spindle reverses the second time
[17:18:35] <awallin_emc> maybe I'm just seeing the dynamics of the spindle then...
[17:27:40] <awallin_emc> in addition to rigid-tapping, has anyone done single-point threading with a mill?
[17:28:06] <awallin_emc> where the spindle would be oriented a certain way at the end of the move before an XY move to the center of the hole and a Z retract
[17:28:32] <awallin_emc> I guess I'm asking for spindle orientation. (might be useful for toolchangers that require that too
[17:28:43] <fenn> like threadmilling but done like on a lathe?
[17:29:32] <awallin_emc> yes.
[17:29:52] <fenn> why would you do that? :)
[17:30:32] <awallin_emc> it might be fun. well perhaps more useful is the spindle orient for toolchangers
[17:30:42] <jmkasunich> single point threading on the mill won't work
[17:31:01] <jmkasunich> (I don't mean EMC can't do it, I mean its impossible to do)
[17:31:11] <fenn> i thin you'd need a counterbore for the cutter to spin around in at the bottom of the hole
[17:31:25] <jmkasunich> spindle orient for toolchange, or for extracting a boring tool or reverse counterbore tool would be usefull
[17:31:33] <awallin_emc> I think boring can use spindle orient too, where the tool is disengaged from the material before retract
[17:31:42] <jmkasunich> yep
[17:32:06] <jmkasunich> the reason single point threading won't work is because the tool tip radius needs to change from pass to pass
[17:32:31] <jmkasunich> on a lathe, you spin the work and move the tool tip radially
[17:32:50] <jmkasunich> on a mill, you'd have to spin the tool _and_ move the tool tip radially - the mill axes can't do that
[17:33:05] <fenn> how do cnc boring heads work?
[17:33:28] <jmkasunich> you can preset a boring head for a certain diameter
[17:33:43] <fenn> that's no fun
[17:33:45] <jmkasunich> rough the hole with some other tool, then select the head and do a single boring pass at the target diameter
[17:34:18] <fenn> but it doesnt even have a wifi transmitter
[17:34:20] <jmkasunich> I know there are fancy boring and facing heads with gearing in side - you grab a knurled ring and hold it still, and the boring head moves the tool in or out
[17:56:43] <alex_joni> jmkasunich: maybe you find a moment to look at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JointsVsAxes
[18:03:28] <jmkasunich> looking
[18:03:33] <fenn> seeing how traj runs at the servo rate, why does cartesian position matter in the realtime thread? PID ensures the joints stay on track as well as the computer can keep up anyway
[18:04:02] <jmkasunich> fenn: what are you suggesting? that we do kins in user space?
[18:04:10] <fenn> yes, maybe
[18:04:16] <fenn> i'm wondering why kins has to be in realtime
[18:04:24] <jmkasunich> two words: FO
[18:04:29] <fenn> i dont get it
[18:04:37] <jmkasunich> actually there are others - like spindle synced motion, etc
[18:04:38] <alex_joni> you need to stay synchronised
[18:05:19] <fenn> why does that need kinematics?
[18:05:28] <alex_joni> fenn: currently planning moves is done in TP
[18:05:39] <alex_joni> it moves along the carthesian LINE (or whatever it is)
[18:05:43] <jmkasunich> since speed may be changed due to FO or spindle sync, we pass a motion command to RT as "go from here to hear following this path", and let the TP control the speed along the path
[18:05:53] <fenn> alex_joni: it could just as easily move on some weird curve in joint space
[18:06:06] <jmkasunich> "this path" needs to be described in some simple form
[18:06:09] <alex_joni> fenn: ok, but you have to specify the curve
[18:06:14] <jmkasunich> arcs and lines can, arbitrary curves cannot
[18:06:25] <fenn> well, it would probably be a sequence of lines
[18:06:29] <alex_joni> I think the main reason is that lines and arcs are easy to express
[18:06:37] <jmkasunich> fenn: how many lines?
[18:06:43] <alex_joni> lots ;)
[18:06:43] <fenn> one per servo period
[18:06:53] <jmkasunich> fenn: and here you have your problem
[18:06:58] <alex_joni> so you basicly send points..
[18:07:02] <fenn> why is that a problem? isnt that how it works already?
[18:07:10] <jmkasunich> if FO changes the feed, then the distance traveled per servo period changes, and all your lines go out the window
[18:07:23] <jmkasunich> no, thats NOT how it works already
[18:07:52] <jmkasunich> what is passed to the TP is "go from here to there along a line" (or from here to there along this arc)
[18:08:01] <jmkasunich> that only takes a few bits of data to convey
[18:08:16] <fenn> and then tp does what
[18:08:30] <jmkasunich> the TP then computes a point on that path every servo period
[18:08:33] <alex_joni> it splits that line into points at each servo period
[18:08:51] <alex_joni> and then runs the points through kins to generate joint positions
[18:08:56] <fenn> i'm failing to see how this is different
[18:09:00] <jmkasunich> the incremental movement per period can be changed on the fly, since all the individual points are NOT precomputed
[18:09:14] <alex_joni> fenn: TP only generated the next point
[18:09:15] <jmkasunich> then you aren't listening to us, or you are being thick
[18:09:33] <alex_joni> if FP changes, the next point which it'll generate will be different
[18:09:36] <alex_joni> FO even
[18:09:53] <jmkasunich> the TP is called ONCE per servo period, and each time it is called it generates ONE point
[18:11:59] <alex_joni> fenn: these are the complications that differentiate emc2 from a simple thingie attached to USB
[18:12:49] <alex_joni> they way you picture it can be easily done by simulating through the whole move, and generating waypoints..
[18:13:17] <jmkasunich> but if you slow down or speed up, the waypoints become useless
[18:13:19] <alex_joni> then sending them to an USB microcontroller, or whatever
[18:13:28] <jmkasunich> (inless your "TP" is going to interpolate between them)
[18:13:31] <alex_joni> jmkasunich: that method implies no changes while running
[18:13:46] <alex_joni> not suitable for threading or any other sync'ed moves, etc
[18:13:46] <fenn> you could interpolate between waypoints
[18:13:46] <jmkasunich> alex_joni: exactly
[18:14:07] <alex_joni> fenn: you basicly have speeds/accels hardcoded
[18:14:16] <alex_joni> if you start to interpolate you might exceed limits
[18:14:28] <fenn> if the local joint transform is so nonlinear that you would exceed limits in one servo period, you'd be screwed anyway
[18:14:52] <alex_joni> no, I mean if you start interpolating between waypoints
[18:14:57] <jmkasunich> alex_joni: interpolation is theoretically possible, and you wouldn't exceed limits if FO was less than 1.0
[18:15:08] <alex_joni> you don't have much knowledge what to do..
[18:15:44] <alex_joni> ok, lowering FO might be ok
[18:15:58] <jmkasunich> raising is a problem though
[18:16:02] <fenn> linear interpolation happens every servo period, right?
[18:16:05] <alex_joni> jmkasunich: you might still exceed max_accel when trying to lower it very rapidly
[18:16:18] <alex_joni> (max_decel actually)
[18:16:40] <jmkasunich> the interpolation code would have to handle that - its non-trivial but possible I think
[18:17:05] <alex_joni> if you assume a microcontroller doing the work.. it might get tricky
[18:17:14] <jmkasunich> one way of looking at what fenn is proposing is that he wants to generate thousands of little lines and queue them to the RT planner
[18:17:23] <fenn> i think planning out the entire move every servo period is a bad idea, that's why they had the trajectory thread originally
[18:17:40] <jmkasunich> fenn: now you are confusing me
[18:17:48] <alex_joni> fenn: it doesn't plan the entire move, just the next point
[18:18:01] <jmkasunich> wtf do you mean by "planning the entire move every servo period" ?
[18:18:02] <alex_joni> (well.. it's a bit more complicated during blending..)
[18:18:37] <jmkasunich> it never plans the entire move
[18:18:49] <fenn> jmkasunich: determining if the next waypoint will exceed joint limits
[18:19:06] <fenn> and capping velocity/accel to match
[18:19:11] <jmkasunich> what waypoint?
[18:19:33] <fenn> the place you hope to be after 1 servo period
[18:19:36] <jmkasunich> you might as well be speaking a different language if you are going to use terms that aren't defined
[18:20:04] <jmkasunich> we don't "determine if the next waypoint will exceed limits", we compute the next waypoint such that it doesn't exceed limits
[18:20:25] <alex_joni> there are different 'limits'
[18:20:29] <alex_joni> vel/acc limits
[18:20:32] <alex_joni> and travel limits
[18:20:35] <fenn> right, but if you're looking at a precomputed path you cant make up the path as you go along
[18:20:45] <jmkasunich> duh
[18:20:55] <jmkasunich> thats what we have been trying to tell you
[18:21:02] <jmkasunich> which is why we don't want precomputed paths
[18:21:42] <fenn> i know, but what i'm saying is that if you recompute the path in real-time, at some rate slower than servo thread, ...
[18:21:57] <jmkasunich> why does the rate matter?
[18:23:03] <jmkasunich> and what do you mean by "recompute the path"?
[18:23:27] <fenn> generate waypoints that satisfy joint limits and FO and spindle sync etc
[18:23:51] <alex_joni> spindle sync changes every servo period
[18:23:54] <jmkasunich> why generate multiple points out into the future that you might turn around and discard?
[18:24:22] <jmkasunich> for a line, the XYZ values for any point along that line can be computed trivially
[18:25:07] <jmkasunich> if X1Y1Z1 is the start point, X2Y2Z2 is the end point, then X = X1+p*(X2-X1), where p is a variable that goes from 0.0 to 1.0 over the length of the line
[18:25:14] <fenn> actually i think i'm thinking wrong. the path should be recomputed in user-space, (or maybe kernel space) not a realtime thread
[18:25:17] <jmkasunich> arcs aren't much more complex
[18:25:33] <jmkasunich> there is no kernel space
[18:25:43] <jmkasunich> user or RT are your only choices
[18:25:47] <fenn> why's that?
[18:26:02] <alex_joni> no need for kernel space..
[18:26:13] <fenn> it's more reliable than user space
[18:26:18] <alex_joni> you would need additional comm's
[18:26:19] <jmkasunich> bullshit
[18:26:25] <alex_joni> and wouldn't gain much besides RT space
[18:26:47] <fenn> i'm not saying you should rely on it, it's just a bonus
[18:26:50] <jmkasunich> user space code: premptable
[18:26:56] <jmkasunich> RT code: not preemptable
[18:26:58] <jmkasunich> period
[18:27:11] <fenn> if your userspace code dies, emc stops
[18:27:23] <jmkasunich> if user space calls a normal Linux operating system call, it may be running in "kernel space", but it is still premptable
[18:27:25] <fenn> i dont care about X11 or whatever
[18:27:45] <fenn> but if you run out of g-code what are you going to do?
[18:27:48] <jmkasunich> wtf does X11 have to do with anything?
[18:27:55] <jmkasunich> you are going way out in left field
[18:28:11] <fenn> there's this myth about the computer completing the part even though X had locked up
[18:28:19] <jmkasunich> if you run out of g-code, motion stops
[18:28:55] <jmkasunich> there is a queue that holds lines and arcs, if userspace dies the machine will still execute all moves that are in the queue
[18:28:58] <jmkasunich> its not a myth
[18:29:03] <fenn> so, you need userspace code for proper function, right?
[18:29:15] <fenn> how big is this queue?
[18:29:21] <jmkasunich> a couple hundred moves
[18:29:58] <jmkasunich> it has to be big enough that even the most fscked up, laggy, prempted user space code can keep it from running empty
[18:30:10] <jmkasunich> at a minimum it should hold a few seconds of motion
[18:30:41] <jmkasunich> since a few seconds of short moves can be many minutes of longer moves, it is quite possible for an entire program or sizable part of a program to be in the queue
[18:30:56] <alex_joni> there are actually 2 queues
[18:31:05] <alex_joni> one going from canon to task
[18:31:16] <alex_joni> and the other one inside motion
[18:31:33] <fenn> lines and arcs is canon->task right?
[18:31:41] <jmkasunich> also, related to the myth: interpreting g-code and queuing up motion is done by task, which is a separate linux process from the GUI, so once the program is started, the GUI can die but if task stays alive the how program will run
[18:31:42] <alex_joni> canon->task->motion
[18:31:49] <fenn> does motion do arc interpolation?
[18:31:53] <alex_joni> yes
[18:32:07] <alex_joni> and even synced moves along that arc interpolation I think
[18:32:08] <jmkasunich> alex_joni: canon and task are the same process aren't they?
[18:32:14] <alex_joni> jmkasunich: yes
[18:32:25] <jmkasunich> so canon->task->motion isn't really correct
[18:32:36] <jmkasunich> if you are talking about interprocess comms
[18:32:49] <alex_joni> it's actually task running the interp which calls the canon calls, which puts stuff into the task queue
[18:32:58] <jmkasunich> but all one process
[18:33:25] <alex_joni> I think
[18:33:38] <alex_joni> actually I'm mostly sure it's one process
[18:34:12] <jmkasunich> task loop: call interp with a line of g-code, interp in turn calls canon, which queues up stuff in the task queue (not the RT queue), then canon returns to interp, interp returns to task, and the next step in the task loop is to take items out of the task queue and stuff them into the motion queue.... then the task loop repeats, calling the interp again
[18:35:08] <alex_joni> yup
[18:35:25] <alex_joni> only the stuffing into motion queue happens only if the motion queue has space available
[18:35:30] <jmkasunich> right
[18:35:45] <alex_joni> so effectively the interp/task queue gets way ahead of the motion queue
[18:35:46] <jmkasunich> and probably calling the interp only happens if the task queue has space available
[18:35:54] <alex_joni> yeah, but that one's pretty big
[18:36:11] <jmkasunich> between the two queues, a lot of motion can be queued
[18:36:35] <jmkasunich> if the GUI dies, task will continue to run the entire program
[18:36:40] <fenn> if you represented the curve as an equation rather than a lot of points, it would reduce the amount of data required
[18:36:45] <jmkasunich> if task dies, motion will continue to run whatever is in the motion queue
[18:36:53] <alex_joni> hmm. it's a linked list (interp_list), so I'm not sure what the size is..
[18:36:54] <jmkasunich> fenn: yes, exactly
[18:37:04] <jmkasunich> lines and arcs are basically represented as equations
[18:37:12] <jmkasunich> not so easy to do if the curve is arbitrary
[18:37:33] <alex_joni> especially if this has to run after some nasty CAM program did his optimisations
[18:37:34] <jmkasunich> alex_joni: maybe limited only by memory?
[18:37:45] <alex_joni> jmkasunich: I might be bothered to look if needed
[18:37:54] <jmkasunich> don't look on my account
[18:38:05] <jmkasunich> I don't care - that queue is only between two parts of the same process
[18:38:15] <fenn> well, if the input is path-o-logical then you cant simplify it no matter what
[18:38:31] <jmkasunich> its not pathological in cartesean space
[18:38:47] <jmkasunich> so that is how we pass it to motion
[18:38:57] <fenn> if it's locally linear in cartesian space it's going to be locally linear in joint space
[18:39:07] <jmkasunich> bullshit again
[18:39:14] <fenn> you can do the same assumptions as you would do in cartesian space (glomming paths together)
[18:39:15] <alex_joni> it's 1000 right now
[18:39:21] <jmkasunich> or are you inventing terms again
[18:39:57] <alex_joni> #define EMC_TASK_INTERP_MAX_LEN 1000
[18:40:19] <fenn> say you had a bunch of line segments, all in a line
[18:40:36] <fenn> in joint space it would look pretty much the same, over a short distance
[18:40:43] <jmkasunich> how short?
[18:40:49] <fenn> however, if you're next to a singularity, it'll look like a curve
[18:41:01] <jmkasunich> how short?
[18:41:08] <fenn> i dont know how short.. that's some magic number that you have to pick
[18:41:16] <alex_joni> it is a curve in joint space. no matter what
[18:41:27] <jmkasunich> you are trying to pretend that the problem doesn't exist
[18:41:41] <fenn> i'm trying to make some simplifying assumptions so the problem is easier
[18:41:53] <jmkasunich> it is true that for a sufficiently short distance, the difference between a curve and a line is small
[18:42:13] <jmkasunich> but you seem to think just because that is true, that all curves can be represented by lines
[18:42:32] <alex_joni> fenn: as it is now, it's close to beeing problematic at feeding data from userspace to motion
[18:42:46] <fenn> no, i'm saying if you have a pathological input path, you can simplify it in either joint space or cartesian space
[18:42:54] <jmkasunich> if I have a straight line in cartesean space, I can break it into 1000 straight lines in cartesean space
[18:43:07] <alex_joni> if we wouldn't be moving little data (lines and arcs parameters), it would be plausible to get into throughput problems
[18:43:20] <jmkasunich> you NEVER have a pathological input path!
[18:43:44] <fenn> huh? lots of little lines is not pathological?
[18:43:47] <jmkasunich> the input path (in cartesean space) is always lines or arcs, because that is all that g-code provides
[18:44:27] <jmkasunich> this is a stupid conversation - you are starting with a proposal that falls on it's face with normal input, then jumping straight to pathological input
[18:44:40] <jmkasunich> prove that it works with normal input first, please
[18:44:52] <jmkasunich> (or admit that it doesn't, and stop wasting time on it)
[18:45:06] <fenn> you started talking about data throughput so i started talking about data compression
[18:45:32] <jmkasunich> we are talking past each other
[18:45:34] <fenn> yes
[18:46:15] <jmkasunich> it sounds like your proposal is to take all input and convert it to pathological input (by breaking it up into tiny slices in user space)
[18:46:20] <fenn> i just think its weird that path planning and PID occur at the same rate
[18:46:37] <alex_joni> then make PID work faster
[18:46:43] <alex_joni> would that make you happier?
[18:46:53] <fenn> alex_joni: but then you run into the bogeyman of precomputed paths
[18:46:53] <jmkasunich> why do you think its weird
[18:47:00] <fenn> we cant have that
[18:47:04] <jmkasunich> why run the PID loop 10 times with the same input position?
[18:47:19] <alex_joni> because it would oscilate nicer
[18:47:24] <jmkasunich> ;-)
[18:47:32] <alex_joni> s/nicer/faster/ :)
[18:47:36] <alex_joni> </joke>
[18:48:13] <alex_joni> fenn: would you have PID run faster or TP?
[18:48:18] <fenn> PID
[18:48:27] <fenn> PID should run as fast as possible
[18:48:33] <alex_joni> as jmk said.. it would run on the same data
[18:48:34] <jmkasunich> again, I ask why have PID loop 10 times with the same input position?
[18:48:48] <fenn> so it tracks better
[18:48:57] <fenn> otherwise it's like riding a bicycle with your eyes closed
[18:49:01] <jmkasunich> tracks the same position better?
[18:49:05] <alex_joni> it might be usefull to get smaller position increments and faster PID
[18:49:13] <alex_joni> but that means both run faster
[18:49:25] <jmkasunich> the absolute speed is irrelevant here
[18:49:41] <jmkasunich> I'm still waiting for a justification for not having the rates the same
[18:49:46] <fenn> if steppers can run at 40kHz then why can't PID also run at 40kHz?
[18:50:11] <jmkasunich> don't bring steppers into this
[18:50:12] <fenn> because we have this huge path planning algorithm that eats up a lot of time each cycle
[18:50:23] <jmkasunich> steppers are discrete distance, servo rate is discrete time
[18:50:25] <alex_joni> hmm.. the processor does 2GHz.. why shouldn't PID run at 2GHz ?
[18:50:40] <jmkasunich> that mismatch has its own issues, that have NOTHING to do with trajectory planning
[18:50:51] <fenn> alex_joni: the rate limiting factor is i/o right?
[18:51:01] <alex_joni> for PID?
[18:51:05] <fenn> yes
[18:51:06] <alex_joni> not at all
[18:51:17] <alex_joni> it's probably for the output from PID
[18:51:25] <fenn> nothing else running, just a PID hal block
[18:51:28] <alex_joni> but PID itself doesn't have any I/O
[18:51:34] <fenn> how fast can i run the servo thread?
[18:51:40] <jmkasunich> the rate limiting factor is the bandwidth of the external system
[18:52:05] <jmkasunich> I'm considering only real servos here, not steppers, they just confuse things
[18:52:12] <alex_joni> fenn: I would bet (without trying) that a simple PID hal block is quite able to run in the BASE_THREAD
[18:52:20] <fenn> ok, for high bandwidth, how about a galvanometer
[18:52:24] <fenn> those laser light shows
[18:52:48] <jmkasunich> the servo motor has a bandwidth limit, based on how much voltage you can apply, which limits how fast you can slew the current throught the motor inductance, which means how fast you can slew the torque
[18:53:26] <alex_joni> you have fast changing motors (like DLP mirrors)
[18:53:27] <jmkasunich> for laser light shows, the "motor" bandwidth is higher, so yes, you can run the PID higher and actually gain something from it
[18:53:56] <fenn> do you agree that it requires kinematics to run one of those?
[18:54:08] <jmkasunich> but for metalcutting machines, long experience has shown that there is little to be gained by increasing servo rate
[18:54:19] <fenn> because you're using a big clunky piece of iron
[18:54:27] <jmkasunich> yes, I am
[18:54:32] <fenn> HSM machines can actually make use of higher PID
[18:54:44] <jmkasunich> a few KHz instead of 1KHz, yes
[18:55:20] <fenn> a bridgeport doesnt need realtime anything
[18:55:38] <fenn> it just needs reliability
[18:55:44] <jmkasunich> sorry, I'm tired of wasting time in this conversation - I have parts to make. If you have a serious proposal, write it up in detail somewhere - there is too much hand-wavium going on right now
[18:56:34] <jmkasunich> now you are either redefining the word 'realtime' or redefining 'reliability', which is it?
[18:57:07] <fenn> reliability is keeping the system going, even though it may stretch the timing a bit
[18:57:24] <fenn> realtime is "this must be done every N seconds, period"
[18:57:30] <jmkasunich> "realtime" = "a guarantee that the code will execute before some deadline is reached" - it doesn't matter if the deadline is measured in uS or weeks
[18:58:43] <jmkasunich> define "keeping the system going" - seems to me that if you miss the deadline for issuing a new position command, the machine is gonna stop at the current position until you do issue a new command
[19:00:07] <fenn> let's say you have a DOS program that does everything it needs to between consecutive position updates
[19:00:31] <alex_joni> that's realtime
[19:00:33] <fenn> as long as that program doesnt hang, it will eventually update the position
[19:01:03] <fenn> i'd say it's not realtime, because it isnt necessarily going to finish within a certain period
[19:01:05] <alex_joni> if the update rate doesn't change or hang, it does it under a certain max value
[19:01:15] <alex_joni> ok, then it's not realtime
[19:01:33] <alex_joni> but your part might be ruined
[19:02:24] <fenn> yeah you might get a divot where the mill stopped, but it's not going to crash or anything
[19:03:00] <alex_joni> it might screw your work if you are cutting plastics
[19:03:11] <fenn> melting?
[19:03:50] <fenn> anyway, in comparison, the same program run on a HSM might wreck the machine because it stopped in the middle of the program
[19:04:27] <SWPadnos> the more important problem is that a userspace crash of the program that provides new waypoints may leave a cutter spinning at high speed, and in contact with the work
[19:04:41] <SWPadnos> this is a fire hazard depending on the material and time involved
[19:04:51] <SWPadnos> (ie, MDF in an 8-hour run you leave overnight)
[19:05:01] <fenn> i'm not talking about a crash
[19:05:12] <fenn> just non-deterministic computing
[19:05:20] <fenn> uh, damn that's an overloaded word
[19:05:30] <SWPadnos> this will still occur even if you have a RT charge-pump component running, since there is currently no way to monitor the userspace process
[19:05:57] <SWPadnos> crash / "pre-emption" - more same thing with a different time constant
[19:06:04] <fenn> functions that dont complete within a certain amount of time (generally you want this time value to be consistent so you can tune the machine for its optimum performance)
[19:06:05] <SWPadnos> as far as motion is concerned
[19:06:24] <SWPadnos> s/more/the/
[19:07:31] <awallin_emc> can I add a comp to 2.2.4 without having the whole source-tree?
[19:07:50] <SWPadnos> I'd bet you can't
[19:07:50] <fenn> comp --install <yourcode>
[19:08:05] <awallin_emc> that compiles it too?
[19:08:08] <SWPadnos> you need the EMC and kernel headers (at least if it's RT)
[19:08:10] <fenn> the easy way is to get the whole source code
[19:08:15] <SWPadnos> yes, that compiles it, but you need the headers
[19:08:28] <awallin_emc> I have build-dep for emc2
[19:08:30] <SWPadnos> you can apt-get source emc2
[19:08:39] <fenn> does emc-dev have the headers?
[19:08:45] <SWPadnos> I doni't know
[19:08:47] <SWPadnos> -i
[19:08:55] <fenn> This package includes files needed to build new realtime components and
[19:08:55] <SWPadnos> mmmmmm - donits
[19:08:55] <fenn> alternate front-ends for emc2
[19:09:03] <SWPadnos> ok, maybe it does :)
[19:09:09] <awallin_emc> I need an 'inverse-deadband' component on the PID outputs
[19:09:24] <SWPadnos> uh - what do you mean?
[19:09:40] <awallin_emc> let me show you a pic
[19:09:58] <SWPadnos> trying to make the output jump from 0 to some minimum?
[19:10:03] <awallin_emc> here
http://www.anderswallin.net/wp-content/2007_11servos/dac_vs_rpm.jpg
[19:10:17] <awallin_emc> the servos won't react to a DAC output between around -0.2 and 0.2
[19:10:29] <awallin_emc> that makes the PID loop 'squishy' around the set-point
[19:10:42] <SWPadnos> isn't there a min_output pin? (or am I thinking of PWM?)
[19:10:58] <SWPadnos> err - parameter I mean
[19:11:20] <awallin_emc> there is dac gain and dac offset, but you still go through zero with those I think
[19:13:07] <alex_joni> awallin_emc: you want to install emc2-dev
[19:13:21] <alex_joni> then you can comp -install ..
[19:13:25] <SWPadnos> that has the appropriate headers?
[19:13:28] <awallin_emc> I think I have that from yesterday
[19:13:58] <alex_joni> you can always check with dpkg -l emc2-dev
[19:14:14] <awallin_emc> anyone have a link to the 'comp' html documentation?
[19:14:47] <fenn> http://linuxcnc.org/docs/html/hal_comp.html
[19:17:02] <awallin_emc> are the comments from the source automagically made into a man page?
[19:17:13] <fenn> yes but they need groff formatting
[19:17:33] <fenn> also it includes hal pins in the man page
[19:19:52] <awallin_emc> nice. it compiles. now lets see if it works...
[19:23:17] <awallin_emc> can I then just use "loadrt mycomp"
[19:27:48] <alex_joni> yup
[19:28:38] <awallin_emc> this is GREAT. the guy who came up with comp must be at least as bright as the one who conceived pyvcp! :)
[19:29:14] <awallin_emc> methinks the pendant buttons will get a special comp and I don't have to learn CL
[19:29:36] <alex_joni> jepler came up with comp
[19:29:54] <alex_joni> don't recall who it was on pyvcp.. tomp?
[19:30:35] <awallin_emc> ehhehe,
http://www.anderswallin.net/2007/01/extending-axis-with-pyvcp/
[19:31:26] <alex_joni> ok, awallin_emc then :P
[19:31:56] <alex_joni> awallin_emc: sorry for pulling your leg :D
[19:35:33] <awallin_emc> alex_joni: I have a suggestion for halui which I might write to the dev list about
[19:36:49] <awallin_emc> nothing big, just would be easier for the integrator if the feed-override and speed-override had an interface more similar to the jog interface of motion
[19:37:07] <alex_joni> and that would be?
[19:37:30] <awallin_emc> enable inputs. now I switch between a scale of say 0.01 and 0.0 (disabled)
[19:37:50] <alex_joni> ah, ok that surely can be done quite easily
[19:38:10] <alex_joni> are you familiar with 'cvs diff -u > halui-improvements.patch' ?
[19:38:53] <awallin_emc> :) I do emc related things far too seldom to remember such long command lines
[19:39:14] <alex_joni> awallin_emc: I can always remind you the command lines :P
[19:41:17] <awallin_emc> yay, my inverse deadband component seems to take care of the problem
[19:41:26] <awallin_emc> servo feels much tighter now when twisting side to side
[19:43:13] <alex_joni> awallin_emc: cool
[19:43:19] <alex_joni> hi crotchetyGuy
[19:43:44] <crotchetyGuy> hi alex_joni-
[19:46:48] <alex_joni> crotchetyGuy: it's CIA-30 in here doing the reporting
[19:46:54] <alex_joni> * alex_joni kills CIA-30
[19:46:54] <CIA-30> * CIA-30 dies
[19:47:44] <crotchetyGuy> so CIA-30 is a program?
[19:47:55] <alex_joni> a bot .. it's not always the same number
[19:48:02] <alex_joni> http://cia.vc/stats/project/emc
[19:48:09] <alex_joni> that's our stats page at cia
[20:12:50] <awallin_emc> was it FF0 or FF1 or FF2 that jon elson recommended for his amps?
[20:12:58] <awallin_emc> torque mode control that is
[20:13:02] <cradek> definitely not ff0
[20:13:19] <cradek> I always end up using both ff1/ff2 (but I've never used elson's amps)
[20:14:20] <awallin_emc> now I have P=20 I=200 and FF1=0.1
[20:14:45] <cradek> I like to turn off I in order to see the FF effects clearly
[20:15:11] <awallin_emc> I'm getting around 0.04 of error, or 100 encoder counts
[20:15:11] <cradek> once FF keeps your error low, you can increase I with impunity because it won't tend to wind up
[20:15:22] <cradek> is that .04 mm?
[20:15:28] <awallin_emc> P=0 also when tuning FF?
[20:15:39] <cradek> no, you need the P
[20:15:56] <awallin_emc> yes, 0,04mm if I read halscope correctly. It has 400counts/rev and the screw is 2.5mm/rev
[20:16:51] <cradek> that's pretty good following, but you can probably improve it
[20:17:20] <awallin_emc> this is accelerating to around 6000mm/min in the middle of a 100mm G0 move
[20:17:41] <cradek> that's a nice speed
[20:19:03] <awallin_emc> better take some screenshots and post them on the blog...
[20:19:17] <awallin_emc> what was the screenshot command in ubuntu?
[20:19:30] <cradek> be sure you use a move long enough to get up to cruise velocity, so you see the steady state errors too
[20:19:41] <cradek> poke the printscreen button
[20:20:43] <jmkasunich> does printscreen capture the whole screen? or is there a trick to get just the active window?
[20:20:52] <alex_joni> alt or ctrl pressed down
[20:20:54] <alex_joni> I forget which
[20:21:08] <cradek> I know you can set it in the keyboard shortcuts thingy
[20:21:16] <jmkasunich> I usually use Gimp's "file->acquire->screenshot" thing
[20:21:24] <awallin_emc> now the DAC goes to around 8.7 at the cruise phase of the G0 move
[20:21:30] <alex_joni> I mostly use printscreen, or alt-printscreen
[20:21:53] <cradek> sounds like you better not go much faster then
[20:24:39] <awallin_emc> so I've found about the maximum velocity for the ini file. what about max acceleration, what would be a good test to find that?
[20:26:12] <jmkasunich> try faster and faster accels, watch to make sure you don't saturate the DAC
[20:26:42] <jmkasunich> accel is proportional to torque which is proportional to current
[20:26:54] <jmkasunich> so if you know the max motor current rating, make sure you don't exceed that
[20:27:17] <jmkasunich> (dunno if you can measure peak current or not, got an o-scope? and a current probe?)
[20:29:36] <awallin_emc> yes I could measure the current... is it worth the trouble? if I just see the DAC doesn't saturate. These jon-elsons amps shouldn't be able to deliver the peak current the motors can take
[20:29:51] <awallin_emc> A little FF1 makes the error oscillate in the accel/deccel phases
[20:30:24] <cradek> FF1 should have most effect during cruise
[20:30:36] <awallin_emc> what about FF2?
[20:30:43] <cradek> during accel/decel
[20:30:52] <awallin_emc> yes, with FF1 the error was cut tenfold copared to only P
[20:31:00] <cradek> cool
[20:31:13] <cradek> D can help with all oscillations
[20:31:28] <cradek> bbl
[20:34:40] <awallin_emc> hmh, FF2 only made the accel/deccel phases much worse
[20:34:51] <awallin_emc> is the sign of FF2 supposed to be the same as for I and P ??
[20:35:30] <jmkasunich> all signs are usually positive
[20:36:00] <awallin_emc> FF2 seems very sensitive
[20:36:12] <jmkasunich> not surprising really
[20:36:44] <awallin_emc> doesn't really improve the accel/deccel phase... perhaps with more mass attached to the motor?
[20:36:47] <jmkasunich> FF2 is the accel term - thats a second derivative of the position command, and derivatives are high-pass filters - they amplify high frequency noise
[20:38:59] <alex_joni> grep -r -e FIXME-AJ src/* | wc -l
[20:39:00] <alex_joni> 20
[20:39:16] <alex_joni> hmm.. those don't seem to decrease :)
[20:39:48] <awallin_emc> now the worst FE happens at the start/end of the accel/deccel phases
[20:40:15] <awallin_emc> i.e. I get mostly zero but four spikes at the beginning and end of the accel/deccel phases
[20:40:23] <alex_joni> how high?
[20:41:01] <awallin_emc> they are one div with the scale set to 20m, so that would be 0.020 mm I guess
[20:41:36] <alex_joni> ok, so probably something not to worry about atm
[20:41:47] <alex_joni> you still have the motor on the table.. right?
[20:41:59] <awallin_emc> yes, no load whatsoever
[20:42:11] <alex_joni> it will be completely different with load
[20:42:35] <awallin_emc> right. maybe stop here then. I'll post the pics so you can all look :)
[21:02:36] <alex_joni> * alex_joni calls it an early night
[21:02:40] <alex_joni> good night all
[23:37:13] <jmkasunich> hey jepler
[23:38:26] <jmkasunich> I have some questions about the offsetting code that you've been messing with
[23:48:18] <jmkasunich> going outside, I'll try again later
