cradek: anything moving?
well this has to be a scary post
[03:41:52] <skunkworks_> http://www.cnczone.com/forums/showthread.php?t=87047
I think it is bad trajectory planning since stepgen is keeping up with what it is told to do.
I had to hack the encoder HAL module to generate the index pulse, which it's possible is the cause of the problem, but as far as I can tell it works correctly: spindle-revs increases steadily, spindle-index-enable gets set high by controller on g33, and encoder sinks it at the appropriate time. Also spindle-velocity seems correct
he should be using interpolated-velocity
(however it's spelled)
hmmm. or whatever it is that's based on interpolated-position
well - I think I finally figured out what was causing one of our servers to become unstable about once a day.
AVG antivirus's update was failing (stalling)
no log no nothing. just caused the server to 'sort of' quit working.
after coming in to figure out why I couldn't dial in.. I hard rebooted 'again' and then tried to update avg. boom - no responce after 'finishing stage'.
couldn't even uninstall it normally. Had to use avg's uninstaller.
something got corrupted.
haha, windows servers
never heard such a thing
very productive weekend
things are looking up?
got feedback from all three axes working, and got it to come out of estop
few if any mysteries left
converted by next weekend? ;)
moving, I bet
the tool changer will be fun
I got a window and a access door in and about half another wall sided.
hope the spindle drive is ok - it is giving an "overspeed" error
(when not running at all)
maybe there's a way to reset/start it - I haven't investigated yet
good thought, I'll keep that in mind
oh, funny story
the Y servo amp has a big red tag "Repaired __again__ by yaskawa xx/xx/2001"
with "again" written dark and underlined
and inside one of the connectors I found a broken tach wire...
probably why it was taken out of service ;)
I bet so too
that wire moved when opening/closing the main panel door
I bet it was intermittent and having the amp "fixed" sometimes "fixed" it for a while
those problems are the worse
* alex_joni has a question to tool-comp
is it ok to use a Z-move for the compensation?
say I want to cut the outside of a 20x20mm square block
(center at 0,0, so outline is -10,-10 .. 10,10)
can I go to X10,Y10, switch on G41/42, then move down to cutting height, and start with the G1 x-10 ?
I don't think so
[12:35:54] <alex_joni> http://pastebin.ca/1516615
SWPadnos: seems some controls allow that
I believe the manual says (or said) that the next XY move will start the compensated path
then again, I could be thinking of tool length comp, which doesn't do any compensation until the next Z move
SWPadnos: the entry move has to include an X or Y component.
I agree, but I can't seem to find that in the docs
I'm scanning appendix B of the RS274NGC_3 pdf
read this instead: http://linuxcnc.org/docs/html/gcode_tool_compensation.html
"Any move that is long enough to perform the compensation will work as the entry move. The minimum lenght(sic) is the cutter radius"
a 10mm z-move is surely longer than the cutter radius
"This can be a rapid move above the work piece. "
if we're going to play "let's misread the documentation", I think I have a previous engagement. bbl.
I don't understand why going to x0,y10, G42, then x10,y10 doesn't compensate it
like this: http://pastebin.ca/1516641
how big is the tool?
ok. I accept that 14.14mm is > 2mm ;)
SWPadnos: try running that program in sim/axis_mm.ini
oh - the laptop is on. one sec
[13:02:24] <jepler> http://emergent.unpy.net/files/sandbox/alex-comp.png
zooming in on that corner, I'm not sure you fully cut out your square, but maybe you did.
the problem I'm seeing is a gauge
[13:05:33] <alex_joni> http://imagebin.ca/view/HV0uyK.html
yep. that's what I see as well
jepler: yeah :)
the preview doesn't match the motion
that corner is closed in the motion, but open in the preview
ugh, it's something to do with the presence of the M6
yeah, you have to program XY after the toolchange
after the T2M6 line you're at the toolchange position, so your entry move isn't what you expect
and axis doesn't know what the toolchange position is; its preview plot is based on a toolchange that doesn't move
yeah, I just found that out
what do you guys think about merging random_toolchange? Several people wished it was a more complete solution, but we weren't sure what that would be. meanwhile, the existing work would let us support random changers while not making nonrandom any worse.
actually nonrandom gains one feature - remembering which tool is in the spindle
what it doesn't gain is arbitrary large tool numbers, and any kind of pocket tracking (it's assumed you don't care about pockets, you just use (small) tool numbers)
it breaks tooltables, right?
yes it changes them (removes the useless column)
my workflow doesn't involve having a useful tool table anyway, so from my point of view it's OK to merge
I think that might be true for a lot of others too, but it's probably not a good basis for a decision
how is tool in spindle remembered for nonrandom?
it's put first in the tool table (along with a comment that says this)
there are still pretend pockets. they are sequential according to the lines in the tool table. pocket 0 (first line) is still the spindle.
what's the line look like for "no tool in spindle"?
pocket and tool numbers are both available in hal for the prep
there is no such thing now. I added a "no tool" tool to the sample tool tables. it is tool 0.
TOOLNO LENGTH DIAMETER COMMENT
0 +0.000000 0.000000 no tool
you don't need to have one, but if you don't, T0 M6 is an error
oops, I was wrong - these changes *do* give you the large T number benefit too
EMC: 03cradek 07random_toolchange * r1bc050308980 10/configs/sim/sim.tbl: demonstrate that large tool numbers are now possible
you'd think I would remember how it worked...
some ideas: I could have it read/write a useless column of numbers, to make it still read old tool tables
I could always use the full pocketed version of the tool table, and the user could ignore the pocket numbers (but maybe be confused because they would change)
so it's really "remove that column of numbers if it bugs you"?
no, you specify RANDOM or not in the ini. depending on that, it expects a different format of tool table
because of the comment, I can't trust the number of columns and magically figure out which format it is
that the table has to be human readable and writable is the major cause of the suckage here I think
another problem with this change is it breaks dewey's semigraphical tool table editor that's in trunk
... which would be better/easier if the tool table were more clearly machine-readable
why must the pocket number be removed from the table?
I understand that for some cases it's not necessary, since the pocket number can be implictly defined as the line number in the table (or the Nth tool entry in the table)
your question implies that you think we currently have a pocket number, and I'm not sure that's true
we currently have a tool number and an ignored number
I believe that's what FMS was meant for - it was for a toolchanger ID of some sirt
I think that's not true - it was some kind of tool tracking or life thing
I think this may be beside the point
yes - it's effectively unused at this point, but there is a possible use
one reason to keep it is so that the tool table format doesn't have to change
wellll until very recently if the tool and FMS numbers don't match, the tool table would not work
another reason to keep it is so that someone can use tools in non-contiguous pockets
so everyone put the tool number in twice
so I could stick a tap in pocket 37 if I want, without having to populate 1-36 first
[18:29:35] <cradek> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=04828f0e89daf3379bd31e9d8d0952c0169b9b62
before this, it broke if they didn't match
I think that was incorrect behavior
but the point is - nobody is using that column for anything except possibly head-scratching
or at least I think that's the point
that's OK with me
I think that's not relevant though
here are my assumptions: 1) there are tool tables out there with the FMS column
frankly I'd rather have one tool table format, and it would be the full format, including pocket and all the lathe information
but I think any "useless" things in the tool table would baffle people
(especially if they change automatically)
I don't think the FMS values are useless
the use case is where I have an automatic toolchanger, like yours or the Mazak, and I want to run a job using "a few unused pockets"
so I want to put my 3 tools in pockets 22, 23, and 24
the easiest thing for me to do is make a little 3-tool table, with the 22, 23, and 24 in the FMX (or Pocket) colymn
and move column
if random, you could do that, and call them whatever T number you want
and move that around with my part file(s)
if nonrandom, you'd have to call them T22 ... T24, I think
(just like before these changes)
no, because I have to put those tools on lines 22, 23, and 24 to tell the toolchanger that they're in those pockets to start with
if nonrandom, you'd "prep" using the tool number, like today
I mean the T word
we're talking about two different things
I'm talking about loading the tools in the carousel and telling EMC where they are
which is easier when the tool number is separate from the pocket number, since I can still call my 3 tools T1-T3, but I can move them around if necessary
to be clear, you're talking about behavior you'd like, which is neither existing nor written?
but I think it is written, if the FMS column is used as an explicit pocket number
it's not accessible in hal, so you can't use it to load the tool
ie, leave in the random_toolchange code, but use the FMS number as the pocket instead of the line number
this is why I said before that the random_toolchange and the tool table changes are separate issues
back to the irritating problem: how would you specify which tool is in the spindle?
I want to use random_toolchange, but I want to be able to specify non-contiguous pockets in my tool table
pocket 0 is fine with me
whoah I'm lost
if random, you can use whatever pockets you want
there is no contiguous requirement
so how do I specify that tool 72 is in pocket 34?
you put it in the tool table
there's only one explicit number in the table
perhaps you meant nonrandom
how do I put it in the tooltable, if I have manually stuck the tool I want to be T72 into the pocket labeled 34?
34 72 0 0 comment...
ok, so the 4-column tooltables are still there for random, but not for nonrandom?
oh, then my bad
or me bad
[18:42:00] <cradek> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=configs/sim/simpockets.tbl;h=8e98c95a21f66e7bc77d297a534a9e6216405d3e;hb=random_toolchange
ok. I guess a superfluous number in the tool table doesn't bug me for the nonrandom case, so I'd still use the 5-column table
so you think always use this format?
I think it's a greater advantage for people with existing tooltables to not have to edit them
I think that is a very unimportant consideration
sorry for wasting so much time with my confusion
if I use the full format always, people with manual tool change by hand will see their tools move among "pockets" (the numbers will change, the lines will reorder)
I think this might cause confusion (and that confusion is the whole reason I hid the numbers)
does a non-random setup write to the tool table now?
yes because that's how it keeps track of which tool is in the spindle
and G10L1 (or whichever) also should cause a write
currently, and with your proposed change, nonrandom still doesn't tell you which pocket the tool came from
right, it does
the order will change anyway, won't it?
currently the tool table is always written in pocket-sequential order
actually, with non-random there is an implicit assumption that the tools don't move
if I give up on the idea of nonrandom remembering which tool is in the spindle, I can just do nothing to the table
it would still get written on G10L1
so the write has to be correct
maybe I should give up until we're ready to write the tool table in some program-readable format that lets us have arbitrary fields
yes it could still write for that
just stick a colon before the comment, that way we can tell where the real data ends
I worry that someone with nonrandom toolchange will write a table for his 4 tools, then run the program starting with T1M6. If T1 is the first line of the tool file, no toolchange will happen, but I think the user would expect it
do you mean break everyone's tool table?
heh, yep :)
jepler: that's a good argument *against* remembering
I always thought of it as a feature, but maybe I'm just wrong
another option is to treat the tooltable as an ini format file, but if a certain key isn't found, revert back to plain text in the old format
if you're not tangling with a changer, the price of having the machine needlessly wait at the toolchange position is pretty minor
so you put in [FORMAT]LATHE=1 and/or [FORMAT]VERSION=3
the price of not getting the right tool in the spindle might be pretty bad
well many users have said they think they want it to remember
(since the current TT code ignores preamble, IIRC)
yes certainly it is something to avoid
I should have not started this without a coherent design. this sucks.
I bet my assumption pocket-0-is-spindle is in a dozen places now
remembering the tool in the spindle is a little like remembering the position in POSITION.TXT - it could change but EMC would still think it knows
thank goodness we all got too tired to keep talking about that
I regret adding POSITION_FILE
it was a bad idea: doesn't integrate with homing, but instead further encourages some people to operate without homing, giving them a false sense that they've preserved machine position
I mean, you could remove it, if it's a bad idea
I know some users use it, though. micges keeps reporting that nans can be written to it, for instance.
(if you have a broken hardware driver that outputs nan motor positions, or a broken kinematics that outputs nan position cartesian coordinates ..)
nan is fun
although bad things happen to vismach :D
I often get tired when programs crash and take several days of work with them
especially when the most recent update to the program appears to have reset the "make automatic backups" option
SWPadnos: sounds like you should get some permanent storage, like some kind of hard disk
I'd say fuck you, but I'm too polite :)
wtf software doesn't save for days?
sounds terrible, sorry
It's only my $12000 PCB package
so much for getting that board done before 5:00
SWPadnos: crap :/
otoh, I managed to get a program borked on a robot, on which I spent 3 weeks :D
I did have some backups, but still a couple days of work lost
(at least you get to sit comfortable in your chair while redoing it)
at least it should be easier to do the second tiem
I've had enough stuff like that, that my fingers automatically hit Ctrl+S every fews minutes any more
SWPadnos_ is now known as SWPadnos
python nerds.... I need the python equivalent of an array of floats... strings wont work... are lists the preferred option? tupples seem to be getting silly
[22:32:30] <SWPadnos> http://docs.python.org/library/array.html
the array needs to hold floating point samples of audio
there are also the numpy and numarray pakcages
SWPadnos, thankyou.... much better
sure. there's probably a better answer, but that was what google told me
now why couldnt I find that??? too many trees in the forest I guess
that was the first hit for "python float array"