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