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