aystarik: glad to see another translation..
good night all
from what I can tell it is close to what the 'real time delay' does with emc.
[03:43:31] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120485992619
what the hell? why is tooling so cheap? 8 bids under $6? these chucks are like $200 new
did you get it?
yes - I put in a throwaway bid of $8 or something like that
great! shipping brings it up a bit it looks like, but not bad.
good grief, it keeps happening - end mill holders for 99c + shipping
pretty soon I'm going to have more than I'll ever need - which is exactly the right amount of tooling
economy. businesses going under and there's more stuff on the market and less people needing it.
guess so - it's buying time...
[03:47:43] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170399784493
It ran 'git checkout v2_3_branch' and it said the following:
Switched to branch 'v2_3_branch'
Your branch is behind 'origin/v2_3_branch' by 113 commits, and can be fast-forwarded.
another one I bought - I was wrong - 99c for two holders, not one
what does that mean?
it means there are 113 changes since you were last on that branch - just do a git pull to update ("fast forward") your copy
ok. I thought it was updating it when I did a pull from master. It always says something about it...
"fast forward" means you have no local commits that need to be merged with others', so the update is trivial - just get the new stuff.
well it does pull it down, but doesn't fast forward your branch unless you ask for it.
when I do a checkout it does switch the code in my working dir doesn't it?
yes, to your own v2_3_branch tag, which was an earlier state of origin/v2_3_branch
to update your v2_3_branch tag, you can do a merge (or pull, which is fetch+merge)
ok. I did that now.
to build debs can I just run ./configure and dpkg-buildpackage in the debian directory?
yes, except I believe the invocation is ./configure -r
trying a 2.4 package build? I bet at least touchy is not yet in it
run one of "debian/configure sim" or "debian/configure -a" to prepare to build packages. Run from the top dir, not inside debian/.
it told me my kernel '18.104.22.168-rtai' is not known. but it said it was successful.
lots of the dependencies in debian/control.in are wrong (they name versions older than 9.10)
python, tcl, tk at least
no, right now I'm trying to build 2.3 packages.
.. but there's not machinery for choosing different versions of those packages as build dependencies because of the detected ubuntu version ..
I see. I'll see what I have to do to get it to work.
I wonder if there's a way to build the control.in in the configure somehow?
I think the solution is to make more things in control.in determined by debian/configure based on the distro version
debian/configure builds debian/control from debian/control.in
some things are configurable, like whatever @KERNEL_DEPENDS@ gets replaced with
I see. I'll play with it some and see where I get.
I see that the version of the python package isn't given explicitly -- that's good
maybe tcl/tk is the only problem
if so I'd consider making the thing substituted be the @TCL_VERSION@ and its value would be 8.4 or 8.5
ok, thanks. good night
how do I pull my changes in hostmot2 from master to 2.3.x?
find the commit ID, and while on the 2.3 branch, do a git cherry-pick that-id
looks like it is f88ea06895
looks like that worked. how do I find the commit IDs? I looked at qgit but didn't see them
gitk shows them in the middle of the window - git log shows them at the top of every log block - I have not used qgit
personally I typed git log --author=moses and the change you wanted was the first line I saw
(I'm on master)
you'd have to type 'git log --author=moses master'
... assuming you're on the branch
thanks. I think I used gitk before but typed qgit now. I forget what I learn if I don't use it for a while :(
sometimes I wonder if I've forgotten more than I currently know - I think not, but how would I know for sure?
heh, I don't know...
take notes ??? ;-)
I've tried that
"hmm, I see this is my handwriting - wonder what it meant"
you lose 'em
cradek: The guy who sold that chuck has been dumping stuff on Ebay ... you might want to watch him... I've been buying inserts for my lathe very cheaply. $1 each or less.... Some are $22 in the MSC book
Dave911: I am currently the only one on the planet buying BT40 tooling. it's OK by me...
the commit IDs git log gives me are much longer than the one you gave.
>> wonder what it meant"
better notes.. ;-)
$6 for that chuck ??? The key costs that much!
mozmck: you can use an abbreviated ID if it's unique
Oh well.. happy buying :-)
Dave911: yes, they're $200+, holder is $75+, pull stud (surely wrong) is $20+
$6 is plain crazy
I've got about 5 of them now, all for < $15 each
so nice to have enough drill chucks ... luxury
I should really buy a mill. Perhaps next spring. I've seen more than a few go by.
that is nice.
on the bridgeport if I needed several drills, I'd change it out and then move the knee to adjust for the new length - huge pain
Yep, but you will fill all of the chucks with tools - then say if I only had just 1 more chuck ..
I have an albrecht I like to keep empty for one-off holes
they're very nice, but (even now) go for real money
I don't think it is possible to have too many tools - albrechts - I have one in a lathe I own... I thought they were pricey
yes but so nice to just hand tighten and I've NEVER had one slip
I've drilled 3/4 holes in steel, just hand tightened
they are a great design
The one I have is a little mangled as some idiot put some channelocks on it.... that is really quite amazing..
I thought my lathe encoder was bad.... turns out my LPT board has "one" flaky input!
Yep, I didn't think it was at all likely, but I tested it in my office with an encoder simulator and it is clearly bad. I think I will be able to try the lathe threading tomorrow, but it sounds like it is fixed from what I have heard.
yes I'm getting good feedback about the latest change I put on master
so 2.3.x doesn't have autogen.sh it looks like.
I'll let you know how it goes.. it will probably be fine ....
Well... I have to get some rest .... good night
how do I revert a cherry-pick?
do you mean discard it?
[revert means to make a new, but opposite commit]
yes, I cherry-picked some old changes and I think they may not be good for 2.3
do you want to discard all your changes you've made since pull, or just some?
just some, but I can just reset and redo the others. I had made changes on master in the makefile to put some stuff in different places, but I'm thinking we didn't want to do that in 2.3 for some reason.
yeah changes in 2.3 should be the absolute minimum possible to fix bugs
what about the one I made yesterday?
you can discard some, using 'git rebase --interactive' (a little bit of a complex process) or discard all with something like 'git reset --hard origin/v2_3_branch'
you should probably ask jepler about that one
ok. it should be good for existing stuff and fix bugs for newer kernels. I had to do it to make it compile
yeah, sounds good to me then - if it didn't build before and does now, how can that be a bad change
(assuming you were able to find the exact version cutoff)
well, I know it worked on 22.214.171.124, and I know that the dev_set_name is in that version and higher (maybe a few back as well), so I made the cutoff at 2.6.30
ack, I should go to bed too
me too. goodnight
cradek: >>turns out my LPT board has "one" flaky input! --I was wrong, my test setup had a bad ribbon cable! pin 13 is an outside strand - PP board checks out fine, I'm back to a bad encoder Geez
mozmck: for now at least, don't push any changes to 2.3 yourself. But if you want a change on 2.3, reporting that it works for you when cherry-picked to your local 2.3 branch is valuable.
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-04.txt
jepler: I have suggestion: in Makefile instead of listing all dirs in usr_intf/ could be script that include all dirs in usr_intf/
so if one want to add new interface to emc could only include link to external dir in usr_intf/
without all makefile messing
I'm logging. I don't understand 'bookmakr', micges_work. Try /msg logger_dev help
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-04.txt
here is proposed patch for above problem: http://www.pastebin.ca/1656761
micges_work: does that even work?
for sure I'll test it again, jas
include $(wildcard $(SUBMAKEFILES))
aha, this is why
I'm not familiar with make scripts (yet)
I think the explicit list is better. I don't really understand why it is a problem. Someone adding a gui already has to add make rules to build it, so this is not a particular obstacle
I'm not saying this is problem
-include $(wildcard $(SUBMAKEFILES))
huh, I wonder why I made this not fail for missing submakefiles
because I sure never intended for wildcards to be used in SUBDIRS
a patch to allow clearing axis info or errors notifications: http://www.panix.com/~dgarrett/stuff/0001-add-support-for-clear-by-iconname.patch
posted earlier but not sure it was noticed?
I saw it go by but didn't take the time to look at it
EMC: 03jepler 07defer-format * r419bef46fcd5 10/src/hal/drivers/mesa-hostmot2/ (hm2_7i43.c hm2_pci.c hm2_test.c): prefer rtapi_snprintf to snprintf
EMC: 03jepler 07defer-format * rc6d47337dfa1 10/src/emc/motion/motion.c: this declaration was unneded
EMC: 03jepler 07defer-format * r02888daee8c9 10/src/rtapi/vsnprintf.h: a convenience function for adding a single character
EMC: 03jepler 07defer-format * rf63621f26cef 10/src/rtapi/vsnprintf.h: "formatting" a double as hex is better than nothing
EMC: 03jepler 07defer-format * r7d1ce2b675a6 10/src/rtapi/ (rtai_rtapi.c rtapi.h vsnprintf.h): use our vsnprintf for %f support
EMC: 03jepler 07defer-format * r293a8126cdf9 10/src/emc/motion/stashf.c: in realtime use our snprintf for %f support
EMC: 03jepler 07master * r0798a048e3c8 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: fix rendering error of selected lines
EMC: 03jepler 07master * ra463346aa76b 10/lib/python/rs274/interpret.py: fix appearance of arcs when abcuvw offsets are in effect
EMC: 03jepler 07master * r3f5bfd6f29ea 10/lib/python/rs274/interpret.py: these comments were misleading
hm, on the other hand I'm surprised push pushed those defer-format changes; on the other hand, I am surprised to find I had anything in that branch that I hadn't pushed
cradek: ah, I *do* have push.default = tracking, but the /usr/bin/git on india is so old that it doesn't support that option
but I thought I had my path set to use my own git
EMC: 03jepler 07master * r74d6628d9679 10/src/emc/usr_intf/axis/scripts/axis.py: add support for clear by iconname
any excitement in the east?
jepler: but: ii git-core 126.96.36.199-1~ppa~dapper fast, scalable, distributed revision control system
are you sure? that's the same one I put everywhere.
LawrenceG: hm, I'm not accustomed to thinking of myself as being in the east..
cradek: india:/usr/share/man/man1/git-config.1.gz doesn't mention push.default.
cradek: hm, 2/3 of those changes don't apply cleanly on v2_3_branch
I'm very surprised that appeared between 188.8.131.52 and 184.108.40.206
jepler: coordinate system rotation, surely
cradek: it looks like uvw offsets were also broken and you accidentally fixed them when adding rotation
clearly I need a 9-axis mill for testing
I think I'm not going to touch this on the branch .. if someone else wants to tackle it, test it, and give me the results I'll consider it for inclusion though
"Planification" sounds like the perfect 'this will make me look smart' word. It goes nicely alongside "implement" and "utilize".
planning = creating a plan (from scratch). planification = turning something that isn't a plan into one
I encountered "6. Resources have been identified to participate in the pilot:" today
only from the context could I guess what it meant
cradek: nice one
it means a list of people who will attend a meeting
in the same email: "to finalize the agenda and confirm the logistics of the service package."
that means decide what time the meeting starts
maybe Yishin should be pointed to the joints/axis branch - He could help :)
jepler: uh-oh, stuart says touch off is borken
cradek: uh oh -- where
g91 g28 x0y0z0 ?
=~ g0 g53 x0y0z0
did you use the g91 g28 formulation or the g53 formulation?
g91 = relative mode?
I wonder if touch off accounts for g91 in effect (or needs to)
I used the g91 one
G10 doesn't care whether you are in G90 or G91 (and that is by design and documented)
yes in this case it means a move to the current point (relative to 0,0,0)
this odd formula is because of the odd way g28 works when given axis words
I think you can get behavior like this if your config directory is not writable
yes - I asked him to check that in my response
though I see that Interp::save_parameters tries to check for errors
CHKS((rename(filename, line) != 0), NCE_CANNOT_CREATE_BACKUP_FILE);
oh the directory too? hmm
rename("sim.var", "sim.var.bak") = -1 EACCES (Permission denied)
I get ghese in strace but no error reported..
somewhere along the line of calls something isn't using CHKF then
hm, now it behaves even more oddly
Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
emc/task/emctaskmain.cc 2076: error executing command 516:EMC_TASK_PLAN_SYNCH
emcTaskIssueCommand() returning: -1
it does this over and over again
but without displaying an operator message
I bet it should only give that error once
I think it synchs all the effing time
jepler: thanks for applying that patch:)
i propose to offer a patch to populate #parameters with the current tool id,diameter, etc but am not sure i know all relevant issues
[19:00:08] <dgarr> http://www.panix.com/~dgarrett/stuff/tool_parms.txt
cradek: if I make it just error once, it errors too early to appear in the GUI
or maybe I'm doing it wrong
dgarr: would you modify the tool table if the user writes #5071=1?
no -- i see it for just immediate use (eg within a gcode subroutine) read-only
that feels kind of incomplete to me
people often ask about accessing all sorts of internal state through # variables. especially current coordinates.
are there philosophical or practical objections to that?
philosophical: no; practical: you have to pick # numbers, and I think there is no existing "reserved" space so you might step on existing programs
also, some things aren't really numbers (is tool compensation currently off, left, or right?)
it just all smells kind of bad
dgarr: seems like pretty much everything in the setup struct could be made available - not sure how to do that and keep it maintainable (since we add stuff to setup willy-nilly)
do you see problems with tool parameters specifically?
no, and I see a very useful way to use it: a roughing pass with G41.1 D[#5072 + 0.010]
i think modifying the tool table if a user wrote #5071 would not be appropriate since it would be trying to maintain the same data in multiple places -- thats why read-only makes sense to me. if a user wrote #5071 etc. he would be on his own.
but to feel complete I think it should write the tool table for the current tool if you modify those. I think anything else will feel like a surprise to users. compare with how you can set offsets with #...=...
the tool table is already written by the intepreter in many situations including G10 and tool change on a random-toolchange machine
your patch is against an old version: be sure you're working on git-master
(I stirred it all up merging random-toolchange)
now, the tool in the spindle is settings->tool_table
i guess i don't understand something: are there #parameters that have side effects from the (only) action of a user writing them from gcode?
yes, all the coordinate systems work that way
also g28/g30 saved points
try #5221=9, then G54
you will see the X origin move
then, also that is saved in the var file
looks like the top parameter is currently #5400. you could be sure to not break any programs by raising it and putting new stuff above there
i'll have to study that, thanks for the example.
if doing this I recommend you leave space for eventual tool offsets in all 9 axes
does that mean make RS274NGC_MAX_PARAMETERS 5400 + 9 * 7 (7== no. of items in tool table)?
and reserve the numbers somehow?
I guess I mean you'd want id, x,y,z,a,b,c,u,v,w offsets, diameter, front/back angle, orientation
so 14? vars would be used
today the unused tool offsets would read as zero
in the very old days someone had the foresight to leave holes in the coordinate system offset #vars so when we added a,b,c,u,v,w axes it did not mess up existing programs which read/wrote the x,y,z offsets
is it a good idea to increase RS274NGC_MAX_PARAMETERS? the 5400 number is cited in rs2274 documentation. Is there a downside to using 5071-5084? it seems to me that it would be better to use use gaps when no conflict exists?
I definitely think you should put the new variables where it was previously forbidden (above 5400) since existing program may use 5071-5084 for other things
by programs do you mean existing gcode programs or other programs? i'm confused what would break? (sorry to be dense)
existing gcode programs
it's unlikely, but possible
[19:56:54] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JMKsFusee
here's an example of a program that uses a bunch of parameter space - I think it doesn't happen to hit the area you are going to modify, but possibly could have
by raising the max and putting new stuff above it, you make it impossible to break any existing gcode
if we subsequently add full introspection (approximately everything in the setup struct) we will definitely want to use that scheme
i understand -- no problem. i thought i had read that there was a range of #numbers for user (gcode) and a range for system (sourcecode) but i can't find it
I vaguely remember something like that too - let me know if you find it... :-/
i guess each extension of #numbers would extend RS274NGC_MAX_PARAMETERS by the right amount -- this makes sense.
i would think most new gcode would use the #<namedparameters> -- it makes code much easier to read and learn from
we may want to call that 'the introspection area', and treat it specially (for instance, don't write it in the varfile, maybe even error if someone manually puts it in the varfile because that makes no sense)
it's an interesting idea that maybe 'the introspection area' could be in named-parameter-space
not sure how to do that cleanly - partly for the same reason of clashing with existing gcode
ok, i will work on a more comprehensive patch for tool parameters -- thanks for your input
i'm still hoping _someone_ will try my gui for subroutines:P http://www.panix.com/~dgarrett/ngcgui/ngcgui.txt
you're welcome for my input - but I'm a little worried that I'm the only one who said anything - don't mistake me for someone whose ideas are always good... :-)
has any one done any work on rear tool post lathe? or should i say slantbed type
I mounted a tool in the back once
or twice even
i ment as in the display as for slantbed its wrong way on graphics on axis
ah, wondered what your real question was :-)
tool offsets just wrap around spindle to other side in effect so no difference there,
only problem is jogging arrows and display are upside-down
yea so i didt know wether to do a ini setting write a patch
I don't think it's an ini setting, but it should be
im sure other are looking for the function also
maybe LATHE=2 instead of =1
yep I'm sure you're right
I've seen it on the list once in a while
i througt lathe=2 should mean a two turret lather later on?
heh, no idea
it could also be a preference on the display menu
for sliding head also,as have two turrets
im just fitting this machine out, http://cnczone.com/forums/showthread.php?t=92057
so ill be looking at ways to add tool offsets for bottom turret also later on
is the bottom turret something like ER for drilling/tapping?
looks like it's for end stuff only
drill tapping bar stoping only as its only a 2nd Z in effect
oh I see, it's always aligned with the center, neat
they did make them with a top turret on bottom so two Z X axes
that will surely be W, but you can't have both W and Z offsets, grr
and also with power tooling and C axes , and also a rear tail stock also, so not bad for a 1980s machine
yea i through two extra turrets on a althe should be U W no hence why lathe=2 ini setting later on
once upon a time I had this snippet of code in my ~/.axisrc file to turn the view "upside down"; I don't recall whether there was a problem or limitation of the code, or whether I just never took the time to make it an easily-enabled optional setting: http://pastebin.ca/1657438
jepler thx ill try and have a play with it see how it works out,
alex_jon1 is now known as alex_joni