#emc-devel | Logs for 2008-01-08

[00:39:54] <jmkasunich> grrrr
[00:40:23] <jmkasunich> axis (or maybe task, I dunno) annoyance #1 on my shit list: touch off while in manual mode does something (reset interp maybe) that stops the spindle
[00:41:17] <jmkasunich> I don't want to keep having to start the spindle every time I touch off another axis (using edge finder, so it has to spin)
[00:41:23] <jmkasunich> thats gonna kill my start cap
[00:44:32] <jepler> task kills the spindle switching from manual to mdi; touch off is accomplished by issuing an mdi
[00:44:39] <jepler> I think chris has a patch to "fix" it; he hates that behavior too
[00:46:40] <jmkasunich> I wonder what (if any) justification there is/was for killing the spindle on a mode change?
[00:47:39] <jepler> I know it's been justified because it was the current behavior :-P beyond that, I don't remember what was said in defense of the status quo the other times this has come up
[00:47:58] <SWPadnos> I thought that was changed in EMC2 - that the spindle kept running in EMC1
[00:48:02] <jepler> another thing people want is to set spindle speed in MDI then switch to manual and manually make cuts -- that's actually the request I remember.
[00:48:10] <SWPadnos> (no direct experience, just faint recollection of discussions)
[00:48:26] <jmkasunich> this particular oddly shaped part is jammed onto an oddly shaped blank, which needs to be mounted on the machine at a weird angle to work
[00:48:37] <jmkasunich> so I'm gonna be tweaking and touching off a lot
[00:50:43] <jepler> cradek: don't suppose you have your "keep spindle turning" patch handy?
[00:51:01] <jmkasunich> if it means doing a build, thats ok
[00:51:18] <jmkasunich> I'm running an installed 2.2.2 right now on the machine, and don't really want to mess with it
[00:51:22] <jmkasunich> I just wanted to bitch a little
[00:51:29] <jepler> yeah I understand
[00:56:05] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/taskintf.cc: get rid of lastVel, last_ini_maxvel, which are no longer useful
[01:04:35] <jepler> jmkasunich: changing to MDI mode, emcTaskSetMode calls emcTaskAbort which calls emcMotionAbort which calls emcSpindleAbort. Unfortunately, emcTaskAbort is called from other places where it probably makes sense to turn the spindle off (e.g., changing from machine on to machine off in emcTaskSetState)
[01:04:48] <jepler> so .. which parts of emcTaskAbort (if any) should be done in the case of changing to MDI mode?
[01:07:21] <jmkasunich> that is one of those "if you change it you will almost certainly suffer the curse of unintended consequences" things
[01:07:43] <jmkasunich> someday task is due for a major overhaul, but for now I'd be afraid to touch it
[01:08:06] <jmkasunich> s/I'd be/I am/
[01:11:07] <jepler> as far back as the tip of v2_0_branch, emcTaskAbort was stopping the spindle (but back then it was doing it by sending a message to io)
[01:12:43] <jepler> the TRUNK of emc1 does not have the emcTaskAbort calls in emcTaskSetMode
[01:13:33] <jepler> 1.8 (paul_c 23-May-05): case EMC_TASK_MODE_MDI:
[01:13:33] <jepler> 1.8 (paul_c 23-May-05): // go to mdi mode
[01:13:33] <jepler> 1.8 (paul_c 23-May-05): emcTrajSetMode(EMC_TRAJ_MODE_COORD);
[01:13:33] <jepler> 1.26 (jepler 24-Jun-07): emcTaskAbort();
[01:13:51] <jepler> hmmmm or is the culprit far more .. recent?
[01:14:06] <SWPadnos> heh
[01:15:18] <jepler> ok -- the call to emcTaskAbort isn't in emcTaskSetMode in 2.0
[01:16:27] <jepler> revision 1.26
[01:16:27] <jepler> date: 2007/06/24 15:27:51; author: jepler; state: Exp; lines: +5 -3
[01:16:27] <jepler> make sure there is no motion left in the queue when switching between mdi and auto
[01:16:43] <jepler> yep it was me ..
[01:16:49] <jepler> * jepler goes and hides in the corner
[01:22:35] <SWPadnos> um - could you fix it and then go hide? :)
[01:24:07] <jepler> there's at least one other call to emcTaskAbort on the mode change -- I'm not the only person to have broken it
[01:24:31] <SWPadnos> I guess fixing it would require someone to know what "proper behavior" is
[01:24:36] <SWPadnos> and I'm not sure we know that
[01:25:23] <SWPadnos> I think there were reasons about why the spindle should stop on a mode change, but I don't remember them
[01:25:28] <SWPadnos> s/about/
[01:25:30] <SWPadnos> /
[01:26:00] <jepler> I have the same recollection, but I failed to find any good discussions in some web searching
[01:27:55] <SWPadnos> hmmm - there was an email from Alfred Smart on May 17 of this year
[01:28:09] <SWPadnos> "why doesn't the spindle stop when EMC2 goes into E-Stop?"
[01:28:11] <SWPadnos> use list
[01:28:13] <SWPadnos> user
[01:28:45] <jepler> the other abort comes from this:
[01:28:46] <jepler> revision 1.86
[01:28:46] <jepler> date: 2007/06/11 07:05:34; author: alex_joni; state: Exp; lines: +35 -29
[01:28:46] <jepler> prevent switching modes from AUTO while interpreter not IDLE. Fixes bug #1734264
[01:29:37] <jepler> (emctaskmain.cc)
[01:29:49] <jepler> man I'd pay good money for a rewritten task
[01:29:52] <jepler> maybe even ten dolla
[01:30:02] <SWPadnos> hmmm. that's not good money
[01:30:19] <SWPadnos> dollars should say the same thing as coupons: "cash value - 1/20 cent"
[01:30:24] <jmkasunich> what does a little pink x mean on the axis preview?
[01:30:32] <jmkasunich> is that where it makes an M0 pause?
[01:30:37] <SWPadnos> buggy open GL driver?
[01:30:40] <SWPadnos> :)
[01:31:05] <jmkasunich> it has a drawn on purpose look about it
[01:31:07] <jepler> I think you can also get one of those for a user M code
[01:31:15] <SWPadnos> a-ha! sourceforge bug 1384013, submitted 12/17/05
[01:31:34] <jepler> or at the bottom of a rigid tap
[01:31:35] <SWPadnos> cool, but wrong, link hilighting in chatzilla
[01:31:49] <jmkasunich> no user M codes here, it might be where I turn the spindle back on
[01:31:55] <jmkasunich> * jmkasunich looks at it from other angles
[01:32:49] <jmkasunich> yeah. thats what it is
[01:33:13] <SWPadnos> there's also a developer list discussion starting on 6/1/05 (by Dave Engvall) titled "spindle control"
[01:34:25] <jepler> I'm glad to see it's been defended as the status quo for at least two years now
[01:34:28] <jepler> bbl
[01:34:32] <SWPadnos> see you
[01:36:05] <skunkworks> jmkasunich: do we get to see what your making yet?
[01:38:34] <jmkasunich> not yet
[01:38:42] <jmkasunich> I'm just starting to run it
[01:39:03] <skunkworks> :)
[01:51:39] <jmkasunich> much happier at 0.030 depth per pass than 0.090
[01:51:43] <jmkasunich> this machine is so lame
[01:54:04] <cradek> by all means, someone please fix the spindle thing
[01:55:38] <cradek> ssh-add
[01:55:41] <cradek> oops
[02:59:00] <jmkasunich> holes and slots done, on pass 4 of either 9 or 10 for the perimeter
[02:59:57] <cradek> the suspense is killing us
[03:50:16] <jmkasunich> http://jmkasunich.com/pics/spindle-encoder-mount-1832.jpg
[03:52:33] <jmkasunich> still need to drill the encoder mounting screw holes, and countersink them on the other side - drill press job
[03:52:54] <jmkasunich> and I need to tweak tool diameter and run the finish passes on the holes again, they came out a little undersize
[03:53:00] <jmkasunich> better than oversize anyway
[03:54:49] <SWPadnos> cool
[03:55:14] <SWPadnos> what is adjusted by moving over the slot?
[03:55:19] <SWPadnos> is that for belt tension
[03:56:30] <jmkasunich> yep
[03:56:48] <jmkasunich> the hole at the right fits over a boss where a change gear banjo used to go
[03:56:54] <SWPadnos> are the holes used for workholding used or just for workholding?
[03:56:59] <SWPadnos> ah, ok
[03:57:00] <jmkasunich> the slot works just like the old banjo slot
[03:57:19] <jmkasunich> the hole on the left is for the encoder - I spot drilled holes for the screws that hold it on
[03:57:25] <SWPadnos> right
[03:57:42] <SWPadnos> so the two holes that the thing is mounted on in the photo are just for machining?
[03:57:43] <jmkasunich> the clamp holes were predrilled on the drillpress, and are non-functional
[03:57:47] <SWPadnos> ok
[03:58:02] <SWPadnos> I was trying to figure out why you needed so many holes ;)
[03:58:07] <cradek> neato
[03:58:12] <jmkasunich> its sitting on 1" dia x 1" hi spacers that are sitting on 2" dia x 3" high spacers
[03:58:16] <cradek> what's the approximate scale?
[03:58:20] <jmkasunich> not enough Z travel to get even close to the table
[03:58:29] <SWPadnos> hmmm. I should go upen up the lathe enclosure on the shoptask at my old company
[03:58:33] <cradek> ah ~ 3" long
[03:58:34] <jmkasunich> about 5.5" overall length, 1/4" thick
[03:58:54] <jmkasunich> I
[03:59:12] <cradek> the spacers must be more than 1" dia then
[03:59:26] <jmkasunich> the upper ones, right under the part, are 1"
[03:59:29] <jmkasunich> the lower ones are 2"
[03:59:33] <cradek> ah
[03:59:39] <jmkasunich> bolts are 3/8, washers are almost 1"
[03:59:47] <cradek> looks like a nice finish especially on the inside surfaces
[03:59:55] <jmkasunich> 0.7 ipm
[03:59:59] <cradek> I suppose you can't climb mill can you
[04:00:05] <jmkasunich> 0.008 DOC
[04:00:10] <jmkasunich> I did climb mill the insides
[04:00:26] <jmkasunich> I went down 0.030 at a time for roughing, and left 0.008 on the wall
[04:00:37] <jmkasunich> the cut full depth with the side of the mill to remove the 0.008
[04:00:47] <cradek> well that's more than max can do :-)
[04:01:37] <jmkasunich> roughing cuts were at 3 ipm
[04:01:47] <jmkasunich> my first attempt was 6 ipm, and 0.090 per pass
[04:01:49] <jmkasunich> not pretty
[04:01:51] <cradek> 3/8 2 flute?
[04:01:57] <jmkasunich> 5/16 2
[04:02:16] <jmkasunich> apparently a regrind - it mics at 0.307
[04:02:18] <SWPadnos> what spindle speed?
[04:02:23] <jmkasunich> 1400
[04:02:29] <SWPadnos> at 0.7IPM?
[04:02:31] <SWPadnos> wow
[04:02:32] <jmkasunich> yes
[04:02:49] <jmkasunich> the finish feed rate was a little silly, didn't know what to expect
[04:03:05] <jmkasunich> actually, for the outside I had it up to 120%
[04:03:18] <SWPadnos> w00t! 0.84 IPM ;)
[04:03:41] <jmkasunich> I could probably have run that pass at 3 ipm and it would have been fine
[04:03:59] <cradek> my feed graph only goes down to 1ipm :-)
[04:04:09] <cradek> that's way under .0005/tooth though
[04:04:18] <jmkasunich> I know
[04:05:10] <jmkasunich> I calculated that 6 ipm would be about 0.002 per tooth, thats why I started with 6 as the roughing feed
[04:05:38] <jmkasunich> the helical ramps were the worst part, the rest was fine
[04:06:06] <jmkasunich> but it was so unhappy with the first (0.090 down) ramp that when I edited the program I didn't take any chances - reduced the Z step and the feed
[04:06:13] <cradek> straight plunge would have been much worse
[04:06:29] <jmkasunich> the spiral was almost a plunge in the curved slot
[04:06:41] <cradek> that's a nice looking slot
[04:06:57] <jmkasunich> its 10mm (0.393") wide, and the cutter is 0.312, plus I was leaving 0.008 allowance for finishing on both sides
[04:07:10] <jmkasunich> I think I was spiraling down in a 0.370 hole
[04:07:12] <cradek> I think I would have plunged with a longer arc along the center of the slot
[04:07:23] <jmkasunich> that would probably have been smart
[04:07:42] <jmkasunich> but would have prevented me from using the same subroutine I used for the other holes and the outside
[04:07:59] <SWPadnos> SMOP
[04:08:16] <cradek> my limit switch cams have 1/8 slots and I zigzagged down through them in about 4 passes
[04:08:34] <jmkasunich> I think I told it to spiral down in a 0.500 hole for the others
[04:08:35] <cradek> (talk about spindle speed being too low)
[04:10:38] <cradek> I bet if you didn't have cnc, the outside shape wouldn't have all those fancy tangent curves
[04:10:50] <jmkasunich> I won't take that bet
[04:11:12] <SWPadnos> heh
[04:11:13] <cradek> that would be such a huge pain
[04:11:23] <SWPadnos> it would have curves, I bet
[04:11:31] <jmkasunich> actually, one of the things I'm particularly pleased about is that I managed to make this out of a piece of scrap that had 6 holes and a large irregular notch in it
[04:11:32] <SWPadnos> at least it would if I had to saw it by hand
[04:11:33] <cradek> just whatever the band saw left :-)
[04:11:44] <SWPadnos> heh
[04:11:50] <jmkasunich> I drew it, then drew the stock, complete with holes
[04:11:57] <jmkasunich> and dragged the stock around the part until it fit
[04:12:07] <cradek> ha
[04:12:17] <cradek> you're a great recycler
[04:12:40] <jmkasunich> I had to tweak the outside profile a bit, originally the top left edge went direct from the circle centered on the encoder hole to the circle centered on the top of the slot
[04:13:13] <jmkasunich> the part edge came within 0.020 of the blank edge on all four sides
[04:13:30] <jmkasunich> and one of the blank holes was inside the pivot hole on the right
[04:13:33] <cradek> wow
[04:13:45] <cradek> you're using some kind of cad to draw things?
[04:13:48] <jmkasunich> easycad
[04:14:29] <cradek> dang, wish you could use Realize.
[04:14:55] <SWPadnos> it would be cool to have a camera on the machine, and allow you to move a G-code path around until it fit the stock
[04:15:17] <SWPadnos> or conversely move the stock around until the path fits in it
[04:15:24] <jmkasunich> a really fast machine with a laser pointer in the spindle
[04:15:28] <SWPadnos> heh
[04:15:58] <cradek> a pointer in the spindle plus axis's cone and the jog buttons makes a pretty darn useful combination
[04:16:18] <SWPadnos> how does the cone work for the 5axis setup?
[04:16:21] <jmkasunich> not for the kind of fitting I was trying to do
[04:16:31] <cradek> it just points to the tooltip location
[04:16:40] <jmkasunich> doesn't tilt?
[04:16:40] <SWPadnos> ok - still vertical though?
[04:16:50] <cradek> it easily could, but it currently doesn't
[04:16:52] <SWPadnos> there was tilt before (at some point)
[04:16:53] <jmkasunich> ah
[04:17:00] <cradek> it tilts for A, I think
[04:17:03] <SWPadnos> ah, ok
[04:17:11] <SWPadnos> and you have B+C, so no tilt for you :)
[04:17:42] <jmkasunich> for my work location, I drew three 0.200" circles on the drawing, two touching the lower edge of the blank (it had to sit at an angle), and one touching the right edge
[04:17:54] <jmkasunich> then wrote down the coords of their centers
[04:18:02] <jmkasunich> my edgefinder is 0.200.....
[04:19:07] <jmkasunich> so I got my coords roughly right, touched off on one bottom spot, near one bolt, snugged that bolt, moved over to the other bottom spot and tapped the part to rotate it till it touched, tightened the other bolt
[04:19:24] <jmkasunich> then touched of again on one bottom and the right for Y and X
[04:19:59] <SWPadnos> hmmm
[04:20:19] <SWPadnos> that reminds me of a technique I think we used for doing coordinate rotation on a fixtureless tester
[04:20:50] <SWPadnos> you pick a test point from the list, then jog the machine to that point
[04:21:03] <SWPadnos> then do the same again for another point
[04:21:04] <jmkasunich> its classic fixturing - two points determines a line, which gives you angle, a third determines position along that line
[04:21:10] <SWPadnos> sure
[04:21:39] <jmkasunich> in my case I moved the part to the desired angle, you're talking about angling the program to fit the part, right?
[04:21:40] <SWPadnos> the interesting part was that the offsets for the rotated system was determined automatically because we had the machine data nd the programmed data for both points
[04:21:56] <SWPadnos> yes - you reminded me of the pleas for coordinate rotation
[04:22:04] <cradek> wah
[04:22:42] <jmkasunich> I better run those hole diameter fixes before I call it a night
[04:22:57] <jmkasunich> would suck if I came back tomorrow and something had happened to make me lose position
[04:23:04] <SWPadnos> one "hard part" of roration (or scaling) is the offsets - you don't want the position to suddenly jump to a new point when the rotation angle changes
[04:23:08] <SWPadnos> rotation
[04:23:42] <cradek> no problem, you just scale/rotate before the interpolator
[04:24:13] <SWPadnos> which interpolator?
[04:24:32] <cradek> the entire motion generation
[04:24:46] <cradek> the line from 1,0 before rotation to 1,0 after rotation is a ... line
[04:24:57] <SWPadnos> I'm thinking of the feedback/following error problem - is that what you're addressing?
[04:25:06] <cradek> yes you're rotating in the wrong place
[04:25:11] <SWPadnos> heh - ok :)
[04:25:14] <SWPadnos> I wasn't sure
[04:25:20] <cradek> rotate the points in the program
[04:25:29] <SWPadnos> ah - rotate before the motor-pos-commands
[04:25:44] <cradek> move from one to the other by issuing a STRAIGHT_TRAVERSE or whatever
[04:25:52] <cradek> just like coordinate system changes, tool offset changes, etc etc
[04:26:00] <SWPadnos> err
[04:26:14] <cradek> let me say it another way
[04:26:21] <SWPadnos> a STRAIGHT_TRAVERSE that generates no motion?
[04:26:31] <cradek> g55 (switching to another coordinate system) generates no motion
[04:26:40] <cradek> gXX (rotating the coordinate system) generates no motion
[04:26:44] <SWPadnos> right
[04:27:12] <cradek> but the next move (g1) after gXX would have its endpoint in the rotated system
[04:27:42] <cradek> just like how TLO etc apply
[04:27:45] <SWPadnos> yep - OK. I just didn't realize that the actual thing done was a STRAIGHT_TRAVERSE function
[04:28:01] <SWPadnos> oh - nevermind. I think I get it now
[04:28:02] <cradek> well it's not - those are what cause motion
[04:28:18] <cradek> g55 and gXX don't issue any canon calls
[04:29:26] <cradek> why have I thought about this? I don't want to do it
[04:29:31] <SWPadnos> heh
[04:29:34] <SWPadnos> sorry to remind you
[04:29:49] <cradek> not at all
[04:30:00] <cradek> if you want to do it, I'll offer all the free advice you want
[04:30:05] <SWPadnos> wow! cool
[04:30:10] <SWPadnos> you never know
[04:30:31] <SWPadnos> I think I may clean up some of the FPGA and modbus code instead so I can commit that
[04:31:42] <SWPadnos> though the modbus thing is a problem - I'm still not sure how that kind of driver should work
[04:32:06] <SWPadnos> and the only thing I had access to was a proprietary register map for a PLC
[04:32:23] <cradek> you mean because the interconnections aren't naturally bits or ints?
[04:32:34] <cradek> or floats
[04:32:52] <SWPadnos> well, there are 16-bit ints and bits, but what they mean are generally device-specific
[04:33:15] <SWPadnos> and the data rate is sufficiently slow that optimization of the data transfers is a good idea
[04:33:46] <SWPadnos> as an example, the data I had to get from the PLC was something like 16 words, plus the packet overhead
[04:33:50] <SWPadnos> and I had to write a few words
[04:34:00] <SWPadnos> luckily this only had to happen a few times a second
[04:34:09] <SWPadnos> and we defined the registers to be contiguous
[04:34:31] <cradek> sounds like an unholy mess
[04:34:46] <SWPadnos> yes
[04:34:49] <cradek> no offense to you of course
[04:34:55] <SWPadnos> no, it's not my fault ;)
[04:35:05] <cradek> why do people want to use it?
[04:35:16] <SWPadnos> modbus has 2 or 3 address spaces, each of which can be read orwritten, and each of which requires a different command
[04:35:22] <SWPadnos> well, it's very generic
[04:35:43] <SWPadnos> think low end serial XML, without the metadata about what things mean
[04:35:51] <SWPadnos> so all you get is the values :)
[04:36:33] <SWPadnos> since my modbus module runs in userspace, it could use a similar XML-ish file format like pyvcp
[04:37:04] <SWPadnos> so it could be made to create pins with certain names, using the data from registers X and Y interpreted as a float ...
[04:37:12] <SWPadnos> but that's a PITA
[04:37:46] <cradek> bleh.
[04:37:56] <cradek> no idea how you will shoehorn that into HAL
[04:37:59] <SWPadnos> yeah, that's why I haven't really gone too far with it
[04:38:20] <SWPadnos> well, the module I have has the meanings of the registers (and the address range) hard-coded
[04:38:26] <SWPadnos> and it exports pins to HAL
[04:38:31] <SWPadnos> pretty straightforward
[04:38:57] <SWPadnos> sleep / issue modbus read command / update pins / check input pins+heartbeat / send modbus write command
[04:50:05] <jmkasunich> encoder and pivot holes milled to proper size, screw holes drilled and countersunk, both sides scotchbrighted for neatness and to deburr, and finally washed to remove wd-40
[04:50:10] <jmkasunich> I gotta say thats a pretty part
[04:50:29] <SWPadnos> yep - it looks nice, and it's even better when you tell about how it used to be scrap ;)
[05:02:59] <jmkasunich> I think its time to walk the dog and get some sleep
[05:03:07] <jmkasunich> goodnight
[05:03:56] <SWPadnos> night
[14:54:07] <jepler> is modbus a "real time" protocol? The spec I found (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf) doesn't address timing guarantees at all. If not, I suppose a userspace hal driver is just fine..
[14:55:54] <jepler> "typically the response time-out is from 1s to several seconds at 9600 bps" -- page 10, http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
[15:46:14] <SWPadnos> yeah - definitely not realtime
[21:28:26] <SWPadnos> jmkasunich had mentioned a possible problem with how G54 vs. other coord systems are displaye dwhen starting a program or using MDI
[21:28:30] <SWPadnos> this was a few days ago
[21:29:36] <cradek> I saw that, I answered him
[21:29:44] <cradek> only a lathe user would see it
[21:30:00] <SWPadnos> oh, ok
[21:30:09] <SWPadnos> * SWPadnos forgets some stuff :)
[22:02:07] <alex_joni> SWPadnos: when you load a program the right coord system gets loaded/displayed
[22:02:16] <SWPadnos> ok
[22:02:16] <alex_joni> that happens automatically for AXIS/mill
[22:02:23] <alex_joni> I think..
[22:02:48] <cradek> right
[22:02:55] <cradek> (I agree it's a bug)
[22:05:02] <alex_joni> not a ferocious one that bites though
[22:15:29] <skunkwork_> I still get warm fuzzies running emc2+axis