EMC: 03jthornton 07v2.4_branch * r4dc63b266db9 10/docs/src/common/machining_center.lyx: add missing numbered parameters to list
EMC: 03jthornton 07v2.4_branch * rfe501a7cc4ca 10/docs/src/hal/components.lyx: add component info
Dave911: it took me around 5 hours to upload it!
mozmck: I tried to burn a CD and try installing it somewhere - but I have no CDs.
that makes things difficult...
yeah, guess I'm quite useless
thanks for all your hard work on it.
mozmck: Thanks.. you are making me feel a little better .. ;-)
ries_ is now known as ries
Dave911: DH = DreamHost (where linuxcnc.org is hosted)
the blazing connection is at the local college, where I have the EU mirror for linuxcnc.org
thanks SWPadnos, Dave911 and robh__
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
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"
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
t lbs @ 1500rpm with max rpm of 4500" means "2k rpm max" ;)
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
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?
I think it's better to just write it plain out
I want to use only velocity mode, and I need +/-10V for velocity setting, and full torque (holding position) when commanding 0V
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
still surprised about the yaskawa distributor's quote most of all
EMC: 03jthornton 07v2.4_branch * ra089185d0081 10/docs/src/gcode/main.lyx: seperate g33 and g33.1
cradek: interesting tach vs synthetic tach traces
yeah, the mesa velocity estimate seems really good
and I'd run jr at a higher accel if I had a thicker floor...
if you need to move your garage a few inches one way or the other... ;)
yeah I'm kind of scared of that effect
do you have pics of the jr online?
[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
the "Boring and measuring" one is the latest I've done
this was running with the original tachs before?
awallin: but the Y tach is bogus: http://timeguy.com/cradek-files/emc/IMAG0105.jpg
a dead spot once per revolution
cradek: thanks for your help with last patch
new patch for consideration: http://www.panix.com/~dgarrett/stuff/0001-new-ini-parameter-search-list-for-user-defined-funct.patch
trying to understand...
one technical comment
- "idd", num, arg1, arg2);
+ "idd", dirindex, num, arg1, arg2);
the format string "idd" needs to be changed here. I think it should be "iidd" now.
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)
updated for iidd
how are subroutines from other files displayed in the GUI(s)?
dgarr: thank you
I know AXIS will show the motions in the preview plot, but what if anything happens to the G-code listing?
I was trying to puzzle out what that acronym stood for :)
I think it it shows you an irrelevant line in the directly loaded file
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?
(or can it still be taken care of at the task level?)
this patch has nothing to do with that question
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
and cradek is right, it's unrelated to this. this is about a search path for M1xx
ah right - sorry
here's me thinking about subroutines
I think there was a suggestion for a separate search path for named subroutine files as well
'currently open file' is in the stat buffer
yep, which gets confusing when there are multiple pseudo-open files
it seems possible that it could be kept updated as execution switches between files
it seems possible that, then, a gui could do something smart
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)
crimson herring? anyway
well yes if you care about that kind of thing, but fixing that is a third unrelated problem IMO
showing subs in multiple files could work as well as showing one file
jepler: " local to task instead of in the interpreter" -- i'm sure you are right, i will work on that and post later
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.
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.
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
I didn't mean one hardcoded directory, I meant an ini entry that names one directory containing the Mxxx
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.
I'm not saying I'm against either change, fwiw.
i see -- ok
I think there's merit to a search path, even if any search path limitation could be worked around (e.g., by linking stuff)
ok, I have no objection to it, I just thought it might be unnecessarily complex.
a search path gives you the ability to have machine-specific and shop-specific M1xx functions in separate directories
err, a path list does anyway
I'm not sure what a non-machine-specific M1xx will be but that is probably just a failure in imagination
too bad the search-the-path part of execvp et al is not separately available
well, morfic was talking about logging certain parameters on a machine
if several machines have configs with the same signal names, the M1xx program could be the same on all machines
but others might need to be different
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
heck, then you could just prepend M_PATH to PATH and us execvp
true, for this part you could actually use execvp. that doesn't help you make the same simplification to O-call though.
no, it doesn't.
we could always make task an X program and use XtResolvePathname
I've never considered before how there's nothing in the unix standard library for "path-like variables"
strtok_r is not an easy API to use properly!
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)
revised (and simpler): http://www.panix.com/~dgarrett/stuff/0001-new-ini-parameter-search-list-for-user-defined-funct.patch
that looks exactly like what I was asking for
dgarr: one minor issue that I'll fix before pushing:
+#define MAX_M_DIRS USER_DEFINED_FUNCTION_MAX_DIRS+1
this should be +#define MAX_M_DIRS (USER_DEFINED_FUNCTION_MAX_DIRS+1)
Otherwise an expression like 10-MAX_M_DIRS would have a different value than expected
(not that there are any expressions like that in your patch)
(the reason is that after macro substitution your expression is 10-5+1 which is of course different than 10-(5+1))
understand, mymistake, revised, bye for now
did the topic of the name of the inifile var get hashed out?
[DISPLAY] feels pretty wrong, though I appreciate wanting to put it next to PROGRAM_PREFIX
even more defensive is the habit of #define MAX_M_DIRS ((USER_DEFINED_FUNCTION_MAX_DIRS)+1)
PROGRAM_PREFIX is a weird one
do we still have a [RS274NGC] section?
did the search directories for O-call get pushed yet?
so to be clear, you're thinking of [RS274NGC]USER_M_DIRS ?
cradek: for cases like: #define USER_DEFINED_FUNCTION_MAX_DIRS 2*3 ?
jepler: I think that's one possible place for it that makes sense
alex_joni: but in that case the USER_DEFINED_FUNCTION_MAX_DIRS macro is broken
but it won't hurt anything to add even more parens
yes I pushed the O-call thing, but now is the best time to change it if you can make it better
between [DISPLAY], [TASK], and [RS274NGC] I think I like [RS274NGC] best.
I agree; these are very specifically ngc features.
change both in a subsequent commit?
I was going to amend the M1xx commit
[RS274NGC]SUBROUTINES or [RS274NGC]SUBROUTINE_DIRS ?
or DIRS instead of PATH
I'm pretty sure PATH is best, because it automatically tells what format the list of dirs is in
we all know what a PATH is
yep. "we" do :)
part of me wants to call it MACRO_DIR
but I acknowledge that we call them subroutines in gcode
maybe USER_MCODE_PATH, SUBROUTINE_PATH
(because that's what we call each of them in the documentation)
those sound fine to me
and that leaves MACRO_PATH for future expansion :)
* jepler notes that SUBROUTINE PATH is an anagram for A PUSHIER BUTTON
so how about we go with [RS274NGC]A_PUSHIER_BUTTON
can we just accept any anagram of it?
heh. search google for "anagram" :)
yeah that joke's been there awhile
oh. it's the first time I've hit it
it's funny every time, though
yes, my statistical sampling proves that
EMC: 03jepler 07master * r02587c4b7f85 10/src/emc/rs274ngc/rs274ngc_pre.cc: Use a better inifile name for subroutine directories
EMC: 03jepler 07master * rd09631bb954a 10/src/hal/utils/halcmd_commands.c: Use a more sensible guess for a component name
EMC: 03jepler 07master * r3eb6c74e64a9 10/src/emc/task/emctask.cc: new ini parameter: search list for user defined functions
also: SHUT UP, BARITONE!
A Brutish Toe Pun
Obtuse Hip Turn
EMC: 03cradek 07master * r0a5f2ca6f9f0 10/src/emc/ (rs274ngc/rs274ngc_pre.cc task/emctask.cc): standardize new variable names
EMC: 03cradek 07master * r49261c1e8d48 10/src/emc/rs274ngc/rs274ngc_pre.cc: fix unreachable logDebug call
what are the odds that my legal name comes out to 'A Loosely Omit Skunk'
He Not Harpsichord Jerk
adjourn ex nail
looks like we have 1 tach that isn't working correctly.
I wonder what we can do about that? ;)
A Journal Index
this one's fun: A Ninja Lured Ox
and of cource it is the first one we hook up. boy that was acting goofy.
ROFLMAO: Anal Injured Ox
DOUR JAIL ANNEX
I can't find anything good from my own name, though
my wifes name - Flasher Ref He Ninny
Infernal Hen She Fry
Ah Refresh Elf Ninny
doesn't beat the Ox though :P
LawrenceG, ding, ding....
Has anyone ever considered making EMC hardware based (embedded)?
SWPadnos: and what happened?
I don't think anyone has a real embedded EMC (or EMC2)
unless you count embedded PCs as embedded systems
"embedded" doesn't gain much, but it does lose a fair amount
the primary gains are presumably low power usage and smaller size
well, my laser is basically that... You literally print it a file, and it does the rest.
have you opened it up to see if there's a small PC in there?
SWPadnos: The dman thing uses 30pin SIMMS!
whch tells me 386/486
that leads me to think it may be an embedded '386 or so
so it is a PC, but nowhere as good as a modern and inexpensive Atom board
Updating the firmware i not much more than printing a file
has a 4x20 LCD and a few buttons for jogging, limit switches etc
The RAM is basically used to hold jobs. it does have a battery to retain the Z axis position.
SWPadnos: once a job is sent to it, you can disconnect the computer and run it
sure, similar to a (real) laser printer
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.
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...
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..
Dave911: it's more of a small form factor pc
SWPadnos: BTW, if you have any 30pin SIMMS (4 or 8MB) PLEASE send them my way
That goes for anyone else too please =)
I think my way-back machine stopps at 72-pin EDO/FPM SIMMS, sorry
SWPadnos: Well, still holds. if you come across any, let me know.
ok, will do
maybe I have a few on that old SoundBlaster card ;)
30 SIMM, back when it was SIM vs SIP (SIM with soldered on pins)
I think I have some 256k in my Anilam case
JT-Hardinge: Needs to be 4 or 8 MB
oh right, Meg, not Gig :)
JT-Hardinge: Years ago I sold 256K for $3/ea
maybe it was $2/ea
JT-Hardinge: remember those old stacker boards?
so they are worth more now
JT-Hardinge: Yeah, keychains
no, I've sept too much since then
JT-Hardinge: (Pssst... it's August)
really, I better get busy gathering some food for the winter
JT-Hardinge: Deer Season isn't till October
but you gotta get out early to beat the poachers
that's why we use subsonic 22's with silencers
so we don't scare the rest of the deer off
.22?! How many does it take, 200?