petev: I believe part of what you are seeing is transport delay
when its not faulted, motion compares the position feedback (just sampled) with the command that it issued last time
that makes perfect sense, it is testing how well the external control (PID, stepgen, whatever) did at making the actual match the command
well how can pid be expected to correct an error it never sees?
PID always compares the current cmd to current fb and never sees an error that large
so pid seems to be doing it's job
but motion has other ideas
forget about PID for now
read what I just wrote
motion issues a command
a millisecond later, it reads the feedback, and tests it against the old command
that means PID or whatever has had 1mS to try to match the command
for motion to do anything else would be wrong
unless and until we can agree that motion is doing the ferror calc right, I don't want to talk about PID, it just muddies the issue
so in the case I captured, PID is actually ahead of where it should be and closer to the current command?
I have no clue, because I don't know what motion was happening
the PID error was less than the motion error
in general, PID will show a larger error than ferror
that's what I would expect
but you aren't listening to me
but here it was reversed
I DO NOT not want to talk about what you saw, or about PID
I am listening, I'm just having a hard time understanding how what I saw happened
I want to come to an agreement that the ferror calc IN MOTION is correct, or not
I think that depends on the exact thread order, so lets review that first
what thread order did you intend? enc, mot, pid, dac?
read encoders (or whatever feedback), run motion, which does the ferror calc early on, and later issues a new pos cmd, then run PID (or whatever motor control), then write the result of that to hardware
lets go on an talk about the pid error
in that case the mot behavior seems like it should be reasonable to compare fb to last cmd
assume the machine has been sitting for a while with constant command, and PID has managed to do its job perfectly
fb = cmd, both ferror and piderror = 0.00000
now motion commands a position change of 0.001
in the same cycle, PID sees that command, and calcs a pid error of 0.001
it starts doing its thing, and it may or may not (probably not) correct that error
only in the next run does motion check the feedback against the new command
pid sees the error first
against the prev cmd?
ok, I follow that
now you have this screwy waveform
and we gotta figure it out
BTW, I think it happened on a decel
I hope this is reproducable, because you almost certainly don't have the right stuff on halscope
yes, I can get more traces
do you know which way it was moving?
positive or negative?
the f-error limit in motion looked good
I sure hope so, that code is trivial
why does that matter?
I'm pretty sure it was a decel
we're trying to understand this scope trace
and was moving neg
but not sure on the dir
"was moving neg", that is the direction
not sure whether the dir was pos or neg
I'm prety sure it was a decel, but not sure the dir
it was part of a home sequence
that makes things harder
initially the pid error is negative
we don't know if that means you were moving negative, and PID was ahead of the command (overshoot maybe?) or if you were moving positive and PID was lagging
its really hard to reconstruct what was happening without such fundamental info
let me look at the ini and see if I can determine
the ferror lim signal is offscale, right?
ok, HOME_OFFSET is 0.050 and HOME is 0
unless you know what phase of homing it was in, not sure that helps
SEARCH_VEL is 0.5 and LATCH_VEL is -0.05
I'm almost positive it was the last move after finding the index
but I didn't have the home state on the trace
so its only moving 0.050 inches?
that won't take long
lets assume it was the last move
so it should be a neg move
I gotta look at the home pic, I always get home and home-offset mixed up
I think home_offset is the position of the switch
home is where you want to end up
sounds right, and thats what I was thinking
but I want to check, won't take long
yes, thats it
so, its moving negative
error is cmd - fb
that makes sense as pid error is neg
so a lag would produce negative error
then swings pos on the decel
do you have non-zero FF1 ?
FF1 = 1
are you at the EMC machine now? or elsewhere?
no, in the house, it's onver 100 degree in the shop right now
it was hot today
we're speculating based on too little data, when the right thing to do is gather more data
ok, what more info do you want to see?
do you still have ddt blocks looking at the command?
commanded velocity would be a good one, so we know which way its moving, whether its acceling, cruising, or decelling
ok, what else>
also set the trigger position near the end of the screen, rather than the beginning
ideally motor-pos-cmd and motor-pos-fb feedback, but they may be large numbers, hard to see small changes
there is also some math between motor-pos-cmd/fb and joint-pos-cmd/fb
yeah, they are very large compared to the error signals and the offsets are a pain to setup
although I believe it just adds an offset to command and subtracts the same offset from fb
I will try and capture them
it should cool down in a couple hours
the joint-pos values should be close to zero, maybe they would be a better choice
in a couple of hours I'm gonna be in bed - business trip tomorrow, gotta get up at 5ish
2 hours is 11pm here
not when I have to get up at 5 its not
I meant 5ish ;-)
but so is 11 pm ;-)
yeah, it is... I don't like travel
will you have email access on the road?
I think my hotel will have internet, and I have an ubuntu VM on my laptop, so I _might_ be online tomorrow evening
I'll capture some more data in the mean time
during the day, no - I might be jacked into the corporate net, but I'll be occupied in meetings all day
let's talk about the auto-tune
I saw that discussion from eariler
did you read any of the earlier discussion on the algo?
and I wanted to scream
forget the EMC part, we can discuss that later
why in gods name do you want to have EMC running while tuning?
which part did you object to?
just wanted the limit checking of motion
and to be able to quickly test results, etc.
how is EMC at all usefull for checking results?
without it, you would have to re-do all the limit checking, amp faults, e-stop, etc.
so after you tune you could run some g-code test and check FE
using g-code to provide a test stimulus seems rather awkward to me, but to each his own I guess
ok, let's talk about the algo
it sets up a limit cycle osc in the process
then checks the amp and period
maybe its because I'm a drives guy, but I can't imagine having a higher level control system active and enabled until the low level (drive+motor combo) works right
from that it calcs PID
please clarify "limit cycle", you've used that term a lot
basically you apply a control effort to the process
every time the process crosses the set point, the control effort is flipped 180 degree
does that mean you command some positive DAC value until position crosses a threshold, then go to a negative DAC value until it crosses going the other way?
so it's always out of phase with the process
control effort is a fancy word for DAC?
IOW, the PID is not active during this?
yes, so the period is determined by the process as well as the amplitude
no, control effort is what the process control guys call the input to the process
in our case it's the DAC output
so a fast system will have a fast and low amplitude oscillation, a laggy high inertia one will have a large slow oscillation
and there are several formulas for coverting this to PID
I just used the way old and simple zeigler-nichols
but here's where it seems a bit non intuitive
the ultimtimate gain and period are used to calc PID
I'm not a mathematically competent control guy, I'm more seat of the pants, so please have patience with me as I put this into what is basically laymans terms
your drive is in velocity mode
yes, but I think it's somewhat irrelavant
so if you send "0.1 ips" to the dac, you expect the drive to go to 0.1 ips, and the position to ramp at that rate
yes, at least as fast as the motor can get to 0.1 ips
and then it may overshoot too
what is relavant here isn't the distance that it moves, but how long it takes to get to 0.1 ips
the two are realated
I think you have to think higher level
you have a set point
you have a process
you are not being precise enough
position setpoint? velocity setpoint?
in our case the setpoint is pos as is the fb
this would be much easier face to face where we could draw pictures, you gotta take into account the limitation of the communication channel (IRC)
for the PID, the cmd and fb are position, yes
so PID has a pos setpoint and pos fb and applies some control effort to the process
for the "plant", the cmd and fb are velocity
(because the drive is part of the plant)
our control guys often use "plant"
but I don't think it really matter what the input to the plant is
all that matters is how the plant reacts to it
so it could be vel, pos, torque or whatever
maybe I'm wrong here, but that's what I'm thinking
so before I ran the algo and got results
the tuning (and maybe even the approach) will be different if its vel vs torque
it changes the order of the system
I don't realy follow what you mean
as long as the setpoint and fb are the same metric, why does the control effor matter?
if the command is torque, then accel will be proportional to dac output, velocity will be the integral of dac, and pos will be the double integral of dac
if its velocity, then pos will be the single integral of dac
but all that matters is the pos response to the dac output
one is first order, one is second, drastically different phase shifts, etc
yes, but all that matter is the response
pos = dac*t^2, vs pos = dac*t - different responses
so if you just look at the response, why do you have to be concerned with what the control effor is?
my gut tells me that an algorithm that works when response = cmd * t^2 isn't going to be appropriate when response = command * t
why not look at it as a black box
and you just want to determine the xfer func
you don't care what's inside
I did look at severl commercial PID controllers and didn't see any special modes for different types of effort
I could be wrong, so don't rule it out, but lets proceed
you looked at autotuning ones?
ok, lets proceed
so before I got any data, I expected the period to pretty much be the same with different control effort
you are basically applying a square wave stimulus
the PID is calc from ultimate gain/period
amplitude determined by you? and frequency by the system
the ultimate period is just the measured period
the ultimate gain is a ratio of control effor to measured amp
the amp is also somewhat dtermined by the system
what are ultimate gain and ultimate period?
those are the inputs to calc PID
they are basically related to per and amp as I just described
lets back up
you said amplitude was also somewhat determined by the system
I mean stimulus amplitude, aka control effort, not result amplitude
the controll effor is flipped every time the process crosses the setpoint
so the ampltitude of the response is also process dependent
its flipped from +youpickedit to -youpickedit
how is that amplitude system dependent?
the feedback swing amplitude is system dependent
that amplitude of the RESPONSE is system dependent, yes
a slow process will not get as far, before the control effor is flipped
I HATE IRC
thats what I've been saying for the past 5 minutes
yes, the amp of the the response (the process)
stimulus amplitude is set by you
the amp of the control effor (the auto tune) is picked by the user
and I bet you get different resulting frequency for different effort
both the process and the control effort effect the response amp
so the ultimate gain is a ration of control effor and response amp
so that make some sense
but the I and D are completely determined from the response period alone
except that the period isn't constant
so depending on the control effort you get different results
here's the interesting part
therefore I can't see how you can get the right I and D from this
it may be that I'm just using raw motors so the response changes a lot
but I get numbers quite far apart but they all seem to work very well
you mean when you change the tuning effort?
changing the tuning effort creates different PID values
I can take the resulting PID and stimulate with a fixed square wave and the respone is very good
it's almost time optimal
how far apart? 2:1?, 4:1? 10:1?
with one overshoot and no ringing
so far about 2:1
what about I & D?
I and D are coming out small, so I have to look to see the ratio, I can't remember off the top of my head
but I can tell you the period seems to vary quite a bit
the larger control effort results in a slower oscillation of larger amp
I is much smaller than P? like 10 times smaller or less?
much smaller than that
hang on and I'll get a set of numbers
here's approx values P=100, I=0.0128, D=0.0032
this is with dac scaled to ips, and commands in inches?
but the system response is only slightly slower than the manual values and it has none of the hig freq oscillations that the manual values had
do you have FF?
FF1=1, but not during tuning
PID is off during tuning
and when I test with the square wave
when you say "the system response is only slightly slower than the manual values" do you have FF on or off?
test the PID result that is
FF is off for testing results
yes, very strange
what happens when you grab the shaft and try to turn it?
as I had much larger I and D was about 0.45
I think P was in the same range
hmmm. I'd think that a tuning effort equal to the max change in position in one period (based on the max vel) would be a good number to pick
the noticable diff was in the overshoot
what happens when you grab the shaft and try to turn it?
I manaully tuned for no overshoot
what happens when you grab the shaft and try to turn it?
echo echo response
it's very stiff
that's going to be almost entirely P, so if P is close, they should be the same
the tune cycle actually runs for several oscillations and takes an average for accuracy
(aut vs manual tuning)
maybe the reason this isn't matching my intuitition is the presence of a digital drive with encoder feedback and a velocity loop
so my whole point was this did not seem intuitive to me, it was not what I expected
if you force the DAC to zero, I bet its _still_ stiff when you try to turn the shaft by hand
heh -matching intuitions, it seems
could be, or maybe having no load on the motors is also a factor
petev, have you tried tuning with the drive in torque mode?
well, the "grab it and turn" is a load on the motor
well, what are you waiting for?
the temperature to drop
yes, but I wasn't holding it while tuning ;-)
heh - chicken
it's over 100 deg in the shopt right now
was about 103 earlier today
I was melting
only got to ~75 here, very nice (for a change)
bout the same here
anyway, back to PID
one of you guys want to try the auto tune on your system and see what kind of results you get?
I don't have servos
you need to get some ;-)
too many projects, too little time
I do have some small motors with encoders
I hear you
they need '298 class drivers
if only I had a motor (*any* motor) connected to a PC ...
what's wrong with your baldors?
they aren't connectable to a PC ;)
however, even if I had drivers for my motors, they would be so far different from your case it would be meaningless
why not? what have you been doing?
I probably could with the USC relatively soon
you have a digital speed loop, I would have an H bridge, not even torque control, just voltage control
I dunno - trying to drum up business, traveling ...
actually, having totally different hardware would be very menaingful
yeah, all I have is digital drives
the idea is to check the algorithm in as many situations as possible to be sure it works
I would really like to see the results on another system
are you coming to the workshop?
when I get my lathe back together I can try it there. I'm actively working on it so it will be one of these days.
no, not going to be able to make it
got plans with the kids
cradek will have his servo lathe there
assuming it's working...
I decided to improve it, now it doesn't work at all
what did you break
you know how it goes
I want to use the pluto for pwm and counting
instead of the dumb divider scheme (which worked ok)
hmmm. does jepler still have the etch-servo together? :)
that would be about as different from pete's hardware as you can get
I could hook it back up with the dumb driver too. I'll try to keep it together in case we want to try it
jmkasunich, I was thinking of adding a second order IIR filter block to HAL, do you think it would be usefull?
I've thought about that before
I can write some code to calc filter coeff too for various notch, low pass, etc.
but I'll need someone to put it in a GUI
2nd order isn't very high is it?
it can produce quite steep notches
I don't think any higer order would be needed
maybe I'm thinking of FIR as needing much higher order to be usefull
it's easy enough to cascade if necessary
do you have EMC installed on the pc you are typing on right now?
no, on a doze box
(I want you to see a manpage, if not I'll find it online)
but I have another test box
[01:54:56] <jmkasunich> http://www.linuxcnc.org/docs/devel/html/man/man9/lowpass.9.html
what order is that? (I believe it is an IIR)
the equation is right there....
you could get approx 12db/octave out of a 2nd order low pass, but it depends on the filter response
lowpass.9 is a first order?
like an elliptical would have steep initial roll off, but oscillations in the stop band
oh, now he's talking about poles and zeros...
phase linear, nice for control
shitty rolloff tho
you can do all the same in digital as analog ;-)
phase linear would be FIR
I've never been good with the math in either realm
can't do it with IIR
bessel is pretty close (at least in the passband)
but it will introduce group delay
the etch cnc is not "put together" right now
jepler, do you have any servos and things to drive them with (controlled from a PC, of course)?
I'll take a look at the etch cnc stuff .. but I think I had ruined some of the poorly-soldered encoder wires after the last fest, and never fixed it
I'm digging around to see how much needs to be done to connecta motor to a gecko here. I should know in a little bit
crap, it's still 90 deg outside
on a somewhat separate note, anyone have any idea why disabling module versioning would cause a kernel to not be able to boot?
leaving everything else the same with that config
SWPadnos: what exactly is "not be able to boot"
Kernel Panic: tried to kill init!
hmm, so not the usual thing about not finding the root fs
I can (not) boot it up and see the exact message
well, there was another message before that about not being able to find /dev/console
did you package it, or install it and make an initrd yourself?
self made initrd (just like the modversions one that worked, but a separate initrd, of course)
I have these servos, but nothing to drive them with: http://jmkasunich.dyndns.org/pics/tapelibservos.jpg
I found a page that mentioned some ACPI / APIC things to try, and tried ne of the three with no success
so make modules_install; make install; mkinitramfs ... 2.6.that.version
is anybody gonna have a spare 298 board?
mkinitrd that_version, but yes otherwise
no make install - manually copied bzImage and System.map to /boot
you told grub about the initrd?
yes, I cleverly overwrote the modversions one that had worked ;)
jmkasunich: with what for reading encoders?
I'll be bringing my 5i20s and breakouts
jmkasunich: I could make you one - I think I offered way back when, but you said you were too busy to build it and didn't want me to waste my time
that could read encoders and make PWM
I have a 7iXX minus which is all you'd need to play except obscure connectors
(using the old driver if I don't get off my ass and get the new one finished by then)
what is it?
this is the thread that had the APIC/ACPI suggestions: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/70774
the quad H bridge and encoder receivers
petev: what is what?
the machine you linked pic too
tape library robot?
its the mechanism from an old tape library
held about 10 tapes and one drive
so you aren't making it into anything yet?
no, its a toy
its only about 12" on the long axis, less than 4 on the short, and rated to hold maybe a half-pound
it's a plotter!
how did it run servos without encoders?
there are encoders there
on the backs of the motors
512 CPR I believe
ac or dc motors?
so why not get the mesa H bridge?
you gotta be kidding, do you really think a tape library would use AC servos?
didn't you get a Mesa H-bridge?
because I'm cheap
I didn't see any brushes
because you're cheap
at least I don't think so
I bet you could get one free for all the driver work
they aren't that much retail
heh, actually, I did get the H bridge
so hook it up
all you need is a supply
only 1 though
maybe a lab supply?
I have a bench supply, and a pile of various lambda's and such (open frame supplies)
I'll try to get it working by fest time
I think that thing should be good for some pretty nice rapids
nice to have something to play with that you don't care if it breaks
nice to have something to play with thats small enough that its hard to break it
and probably won't hurt you ;-)
I certainly care if I let the smoke out of either the motors or the H bridge
just cause I pulled the motors out of the dumpster doesn't mean I can go there tomorrow and get more
there was something I was gonna do, and now I forgot what it was
configs/servo_sim has PID and simulated motors
going to sim an auto tune?
no, just look at ferror and such
actually, you should be able to sim autotuning of differnet order systems (though I'm not sure exactly what the setups would be atm)
right now, PID output goes thru a scale block (ips to revs/sec), then a lowpass, then to a sim-encoder's speed input
so it kinda simulates a drive with a velocity loop, and with some inertia or other lag in that loop
right - you could stick an integrator in there somewhere to roughly simulate torque mode
a motor is an integrator
maybe with a decay or offset value or something so you still need nonzero output to get motion
motor integrates speed to make position, sim-servo has that already
the sim-encoder is an integrator as well, but for torque mode sim, you need two of them
can't find all the parts of etch servo .. oh well
oh well - thanks for looking
I'm jealous of Dean
I get old tape libraries, he gets a PC board router
in the dumpster?
(mail on users list)
60000 rpm spindle
at least you got something
I have never found anything decent out here
you don't work for a big company do you?
I can usually find rotting food and worms
I think it all ends up at triangle ;-)
SWPadnos: you don't work at a big company either
no, definitely not :)
I think my best find was an 8-foot or so section of 200-pair (or so) telephone cable
lifetime supply of 24AWG solid hookup wire, eh?
I think it got thrown out though :(
hmm, you bport guys might be interested in the cables I snagged
6 conductor, 16 AWG, nice crud-proof connectors
pic coming soon
cool. what kind of conn - err, thanks :)
I know my motors have a single MS connector for motor, tach, and encoder
the servo cables are expensive as hell
the connectors are also expensive as hell (more than I paid for the motors)
if your motor already has connectors, its a safe bet these won't fit
I know they won't, if they're 6-pin
they aren't firewire-shape, are they?
no, they're industrial duty
sensor cables I think, but I don't know why so heavy
ok. the Yaskawas motor I have has a firewire-shaped clocking connector for the encoder
16AWG is fat wire
yeah, that's big for sensors
[02:52:44] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010001.JPG
I'm too lazy to rename
[02:53:51] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010002.JPG
[02:54:54] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010003.JPG
the bad news is that each half is only about two feet long
the good news is that if you can use 4ft from point A to point B, they are nice cables
very flexible, uv, water, and oil resistant, 600V rated
and I have about 50 mated pairs
wow - that's great
I'll be bringing a bunch to the fest I think
I wonder where to get the matching connector though, in case an extension is needed
I'm gonna use a few pairs on my machine, to connect things that I want to be able to remove
millhead to main part of machine, saddle to control, that kind of thing
color code them so I don't plug them wrong
they'll be nice for my 6A steppers
you could use 3 conductors in parallel for LARGE DC servos
those connectors look familiar, but I can't quite place them
and the connector makes it easy to remove the motor if you have to
they're almost like lockable AT keyboard connectors
with an extra pin
except heavier (pin size, and general construction) and sealed
right, heavy duty sealed lockable high current 6-pin AT keyboard connectors ;)
it doesn't jump out at you in pic2, but one pin is longer than the others, probably for grounding
hmm, looks a lot like this, but with one more pin: tp://www.amci.com/rotary-encoders/images/devicenet-connector.gif
getting closer: http://literature.rockwellautomation.com/idc/groups/literature/documents/ca/889n-ca503_-en-p.pdf
[03:16:06] <SWPadnos> http://rocky.digikey.com/WebLib/Switchcraft/Web%20Photos/EN3C6F.jpg
similar, but no cigar
the pins are too thin
ah - right
and the polarization rib on these is more squared off
there were several other kinds, but I was too lazy to look at all of them
I'm certain its the device net family
it seems the network cables use one 5 pin config, and the power cables use another, but both are based on the same 6 pin connector with one missing pin
[03:18:30] <SWPadnos> http://www.tpcwire.com/tpc/TOfnetBODY.html
you could mate those 5 pins plugs with these 6 pin sockets, but not vice-versa (obviously)
[03:21:20] <jmkasunich> http://www.tpcwire.com/tpc/pdf/12_TrOxDevicenet_6.pdf#page=9
the pic matches, pin diameter, even the one long pin
yep - I just didn't want to link the PDF :)
no particular reason
ok, I can finally boot and use gnome again on the Opteron. I think it's bedtime
see you later
I need to sleep too, catching a plane in the morning
yep - early :)
hrmm.. wrong window
so you guys have the auto-tuning all figured out then ;)
pete does :)
hey Ray - do you have any servos around (that you can drive with EMC)?
I can throw this out.. In my situation - I think I have to use emc as the current limiting.. As there is none in the amps.. yet. So I don't know what will happen sending it a square wave. if that made sense.
full servo feedback, gecko, rutex
skunkworks, you can't current limit with EMC, since you have no current feedback (and it's a Bad Thing anyway)
rayh, ok. if you can read back through the conversation on auto-tuning PID, it may be a good thing for you to do some testing
(in your copious spare time :) )
never said it was good.. I am limiting it by accelleration and top speed. I know it isn't going to be the best solution.
I'm a real skeptic when it comes to autotune.
skunkworks, you *may* be able to do something that approaches current limiting within EMC, if you set the maximum PDM pulse width based on speed
rayh, apparently it was working pretty well. the only tester so far has been pete though, with a smart drive from AB
So I probably should test it, eh.
jmk was wondering if the method would work for torque mode as well as vel mode (which is what pete used)
yes, the more the merrier
skunkworks: you won't be sending a square wave to the motor
you're sending a square wave to the pwmgen
and it's a small square wave
ah - ok
It should have pretty good peak current ability.. so maybe it isn't a problem
I probably should read back. I dipped out early while you guys where talking.
rayh, I thought one of the more interesting comments pete made was that the PID numbers he got were dependent on the "effort
he used to tune, but that all the results worked very wel
Okay. Sounds like something I'll have to do someday.
Perhaps it's something we'll have to try on the Mazak at fest.
That should be a pretty good test.
indeed it should
rayh, one more question: do you have any Yaskawa AC servo drives around?
No I don't.
ok. thanks (that makes two of us :) )
I saw their name on something very recently but I can't remember what.
IRC logs? ;)
Nah. A device laying around one of the places I visited.
heh - ok
Oh. Beijing machine tool show.
I have a motor from a Yaskawa robot, and I'd like to make it spin. too bad it's an AC motor with a special type of absolute encoder
that's an odd combination.
I could see absolute on an axis but on a motor?
I actuall yneed the absolute encoder for my application (and the brake), but it makes sense that Yaskawa would use their own motors in their robots
That is really a single use thing.
the main thing is that it needs to track position during power-off (or at least know where it is when powered up)
gotta run - bbl
Sure. That is a good use for absolute positioning devices..
this dual processor seems to have ovl-max of around 30000
dual pentium III 1ghz
huh, mine is about 12000
(5000 with a cpu isolated)
my dual 800 at home does better.. but not that good.
wow look at that entry move http://imagebin.org/8507
I guess it's calculated "automatically"
the dotted green is the path taken, and the blue/magenta is the path given?
yes I think so
this is the motherboard http://www.msicomputer.com/product/detail_spec/694D_Pro2.htm
I'm having trouble convincing myself it's right
this is part of the "why don't you just change it so concave corners are OK" discussion?
it crosses the programmed path about perpendicular, hard to see how that could be "right"
mach apparently allows it in some cases
although to me it looks like it curves in inappropriately - hard to tell from the one dot though.
it sure looks like there's an inward curve on the second to last move
this wouldn't be so hard if we didn't have Z moves with comp on
what about Z moves complicates things?
it takes more than adjacent segments to see the concavity of the corner
why is that? if comp only affects XY offsets, then Z moves are (should be) immaterial
to cut up to a concave corner, you have to calculate that endpoint
without Z moves in the corner, you can do that by considering just the adjacent segments
ah - unless you're talking about moving in XY, then in Z, then in XY again
into the corner, up and down a hundred times, then into the next corner
I think that's just part of the generic problem of needing more than one segment of lokoahead
heh this reminds me - I found the manual for the old maxnc software
for cutter comp, it says "you must be very careful to not confuse the software when using cutter comp"
it says if you confuse it, it can do wildly wrong things
at least we have error checking for the cases we can't handle
cradek: nice machine limits in axis :)
glad you like it
Now I can't think outside the box ;)
well you sure can't cut outside the box
* skunkworks wonders what it does for pumakins..
something wildly wrong
limits are all screwy in general
it would be cool to run joint linits through kins to get an accurate boundary set
I don't see at first how you could do that
but for 8 possible joints, you have 3^8 combinations to check (at minumum - endpoints + midpoint on each axis)
I don't know how to get the a priori knowledge of what poses are invalid though
if you could do it, you could end up with a very complex shape
we need to be able to model tombstones in the axis preview :)
you need to check more than endpoints and midpoint
imagine that i have a scara-type robot but I set the limit for joint 0 (the rotary joint at the base) to -360, 360.
with your method you'd check for J = -360, 0, 360 -- but those lead to the same cartesian coordinates
sure - that's an absolute minimum
you could use some other logic for rotary joints - like using 4 quadrants
or 8 octants, actually