I trust that folk will fix my reboot post where y'all see the need.
I can't believe you told people they should count
And start with the Arabic 0
How you doing this evening, SWPadnos
just fine. you?
great. did I hear earlier that you had frost last night? (or something close to it)
Yes a fairly hard frost. And snow in the air.
Tough on gardens.
hmmm. I thought it seemed cooler today
I wonder hoe the robin's eggs will do
I'd bet they protect them.
I'm sure they'll try
We had a nest several years ago less than 4 feet from the kitchen window.
Interesting to watch.
yeah. I think the first egg was laid an hour or two after I was asking Jymmm about moving it
Really. Did you make the move?
we'll just bring the hose around from the back if we need to water anything in the front :)
You put a web cam on it?
I'm not sure I have one I can stick out there
I had an old B&W surveillance cam complete with waterproof enclosure and windshield wiper.
Tilt, pan, and zoom.
heh - nothing like that here
I used the tilt and pan for something else with emc and tossed the camera.
I have a small digital camera with a C-mount lens on it, which is sitting on bare boards :)
kind of the opposite of weatherproof
well, you need 6 axis control for a camera: pan, tilt, dutch, zoom, focus, and iris
Ihave enclosures but the opacity isn't good for a camera
wow, jepler finished the naive arc detector tonight
fenn_ is now known as fenn
cradek_ is now known as cradek
What you thinking on that, skunkworks_?
I am suprised I guess.
seems a bit poorly implimented.
Ah okay. The "workaround" for Mach sounds like a real kludge.
like FO was an afterthought.
well -- it certainly simplifies a few things in the trajectory planner if the control derates accel at 100% FO and increases both accel and vel proportionally at >100%FO.
I call that cheating ;)
it's just a different trade-off. if users like the advantages you can get (pre-planning probably makes >1 segment lookahead easier, for instance) then I don't see anything wrong with it.
sigh. launchpad automatically closed my question "how can I improve my users' experience with apport".
(because nobody had "answered" it)
I understand. SWPadnos thoughts on mach's FO not taking effect until all the pre-read segments are done maybe is wrong then. They just dynamically change the accel and feed after the fact. (if I am understanding it right)
I fail to see the value of 5% accel if I set fo to that value.
And I am in "willing to learn" mode this morning!
true, it only sounds vaguely useful if you stay very near 100%
I'm sure whoever wrote it knew it was a painful but necessary tradeoff
100% of the machine's ability?
no 100% of FO in mach
Not 100% of some assigned feedrate.
here's one possible justification at low FO: With that scheme, at 5% the program will stay on the exact same path as if you were at 100%. Useful if you want to run it and see if the path clears some obstruction on your table. Compared to our system where it'll stay nearly on the exact path at 5% but maybe diverge wildly at 100% if you have a low inifile accel.
(exact path != exact same path)
very true jepler
Wildly as in 0.01 or so?
Although we are making assumptions. maybe feed is the only thing changed < FO 100% and > FO 100 the accel and feed are increased. (if that works)
but at 101% that same path becomes impossible for the machine to follow ... uh-oh
now toss adaptive-feedrate override in there
(I have morning brain)
Seems like the thought is that max-vel is also overridden by FO >100%
skunkworks_: it's impossible to know exactly how closed software works, but the simplest implementation of FO is to "scale time" on the preplanned path
So that you could push feedrate faster than the machine was capable of.
rayh: yes I'm certain you are right.
I remember seeing this on steve stallings's demo machine a couple years ago.
I recall thinking wow, we fixed that in emc a long time ago :-)
except you may have thought "I"
Yea. It worked when the code was still at nist.
jepler: I recall you're the one who noticed it
yes, "I", haha
Must have broken it someplace along the way.
[12:39:48] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457169&postcount=9
iirc, emc1's FO would violate velocity but not accel constraints at >100%
another reply (why he wants to try emc2)
I don't seem to remember it being much of an issue because no one was thinking about serious contouring or cutting near max vel.
on my BOSS it scales the velocity up to 125%. even the rapids and jogs scale up. not a very smart implementation I guess.
wonder why I'm chatting instead of getting ready for work.
[12:43:53] <cradek> http://www.cnczone.com/forums/showpost.php?p=457169&postcount=9
I think that's what it is here.
the sad thing about this post is he spent months on this problem, apparently without knowing what was really going on.
if he had known 'the accel scales too' he may have been able to work around it.
I am sure everyone told him it was a hardware issue
We never do that;)
heck no. ;)
on a related note, I see that aaron moore has now said he gets bad behavior at all speeds with mach as well.
jepler: it does sound like a PSU problem for aaron moore
but his troubleshooting is really chaotic
I'm still stuck on MAX_VEL as the upper limit of the motion of any axis.
3-Mar-2000 FMP added fault to axis status; clipped axis jog vel to
I do see a lot of fiddling with the velocity code back then. But it seems clear that intent is that an axis max vel is as fast as it was permitted to go under any circumstance.
3-Mar-2000 FMP changed STRAIGHT_FEED to limit feed rate to axis max
velocities, as was done for STRAIGHT_TRAVERSE below.
skunkworks_, when FO takes effect has nothing to do with how badly it affects accel :)
I wonder if 125% somehow magically overflows some integer value that's used deep down in the step generation code
as cradek said, if you look at it as a "when does the next step pulse get output" question, then scaling everything in time makes a lot of sense
seems like it would end up depending on SCALE and such stuff
and there are also 3 "max pulse rate" settings (I think), it's not continuously variable
somebody go find the new arc-related bugs I wrote yesterday
I think they're in the code you wrote yesterday :)
I suppose it is exponentally harder to combine multible arcs within the Px.xxx tollerence?
yeah but I dunno how to make the bugs manifest
no, it's only geometrically harder ;)
jepler: tried torture.py ?
skunkworks_: the code doesn't combine arcs .. it turns tiny and nearly-straight arcs into two straight lines, then applies the existing line-related simplification code to them
SWPadnos: funny. :)
jepler: I will review the code later, as if that can give you any more confidence
cradek: thanks for the offer -- I appreciate it
jepler: I understood that from your explaination yesterday. I guess this does also fix the arc-line-arc issue.
somebody could also follow the given example to add support for G18/G19 arcs
skunkworks_: yes, I think it should
is anyone else here a member ofthe geckodrive Yahoo group?
I don't think I have ever posted there though.
well, there's a thread about EMC2, and I want to respond to it, but I'd like someone else to read it through
in fact, I think it's based off a commend you made on cnczone :)
oh - crap.
what did I do now ;)
heh. Mariss started out a long post with this quote:
"Emc2 does motion within itself. Any hardware that moves motion outside of emc isn't a good match. It would make emc2 not emc2 . Emc2 only requires 'dumb' cards that count encoders and maybe a few dac's, adc's or PWM if your build requires that. Emc closes the pid loop within software."
I think I remember where that came from ;)
actually - that is me quoting you... ;)
yeah, me or somebody :)
well - the first part anyways.
I'm of the impression that this came from some stuff Matt was suggesting regarding the rabbit.
I don't think so
There was a two track approach to what the rabbit did.
most of those discussions were too long ago to be relevant (unless Matt recently mailed Mariss privately)
No I don't think Mariss forgets.
I've probably stirred that pot more - I've mentioned several times that the Rabbit is an impediment to G100 uptake in the EMC2 world, and that I might just make an ARM board to replace it :)
I probably am out replaying to that.. (as I am the one that started it) ;)
IMO the EMC approach is the ability to determine what software might be running out there.
I'm replying to it - just wanted others to read it
well, from a certain perspective, we do have a deficiency in EMC2 - we can't use smart devices
even though the motion controller essentially does exactly what a smart device would want - it outputs new positions every milllisecond
Sure we can, or should be able to. As long as we have access to what the smarts are and do.
we shouldn't need access - it's like a stepper motor, but we only need to output the positions, not all the steps
Sorta but only sorta.
If I can compile an EMC stepper module and run it outboard. Okay.
At least that way I know what it does or is supposed to do.
well, if we could use any of the USB-connected devices, that would be great
but there would be limitations to what you could do with one of those
his comment about his stepper servo is mute I think.. emc will run it just fine as it will probably be step and direction input
Yea. The cost in terms of ability is the killer there.
though it would probably do what 90+% of CNC users need
skunkworks_, he gets corrected by Les Newell later :
Is this multi axis?
And does it do traj planning out there?
oh, I know the tradeoffs :)
and yes, they're all 4 or 6 axis, and they keep the axes synchronized
If yes then we have the same killer loss of override and such.
but not to a spindle, or an MPG (unless that code is built into the end device)
but FO taking effect this millisecond isn't a huge problem for a lot of people
I think it's icky, so I'll stick with EMC2 (when I get to the retrofit ;) )
How long ago did he promise this with the rabbit device?
Steve Hardy promised it a looooong time ago ;)
and the SmoothStepper is having the same problem
The factories in China that I visited sure could not get it to go.
nope, I don't think anyone has it working, though I haven't checked the ncPod
Last I heard they had retreated to a totally dumb thing with parport.
what is an ncPod?
oh - that's the USB-connected device that uses a modified EMC2 planner to spit out 1ms positions, which are fed down the wire to the controller
[13:44:40] <SWPadnos> http://ncpod.oemtech.com/
Fred Smith and company?
I think so
I tend to refer back to the NIST coffee cup for guidance on these sorts of things.
I'm not sure they're selling it, actually
I agree - we've got the better way
Sense -> Model -> Act
and do it at local, regional, and global levels.
sure. so you could have a USB-connected multi-axis motion controller at one level, but you can't expect RT communications back to the PC
Right but the PC level must be an adequate supervisor.
I would personally hate to give up the halscope ability at the base thread level.
it just becomes a black box in the way that the pwm inside mesa is a black box .. you have to trust that it's working properly
me too, but I think that doesn't impact most CNC users (or even most EMC2 users)
But it would be possible to run that level of data into a xxx at that level and then pass it and read it at the supervisory level.
it may be possible, but maybe not. the reason to use a hardware step generator is because the PC can't twiddle the bits fast enough
so if you want to see when each bit got twiddled, you'd need enough bandwidth for all those "base periods"
With mesa we do have the advantage of being able to look if we want to.
or pluto - don't forget pluto!
Sure and ppmc
well, we can't look in there
We can't look at the code in there but we can look at the effect of the code.
There are all kinds of levels of distributed tasks here.
true, though not at a halscope level - we can't look at the step/dir pins in HAL
Clear up to the "black box" emc thing.
ok - I know there are a lot of reasons for wanting the PC in direct control of everything. can we make a list?
I can make my MiniITX behave like a step generator.
flexibility is one thing - we can change the way the machine works, both with HAL and with software changes
things that should be RT, like feed override, are another
synchronizing motion with an external device (MPG, spindle, axis to axis)
Some would argue that since the human has a hand on the override it is not inherently rt.
it's RT, but not on a millisecond timescale
maybe 0.1 second lag is OK
is there any way to home to index on a servo machine with mach?
cradek: last year we heard a guy explain how he did it, but it's a hack
make a PLC that does it
That was not to the mach question. I know nothing re mach.
Except that it's about 740mph.
I think he used external hardware to AND together the index and the home switch
cradek: roughly, the switch sets the input to the PC and the index pulse unsets it, so that mach just acts like there's a switch
more like a SR flip-flop than an AND, I think
so you home slow enough that mach can respond before you've moved on to the next count
unless there's some bit of clever I don't remember, I think that's true
same as EMC - it's just parallel port input and output at that stage
got it, just curious
You'd have to or there would be uncertainty
EMC can only do things faster with hardware assist
emc can do index homing to the individual encoder count even if it's faster than SERVO_PERIOD
but not faster than BASE_PERIOD
and probing the same I think.
ah - ok. I'm not sure where Mach detects the inputs
I *think* that probing happens at servo rate. index is the only thing that can capture a position between SERVO_PERIODs.
(whether at BASE_PERIOD accuracy or the accuracy of the hardware encoder counter in mesa/ppmc/pluto/etc)
This is a case where the "local" level has to pass an actual position value to the regional level
Oh. It used to. If I remember right.
It would keep track of the base loop when it sensed the probe close.
and then pass that up.
But then that was long ago and far away in a visit to Fred's office.
that may have been something that changed very early in the HAL cycle
the probe input is connected to motion, not to any of the things that run in the base thread
it may make sense for the canonical encoder to have a "latch" input, which will latch a separate count when activated
I'm beginning to think that my understanding of things is way obsolete.
actually, that can be done with sample+hold components (which already exist)
you could change stepgen/encoder/HAL abstract position feedback to have a "capture position" that is like index but driven by some other signal. in the case of software stepgen/encoder that could be another signal in HAL; in the case of hardware encoder counters it would have to be a signal outside of HAL
SWPadnos: no, because stepgen doesn't update its position output in the fast thread
ah, true - it would have to output counts at least
a machine that's busy swinging a probe around doesn't move very many steps/counts in a millisecond
I'm not sure more complexity would gain you much probing precision
for my machine, 1 count/ms is 1/40 inch/sec or 1.5 IPM
that seems a little slow, but it may not be
you could sure do a fast probe and then a slow one at <1.5 ipm
but at 10ipm (with a perfect probe) you could still get a probe result within 0.00015
is my math wrong? I would sure not be surprised.
at 5ipm you could get 0.000075
No there's nothing wrong with your math.
how fast do people usually swing probes rayh?
I'm being a bit light hearted here. My concern is not with the speed at which a user could do something.
It's the ability to do something at the resolution of the device they create.
If we twiddle with the numbers between servo and base threads then we twiddle with the resolution that probing can see.
I can't argue that it wouldn't be nice to have something like index for probing, with position captured at the lowest possible level.
But I can see your point that all we have to do is slow down the probe speed and we increase resolution
it's very hard to do since it requires low level support which would have to go in hardware devices. also I think the numbers show that the improvement we would get in return is pretty small.
* cradek shrugs
now that we finally have index homing working consistently on all (?) our interfaces, it would suck to stir the pot again :-)
here's a sketch of how it would work: add axis.N.position-capture-in (float in). add .capture (bit in) and .position-capture-out (float out) to stepgen/encoder. if you are using something with position-capture-out, hook that to position-capture-in. otherwise, just hook the regular position feedback to it. probably pluto/ppmc/mesa would not be able to add position-capture-out without revising firmwares.
the implementation is left as an exercise for someone who wants to get this last little bit of precision in probing :-P
I can see that. And since back then all we had for hardware was stg and parport and both were unusually dumb, it was easier to see everything in the innermost loop.
or at least extrapolate position from something happening at the lowest level.
fascinating. Thanks for the lesson guys.
jepler: you left in a debug fprintf
cradek: sigh, do I ever not do that?
I decline to say
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: remove debugging prints
jepler: I think you missed TLO
also it seems possible that you will violate constraints since the centripetal test is avoided
I don't understand
when the chord_deviation test passes, you get two lines and zero arcs so there is no centripetal acceleration
oh forget it, I see that flush_segments() calculates new vel/acc
ok I think TLO is the only problem I see. you handled helixes and 'extra' axis moves
of course I haven't even run this yet...
what an odd face
is it the emoticon for "man eating escargot"?
yes, must be
I hope I never bump into the man eating escargot out in the woods...
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc:
EMC: naive cam arc detection must take into account the tool offset
EMC: also introduce (but don't yet use) some new functions to apply/unapply the
EMC: various offsets to coordinates. Once these are used through emccanon.cc,
EMC: adding a new offsetlike thing would only require changing one location.
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot1_log.txt
EMC: 03compile-farm 07BDI-4.51 (220.127.116.11-rtai) * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
yeah yeah I know
jepler: DID YOU KNOW IT'S GOING TITS UP
oops - sorry
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: as any fool can tell you, it's best to compile first then commit second, not the other way around
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build PASSED
what's the opposite of ... oh forget it
remember this forever ?
EMC: 03compile-farm 07BDI-4.51 (18.104.22.168-rtai) * 10emc2head/: build PASSED
of "tits up", I was going to ask
TITS ARE BACK DOWN NOW
but I doubt that's actually funny except to a junior high kid (and me)
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
me to, me too!
tits up would be recumbent, so I guess tits down is prone
[15:26:52] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457237&postcount=20
maybe mach isn't all sunshine and light. ;)
this would be cool :) http://www.cnczone.com/forums/showpost.php?p=457245&postcount=37
I don't have a use for it at the moment but - does that really matter? ;)
that would be cool to have
yeah. I've wanted that for a while
but there are a lot of problems with backing up through G-code
(if you want a general solution)
I wouldn't know were to start anyways.. :)
I wonder if cncpro really does 150k steps per second.
jepler: NCD doesn't work on arcs other than g17 plane
anyways - can't surf with it ;)
cradek: you mean it does the wrong thing, or that it does nothing? the latter is what I expect.
sorry, does nothing, I get the full arc
<jepler> somebody could also follow the given example to add support for G18/G19 arcs
oops - too slow
cradek: is it OK or is it a bug that STRAIGHT_PROBE doesn't use getStraightVelocity?
it does but it's also doing something else..
hmmm. can you probe an arc?
in an arc
like a probing G2/G3
that would be cool for checking something that's supposed to be circular
could sure be done if anyone cared.
EMC: 03cradek 07TRUNK * 10emc2/debian/changelog: interp change
I bet there's a lot missing from trunk's changelog...
I'm sure you're right
cradek: did you have a reason in mind that 'systems.ngc' doesn't specify G20 or G21? or was it just an oversight?
EMC: 03jepler 07TRUNK * 10emc2/nc_files/systems.ngc: specify units as inches
EMC: 03cradek 07TRUNK * 10emc2/nc_files/3dtest.ngc: do these as full circles
well that is an interesting shape to get!
if your probing an arc how could you tell if the circle is round unless you stop every increment and to a line probe ?
use it as a no-go gauge?
go - no go
keep making bigger circles till it touches somewhere ?
if you've just machined a circle, you can probe around it at low speed (and no cutting force) to see if it's out of round
jepler: which is an interesting shape?
cradek: oh, I wrote a bug
it made a helix where it should have made an arc
[16:36:21] <BigJohnT> http://www.cnczone.com/forums/showthread.php?p=457270#post457270
I don't understand how a machine could fail to cut a round circle but then be trusted to probe a round circle
Cutting forces and speed could have an effect
I suppose so
it could also be something that you didn't just mill on the same machine
you could do one probing move just inside the circle in the mode which starts out of contact and doesn't error if it stays out of contact, then do the same a bit further out where it is OK to start in contact and doesn't error if it stays in contact. if either time the probe trips, you've found that it's out of round
is that what you're thinking?
yep, something like that
and you'd know where the problem is, since you get the coordinates of the error
I don't think a probe can generally be dragged along a part in contact with it
and imagine the cut stops early. the probe would snap off.
surely hypothetical probes can
I guess I can't argue with that.
that's why you do the inside probe first -- you know the circle is at least as big as the deflection your probe can handle
talk about service http://www.cnczone.com/forums/showthread.php?t=58497
[17:23:26] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=457294&postcount=22
everyone must be working...
shhhh. I'm trying to sleep
sounds great, mariss. why not open-source the verliog source code so that anyone can improve the drive? </never in="1 million years">
(I am sure it's very easy to toast a 203v if you incorrectly revise the cpld configuration though)
and/or a motor
SWPadnos: nice replies :)
thanks - working on the last one (for now)
too noisy to sleep around here...
you should post the fusee video for wayne..
I like my example of an MPG, or 6 :)
right. I also like you you're planting the seed for maris to try out hal.
heh -sneaky, huh?
I'd love it if he'd stick Mach and EMC2 on an o-scope too
he may be surprised
I have no idea how that experiment would turn out
you are hoping that emc2's pulsetrain is much more regular?
I know for sure that it is
you've performed the experiment?
also the spindle PWM is much better
ah then I bow to your actual knowledge :-P
I'm not sure that the hardware was identical, but they were very similar machines
bah - who needs actual knowledge..
and the EMC2 machine wasn't well optimized - we didn't replace the onboard video, for example
yea, I just guess 1/2 the time you just have to know when I'm guessing
(and I couldn't figure out, in 5 minutes or less with no internet connection, how to change the driver on 8.04)
so - recently?
or maybe that was this month,. I don't remember
you where in WI?
kinda. actually the weather was fine :)
did you get them excited about emc?
I would think rigid tapping would be a nice addition to thier system
theywere interested anyway. that's why I was there
I'm not sure they'll be able to do rigid tapping - there's only the single pulse for feedback
what do they use that for? spindle rpm feedback?
Mach does threading with single pulse feedback
they do use it for an RPM readout as well
(are we talking lathes?
I didn't know tormach had lathes for some reason
yes. rigid tapping in Mach requires a floating tap holer
you may get a chance to see it at CNC workshop
Mach may try to do rigid tapping with single pulse feedback - I'm not sure
you guys should demo a thread mill at the CNC workshop
pfff - anyone can treadmill.. That is just a helix. ;)
or threadmill even
not true. last year a guy was excited about switching to emc because he had a job that required a thread mill but his software could not do helixes.
I forget his name unfortunately
heck I even got BOSS to do a helix ... once
I wonder if TurboCNC can't do helixes or something
you have to do it in polar mode or something
I can get one
SWPadnos: I also forget what software he was currently using. seems like it was a dos program.
ok. that could be TurboCNC, and Mariss mentioned one called CNCPro or something
BigJohnT, something small enough for a Sherline, but big enough for a Mazak :)
they start at 4-40 and go up from there
they are pretty much the same price till you pass 1/4-20
that would have to be a 1/4 shank then if you hope to use it in both machines
assuming we will have a 1/4 collet
hey does anyone remember if that chuck was ER40? I could bring my collets.
the 1/4-20 is a 3/16 shank
the 5/16-18 has a 1/4" shank
I have to order a few end mills just let me know if you want to try a thread mill...
If you don't break it I'll use it after you finish the show
cool - the new SheetCAM will be available for Linux
SWPadnos: where did you hear that?
so says Les Newell, on the Gecko list about a minute ago
I guess all my bugging him for the last few months got him to finish it LOL
[20:01:02] <cradek> http://www.cnczone.com/forums/showthread.php?t=9500
I think he is running is in wine
he was, but Les just said there would be a Linux version
if he meant a version that's wine friendly, then I'm less happy :)
when I e-mailed him the other day he said he was working on it...
anyhow you guys let me know on the thread mill... I'll most likely place an order tomorrow or friday for some tooling...
np, just need to know what size you want
[20:15:16] <BigJohnT> http://www.lakeshorecarbide.com/index.asp?PageAction=VIEWPROD&ProdID=9
[20:15:32] <BigJohnT> http://www.lakeshorecarbide.com/index.asp?PageAction=VIEWPROD&ProdID=7
eek those are not cheap
just pick the one you want my business is footing the bill :)
let me look tonight to see what the threads are in the part we may be making.
unless you have digital machinist magazine - I think there's a drawing in there.
no, I don't have it
ok I'll find mine tonight, thanks again
keep in mind the depth of cut of the thread mills is limited
I think this part is 1/2
but just think how cool it would be to mill out a blind hole and put threads all the way to the bottom
yeah. I may make one (single point) to try out for fun
the 1/4-20 will do 0.5 thread lenght
* BigJohnT is going home and sit on the porch and rub my girlfriends head and sip on some wine it is a lovely day...
If I can just keep her from licking me all the time...