Back
[00:43:42] <cmorley> mozmck:
http://www.linuxcnc.org/docs/2.7/html/remap/remap.html#remap:referto-inifile-variables
[07:31:07] <jepler> seb_kuzminsky: yes that is essentially the shell script I imagined writing.
[08:35:21] <cradek> I didn't know about $SECONDS
[08:36:56] <jepler> a bashism I guess?
[08:44:34] <cradek> jepler: does this help you understand community builder?:
http://www.joomlapolis.com/images/stories/cbsubs.jpg
[08:46:10] <jepler> ummm
[08:46:19] <jepler> I have to say I suspected it might be an unhelpful image before I opened it
[08:46:42] <cradek> well, you know me
[08:56:06] <JT-Shop> jepler, if you want to give me administrator rights to the test site I can learn how to format the pages etc in a safe place
[08:56:46] <mozmck> cmorley: thanks! I missed that somehow.
[08:56:54] <jepler> JT-Shop: happy to, jas
[08:57:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 5972fc8 06linuxcnc 10src/Makefile 10src/emc/motion/motion_debug.h Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5972fc8
[08:57:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 cc589a5 06linuxcnc 10src/emc/motion-logger/motion-logger.c 10tests/motion-logger/expected.builtin-startup motion-logger: add the new Motion commands in 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc589a5
[08:57:52] <jepler> JT-Shop: you should be able to do anything now
[09:00:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 96026f6 06linuxcnc 10scripts/realtime.in realtime script: wait for the last rtapi_app to die when stopping realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96026f6
[09:00:50] <KGB-linuxcnc> 052.7-realtime-unload-race d523d9e 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d523d9e
[09:00:50] <KGB-linuxcnc> 052.7-test-startup-shutdown 28f9af8 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=28f9af8
[09:05:33] <JT-Shop> hmm, either I forgot my password or it got reset
[09:17:05] <ssi> 20:18 < jepler> ok this is crazy -- a 28-bit R-2R DAC. look at all those SMD parts!
http://soekris.com/products/audio-products/dam1021.html
[09:17:13] <ssi> that's... awesome. In a terrible sort of way
[09:17:38] <ssi> similar, but slightly less terrible:
[09:17:39] <ssi> http://www.amb.org/audio/delta1/
[09:17:53] <ssi> I built one of those, and aside from the switching noise when changing volumes, it works pretty well
[09:18:05] <ssi> but to pcw's point, it's all leaded precision resistors
[09:25:43] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/149242
[09:33:20] <jepler> ssi: nice
[09:33:55] <jepler> JT-Shop: uh oh, when I was updating your account it said something about the passwords not matching
[09:34:12] <jepler> JT-Shop: were you able to get logged in again? looks like a perfect opportunity to try the password reset procedure :-/
[09:34:50] <jepler> cradek: Yes, normally a RSS fetcher wouldn't be logged in to the forum or whatever site it's fetching rss from
[09:35:10] <jepler> cradek: but I was looking at the rss feed via my web browser, and its contents did depend on whether I was logged into the website in another tab or not
[09:38:04] <JT-Shop> I'm logged into the forum when I go to /administrator it asks for my username and password. After I enter it I get You do not have access to the Administrator section of this site. When I click on the ? next to password and enter my user name it says I'm already logged in.
[09:39:59] <jepler> JT-Shop: I tried changing your user groups again
[09:40:01] <jepler> please try again?
[09:40:34] <JT-Shop> that worked
[09:40:35] <jepler> it does look like the settings I made earlier didn't stick but I think this time they did
[09:40:43] <jepler> i'm not very good at website
[09:41:48] <jepler> JT-Shop: if you do make changes via the administrator interface, make note of what they are since like everything else they'll get deleted when I do the real upgrade.
[09:41:58] <JT-Shop> ok, will do
[09:52:12] <seb_kuzminsky> wow, rob ellenbergs email to gene was really well thought out and clearly worded, what great support
[09:53:57] <jepler> sometimes I do wonder if we should have different G64 defaults
[10:07:36] <jepler> but on the other hand I feel strongly that all relevant modal codes should be specified at the top of a part program
[10:10:38] <jepler> on yet another hand, you want to just start up your machine and MDI sometimes
[10:12:33] <mozmck> It can be put in the RS274NGC_STARTUP_CODE
[10:13:09] <ssi> does that execute only once at axis launch, or does it execute before every program?
[10:13:31] <ssi> in other words, if you default G64 in ini like that, and a program modifies it, does it stay modified for a subsequent program that doesn't explicitly set it?
[10:14:00] <mozmck> Hmm, I think it does
[10:14:33] <ssi> I mean, jepler's right... for consistency, every program should set all modals
[10:18:14] <jepler> yes, the way the G64 setting works (not reset to a default value by M2 and certainly not by a program that is terminated by %) means it's even important to specify in your part programs even if you have a value you like in your RS274NGC_STARTUP_CODE
[10:19:52] <JT-Shop> I've always thought G61 should be the default as the safest way to run a machine with slow acceleration
[10:20:54] <ssi> other than plasma, what case would G64 be a sensible default?
[10:21:28] <ssi> oh I guess that's part of the TP issues with small line segments isn't it
[10:22:47] <jepler> JT-Shop: possibly
[10:23:12] <JT-Shop> I've often seen questions as to why the end mill or drill broke off retracting out of a hole then rapiding to next location
[10:23:23] <jepler> JT-Shop: but so what if it is -- you can put G61 in RS274NGC_STARTUP_CODE, but that's no guarantee that G61 is in effect when you start your second part program during a session
[10:24:19] <cradek> this is maybe beside the point, but I'm pretty sure drill cycles automatically switch to g61 mode and back, for you
[10:24:30] <jepler> we *could* redefine what happens to the blend mode at M2 / % I suppose
[10:25:04] <cradek> we could also choose to not blend rapids
[10:25:41] <ssi> for the modals that are more "machine specific", it might make sense to reset to default then startup_code, for principle of least surprise
[10:26:15] <jepler> but the G64 setting is *NOT* machine specific. The proper setting is informed both by machine details AND by part tolerances
[10:26:50] <ssi> true, but I can imagine people sticking with one G64 setting for the machine as a whole... again, thinking about plasma machines
[10:27:19] <ssi> you're still right in that competent operators should be specifying modals in every program header
[10:27:35] <jepler> afk
[10:27:51] <ssi> but I'm just thinking about folks who set a machine up a particular way, are sloppy about modals, and then run someone else's program or test program that modifies their "defaults" and they don't realise it
[11:09:15] <seb_kuzminsky> http://linuxgizmos.com/raspberry-pi-2-clone-runs-linux-on-an-intel-atom-x5/
[11:23:21] <jepler> 16GB eMMC is nice. hopefully the ethernet is on PCIe but I don't see it called out in the block diagram
[11:23:59] <ssi> might could do mesa via spi if not
[11:24:04] <jepler> yeah, might could
[11:25:34] <jepler> I have a feeling that 1GB RAM and 1.84GHz means it's going to be as lousy for *developing* linuxcnc as any of those ARM boards
[11:25:58] <ssi> I'd happily pay $100 for a small form factor sbc that runs linuxcnc w/axis well via mesa hardware
[11:26:05] <ssi> I hate having to manage full size pcs
[11:26:14] <jepler> yes agreed fully
[11:26:33] <ssi> was really hoping that the bbb would be that two years ago, but obviously that didn't pan out
[11:26:45] <ssi> I don't care about the low cost aspect so much
[11:27:01] <ssi> the host is the cheapest part of the machine integration :P
[11:27:20] <jepler> I spend 1000x as much time developing linuxcnc than using it, so stuff like "can rebuild a source tree in way under a minute" is a real perk and none of the itty bitty systems do that
[11:27:54] <ssi> yea absolutely
[11:28:07] <ssi> but hopefully on an x86 system there shouldn't be too much on-system development work
[11:28:23] <ssi> not a lot of porting and device tree crap like you have to do on the arm boards
[11:29:40] <jepler> you taking out a bet about our Wheezy image installing and running with good latency and no hacking necessary?
[11:29:47] <ssi> nope! :D
[11:29:59] <ssi> just hoping for "reduced" hacking
[11:30:00] <jepler> the linux kernel mailing list is as full of "make this new shit from intel work" as "make this new shit from unknown arm SBC manufacturer work"
[11:31:49] <seb_kuzminsky> pcw_home has mentioned a little tupperware computer a couple of times, apparently it's a regular PC with no porting needed, and it's fast enough to be a devel box, and it's got good enough latency to run a machine
[11:38:08] <pcw_home> Its not fast (well faster than the older Atom D525/D2550) but runs Preemt-RT well enough
[11:39:01] <seb_kuzminsky> does it have a free PCIe port? or dual ethernet? how do you connect the fpga to it?
[11:39:19] <pcw_home> There are a lot of VESA mount mini PCs from the J1800 class up to I7s
[11:39:40] <pcw_home> Ethernet (and USB wireless)
[11:40:10] <pcw_home> (Ethernet --> FPGA USB wireless--> net)
[11:43:03] <pcw_home> most mini PCs have built in wireless but the stream mini (Tupperware)
[11:43:05] <pcw_home> has a Broadcom card that
[11:43:06] <pcw_home> 1. requires fetching and installing Broadcoms binary driver
[11:43:08] <pcw_home> 2. and does bad things to latency
[11:43:09] <pcw_home> So I had t use a USB wireless dongle for network access
[11:54:48] <ssi> you're using wireless for rt mesa?
[11:54:57] <ssi> or using the builtin ethernet for mesa and using the usb wireless for network
[11:55:44] <jepler> ssi: the latter, I think
[11:55:58] <ssi> that makes more sense
[11:56:09] <ssi> ah I see how to parse what pcw said there
[11:58:18] <pcw_home> The Atheros wireless in my laptop seems OK latency wise, Ive never had good luck with broadcom
[12:00:03] <linuxcnc-build_> build #2850 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2850 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:01:02] <jepler> 00:19.0 Ethernet controller: Intel Corporation 82567V-2 Gigabit Network Connection
[12:01:05] <jepler> 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
[12:01:15] <jepler> these are the three ethernets I regularly use with hm2_eth
[12:03:52] <pcw_home> the Realtek ones work well also
[12:04:08] <pcw_home> (8168, 8169, 8111, 8139)
[12:05:26] <pcw_home> the Realtek MACs don't have the IRQ coalescing option in the driver so dont need the ethtool tweak
[12:06:23] <pcw_home> the newer low cost Intel macs work also (210,211 etc)
[13:22:22] <skunkworks> rob emailed me and he is looking into a way to do circular arc blending in all axis..
[13:22:40] <skunkworks> he said it is 'complicated' ;)
[13:23:07] <jepler> I was just musing this weekend that hot glue guns can't use the Ellenberg TP since they're always moving an additional axis for the extruder
[13:23:59] <ssi> hm really?
[13:24:53] <skunkworks> the workaround the machinekit people are doing is 'velocity' extruding..
[13:25:18] <jepler> skunkworks: so they noticed the limitation
[13:25:55] <skunkworks> it actually works ok - usually you can have the accelleration of the protoypers so high that it works..
[13:26:07] <skunkworks> (1 segment blending)
[13:27:04] <skunkworks> that is how charles reprap was setup at wichita..
[13:27:36] <skunkworks> and it seemed to do ok. but ti would be nice to have X lookahead in rotory axis also
[13:30:01] <skunkworks> jepler,
http://basdebruijn.com/tag/velocity-extrusion/
[13:34:01] <pcw_home> One of our customers would _really_ like XYZA CAB to work
[15:19:02] <skunkworks_> yikes - he really seems to want to move away from the hobby side
[15:19:04] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/149263
[15:23:19] <cradek> so ... he expects people to politely help him do early testing for free, and also buy the result from him?
[15:23:32] <skunkworks_> correct
[15:23:41] <cradek> welp
[15:23:57] <skunkworks_> some have already bought the software..
[15:24:17] <cradek> welp
[15:24:23] <skunkworks_> so you are paying to test.. :)
[15:24:49] <seb_kuzminsky> we should definitely charge skunkworks more
[15:24:53] <skunkworks_> no reason to be upset about that... ;)
[15:25:20] <skunkworks_> I would pay twice - but nothing more..
[15:25:27] <seb_kuzminsky> heh
[15:26:37] <skunkworks_> (I would pay mesa twice what he charges but don't tell him that...)
[15:27:37] <seb_kuzminsky> for realsies
[15:27:47] <andypugh> I got a nice stack of 6 Mesa cards today (6i24, 7i49, 7i44, 7i85, 7i73, 8i20)
[15:27:49] <cradek> actually I think we should double skunkworks's salary too
[15:28:38] <skunkworks_> oooh - awesome!
[15:28:47] <seb_kuzminsky> my weekend netted -1 mesa cards, but it went to a good cause, and i got a clearer idea about my robot arm kinematics in trade so i'm calling it a win
[15:28:56] <cradek> yay!
[15:29:11] <cradek> (uh dude isn't that just a right triangle?)
[15:29:16] <cradek> -> mesa card
[15:29:20] <seb_kuzminsky> heh
[16:49:02] <JT-Shop> I have a handle on Kunena now!
[16:54:55] <jepler> what's that mean?
[16:58:18] <JT-Shop> I know how to arrange things like the log in which was on the right column and now is in the header
[16:58:44] <JT-Shop> this version is much easier to do things like that
[16:59:01] <jepler> oh I see
[16:59:22] <jepler> I thought 'handle' like on CB radio
[17:00:10] <jepler> since the page doesn't spread out to my full browser window I like getting rid of the right column
[17:00:41] <jepler> at one point it had a list of logged-in users on the side bar. do people want things like that?
[17:02:13] <JT-Shop> not sure how helpful that would be, you can't PM anyone
[17:02:17] <jepler> ok
[17:02:47] <jepler> are there two login prompts now? I guess you're actively working on organizing it..?
[17:02:54] <jepler> I'll stop watching every little move.
[17:04:37] <JT-Shop> there we go, you can look now
[17:05:32] <jepler> ok
[17:05:38] <jepler> I take it you haven't found any showstopper problems yet either?
[17:06:27] <JT-Shop> nope looks good to me
[17:06:56] <JT-Shop> I've tried about everthing I can think of on the user end with no issues
[17:07:05] <jepler> I appreciate you taking the time to do that.
[17:11:10] <jepler> Operation Tips: 2.Avoid point the beam to eyes.
[17:12:38] <JT-Shop> lol
[17:13:15] <jepler> Quality Assurance policy to assure you buy lasers without care.
[17:50:06] <jepler> http://jtechphotonics.com/?product=new-2-8w-laser-and-2-5amp-safety-compliant-driver-kit-with-us-style-power-adapter
[17:50:35] <jepler> these guys look like they might know what they're doing
[17:50:54] <jepler> mounting holes on their heatsinked laser and everything :)
[18:52:15] <malcom2073_> Lasers: Please don't look into beam with remaining eye
[19:07:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master d1e507b 06linuxcnc 10debian/changelog 10src/Makefile Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d1e507b
[19:17:11] <seb_kuzminsky> wow, the SF bug tracker changed, i think it's better now
[19:54:59] <jepler> seb_kuzminsky: a rare occasion but we welcome it if it comes
[20:08:38] <seb_kuzminsky> can't you just add a bugtracker to your new joomla??
[20:08:42] <seb_kuzminsky> </troll>
[20:15:04] <jepler> seb_kuzminsky: thank you for entering those bugs
[20:15:37] <jepler> I was thinking that if a UI in general can detect that gentrivkins is in use, it can use [TRAJ]AXES = X X Y Z (or whatever) to figure out how to relate joint home states to axis letters
[20:28:52] <jepler> so in that case, if joint 2 is homed, then Y would get a home icon
[20:29:20] <jepler> if both 0 and 1 are homed, X would get a home icon (and maybe it would get a faint icon if just one was homed?)
[20:31:54] <micges> maybe two icons?
[20:32:33] <jepler> an NML homing request is about joints, right?
[20:32:47] <jepler> so the HOME button would be greyed out in axis mode?
[20:33:04] <jepler> $ host usr.bin.coffee
[20:33:04] <jepler> usr.bin.coffee has address 104.131.143.72
[20:33:26] <micges> yes joints
[20:59:03] <seb_kuzminsky> mmm, joints
[20:59:16] <seb_kuzminsky> i sent my understanding of the joints-axes design to the developers list
[21:00:19] <cradek> to the commit list...?
[21:02:24] <cradek> > status.motion.traj.axes: A count of the number of axes the machine has.
[21:02:35] <cradek> this is overspecified, so it should be removed
[21:20:53] <jepler> after my latest patches, it is defined as one higher than the greatest defined axis number, so for instance for both an XZ and an XYZ machine (highest axis number Z = 2) it is defined as 3.
[21:21:15] <jepler> this is essentially how you had to define it in 2.7
[21:21:43] <jepler> I agree we could deprecate it and remove it according to our normal deprecation schedule though
[21:22:38] <cradek> it bothers me that it's a thing the user has to figure out and get right (and it's not an obvious value), but it seems like it serves no purpose
[21:22:52] <jepler> oh, the inifile item is no longer used
[21:22:54] <cradek> if we care about it internally, we could generate it from the AXES= or whatever
[21:22:59] <cradek> oh
[21:23:10] <cradek> then it's weird but fine
[21:23:32] <jepler> as far as I could tell, the old [TRAJ]AXES number is not used now by task
[21:23:47] <cradek> yay
[21:23:47] <jepler> the number in stat is calculated, I guess from [TRAJ]COORDINATES
[21:24:09] <jepler> (earlier I was saying something about [TRAJ]AXES = X X Y Z but I meant [TRAJ]COORDINATES = X X Y Z)
[21:24:12] <cradek> cool, that's what I meant above
[21:24:24] <cradek> however it's spelled
[21:24:38] <cradek> it's good that it's only in one place
[21:25:10] <jepler> I'm not sure what [TRAJ]HOME means these days
[21:25:34] <cradek> I think that's the world coordinates of the all-joints-homed position for kins bootstrap
[21:25:51] <jepler> oh in case it's a multiple-solutions kins situation?
[21:26:14] <cradek> or inverse only (here's where you can switch into world mode)
[21:27:19] <cradek> > Coordinates of the homed position of each axis. Again for a fourth axis you will need 0 0 0 0. This value is only used for machines with nontrivial kinematics. On machines with trivial kinematics this value is ignored.
[21:27:26] <seb_kuzminsky> wth why did i send it to the commit list
[21:27:36] <seb_kuzminsky> well, good, since its wrong anyway
[21:27:43] <cradek> ha
[21:29:24] <cradek> seb_kuzminsky: thanks for doing all the after-work of the hackfest
[21:29:27] <seb_kuzminsky> once its not wrong any more and we figure out all the things it should say, i'll transcribe it into the Code Notes part of the docs
[21:29:38] <seb_kuzminsky> cradek: sure :-)
[22:13:19] <seb_kuzminsky> cradek: re: [TRAJ]HOME, isn't that what [AXIS_*]HOME means?
[22:21:57] <seb_kuzminsky> in ja, the number of joints is provided simply and unambiguously in the ini, by the number of [JOINT_*] sections. we should verify that they're compact
[22:22:25] <seb_kuzminsky> the number of axes are given simply and unambiguously by the [AXIS_*] sections
[22:23:36] <seb_kuzminsky> the mapping between them still needs to be provided by the ini, maybe in the [KINS] section somewhere
[22:25:02] <seb_kuzminsky> currently the only defined variable in [KINS] seems to be JOINTS, which sets the number of joints
