Back
[00:42:10] <CIA-5> EMC: 03jthornton 07v2.4_branch * r4dc63b266db9 10/docs/src/common/machining_center.lyx: add missing numbered parameters to list
[00:42:11] <CIA-5> EMC: 03jthornton 07v2.4_branch * rfe501a7cc4ca 10/docs/src/hal/components.lyx: add component info
[00:43:02] <mozmck> Dave911: it took me around 5 hours to upload it!
[02:08:39] <cradek> mozmck: I tried to burn a CD and try installing it somewhere - but I have no CDs.
[02:09:02] <mozmck> that makes things difficult...
[02:10:05] <cradek> yeah, guess I'm quite useless
[02:10:25] <cradek> thanks for all your hard work on it.
[02:12:17] <Dave911> mozmck: Thanks.. you are making me feel a little better .. ;-)
[05:16:14] <ries_> ries_ is now known as ries
[08:24:06] <alex_joni> Dave911: DH = DreamHost (where linuxcnc.org is hosted)
[08:24:27] <alex_joni> the blazing connection is at the local college, where I have the EU mirror for linuxcnc.org
[11:31:35] <morficmobile> thanks SWPadnos, Dave911 and robh__
[11:34:16] <morficmobile> so SWPadnos and Dave911 agree, Dave911 is just concerned that it would be pertinent to verify i can stay in velocity mode to achieve the goal of "full torque at zero rpm" as some drive's implementation may (as robh__ confirmed) switch modes at low rpm to achieve that, while true servo drives could stay in velocity mode to do that
[11:38:43] <morficmobile> the way i asked vendors, they could come back and say "you wanted +-10V velocity control, you have that, and you wanted full torque at zero rpm, you got that, you never asked to get both in the same mode"
[11:41:42] <morficmobile> about making sure to get a tech side guy, with siemens i talked to a tech guy until he felt it was time to start CC:ing the sales guy, who then quoted what the tech guy suggested, with Minarik we talked again to the sales guy, since the tech guy we usually talk to was busy in some plant, sales guy boldly stated "with the specifications you gave me, i can quote this and don't need to wait for the tech guy", not sure where "127f
[11:41:43] <morficmobile> t lbs @ 1500rpm with max rpm of 4500" means "2k rpm max" ;)
[11:43:08] <morficmobile> for the record, i had to ask the Siemens sales guy twice to correct the quotes as he combined the wrong drives with the motors
[11:54:06] <morficmobile> to clarify, does it not imply velocity mode when saying "full torque at 0 RPM when given a zero speed reference" ? torque or positioning modes would not be given a "speed reference", correct?
[11:56:12] <alex_joni> I think it's better to just write it plain out
[11:56:37] <alex_joni> I want to use only velocity mode, and I need +/-10V for velocity setting, and full torque (holding position) when commanding 0V
[12:01:52] <morficmobile> that's what i plan on doing, and i have to talk to the Siemens guy about something else anyways, going to double check on that too in the conversation
[12:02:32] <morficmobile> still surprised about the yaskawa distributor's quote most of all
[12:50:05] <CIA-5> EMC: 03jthornton 07v2.4_branch * ra089185d0081 10/docs/src/gcode/main.lyx: seperate g33 and g33.1
[13:59:54] <jepler> cradek: interesting tach vs synthetic tach traces
[14:12:13] <cradek> yeah, the mesa velocity estimate seems really good
[14:13:50] <cradek> and I'd run jr at a higher accel if I had a thicker floor...
[14:15:27] <skunkworks> heh
[14:15:50] <skunkworks> if you need to move your garage a few inches one way or the other... ;)
[14:16:27] <cradek> yeah I'm kind of scared of that effect
[14:19:36] <awallin> do you have pics of the jr online?
[14:19:46] <awallin> or video?
[14:20:01] <cradek> both
[14:20:02] <cradek> http://timeguy.com/cradek-files/emc/jr.jpg
[14:20:27] <cradek> http://www.youtube.com/results?search_query=ChrisRadek&aq=f
[14:20:47] <cradek> the "Boring and measuring" one is the latest I've done
[14:27:30] <awallin> this was running with the original tachs before?
[14:27:55] <cradek> yes
[14:28:47] <cradek> awallin: but the Y tach is bogus:
http://timeguy.com/cradek-files/emc/IMAG0105.jpg
[14:28:58] <cradek> a dead spot once per revolution
[14:42:22] <dgarr> cradek: thanks for your help with last patch
[14:42:32] <dgarr> new patch for consideration:
http://www.panix.com/~dgarrett/stuff/0001-new-ini-parameter-search-list-for-user-defined-funct.patch
[14:45:24] <cradek> trying to understand...
[14:53:03] <jepler> one technical comment
[14:53:03] <jepler> PyObject_CallMethod(callback, "user_defined_function",
[14:53:03] <jepler> - "idd", num, arg1, arg2);
[14:53:03] <jepler> + "idd", dirindex, num, arg1, arg2);
[14:53:18] <jepler> the format string "idd" needs to be changed here. I think it should be "iidd" now.
[14:55:09] <jepler> I am tempted to think that this detail of having a search path could be kept in task and not require changing the canon interface (basically, make USER_DEFINED_FUNCTION_DIRINDEX local to task instead of in the interpreter)
[14:58:20] <dgarr> updated for iidd
[15:00:15] <SWPadnos> how are subroutines from other files displayed in the GUI(s)?
[15:00:26] <jepler> dgarr: thank you
[15:00:51] <jepler> swbadiyl :-/
[15:00:51] <SWPadnos> I know AXIS will show the motions in the preview plot, but what if anything happens to the G-code listing?
[15:01:14] <jepler> er, "badly"
[15:01:18] <SWPadnos> phew
[15:01:28] <SWPadnos> I was trying to puzzle out what that acronym stood for :)
[15:01:38] <jepler> I think it it shows you an irrelevant line in the directly loaded file
[15:02:52] <jepler> bbl, meeting
[15:03:18] <SWPadnos> if the lines will ever be shown in a GUI, and particularly in multiple (possibly remote) GUIs, does the information need to be in CANON?
[15:03:28] <SWPadnos> (or can it still be taken care of at the task level?)
[15:03:44] <cradek> this patch has nothing to do with that question
[15:03:51] <jepler> I don't think there are canon calls for "now interpreting from file foo.ngc" and I'm sure it's not in the stat buffer
[15:04:02] <jepler> and cradek is right, it's unrelated to this. this is about a search path for M1xx
[15:04:13] <SWPadnos> ah right - sorry
[15:04:20] <SWPadnos> here's me thinking about subroutines
[15:04:42] <SWPadnos> I think there was a suggestion for a separate search path for named subroutine files as well
[15:04:49] <cradek> 'currently open file' is in the stat buffer
[15:05:14] <SWPadnos> yep, which gets confusing when there are multiple pseudo-open files
[15:05:19] <cradek> it seems possible that it could be kept updated as execution switches between files
[15:05:29] <cradek> it seems possible that, then, a gui could do something smart
[15:05:41] <SWPadnos> that's a tarball anyway, since the file needs to be at the same path on all machines displaying a GUI (for program listings to work correctly)
[15:05:52] <SWPadnos> tarbaby
[15:06:04] <SWPadnos> crimson herring? anyway
[15:06:55] <cradek> well yes if you care about that kind of thing, but fixing that is a third unrelated problem IMO
[15:07:25] <SWPadnos> yep
[15:07:26] <cradek> showing subs in multiple files could work as well as showing one file
[15:57:10] <dgarr> jepler: " local to task instead of in the interpreter" -- i'm sure you are right, i will work on that and post later
[15:58:21] <jepler> dgarr: OK
[15:58:34] <cradek> dgarr: is the goal just to separate the Mxxx from the gcode files? I am asking because I wonder if one path for those is good enough.
[15:59:36] <cradek> for subs I can imagine having several directories (although I will surely just use one) but I use Mxxx for machine integration stuff like open/close collet and gear change, and I never look at them or change them. I just want them hidden and out of the way.
[16:01:27] <dgarr> one is probably ok but, for example, i use one computer/powersupply/ppmc/amplifiers/ for more than one machine configuration and separate directories could help organization
[16:02:32] <cradek> I didn't mean one hardcoded directory, I meant an ini entry that names one directory containing the Mxxx
[16:03:32] <cradek> I was thinking the bulk of the complexity of the change was to support multiple directories containing Mxxx per config, and I was wondering if that was necessary to accomplish the main goal.
[16:04:16] <cradek> I'm not saying I'm against either change, fwiw.
[16:04:58] <dgarr> i see -- ok
[16:10:45] <jepler> I think there's merit to a search path, even if any search path limitation could be worked around (e.g., by linking stuff)
[16:13:07] <cradek> ok, I have no objection to it, I just thought it might be unnecessarily complex.
[16:13:53] <SWPadnos> a search path gives you the ability to have machine-specific and shop-specific M1xx functions in separate directories
[16:14:10] <SWPadnos> err, a path list does anyway
[16:14:21] <jepler> I'm not sure what a non-machine-specific M1xx will be but that is probably just a failure in imagination
[16:14:22] <cradek> too bad the search-the-path part of execvp et al is not separately available
[16:14:56] <SWPadnos> well, morfic was talking about logging certain parameters on a machine
[16:15:29] <SWPadnos> if several machines have configs with the same signal names, the M1xx program could be the same on all machines
[16:15:41] <SWPadnos> but others might need to be different
[16:15:42] <jepler> the other thing that's been rattling around in my head is whether there's a way to rework the code so that the decision on whether a specific M1xx exists can take place at the site where the M1xx is used
[16:16:13] <jepler> heck, then you could just prepend M_PATH to PATH and us execvp
[16:17:13] <jepler> s/us/use/
[16:17:27] <cradek> true, for this part you could actually use execvp. that doesn't help you make the same simplification to O-call though.
[16:20:11] <jepler> no, it doesn't.
[16:24:10] <jepler> we could always make task an X program and use XtResolvePathname
[16:24:27] <jepler> I've never considered before how there's nothing in the unix standard library for "path-like variables"
[16:53:02] <jepler> strtok_r is not an easy API to use properly!
[17:06:43] <jepler> hm, and it's not even right for parsing PATH-like variables! (it doesn't give an empty element when the string starts with ":", unless I did something wrong)
[17:22:40] <dgarr> revised (and simpler):
http://www.panix.com/~dgarrett/stuff/0001-new-ini-parameter-search-list-for-user-defined-funct.patch
[18:21:32] <jepler> that looks exactly like what I was asking for
[18:35:24] <jepler> dgarr: one minor issue that I'll fix before pushing:
[18:35:29] <jepler> +#define MAX_M_DIRS USER_DEFINED_FUNCTION_MAX_DIRS+1
[18:35:36] <jepler> this should be +#define MAX_M_DIRS (USER_DEFINED_FUNCTION_MAX_DIRS+1)
[18:36:09] <jepler> Otherwise an expression like 10-MAX_M_DIRS would have a different value than expected
[18:36:22] <jepler> (not that there are any expressions like that in your patch)
[18:38:15] <jepler> (the reason is that after macro substitution your expression is 10-5+1 which is of course different than 10-(5+1))
[18:42:43] <dgarr> understand, mymistake, revised, bye for now
[18:42:47] <jepler> see you
[18:42:49] <jepler> thanks
[18:45:10] <jepler> did the topic of the name of the inifile var get hashed out?
[18:45:26] <jepler> [DISPLAY] feels pretty wrong, though I appreciate wanting to put it next to PROGRAM_PREFIX
[18:46:30] <cradek> even more defensive is the habit of #define MAX_M_DIRS ((USER_DEFINED_FUNCTION_MAX_DIRS)+1)
[18:46:59] <cradek> PROGRAM_PREFIX is a weird one
[18:47:30] <jepler> [TASK]USER_M_DIRS ?
[18:47:48] <cradek> do we still have a [RS274NGC] section?
[18:48:19] <jepler> Yes.
[18:48:41] <jepler> did the search directories for O-call get pushed yet?
[18:49:16] <jepler> so to be clear, you're thinking of [RS274NGC]USER_M_DIRS ?
[18:49:35] <alex_joni> cradek: for cases like: #define USER_DEFINED_FUNCTION_MAX_DIRS 2*3 ?
[18:50:07] <cradek> jepler: I think that's one possible place for it that makes sense
[18:51:29] <jepler> alex_joni: but in that case the USER_DEFINED_FUNCTION_MAX_DIRS macro is broken
[18:52:08] <jepler> but it won't hurt anything to add even more parens
[18:53:28] <cradek> yes I pushed the O-call thing, but now is the best time to change it if you can make it better
[18:54:14] <jepler> between [DISPLAY], [TASK], and [RS274NGC] I think I like [RS274NGC] best.
[18:54:32] <cradek> I agree; these are very specifically ngc features.
[18:55:10] <cradek> change both in a subsequent commit?
[18:55:39] <jepler> I was going to amend the M1xx commit
[19:13:50] <jepler> [RS274NGC]SUBROUTINES or [RS274NGC]SUBROUTINE_DIRS ?
[19:14:15] <cradek> _PATH?
[19:24:57] <SWPadnos> MCODE_SEARCH_PATH, GCODE_SEARCH_PATH
[19:25:00] <SWPadnos> ?
[19:25:32] <SWPadnos> or DIRS instead of PATH
[19:25:58] <cradek> I'm pretty sure PATH is best, because it automatically tells what format the list of dirs is in
[19:26:02] <cradek> we all know what a PATH is
[19:26:12] <SWPadnos> yep. "we" do :)
[19:39:27] <cradek> part of me wants to call it MACRO_DIR
[19:39:30] <cradek> err ffff
[19:39:33] <cradek> MACRO_PATH
[19:39:53] <cradek> but I acknowledge that we call them subroutines in gcode
[19:41:18] <cradek> maybe USER_MCODE_PATH, SUBROUTINE_PATH
[19:41:52] <cradek> (because that's what we call each of them in the documentation)
[19:42:31] <SWPadnos> those sound fine to me
[19:42:51] <SWPadnos> and that leaves MACRO_PATH for future expansion :)
[19:50:13] <jepler> * jepler notes that SUBROUTINE PATH is an anagram for A PUSHIER BUTTON
[19:50:26] <jepler> so how about we go with [RS274NGC]A_PUSHIER_BUTTON
[19:50:45] <cradek> can we just accept any anagram of it?
[19:50:55] <SWPadnos> heh. search google for "anagram" :)
[19:51:25] <jepler> yeah that joke's been there awhile
[19:51:37] <SWPadnos> oh. it's the first time I've hit it
[19:51:44] <jepler> it's funny every time, though
[19:51:56] <SWPadnos> yes, my statistical sampling proves that
[19:55:25] <SWPadnos> bbl
[19:58:57] <CIA-5> EMC: 03jepler 07master * r02587c4b7f85 10/src/emc/rs274ngc/rs274ngc_pre.cc: Use a better inifile name for subroutine directories
[19:58:57] <CIA-5> EMC: 03jepler 07master * rd09631bb954a 10/src/hal/utils/halcmd_commands.c: Use a more sensible guess for a component name
[19:58:57] <CIA-5> EMC: 03jepler 07master * r3eb6c74e64a9 10/src/emc/task/emctask.cc: new ini parameter: search list for user defined functions
[20:11:15] <jepler> also: SHUT UP, BARITONE!
[20:13:14] <skunkworks> A Brutish Toe Pun
[20:13:59] <skunkworks> Obtuse Hip Turn
[20:14:52] <skunkworks> A
[20:15:11] <skunkworks> (anagram generator)
[20:27:42] <CIA-5> EMC: 03cradek 07master * r0a5f2ca6f9f0 10/src/emc/ (rs274ngc/rs274ngc_pre.cc task/emctask.cc): standardize new variable names
[20:27:52] <CIA-5> EMC: 03cradek 07master * r49261c1e8d48 10/src/emc/rs274ngc/rs274ngc_pre.cc: fix unreachable logDebug call
[20:32:10] <skunkworks> what are the odds that my legal name comes out to 'A Loosely Omit Skunk'
[20:40:16] <cradek> He Not Harpsichord Jerk
[20:55:34] <skunkworks> heh
[21:03:12] <alex_joni> adjourn ex nail
[21:03:46] <skunkworks> looks like we have 1 tach that isn't working correctly.
[21:04:01] <skunkworks> I wonder what we can do about that? ;)
[21:04:49] <alex_joni> A Journal Index
[21:04:57] <alex_joni> skunkworks: heh
[21:05:51] <alex_joni> this one's fun: A Ninja Lured Ox
[21:07:21] <skunkworks> heh
[21:07:41] <skunkworks> and of cource it is the first one we hook up. boy that was acting goofy.
[21:10:38] <alex_joni> ROFLMAO: Anal Injured Ox
[21:15:13] <jepler> DOUR JAIL ANNEX
[21:15:27] <jepler> I can't find anything good from my own name, though
[21:25:19] <skunkworks> my wifes name - Flasher Ref He Ninny
[21:25:35] <skunkworks> Infernal Hen She Fry
[21:26:38] <skunkworks> Ah Refresh Elf Ninny
[21:33:56] <alex_joni> doesn't beat the Ox though :P
[22:35:34] <tfmacz> LawrenceG, ding, ding....
[22:43:35] <Jymmm> Has anyone ever considered making EMC hardware based (embedded)?
[22:44:18] <SWPadnos> Jymmm, yes
[22:44:27] <Jymmm> SWPadnos: and?
[22:44:47] <SWPadnos> and what?
[22:44:59] <Jymmm> SWPadnos: and what happened?
[22:45:15] <SWPadnos> I don't think anyone has a real embedded EMC (or EMC2)
[22:45:25] <SWPadnos> unless you count embedded PCs as embedded systems
[22:45:35] <Jymmm> not really
[22:46:11] <SWPadnos> "embedded" doesn't gain much, but it does lose a fair amount
[22:46:28] <SWPadnos> the primary gains are presumably low power usage and smaller size
[22:46:39] <Jymmm> well, my laser is basically that... You literally print it a file, and it does the rest.
[22:46:54] <SWPadnos> have you opened it up to see if there's a small PC in there?
[22:47:07] <Jymmm> SWPadnos: The dman thing uses 30pin SIMMS!
[22:47:25] <Jymmm> whch tells me 386/486
[22:47:27] <SWPadnos> that leads me to think it may be an embedded '386 or so
[22:47:30] <SWPadnos> yep
[22:47:49] <SWPadnos> so it is a PC, but nowhere as good as a modern and inexpensive Atom board
[22:47:54] <Jymmm> Updating the firmware i not much more than printing a file
[22:48:34] <Jymmm> has a 4x20 LCD and a few buttons for jogging, limit switches etc
[22:49:13] <Jymmm> The RAM is basically used to hold jobs. it does have a battery to retain the Z axis position.
[22:51:09] <Jymmm> SWPadnos: once a job is sent to it, you can disconnect the computer and run it
[22:55:25] <SWPadnos> sure, similar to a (real) laser printer
[22:59:40] <Dave911> These little Atom based boards are really hard to beat for the $.. and the "embedded" PC is getting hard to distinguish from "regular" PC hardware.
[23:01:34] <Dave911> I just put EMC2 10.04 and the latest EMC2 master on a 8 gig flash drive which plugs into a PC slot mounted CF card reader.. The PC runs EMC2 (actually only the backend of EMC2) headless.. All of the parts except for one was ordered from Newegg...
[23:02:38] <Dave911> So is that an embedded.. or a desktop pc? If the flash card makes it embedded, what if I removed the flash card and used an SSD? The line is getting very blurry..
[23:25:55] <morfic> Dave911: it's more of a small form factor pc
[23:48:49] <Jymmm> SWPadnos: BTW, if you have any 30pin SIMMS (4 or 8MB) PLEASE send them my way
[23:49:11] <Jymmm> That goes for anyone else too please =)
[23:49:40] <SWPadnos> I think my way-back machine stopps at 72-pin EDO/FPM SIMMS, sorry
[23:49:43] <SWPadnos> -p
[23:50:24] <Jymmm> SWPadnos: Well, still holds. if you come across any, let me know.
[23:50:33] <SWPadnos> ok, will do
[23:50:43] <SWPadnos> maybe I have a few on that old SoundBlaster card ;)
[23:50:49] <morfic> 30 SIMM, back when it was SIM vs SIP (SIM with soldered on pins)
[23:51:03] <JT-Hardinge> I think I have some 256k in my Anilam case
[23:51:20] <Jymmm> JT-Hardinge: Needs to be 4 or 8 MB
[23:51:58] <SWPadnos> oh right, Meg, not Gig :)
[23:52:10] <Jymmm> SWPadnos: =)
[23:52:27] <Jymmm> JT-Hardinge: Years ago I sold 256K for $3/ea
[23:52:34] <Jymmm> maybe it was $2/ea
[23:52:50] <Jymmm> JT-Hardinge: remember those old stacker boards?
[23:52:54] <JT-Hardinge> so they are worth more now
[23:53:07] <Jymmm> JT-Hardinge: Yeah, keychains
[23:53:11] <JT-Hardinge> no, I've sept too much since then
[23:54:30] <Jymmm> JT-Hardinge: (Pssst... it's August)
[23:55:07] <JT-Hardinge> really, I better get busy gathering some food for the winter
[23:55:27] <Jymmm> JT-Hardinge: Deer Season isn't till October
[23:56:44] <JT-Hardinge> but you gotta get out early to beat the poachers
[23:56:51] <Jymmm> ROTF
[23:57:42] <JT-Hardinge> that's why we use subsonic 22's with silencers
[23:57:57] <JT-Hardinge> so we don't scare the rest of the deer off
[23:58:26] <Jymmm> .22?! How many does it take, 200?
[23:58:37] <JT-Hardinge> one!
