I finally understand execution flow in tpRunCycle()
I've located two places that must be modificated to fix arc blending bug
now I must read some theory and make some drawings :)
sounds great, I always have to make drawings too :-)
maybe by the way I'll be able to define some interface to adds curve acceleration to tp
If I had more time :)
micges, if you describe the problem, may be I could help?
do you remember talk about arc blending here 30.03?
yes, I've seen pic you posted
aystarik: so you have emc2 source around?
at line 975 is first blending condition
nexttc && nexttc->maxaccel
in this condition there is calculated velocity for blending
this whole condition is correct only for line->line
for arc->line, arc->arc, line->arc there must be added other conditions
actually it looks not right even for line-line... S = (at^2)/2 => t = sqrt(2S/a)
so what is needed is for the blending to be based on the lines tangent to the ends of the arc?
v = ta = a * sqrt (2 * S/a)
mozmck: no, that's the mistake it currently makes
oh. what then?
is it a mistaken idea or a mistaken implementation of the idea?
mozmck: that is exactly the question at hand :-)
SWPadnos: mistaken idea
I think the implementation is correct and very well tested
it seems just incomplete, thinking about accel limits
I have some papers somewhere about blending I think. maybe y'all do to...
but I don't know what I'm talking about, so ...
(I'm glad I drew a picture and explained the derivation of this, yay me)
mozmck: pastebin those docs if you can
cradek: where's the picture?
micges: I'll have a look for them. They are pdf I think.
it is found by reading the comment in the code. it's a not-very-good treasure hunt.
cradek: siemense is able to do 8 axis nurbs and cubic splines.
(picture is in that same directory)
is it xfig&
micges: I think I may be remembering stuff out of some papers on traj planning. Most of what I have is linked on the wiki somewhere
the Sonia paper?
that has some I know
back to work...
"3-Axis CNC Path Planning Using Depth Buffer and Fragment Shader" ?
that sounds quite nutso...
hm, one more task for graphics card :)
sure, I'll take one
waiting for Fermi to start...
SWPadnos: here you go http://en.wikipedia.org/wiki/OpenCL
I bet papers describing totally different planning algorithms aren't going to help micges.
Fermi is finally out, but the first reports are that it's not a major improvement over the faster HD5000 series
cradek, it has some bibliography at the back
newegg will have it by 16.04, before that it is not "out" :)
it has doubles only 2 times slower than float.
I did notice that NewEgg is all out of stock
wow. a lot more part numbers than there were a day or two ago
still all out of stock
ries_ is now known as ries
[19:59:04] <aystarik> http://www.isd.mel.nist.gov/projects/rcslib/posemathdoc/PoseMathCpp.htm
I think there have been a lot of changes to posemath since the NIST days
specifically, I think it's actually C++ now :)
no, same c/c++ mix
isn't it already used in emc2?
yes, this is description of it.
I wonder if the changes I'm thinking of were on the BDI branch
then again, it could just be that the callers were changed to use C++ instead of messing with the C versions
does anyone have segmentqueue.pdf paper handy?
I recall it's in the emc1 cvs somewhere
I've talked with pcw about spi in hm2 to connect 5i20 to 7i65
it seems that only driver support is needed
am I right?
micges: i think so
cradek, what is emc1 cvs? where is it?
[21:33:16] <alex_joni> http://emc.cvs.sourceforge.net/viewvc/emc/emc/
[21:33:50] <alex_joni> http://emc.cvs.sourceforge.net/viewvc/emc/emc/doc/segmentqueue.pdf?view=log
Thu Dec 30 23:22:54 2004 UTC (5 years, 3 months ago) by cradek
wow how time flies
fwiw I think segmentqueue in emc1 does actually run and work right
[21:39:27] <aystarik> http://www.springerlink.com/content/r84g0lv1275xk396/
-- one more paper on subject
can't exactly tell from the first page but that appears to be the same thing I wrote or extremely close
I'm just trying to understand what you wrote :)
well sorry about that :-)
micges is exactly right about what needs to be done to fix the arc problem though
I once wrote for Google solver for 15-game... it's fun :)
because that code has lost any original beauty it once had, long since traded for functionality
why it is C and not C++?
because C is the language it was written in and C++ is not
I already found how to shave off couple of cycles... interested?
also because it's realtime kernel code and I don't think you can even use C++ there if you wanted to
ok. kernel is no fun... :)
they somehow put floating point inside... no-no in generic linux kernel ...
seb_kuzminsky, do you remember anything about our discussions of an SPI module interface?
I think we may have talked about making a SPI driver block that would export pins for the in/out data, and maybe a strobe and data_ready line for handshaking
SWPadnos: that was one interface we discussed, i prefer a different one (that we also discussed)
ok, so you do remember :)
I don't - was wondering if what I have in mind now makes any sense
i'd prefer a binary interface outside of hal, down inside the kernel
something a bit similar to how the generic hostmot2 driver accepts connections from many different anyio-board drivers
so then the question is whether we want to think about supporting e.g. multiple SPI interfaces (from different hardware drivers) at the same time, and how that would work with the "client" modules
similarly, an spi-port driver inside the hostmot2 driver would accept connections from spi-device drivers (which would be separate driver modules)
ok - that's more or less what just popped into mind. there would be e.g. a 7i65 (?) module, that would link to the "hostmot family" and would directly call various SPI functions
another example of this kind of interface is that parport driver in linux, and drivers that talk over the parport to devices plugged into the parport
yep, the bus/device model
i think there should not be a "7i65" driver, there should be several small drivers for the various spi devices on the 7i65
AD5754 DAC chips, AD7329 ADC chips
do they share the same SPI channel?
(I should look at the specs some day)
they use the same data in, data out, Clock and Frame pins, but they have different chip select lines to enable the different devices
ok, in that case I think they should share the same SPI driver
that way, there are no sharing issues with the SPI "port" itself
i disagree, i think
and the driver may be able to do things like optimize transfers so that you have outbound data transferred simultaneously with inbound
(multiple chip selects active there)
the driver for the ad5754 chip should not be mixed up with the driver for the ad7329 just because the 7i65 puts them both on the same bus
I'd agree with that completely if you would substitute the word "code" for the word "driver"
the spi bus driver (which'll be implemented as a part of the hostmot2 driver) should have an interface rich enough that different spi-device drivers can share an spi-bus
that would of course be ideal, but I think it's a pretty high standard, and may be overly complex
consider several chips connected together serially, with one (or no) chip select
unless you only support MOSI/MISO style, not chained devices
(I shouldn't have this discussion while I have a cold :)
hm, i hadnt thought of chained devices...
seb_kuzminsky: do you have any docs or regmaps about spi in 5i20?
ah yes :P