03jepler 07v2_1_branch * 10emc2/debian/control.in: without yapps2-runtime, the emc-dev package does not work
03jepler 07v2_1_branch * 10emc2/debian/changelog: note bugfix
03jmkasunich 07TRUNK * 10infrastructure/farm-scripts/ (build emc2_build emc2_build_sim): only do a complete build (make clean; make) if its been at least 12 hours since the last complete build
03jmkasunich 07TRUNK * 10infrastructure/farm-scripts/ (build emc2_build emc2_build_sim): redo complete/incremental build stuff
03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
stepper abuse: zero to 775 RPM and back down to zero in 100mS (precisely one complete rev), then wait 20mS and repeat going the other way......
accel and decel rates are 500 rev/sec^2 (30000RPM/second)
it's working right now?
no, its losing a step every once in a while
I'm abusing it to try to hunt down the problem
03cradek 07TRUNK * 10emc2/docs/man/man9/.cvsignore: new manpages
I think its setup/hold maybe
its _not_ the motor getting out of sync with the drive
its the drive getting out of sync with the commanded steps
I thought the geckos didn't require fancy timing considerations
it depends on who you ask, and which geckos
the new G203's have a cpld, and I think they have very simple timing requirements
the older ones aren't so nice
and the ones with pulse multipliers (which I don't have) are really nasty
And which are you using?
G202, version 13 (about a year and a half old)
I figured if I was going to pay the price of a gecko, I'd go full servo. But I do have a HCNC set I'm going to try on my X3 just for giggles.
03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix angled entry and exit for canned threading cycle
03cradek 07TRUNK * 10emc2/nc_files/g76.ngc: fix angled entry and exit for canned threading cycle
are all the servo gecko drives also step/dir?
cradek: yes, that's my impression anyway
cradek: reportedly you can sabotage the thing into a 0..5V-input analog servo
although they are probably more immune to siming issues
the step/dir inputs simply drive an up down counter chip on the servo drives
the counter is compared to another counter driven by the encoder, to generate an error signal
too bad he doesn't make one with an analog input
actually he has posted a hack to let you drive it with analog
yes but the sync lock is +/- 128 ecoder counts
don't recall the details
didn't abort (esc) turn off the spindle in the past?
seems like elson's PWM servo drives are a better choice if you want to close the loop on the PC
jepler: yeah, step/dir servo drives seem like a kuldge to me
they're targeted at software that can't do real servo
yeah I'd probably go with elson's stuff which targets emc
plus jon's units have much higher Volt/amp capacity
maybe someday I'll have a mill that requires me to worry about that
jepler: do you still have a running emc1?
cradek: I have an emc sim at work, that's it
let me try 2.0 first
yeah I think we have a regression - in 2.0.5 the spindle turns off (and brake on) at abort
regression or intentional change?
I think I would have remembered (and argued) if it was intentional
this was also broken (way) before 2.0 iirc
if you turn the spindle off at the same time as you start decelling the axes, and the cut is heavy/spindle inertia is low, compared to axis decel, you might find yourself driving an axis against a stopped cutter (which breaks the cutter)
pick your poison
does the spec say what abort is supposed to do?
no, I think it says exactly nothing about abort
03jmkasunich 07TRUNK * 10emc2/src/hal/utils/ (scope_disp.c scope_trig.c): calculate and display correct trigger level when used with offset
hmm, the spindle also used to turn off when switching between auto and mdi modes (which I always hated), and it doesn't do that now either
03jmkasunich 07v2_1_branch * 10emc2/src/hal/utils/ (scope_disp.c scope_trig.c): backport bugfix: calculate and display correct trigger level when used with offset
what is the significance of the "load average" numbers from uptime?
are they just some arbitrary scale?
1.0 = full processor utilization by one process
so this is pretty busy?
22:22:53 up 28 days, 4:29, 6 users, load average: 10.06, 9.54, 9.28
yeah 10 is pretty high.
thats with two of the farm vm's suspended
the plot thickens
the abort/spindle plot?
coolants still turn off when switching modes or aborting
so this broke when we moved spindle control from iocontrol to motion
I was just gonna say that
2.1.1 here we come
wish alex were here
"load" may reflect processes waiting on disk, too. for instance, my reported load is higher while running a bunch of disk-intensive "find"s, even though user+system is at most 20%
the three numbers represent moving averages with different weights
yeah, 1, 5, and 15 minutes
thats in the manpage, but exactly what kind of "load" the numbers represent isn't
is there a straightforward way to get user+sysem?
looking at top is the only way I know
"vmstat 5" will show you those numbers too
I think the information is in /proc/stat but not in an easy-to-read format
I was thinking of having the farm slots check load each time they wake up, and if the load is high, go back to sleep for another 5 mins
except I just realized that checking a VM's load doesn't tell you how busy the host is
03cradek 07TRUNK * 10emc2/src/emc/task/taskintf.cc: fix bug that left the spindle on after abort
03cradek 07v2_1_branch * 10emc2/src/emc/task/taskintf.cc: backport 1.62: fix bug that left the spindle on after abort
03cradek 07v2_1_branch * 10emc2/debian/changelog: fix
more arc fitting stuff: http://axis.unpy.net/index.cgi/01171767993
heh - another case where the small pic is bigger than the original
There are enough letters to specify one full bezier curve on a single line: G? P- Q- I- J- X- Y- Z-
PQ and IJ are the control points (relative to the start?)?
something like that
I mean, how does Z work
and if Z specifies motion, it is linear, a "helical spline"
if the total curve length is L and the distance so far is M, then you're at oldz + (Z-oldz) * (M/L)
and we can do that with just the existing helixes
(in the emc implementation, L is the sum of the length of the arcs used to fit the spline)
cool, I say stick it in there
I will, just not tonight
will you just make a SPLINE canon call and do this in task?
load average: 14.66, 13.69, 11.76 :-(
cradek: I think so, though I'm now realizing that makes things harder in AXIS
if so, task knows the tolerance so you could do something smart based on that (interp doesn't know anything about that)
these "splines" are constrained to be in a particular plane (disregarding the linear Z), right?
a general spline would not be, and we should make sure the g-code can be extended to the general case if we ever figure out how to do that
there are still enough floating-point numbers: P- Q- R- I- J- K- X- Y- Z-
I don't think the biarc method works when the curve is not planar, though.
I didn't think it would
I was thinking of someday having a real spline primitive in the TP
(even assuming non-planar arcs)
(someday being after somebody solves the "where am I on the spline" problem)
I bet soft limits don't actually work right for arcs (only the endpoint is tested)
I remember noticing that too, then looking the other way
"AXIS will probably catch it"
^^ found that out the other day
really? you ran into it?
quite literally. i did and arc and i ran the table into the mill
did you have soft limits that should have protected you?
well i asume so, theyve worked in the past
did you do the arc in MDI?
yes, just went to do a big circle for fun
ok, I just confirmed it here too
if i had known this was an axis issue i would have taken screen shots for you
i thought i had just done soemthing stupid
it's not an axis issue, it's a motion controller issue
* cradek pokes jmkasunich
and, I bet, a pain in the neck to get right
added a graph of the velocity profile while following the fitted splines: http://axis.unpy.net/01171767993
-- is there a "first or last segment" blending bug? I wonder why those notches are there.
[04:28:34] <jepler> http://axis.unpy.net/files/01171767993/spline-velocity-profile.png
about how many arcs is it?
overall the program (3 passes) is 42 lines
4, 8, and 16 arcs per circuit
is this the vel profile for the 16?
it's all 3, back to back
I don't understand what I'm looking at then
er -- 8, 16, and 32 arcs per circuit
[04:32:53] <jepler> http://axis.unpy.net/index.cgi-files/01171767993/spline-velocity-profile2.png
here's just one circuit, 8 arcs
they should all be roughly the same length
hm I can see one other tiny notch so it's not after the first segment that the velocity dips so much
I see that too
the blends that are right are very good... but some are wrong
download the python from that blog entry and change the generating lines at the end to:
it doesn't go to 0, so I don't think it's a starvation
spline(P(0,0), P(.25,1), P(1,1), P(2,0), 2)
that's the program I'm running
spline(P(2,0), P(3,-1), P(-.25,-1), P(0,0), 2)
I've also pastebinned the generated file: http://pastebin.ca/361479
if I make it go around twice (same exact parameters) the notch doesn't happen the second time
[04:39:51] <cradek> http://timeguy.com/cradek-files/emc/biarcvel.png
some of them are being done at a different velocity?
it would be nice to have the seq nums in halscope...
are they in a global or struct that exists outside the tp?
yes, stat buf
the last part of control.c has some hal params that you can use for debug - just assign the value of what you want to see to one of the params
I bet you want ints tho.... the test params are 2 bit and 2 float
not hard to add a couple s32
line 2377 in control.c
you want me to add a couple s32 ones?
that would be great - let me try to figure out what the field to use is
[04:44:49] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lines-velocity-profile2.png
this is just 'G1 X.4 / G1 X.8 ...'
it should also be a real easy case for the planner
6 .4" movements in all
I bet we're seeing accel mismatches because of the non-tangent end
in the case of the lines only in X?
I don't understand your plot again
that's running this program: http://pastebin.ca/361490
it's just movements towards +X, each .4" long
then back to the origin -- I assume that's the actual stop
03jmkasunich 07TRUNK * 10emc2/src/emc/motion/ (control.c mot_priv.h motion.c): added s32 debug params to motion controller
there you go...
right now, number 1 is connected to the X axis homing state (state machine)
just for testing
you can connect either one or both to whatever you need
number 0 is just set to 0 right now
thanks, let me try it
works like a charm
03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: give current motion id to halscope
[05:03:50] <cradek> http://timeguy.com/cradek-files/emc/biarcvel.png
but I hope its more enlightening to you than it is to me
no, I especially don't understand the first dip
you can use the other debug pins to get a look at TP internals
yuck, the TRAJ_CIRCULAR_MOVE debug output is bogus
03cradek 07TRUNK * 10emc2/src/emc/nml_intf/emc.cc: fix circular move traj issue debug output
03jmkasunich 07TRUNK * 10emc2/docs/man/man9/ (sampler.9 streamer.9): add enable pins to streamer and sampler
03jmkasunich 07TRUNK * 10emc2/src/hal/components/ (sampler.c sampler_usr.c streamer.c streamer_usr.c): add enable pins to streamer and sampler
well I fixed a task thing and an nml thing - I think it's time for bed
03jepler 07TRUNK * 10emc2/debian/control.in: got import error when running comp if yapps2-runtime is not installed
03jepler 07TRUNK * 10emc2/src/Makefile: make installation dirs at the right time during the build, otherwise 'install-python' fails when making the deb
* jepler imagines bezier curve + tool shape compensation
jepler: is someone doing bezier curves for the interp now?
awallin: right now I'm looking at the difficulty of adding it to the interpreter
jepler: would the interpreter convert a bezier curve to canon-commands(lines and arcs)?, or would the trajectory controller be taught a new type of move (bezier)
awallin: the interpreter would have a canon call for "cubic bezier curve", but the initial implementation would be to convert that curve into a series of arcs before the motion reaches the real-time code. http://axis.unpy.net/01171767993
[16:08:13] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/emc2-g5-spline.png
right now both axis and emc interpolate it with a fixed number of lines (10) but the next step is to use the biarc algorithm in emc
actually the next step is apparently to make chocolate chip cookies
Anyone have experiance with EMC2 & standard stepper config - and able to spare a little time to help?
DavidMB: go ahead, there might be people around with helpfull info
Ok, I have a setup that works fine with EMC1 ( 4.51 I think ), I use bridgeportio to generate a spindle on signal to control on-off spindle, this is all working fine. Have installed Ubuntu/EMC2 on a second hard disk and motion seems to work ok apart from some fiddling with scales etc, but I can't get the spindle to come on. Have two paraports working fine, even switched load order and run step & direction through second car
what Ubuntu/EMC2 disk did you use?
I mean how old is it (I'm interested in the emc2 version on it)
I think it's 6.06, the ISO image from the LinuxCNC site.
ok, did you get that lately?
DavidMB: if it's 1-2months old then it's probably emc2-2.0.x
if it's newer then it's emc2-2.1.0
Yes sorry, it was downloaded last week.
I only ask because the spindle control has been changed in 2.1.0
Sure it's 2.1.0
do you know about HAL?
I read that you were able to run step & dir on the second card
that means at least some parts you surely know already :)
Yes thats correct
ok.. you had the spindle driven by a on/off pin ?
Yes I drive an opto isolated relay.
ok, looking at the default config I see there is some part that refers to spindle control
# create a signal for "spindle on"
newsig spindle-on bit
# connect the controller to it
linkps motion.spindle-on => spindle-on
# connect it to a physical pin
linksp spindle-on => parport.0.pin-09-out
Yes I changed it to use pin 3 and then pin 5 with no joy.
are you sure those are output pins?
3 and 5 are usually inputs
unless you define the port as output, 3 and 5 are actually DATA2 and DATA4 (which are bidir, and by default outputs)
will check, but doc says parports config for out unless specified for in
right, default is out
not sure what I am thinking :P
can you check the level of the parport pin?
DavidMB: you seem on the right track.. gotta run for an hour.. but I'll be back
in the mean time there might be others helpfull in here
yes, I was going to put a proper meter on it next, I think the pin is not outputting the signal, but when I swap the HD and run up EMC1 it works so I guess I'm missing something in config.
alex_joni: I was able to install ubuntu 6.06 by taking the hd out of a very limited system, and using another box, add vmlinz & initrd.gz of .iso img to the hd's /boot. Then edit grub to use those to boot 'NewInstall' with. I put the hd back into laptop & booted. Those 2 files look to the cd for the real filesystem. This let me install from the cd, tho i cant boot from the cd :)
alex_joni: i thought you were experimenting with alternate small linux's and it might be useful
tomp: cool, thanks for mentioning that
drat, it didn't work on the first try: http://emergent.unpy.net/index.cgi-files/sandbox/wrong-arcs.png
was that supposed to be a hairy egg?
is that a pure bezier?
SWPadnos: no, the backplot should match the preview plot
lerneaen_hydra: define "pure". The user specifies a cubic bezier in the XY plane by giving two control points and an endpoint
err - I hope you changed something to get that plot O_O
ok, so it's a bezier and not straight-line segments, as one could think if only looking at the plot (low-poly-count bezier)
lerneaen_hydra: just like for arcs, AXIS approximates it as a series of lines for the preview plot
what does it base the number on?
lerneaen_hydra: it uses a number of segments that depends on the angle of the arc
from 8 to 128
I have a question about Axis config- how do I change the appearance of the tool in the opengl window? I want to change tools to .5 em and don't know how to get away from the v-bit
I am doing an M6 Txx with a different diameter tool in the program
and have edited sim.tbl to reflect that
with .5 dia tool
do I need to reload axis to make it see it?
did you reload the tool table? (it's on the menu)
ok that's it- thanks
I have been using apt360 to generate a few simple programs - it's very cool too
I saw the new wiki pages about that - but I haven't played with it yet
I have nedit open for editing and set up a shell command to apt360 | vapt and now have Axis and vapt simulating the gcode- I'm very happy : )
DanielFalck; how's apt going?
you should seriously try it out- there are a lot of things that are already done for gcode generation that will blow you away
apt looks like one of those things that you'd be happy to still/again have if you learned it long ago, but maybe doesn't have a lot of attraction for a new user
but for someone like you- who can harness it it's very good
cradek: uh oh -- my still-buggy biarcs code is calling ARC_FEED() to make its motions, but the resulting movements are way out of the velocity limits
Brent is using it at his workplace for some stuff that the commercial cam system can't handle
translation "cradek: expand your ninja powers"
4th axis continous stuff
jepler: uh-oh, are the arcs bogus somehow and it's not being caught?
cradek: I'm not sure -- they are "nearly lines"
in fact I notice there's a case in ARC_FEED to handle arcs-that-are-lines -- I doubt it's right, because it's never been exercised
large R compared to the length of the arc
[18:23:22] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/wrong-arcs2.png
doesn't seem quite right
if my debugging statements can be trusted, the radius passed in is fairly small
can you grab the output of your bezier to arc's function, write that in G2/3 statements, and see how that code runs?
I have the earlier, python implementation, and it doesn't do anything this crazy
but the numbers generated by both are a little different (a lurking bug) and the numbers given to ARC_FEED are wildly different from the numbers specified in a G2/G3 so that translation is probably bogus too
btw I fixed the arc traj message's debug, you could compare there
jepler: you had mentioned that there was modbus support in the verson that you integrated into emc.. Do you see a reason why it would not work?
* skunkworks is talking about classic ladder... sorry
skunkworks: I don't have a clue in the world about modbus
skunkworks: since the classicladder logic portion runs in realtime code, it doesn't have any code to actually send or receive bytes on a serial bus
so I'm pretty sure it can't actually do anything
Thanks. I didn't know if it was something within classicladder - (not a clue)
anyway, with HAL it doesn't make sense for classicladder to speak the modbus protocol -- a HAL module should speak modbus and provide appropriate HAL pins.
I agree with jeff
[18:48:16] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=259897#post259897
the CL modbus code might be a good start on such a driver
but it should be pulled out of CL
I agree with what ever you guys agree with :)
lerman__ is now known as lerman
YAY found the bug, now the spline approximation is good
since modbus is serial, and therefore "slow", a userspace serial driver that exports HAL pins should be relatively easy
I thikn we've been thinking about an RT serial driver for HAL, which may not be the best way to go for I/O
(of course, it would be needed for serial motor drivers ... )
the problem with modbus is that the people who want to use it and the people who are able to write the driver are not the same set of people
if only the people who want to use it were willing to pay the people who can write the driver :)
and provide the hardware to test on
or at least provide hardware for testing
note: AND not OR
* SWPadnos isn't feeling too well, so the brain is running on 2 cylinders
* jmkasunich is abusing geckos
and stepgen, and freqgen, etc
did you try connecting the motor to something to move the resonance point?
I suspect that belted to a leadscrew it will be much less pronounced
[18:57:25] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/gcode-spline-working.png
and I'm all but certain that isn't the cause of the stuff I'm trying to track down
yeah, though you may end up with bad part finish
jepler, much better :)
jepler: the other pictures were much more "interesting"
jepler: wow, that's neat
magnitude velocity plot is still the same I assume?
currently AXIS is using a hard-coded 100 line segments per spline, and emc is using a hard-coded 20 arcs per spline
cradek: I haven't looked yet, but that's what I expect..
cradek: yes, basically the same
fwiw G5 is "unassigned" in rs274d/1980 according to my book
there's not a spline code is there?
[19:04:47] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/g5-spec.png
are K and R free?
(for eventual extension to 3D
jepler: no I don't see anything about splines
K and R are both used in G2/G3 arcs as floats
I suggest reversing PQ so they are alphabetical too
oh -- I think they are, and the picture's wrong.
if you are stringing bunches to gether, the I and J of move N are -P and -Q of move N-1
also can you remove one arrow on all the dims to (sort of) show the signs?
jmkasunich: yes, that's why (I- J-) is parenthesized -- it's optional and is found in the way you suggest
if not specified
squint at the code on the bottom of http://emergent.unpy.net/index.cgi-files/sandbox/gcode-spline-working.png
next item of business: Change segment joining in G64 P- mode to fit arcs to the path within the tolerance, as shown here: http://www.cosy.sbg.ac.at/~held/projects/biarcs/img/113_ba.gif
More than neat. Is there some way to use the precision (blending) spec to control the number of segments?
lerman: not yet, it's a pretty basic implementation right now
lerman: I'd *like* the G64 P- blending tolerance to be used instead of a hard-coded "20 arcs per spline", which is what it does now
jepler: tell me again why the arc-fitting instead of general spline?
something about not being able to control the velocity along the path?
jmkasunich: there's not an easy way to convert a spline so that the parameter is length, or put another way the velocity varies over the spline if you treat "t" as a time parameter
but the various f(t) that produce the coordinates x(t), y(t), z(t), all are cubic polys in t, right?
So, instead you approximate the spline by arcs? Why not still cut the spline but approximate the velocity with what you would have if you were cutting arcs?
if they are cubic polys in t, I believe the derivitaves are closed form (actually one order lower IIRC)
so when you are at t = whatever, you can compute dx/dt(t), etc
and thus v(t)
jmkasunich: if you're offering to complete the implementation of splines all the way down to the realtime level, I accept.
which you want to be constant at f
not right now
what I am doing is a thought excersize to see where my ideas fall flat
if they don't, then yes, one of these days I'll go for it
but if I'm missing something that makes the task near impossible, then...
so, you are at t= whatever, you've computed v(t) (order O(1))
t = Tn lets say
if you know v(Tn), you can calculate Tn+1 such that you get the desired v
yes you can compute the derivative of the spline easily, I use it to find tangents to the spline at desired points
(or a reasonable approximation thereof)
without ever knowing the overall length
I suspect the shit hits the fan when you think about blending, which need to know distance to go...
you need the overall length to .. yes exactly
jmk: I think you are on the right track. Also, by computing the new position and adjusting the velocity at each servo cycle, you will divide the spline into the number of segments as well as you can given the servo cycle time.
you can approximate the length in the same fashion as you approximate velocity
(my words, that is)
lerman: the problem with that approach is you are dividing into just the "huge number of tiny segments" that gives blending and lookahead fits
13:04:22 <andrew> jepler: i think its becaue i didnt turn off the modem to reboot it just my cpu
trying to help someone with his stupid windows computer, and this is what he just said to me ^^
How often does a circle get broken into parts?
if you don't need lookahead, the derivative approach works, and is O(1)
if you do need lookahead, the derivative method means you need to precompute the whole spline so you can work out where in it you need to begin your decel, etc
actually, that is the general problem with all lookahead - general lookahead may be forced to look ahead an arbitrary number of "segments", whatever segments are
Precomputing is bad because? (a) it doesn't fit the current structure? (b) it takes too much memory? (c)??? (d) all of the above?
the work done in the TP each servo cycle needs to be O(1), or at least O(n) for some very small and bounded n
Compared to memory in the 1980s when a lot of this stuff was conceived, we have infinite memory, today.
precomputing in user space has limits though
[Also infinite processor.]
suppose you hit a limit or the user changes something while you are running your precomputed path
toss the computations out the window and start over
Hitting a limit is 'fatal', anyway.
"changes something" = feedhold, abort, feed override
lerman: the infinite memory isn't always true for kernel space
lerman: limit of acceleration or velocity
not of machine travel
limit was a bad example
The interpreter already runs way ahead of realtime.
suppose we're talking about a linear move, and you are probing - when the probe touches, you need to stop
Well, probing already stops interpreter lookahead.
lerman: yeah, it does - and that causes all manner of grief too - when somebody hits abort and the line displayed on the GUI bears no resemblence to the line that was actually running, etc
probing is just one case
adaptive feed - changing the feedrate mS by mS based on voltage (for edm) or spindle load current (milling, routing)
The GUI issue is a defect (IMHO). The GUI should have a way to show the 'actual' current position.
yeah, and that defect has largely been handled
but it illustrates the larger issue of time and precomputation as a substitute for realtime calculations
if the interp could run in realtime, you wouldn't need to jump thru those hoops
but sooner or later you have to get out of realtime - even if the interp was infinitely fast and ran in realtime, the g-code itself is being served up from a disk that has latency, and is managed by a non-rt OS
Is there any evidence that the interp couldn't run in real time? (Or be improved slightly, so it could?)
lerman: first of all it's c++ .. which isn't always kernel friendly
I wasn't suggesting that a RT interp was the answer at all
just trying to make a point
More importantly, a user reports that his loop variable has advanced to 20 when he aborted after 5 runs
that's the readahead problem
or that a modal code from the last line of the program has been applied, even though he aborted before then
I wasn't suggesting that the current interp should be RT'd. I'm just trying to understand the problem space.
but as usual we've strayed far from the subject at hand
consider conditional branches in g-code for example... the interp can't test the condition ahead of time (assuming the condition is some physical thing on the machine, not just a variable in the g-code)
jepler: yeah, I tend to stray
Well, right now, there aren't many inputs to the interp.
I'm always trying to figure out the general problem, and I usually get nowhere
(Although I'm in favor of adding the ability to have more).
certain other people just attack a subset of it and get things working
lerman: the key to using g-code subroutines to do toolchanges (for example) is exactly that - the ability for g-code to test machine status
but that brings us right back to the lookahead issue
sometimes the interp can work ahead, other times it can't
No. The reason for the interp to do lookahead is so that it doesn't stall the pipeline. But there is no pipeline (and shouldn't be) in the middle of a toolchange.
iow: "sometimes the interp can work ahead, other times it can't"
some operations can (and need to) be pipelined
others can't and/or shouldn't
The pipeline is so that the tool keeps cutting during changes in direction. We don't want to stop the feed while we are cutting a curve.
Particularly if the material will work harden or if finish is important.
pipelineable operations are really the exception, not the rule
But -- back to splines, we want them to cut continuousousuously (never could get my fingers to type that right).
right, they are in the same class as arcs and lines
you should be able to go line; arc; line; spline; spline; arc; spline; etc
and have the tool never stop
assuming the appropriate G6x mode is in effect
I notice you didn't have two lines in a row -- depends on the angle between them and the tolerance. But if the parts have the same tangent (or mathematically, if the derivatives are continuous) there should be no stops.
actually that wasn't on purpose
I didn't rigorously list all the combinations
After I typed it, I guessed that.
with blending enabled, line to non-tangent line is ok
Should also be OK for arc to arc, arc to spline, etc. Blending is the process of inserting an arc that is tangent to the incoming and outgoing components. (I don't intend the word 'arc' to mean circular arc -- could be a spline, hyperbola, etc)
[add to previous defn of blending -- while maintaining a specified tolerance]
one interesting thing about that endpoint+tangent notation that jepler proposed for G5... it carries the critical info for blending
everything, line, arc, and spline, has endpoints and endpoint tangents, and that is most of what you need to know to blend
jepler: did you lift that notation from someplace? That specification is brilliant... it would be nice if someone I knew could claim credit for it.
normal spline notation is 2 endpoints and 2 control points
the key here is that the control points are specfied as relative to the endpoints
lerman: which notation?
G5 I-J- P-Q- X-Y-?
The idea of specifying the control points as relative to the endpoints.
I made it up, but it's pretty obvious given that gcode already specifies arc centers that way
dang - 55C is HOT to the touch
you can still keep your finger there
not for long
10 seconds maybe
70 is hot to touch
maybe I'm just a wimp
meter says 55C
55C is a bit more than a hot tub :D
fingers say "leggo now please"
maybe I should go boil some water and check my meter
With a small amount of work, I could get the interpreter to handle G5 as an oword subroutine. -- without changing the notation that the programmer uses.
That would be neat for playing.
jmkasunich: 131F.. does that still sound hot to you?
It would get pretty tricky to try to figure out how many segments to use, though.
alex_joni: its not a C/F thing (I use C all the time for electronics work)
its a numbers on display to fingers thing
jmkasunich: oh, ok.. it just seems not that hot to me :)
I'm used to 200C+ welded parts :D
* jmkasunich goes to check the meter
Hi Alex_joni, sorted out problem of spindle-on, after unplugging lead from port and metering output signal was coming out ok, after re-connecting controller everything worked ok. Thank's for your help earlier.
DavidMB: no problem, glad it's working
hope you're happy with emc2 :)
Looking forward to being able to use all the easy config stuff for separate home and limit switches, always a pain with EMC1.
meter works, its just my fingers that need calibrating
water boils at 97-98C, ice is at 3C ;-)
Are you high? :-) That would explain the BP error.
thermal gradient in the probe explains the errors
tip in boiling water, body in ambient - sensor isn't perfectly coupled to tip or perfectly isolated from body
for intensive 3D work (lot's and lot's of small linear segments), maybe a separate trajectory planner with precomputed trajectory would be OK? A simple implementation would have to disable feed-override, but it would give the added benefit of "infinite" lookahead. Some users do complain about the current blending capability (I haven't tested 2.1 extensively yet, but I intend to run some moulds etc later in the spring)
I think anyone worried about TP performance should check out matt timmermans's work before anything else
quickstep? or something else?
I don't think we should settle for anything that doesn't allow feed override changes, for instance, and we should have exactly one planner
no, quickstep is a different ball of wax
I thought so
quickstep ~= emc2 stepgen
but he also changed the trajectory planner in bdi
so what work are you talking about?
he wrote a different planner for bdi4emc, there was some talk about it on the lists a while back
[20:32:03] <alex_joni> http://www.youtube.com/watch?v=MPG-LYoW27E&NR
Re: feed override. Decreasing the feed isn't a problem. Increasing it can be a problem. But increasing the feed *always* takes time. So, are we just talking about degree. How long does it take for each planner to increase to the new speed?
that's about how I felt about it
it reminds me a bit too much of LabView
retractable is a damn cool thin :)
I like the technology of the display/input interface
and it's pretty neat that the yhave blocks with different shapes/codes on them to do different thing - that's very cool
[20:51:09] <anonimasu> http://www.youtube.com/watch?v=0h-RhyopUmc&mode=related&search=
I'd love that UI..
cool - the interface software is open source: http://mtg.upf.edu/reactable/?software
I'd love to have a cad program that worked with that kind of controls..
rather one of thoose multipoint touchscreens..
yeah - those screens are acutally using optical information, I think
it says so on their page http://mtg.upf.edu/reactable/
[20:58:36] <anonimasu> http://www.youtube.com/watch?v=Jm39v_MdnzM&mode=related&search=
pretty cool too
those things are wonderful!!
I'd love a table like that for controlling lighting.
[21:07:30] <alex_joni> http://www.youtube.com/watch?v=DbtJIq3SRcg&eurl=
alex_joni; ... that music is *not* what I was expecting
[21:15:11] <xemet> http://www.youtube.com/watch?v=D4ECEAj3Ob4&eurl=
that system is just begging for accidents and a fault where the poles will rise while the bus is still there
if they had that in the US a laywer would set up a stand right next to it
stupid person hits it, files sues the govt
it's in England, and at least one town has people lobbying/suing to get rid of them
I especially like the second one - she actually accelerates to sneak in behind the bus, whams into it hard enough to fire the airbags
then runs around to the back "oh, my baby"
yeah - oops - what happened?
wow that second one really nailed it
stomped on the gas trying to sneak thru behind the bus
lerman: re feed override: the current approach is that the tp reacts immediately to a new (possibly higher) feed-override. If we wanted a deeper lookahead buffer then I guess we would have to accept a more sluggish response to increased feed override (immediate response to lowered feed-override is probably doable)
Well, sluggish is relative. A few second lookahead would probably be sufficient. If it took a few seconds to react to a feed increase, that probably wouldn't be a big problem.
The lookahead time should be roughly the amount of time to decelerate from the current velocity to zero.
which on any reasonably responsive machine is under a second
a few seconds probably would be a problem for people who use FO
I think the main use for FO is for someone to "tune" the speed
which they do by listening to / watching the machine cut
How is feed hold / resume handle now, I would think it would function nearly the same.
I think feed hold just sets feed override to zero
so when feedhold is released the machine accels at G00 rate until it reaches the Fxx velocity?
it accels at max
G0 is a velocity, not an accel rate
Does anyone have a problem with the tp and short segments with an actual machine currently? I'd be motivated to work on this if there is a real problem, but I won't be able to test on my own machine in a few months still
The discussion started with the question of how many segments a spline should have. I suggested that if we used one segment per servo position update, we could do no better. (more precise). A response was that TP would not be happy because it has limited lookahead and there might be a blending issue. Then I suggested that TP could have as much lookahead as we needed (memory is cheap). The...
...response was that then feed override would be sluggish. And here we are.
blending and FO (plus other user controls) are at cross purposes in the TP
ideal belnding could be as complex as an iterative operation over the entire file, but that has zero compatibility with user overrides
I asked (but didn't get an answer) how circles (arcs) are handled. How many segments are they broken in to.
so I suggested a blend mode which does not allow FO>1
lerman: a circle is an 'intrinsic' move that the tp knows about
circles aren't borken into segments
it knows about lines and arcs
the only "segmentation" is that there is only one velocity update per planner period
a circle is well behaved mathemetically - if you know you have to stop at the end, its not hard to figure out when to begin slowing down
But the servos (or steppers) know only line segments. So in that sense, they are broken.
How long is a planner period? Is that the same as a servo cycle?
yes, but the motors themselves don't let you do a step change in velocity
true, but I'm not talking about that - thats basically just sampling the path at the servo rate
I'm not sure. I think it is, but it doesn't have to be
yes, but an arc is only one entry in the tp stack of commands, not many small line segments
Once upon a time there was a blurb in the fine print about FANUC specs which advised that the machines repeatability spec was only valid up to 159 IPM and that there would be following errors when FO was used in high speed contouring.
So arcs don't drive the TP crazy.
this was circa 1908
although if you put a bazillion very short arcs together in a row, it would be just as bad as a bazillion lines
in fact, you may only need 0.9 bazillion arcs, since the computational loadis a little higher with arcs
has anyone been in touch with Les Watts recently?
It isn't a computational load issue -- it's an algorithmic lookahead issue.
it may be good to see if he's interested in doing some EMC2 testing on his high performance machine ...
I seem to recall that he was interested in the issue.
And had some ideas.
I think the problem now is that the stack of canon commands (linear or arc) are processed in RT, so throughput there becomes a computational load problem.
awallin: the bottleneck is getting loads of small lines from userspace to rt
I'm pretty sure there are spline types that have relatively easily calculated lengths
and lookahead which emc2 doesn't do that well
if you dissallow FO, the whole trajectory can be precomputed, no processing of canon commands needed in RT
That shouldn't be. Just use a somewhat larger buffer and transfer more lines at a time.
lerman: I think it's one / cycle now
remember that there are G-code files that are in the gigabyte range. preprocessing isn't a good option for those
still, when processing the canon commands, currently it's not possible to process more than one command per cycle
One 'problem' is that we must design for the worst case -- lot's of sjprt lines at large different angles at high speed.
so if you have close to, or over one linear segment per cycle (thats 1000 segments/s if TRAJ=0.001 I think) there will be a problem
But most of the time it really isn't an issue.
sjprt => short
we just need a realtime CAM algorithm :)
how does that solve anything ?
you can change the model in realtime, and have the achine make the new design :)
the only problem is adding metal :)
Why can't we preprocess gigabyte GCode files? Disk space is cheap.
SWPadnos: that's genius!
Remember that the TP problem is essentially one of assuring that we run at maximum feed consistent with the tolerance and feed rate constraints.
there's always some problem. one is time: if it takes 50 ms to preprocess a line, and there are 20 million lines in the file, it'll take ~12 days to preprocess
50ms is ages
even at 1.2 ms (just longer than the servo rate, it's ~1.5 days
thats 60000000 cycles on my machine
It clearly should not take longer to preprocess than to actually process. So, that would assume a machining time greater than 12 days.
it's OK for the machine to take that long (it has to), but to make someone wait for the preprocessing would be bad
the only reason for preprocessing is that you can't meet the RT deadlines for processing
When we precompute the TP, we could also compute it for the case of differing (increasing) feeds.
so it must be longer to preprocess than to process
SWPadnos: how about the problem with more than one segment per cycle?
good idea - I thikn I'll grab a bite
it doesn't necessarily take longer than one cycle to process a short segment, you just need them at a throughput higher than one segment per traj cycle
No. Batch processing could (should) be faster than RT. Also, RT must handle the worst case, while batch just takes longer to do it.
At any rate, the preprocessing was just a thought experiment. A few second lookahead would be more than enough.
you can't have more than one segment per TP cycle - the only way to get higher throughput is to collapse multiple segments into larger single segments
(and/or speed up the TRAJ loop)
SWPadnos: that's how it currently works, and I agree that programming more than one segment per cycle is not a great idea...
these ideas come up pretty regularly, and it seems there's a pathological case that screws up any of them :)
When you get to the point that one segment per TP cycle isn't fast enough, you need faster servo cycles and (possibly) a faster machine.
awallin, it's not possible - you can only generate one endpoint per TRAJ cycle
Les was looking at that, I think.
so you can't have multiple segments per cycle
yes, Les was looking at that
he specifically wanted to use PCI cards because the ISA ones can't seem to support a fast enough servo loop
I've got to get some work done. I'll see you later.
Les Who?! Surely you can't be speak of Les Watts
(he maxed out at ~2 KHz for ISA, but someone had done 8 KHz with the PCI version of the same card)
Yes. Les Watts.
The problem is that the fast machines still have long latencys. The x86 seems to be designed for throughput, not latency.
lerman: No, no, no... Les Watts is just a figment of your imagination.
recent versions of the x86 certainly are designed for throughput at the sxpense of latency
I'd expect the AMD cores to be batter for latency, due to the very deep pipelines of the P4
I haven't tested that theory though
(I have no recent Intel chips :) )
SWPadnos But have you tested the touchscreen
How fast are the fastest power PCs?
if you can get 50khz i/o from a parport, how is it a problem to get 8khz servo update rate?
lerman, the ones with 20 cores, or the ones that humans can afford?
fenn, you aren't using FP in the thread that deals with the parport, and it's only 2 or 3 bytes of I/O
a full servo cycle will be many reads and writes
err - getting / sending full servo data is many reads/writes
hm i figured it'd be only one read and one write
look at the USC - that takes ~50 uS for a full update on 4 axes
no - you need to read position and digital inputs, and write DACs and digital outputs
for each axis
SWPadnos: You saying that a dual cpu/core will yield less latency?
yes but you can do all the reading at once and all the writing at once
SWPadnos ok, carry on
so with "burst" mode like epp you can just dump it all in one go
er, two goes
fenn, yes, but since ISA is just like that parallel port (except for width), it still takes ~1 uS per read or write
SWPadnos and PCI instead of ISA?
yeah that's what i'm saying
Jymmmm, yes - that's what I was saying is faster
How fast is a modern FPGA? One that I could program a processor in.
lerman, a $20 FPGA or a $10000 FPGA? :)
the processor would be slower than a real hardware processor
Are there $10000 FPGAs?
I haven't seen any on the market for more than $12k or so
(i guess it always goes up if you have the money to pay)
Damn. I'm in the wrong business :-)
fpga for $10K, better come with a free BJ attatchment
they're too small
What sort of mill do I need to make FPGAs?
a micromill, of course ;)
I'm using pico systems boards. I suppose that doesn't count.
SWPadnos: weren't we going for dinner? Who's buying?
I'm prolly going to get a USC at some point... I still have to finish the motor mounts...
lerman: softcore cpu's can go into hundreds of megahertz
Well, almost done rewiring the machine... just need to find/order the crimpers
I was going for dinner. thanks for reminding me :)
lerman, where are you located?
A pair of pliers and a soldering iron work OK in a pinch.
ah -close to here but not that close :)
SWPadnos: I'm closer :D
In that case, I'll offer to buy (if you drive over). :-)
hmmm - to what? ;)
I'm off (for dinner).
lerman, it's a deal :)
see you later
lerman: Yeah, but I've spent so much time making it nice energy chian, split loom tubing, etc, I'd like the molex connectors to have a nice crimp as they also have a bit of strain relief too.
use a strain relief then
fenn I am, as soone as I buy the crimpres =)
* skunkworks hates crimp connections/
crimp and solder?
solder = brittle
thats what the strain relief is for
crimp = yeck :)
its just me.
Plus I'll be able to use the crimpers on the other driver box I have in mind if I get geckos.
I crimp my spade connectors and then solder them.
[22:29:39] <SWPadnos> http://www.ch601.org/resources/crimpsolder.htm
wife says I am an 'over doer'. I have no clue what she is talking about
skunkworks buy good crimpers and you won't need to do all that =)
not $0.99 flea market specials =)
[22:31:00] <alex_joni> http://www.automarket.ro/img/db/article/001/669/240986l.jpg?ts=1170244434
alex_joni that is so bad
D'Vinci Forgiato Radurra clear polycarbonate wheels
[22:31:46] <alex_joni> http://www.ministryoftech.com/2006/11/02/d.vinci-forgiato-radurra-clear-polycarbonate-wheels/
that is cool :)
ohhh - I want those for my car
- a small mill seen at Cabin Fever. bbl
I wonder if that wieghs less that a light aluminum rim.
jtr, it even has a rear shaping head :)
wondr if it's functional
lexan is very strong, so it's entirely possible that the car is drivable
[22:35:12] <xemet> http://www.craftsmanshipmuseum.com/Spielmann.htm
I mant the mico BP
look at this 5 axes "desktop" mill...
oh that - I was wondering the same thing
there was a switch, so I'll bet the spindle turns
[22:36:08] <xemet> http://www.craftsmanshipmuseum.com/images/SpielCin2.JPG
on the solder/crimp discussion: good soldering is worse than good crimping in situactions where the wire may flex
though I can't find the paper that told me that
you can tell why though: when you solder, you make a very stiff area in the wire (I'm assuming stranded here)
[22:38:29] <alex_joni> http://www.automarket.ro/img/db/article/001/661/308896l.jpg?ts=1170195176
all flexing occurs at the end of the stiff part, causing that to break
swpadnos: I understand - I just don't have to like it ;)
SWPadnos: that's what I read/told
a crimp has a longer region over which the bends can occur, so there's less stress when ther wire flexes
ok. now it's really dinnertime
[22:40:14] <xemet> http://www.wreckedexotics.com/newphotos/exotics/
I used to solder only the wire on the ring side of the crimp
try not to let it wick up past the crimp
to get the best of both worlds
they should put some goldfish inside those wheels
fenn: poor goldfish.. doing 90 on the freeway
Alex: those tow bikes better have additional brakes in that towing attachement...
alex_joni: I uploaded this just for you.... http://farm1.static.flickr.com/139/394582911_56f5e93028_o.jpg
Ford on top!
I'm thinking of buying one of these... http://www.atacom.com/program/print_html_new.cgi?&USER_ID=www&cart_id=1369934_69_226_27_69&Item_code=NASX_ATAC_NA_00
but.. why do you need 1.5TB raid?
Ah, media jukebox.... I already finished making the TVPC w/ IR kybd/mouse
oh, a media jukebox..
how silly of me
we have filled up a .5TB server at work with art files. - They need them all - or so they say.
* Skullworks is old school - all u160LVD SCSI raids.
mass storage on the backend.
Skullworks But I can get 500GB SATA drives for $50/ea
Skullworks There's a catch
care to share the wealth?
(there always is...)
Skullworks: Like I said, there's a catch... These drives have had a program called thrasher on them, so their integrity is questionable, no warranty, thus the RAID5 to CYA =)
and I thought I struck GOLD when I was able to buy the 74GB Cheetahs @$40
what was thrasher?
a MTBF test program?
The company gets HDD's buy the pallet for testing purposes in their products. They do crash and burn testing.
I found a SATA RAID5 card for $300 or this NAS RAID5 box for $500 that's self-enclosed and ready to go.
I'm tooo cheap
Well, 500GB is ~$200 x 4 = $800 drives alone, or NAS box $500 + $200 HDD = $700 ready to go.
I'd just grab a spare PC case, chop off a molex connector and solder in 2 load resistors on the 5V line...
thats a quick and cheap drive enclosure
Skullworks It's not JSUT a drive enclosure, it's a RAID5 nand NAS built in.
make some rear panel connector ports for the sata cables
true - mine has to sit beside the host unit - not NAS
You just plug it into the router and it's online.
no computer to attach it to.
although my SCSI raid is 12ft away
I used NAS - it bogs terrible when doing vid editing
This box also has USB ports in the back as well
my 64bit 39160 running parallel channels dumps data sooo fast
800mb CD iso = 3 sec
* also getts his house heat by SCSI in winter.
Summer is... HOT
I don't fire up the extra RAIDs in summer unless I have to.
HARDWARE Question ?
what is a prefered Vid card that plays well with RT?
Skullworks: most not onboard
but stay away from NVIDIA and ATI drivers
if you have a board like that use the open source driver
Current EMC2 box has a ATi Rage-128XL 8m agp
driver is whatever the Ubuntu install popped in during the Breezy install
all my hardware is old
I build junkyard monsters
then I think it should be just fine