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