Back
[10:08:45] <cradek> I really like how rellenberg notices the ways people before him were clever, instead of reveling in the ways they were stupid or laughing at them for not adequately knowing the future
[10:13:40] <skunkworks> Yes - he seems to be very impressed with the current work :)
[10:14:34] <skunkworks> if you can acellerate through the current parabolic blend - why can't you just use that?
[10:15:34] <skunkworks> (keep adding segments and increasing the velocity)
[10:16:04] <cradek> I do not really understand why he's working on arcs
[10:18:15] <skunkworks> My impression is that he can then easilly calculate the position or whatever at any point. (maybe it is harder with parabolic bland?)
[10:18:49] <skunkworks> bland? heh
[10:19:23] <cradek> it's true with the blend the position is ... emergent? rather than calculated directly
[10:19:52] <cradek> but calculating all the blends directly is very hard
[10:20:12] <cradek> so you have to handle the hard cases separately (by fixing up the current algorithm I guess)
[10:20:54] <cradek> so once you've done that, why did you calculate those arcs again?
[10:21:29] <skunkworks> I think it is neat that he is planning on using the current blending when he can't figure out a better way
[10:21:56] <cradek> it's definitely a pragmatic approach
[10:22:44] <cradek> I'm a bit afraid of a "now you have two problems" type of problem though
[10:23:14] <cradek> we'll see what he comes up with, I trust him :-)
[10:25:19] <seb_kuzminsky> https://plus.google.com/103982631119479761813/posts/KHWEV8iJe9q
[10:26:09] <cradek> that can't be the right way to get support
[10:28:48] <seb_kuzminsky> what, post to g+ so some random guy reposts to an unrelated irc channel? seems legit
[10:32:52] <cradek> the WTF is a nice touch
[10:33:02] <cradek> click on #MACH3 and you get a semi truck and razors
[10:33:29] <cradek> Explore related hashtags: #Gillette
[10:33:43] <cradek> yay for social media
[10:38:38] <skunkworks> heh
[10:39:10] <skunkworks> well - rob just explained on the list what we where talking about. ;)
[10:42:01] <archivist> I wonder if there will be less hate for NML now the debugging got unearthed :)
[10:42:14] <skunkworks> NO
[10:46:30] <cradek> oh I see what he means
[10:46:56] <cradek> I cringe at the thought of calculating line-arc, arc-line, and arc-arc blend arcs
[10:47:41] <cradek> I bet helixes are rare enough that you can not bother optimizing them
[10:47:55] <cradek> but arcs are really not uncommon at all I bet...
[10:49:06] <skunkworks> his table here
https://www.dropbox.com/s/o5he7ijpplkvc8r/Trajectory%20Lookahead%20with%20Arcs.pdf
[10:49:18] <archivist> arcs are very uncommon in my code, I love my rotaries :)
[10:49:33] <skunkworks> show he is thinking about arc - line, arc - arc and line-arc
[10:50:02] <skunkworks> only though when they are coplaner
[10:50:14] <cradek> arc-line isn't in there
[10:50:16] <skunkworks> which most probably are going to be... atleast cam generated
[10:50:40] <skunkworks> hmm - wonder if it is an oversite
[10:51:45] <cradek> I don't understand what coplanar means in this case
[10:54:33] <skunkworks> I just assumed - the line isn't perpendicular to the center-edge of the arc
[10:54:52] <skunkworks> did that make sense?
[10:56:11] <skunkworks> like - a z move coming into a circle in the x-y plane
[10:56:32] <skunkworks> vs a line in the xy plane meeting up with a circle in the xy plane
[10:57:18] <cradek> ok I can see that - any arc is in a certain plane - is the line also in that same plane
[10:57:58] <cradek> but a line is in many planes - every two lines share at least one plane - what does coplanar mean there
[10:58:34] <cradek> er that's why he just has "y"
[10:58:37] <skunkworks> He doesn't state that (asuming because of what you just stated..)
[10:58:38] <cradek> I get it now
[10:58:46] <skunkworks> right
[11:00:42] <cradek> I wonder if he knows that if he uses cutter comp and avoids concave corners he'll get these nice smooth paths made for him
[11:00:51] <cradek> that could be good for testing
[11:09:27] <jepler> I only looked at the centerfold, does he contemplate the case where the primitives are so small that the needed arc join doesn't fit?
[11:10:30] <jepler> somewhere, maybe just in my own dreams, I saw that some control had a g-code to add these arcs automatically. you specified the "miter" radius explicitly, I think.
[11:11:44] <cradek> yes I've seen R-word on G1 somewhere. fanuc10 or boss8
[11:12:57] <cradek> I think in the degenerate small-lines case you'll end up changing the program into the same number of arcs, whose endpoints are the midpoints of the original lines
[11:13:36] <cradek> they may be small, and they're not necessarily planar arcs
[11:13:48] <cradek> by planar I mean in a gcode g17/g18/g19 plane
[11:13:53] <jepler> will that be enough to get to high speed, with his other contemplated planner changes?
[11:16:45] <jepler> it seems like the hard cases can be done by biarcs (two arcs which have given direction and position at both endpoints, and G1 continuity where they join)
[11:17:59] <cradek> his table has some "two arc solution but yuck" in it
[11:18:02] <jepler> yeah
[11:18:20] <jepler> he contemplates being able to give the radius as an input
[11:18:34] <jepler> with biarcs you would pick the blend points and "suck up" the radius of the arcs you get back
[11:18:51] <cradek> I wish he'd hang out here more :-/
[11:18:53] <jepler> or do a rudimentary binary search or something
[11:27:41] <cradek> the planar line-line line-arc arc-line arc-arc calculations are going to be almost the same as the ones that cutter comp already knows how to do
[11:28:22] <cradek> er no, it does fixed radius, he'll want fixed divergence
[11:28:44] <cradek> and ccomp errors when the fixed radius won't fit, he'll have to shrink until it fits
[11:28:54] * cradek rambles to himself
[11:29:44] <skunkworks> that's ok - it is quite interesting rambling.
[11:31:24] <archivist> what about a helical path along z into material followed by an arc on the xy plane
[11:32:07] <cradek> ccomp handles that fine
[11:32:24] <skunkworks> helical-arc or arc helical...
[11:32:48] <cradek> being a helix makes it no harder - you just project it onto the plane and you can find the endpoint the same way
[13:59:43] <mozmck> cradek said: "I really like how rellenberg notices the ways people before him were clever..." -- agreed! I wish some of the modern UI designers were more like this. Pretty soon we'll all have nothing but blank screens because anything else is cluttered and distracting. And who needs to options???
[14:00:09] <mozmck> Just because it's "old" doesn't mean it's bad.
[14:00:53] <mozmck> </end rant> :)
[14:11:18] <andypugh> Why do people on forums assume that if you have a different opinion to them that it is because you know less than them about the subject, rather than more?
[14:12:10] <andypugh> (An electrical engineer is pointing me to books on basic electrics...)
[14:14:16] <skunkworks> heh
[14:15:55] <andypugh> It is likely that he does know more, but his basis for stating that acccelleration can't change instantaneously is that acelleration is analagous to current, and current can't change instantaneously. Which is a) not true for a pure resistive load and b) a bad analogy anyway.
[14:21:24] <jepler> how long does it take for a photon to accelerate to 'c'?
[14:22:00] <jepler> the totally ideal resistive load driven by a magic voltage source has got to be a lot like accelerating a zero-mass object
[14:22:13] <jepler> I mean, as long as we're drawing dubious parallels
[14:24:46] <andypugh> We are talking about Jerk, and AFAIK there really is no limit to that.
[14:25:50] <andypugh> Consider just dropping something. When you let go, it has an accelleration of g. Before you let go, it doesn't.
[14:26:17] <jepler> I dunno, it seems like whatever argument you use to show there can't *really* be a step change in velocity could be applied to the step change in acceleration that "is" infinite jerk
[14:26:21] <jepler> and so on, in inductive fashion
[14:26:28] <andypugh> In practice letting go takes a finite time, because fingers are squishy.
[14:27:31] <andypugh> The existence of mass (and inertia) precludes an instantaneous change in velocity. What is the time-derivitive version of mass?
[14:42:05] <alex_joni> jepler: shouldn't the src/hal/Submakefile have $(TCL_LIBS) for the linking of ../tcl/hal.so ?
[14:43:35] <jepler> are you just idly speculating?
[14:43:46] <jepler> or have you encountered a problem?
[14:44:18] <alex_joni> encountered a problem
[14:44:46] <jepler> the first "other" Tcl extension I got my hands on, tkimg, doesn't link with tcl or tk according to ldd
[14:44:48] <alex_joni> but since I'm compiling on a non-supported platform, I just care about telling someone.. not actually changing lcnc code for it
[14:45:08] <alex_joni> I'm compiling under cygwin
[14:45:38] <alex_joni> and if I don't link against the tcl stubs lib, I get some undefined reference to 'tclStubsPtr'
[14:47:16] <jepler> all I know about windows linking is that it is irritating and different from unix
[14:47:29] <alex_joni> I agree
[14:47:44] <alex_joni> but still from a theoretical point of view, it should have that linked..
[14:48:03] <alex_joni> as hal.so contains halsh.o (which provides tcl extensions..)
[14:48:11] <jepler> in unix, the undefined symbols in _hal.so will be resolved when the module is loaded into a running tclsh
[14:48:26] <jepler> in windows maybe the rules are different
[14:48:27] <alex_joni> ah, ok
[14:48:37] <alex_joni> the errors I got where during linking time
[14:48:40] <alex_joni> not during run time
[14:49:46] <jepler> but anyway, we do sometimes specify it when linking Tcl extensions and it doesn't seem to be harmful
[14:49:58] <jepler> so if you want to push that bit of your cygwin-specific change into master branch I don't have a problem with it
[14:50:00] <alex_joni> otoh, it's been working for so long..
[14:50:31] <jepler> errr interesting
[14:50:43] <jepler> if I remove it from SETICONMODULE or TOGLMODULE I get a runtime error
[14:51:05] <alex_joni> hmmm
[14:51:27] <jepler> ImportError: /usr/local/jepler/src/linuxcnc/lib/python/_tk_seticon.so: undefined symbol: Tk_NameToWindow
[14:51:45] <jepler> ImportError: /usr/local/jepler/src/linuxcnc/lib/python/_togl.so: undefined symbol: tclStubsPtr
[15:02:41] <jepler> (_tk_seticon shouldn't be necessary now that tk8.5 has [wm iconphoto] and I should also check whether the libtogl1 packge works properly on current distros)
[15:02:49] <jepler> (heck, maybe reevaluate minigl while I'm at it)
[15:17:08] <alex_joni> it wasn't my intention to make you spend time on this..
[15:38:27] <alex_joni> jepler: still around?
[15:38:52] <skunkworks> logger[mah]:
[15:38:52] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-10-24.html
[15:38:53] <alex_joni> I'm running into a similar issue with librs274.so.0
[15:39:09] <jepler> you may not be able to solve that'un
[15:39:10] <alex_joni> it's missing references to the CANON stuff, since that's not linked in
[15:39:18] <jepler> it explicitly depends on providing the callback functions from the main program
[15:39:33] <jepler> or from whatever is loading it (gcodemodule.so)
[15:39:54] <alex_joni> do we use it for something else?
[15:40:11] <jepler> task, axis, rs274 standalone interpreter all link to it
[15:40:13] <alex_joni> cause I can skip building librs274, and just build the gcodemodule with all the .o's in it
[15:40:25] <jepler> sure, that's one approach that could work
[15:40:45] <alex_joni> providing stub implementation won't work, I imagine
[15:41:00] <alex_joni> as I get double implementations when linking with the main program
[15:41:11] <jepler> yeah I expect so
[15:41:30] <jepler> if it did "work" at link time, I doubt it would call the right one at runtime
[15:43:52] <alex_joni> right
[15:44:27] <alex_joni> so the 'best' way is to skip building librs274 and just have the stuff that uses it include all the .o's
[15:44:35] <jepler> or build it into a .a instead of a .so
[15:45:08] <alex_joni> .a is static, right?
[15:45:12] <jepler> yes
[15:45:21] <jepler> produced by ar instead of by ld or gcc
[15:48:43] <cradek> zultron: thanks for emailing to ask about that.
[15:49:33] <cradek> zultron: this has come up off and on for years now and each time we decide we ought not touch ethercat. it's sad but there it is.
[15:53:12] <alex_joni> jepler: another short question.. I can't include liblinuxcncini.so in librs274.a right?
[15:53:40] <jepler> if librs274.a uses it then you'd have to link it in whereever you link librs274.a
[15:53:45] <jepler> you can't link a .so from a .a
[15:53:59] <alex_joni> right.. that's what I thought
[16:01:13] <zultron> Sure, cradek. Glad andypugh and jepler brought this up before I sunk a lot of time into EtherCAT kernel module packages. It is a sad situation, indeed.
[16:02:01] <zultron> Seems like a culture clash between the hardware industry and FOSS communities.
[16:19:51] <alex_joni> jepler: another (hopefully last) question: where do the comp.mak files get generated?
[16:21:02] <alex_joni> disregard that.. :)
[16:22:13] <jepler> alex_joni: "in some Submakefile" was the only answer I could come up with without looking
[16:23:32] <alex_joni> yeah, it was in fron to f my eyes
[16:23:38] <alex_joni> front of*
[16:29:05] <alex_joni> hummm.. comp uses 'hal_export_funct' in the generated abs.c (for example)
[16:29:16] <alex_joni> but hal_export_funct is only defined for RTAPI
[16:38:50] <cradek> zultron: glad you didn't waste your effort on it. their position is baffling to me, and that they keep saying "but the license doesn't cost anything!" just means they are clueless about FOSS.
[16:39:22] <alex_joni> clueless but they don't really want to do anything about it
[16:43:58] <cradek> it may be the right decision to further their non-freedom-related goals, which would be all of them
[16:44:01] * cradek shrugs
[16:44:19] <cradek> our simple remedy is to not use it or spend our time on it
[16:44:32] * alex_joni compiles another lcnc-sim
[16:50:50] <alex_joni> jepler: do you happen to know who provides RTAPI parts of hallib on a simulator build?
[17:28:37] <KGB-linuxcnc> 03andy 05v2.5_branch 24dc2a2 06linuxcnc 10docs/man/man9/lcd.9 10src/hal/components/lcd.c
[17:28:38] <KGB-linuxcnc> Fix a bug caused by misunderstanding do_div in the lcd.comp
[17:28:38] <KGB-linuxcnc> If no format length was specified then the formatting would break for any value with a zero in its representation.
[17:28:38] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[17:28:39] <KGB-linuxcnc> Fix some bugs in the lcd component
[17:28:41] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[17:29:41] <andypugh> Ah, I squashed the commits, but not the comments. No matter
[17:36:29] <linuxcnc-build> build #1422 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1422 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:38:07] <linuxcnc-build> build #1423 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1423 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:38:07] <linuxcnc-build> build #1425 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1425 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:38:07] <andypugh> <confused> The main change was taking out some do_divs!
[17:38:41] <linuxcnc-build> build #1424 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1424 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:38:45] <linuxcnc-build> build #1426 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1426 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:39:13] <linuxcnc-build> build #1424 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1424 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:40:59] <andypugh> In case you are wondering I _did_ compile and test this before pushing it!
[17:46:48] <linuxcnc-build> build #1220 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1220 blamelist: Andy Pugh <andy@bodgesoc.org>
[17:48:46] <alex_joni> andypugh: I notice only sim's failed
[17:49:40] <andypugh> Indeed. It seems to not like u64, but there were other u64s in there all along. The only new thing is that the new u64 is in a function declaration.
[17:54:20] <jepler> there are uses of __u64 in lcd.c before that commit, but I didn't see any lone u64
[17:54:36] <andypugh> Line 496?
[17:55:49] <andypugh> I just configured for sim. I will see if it goes wrong here too.
[17:56:11] <andypugh> Annoyingly I just changed the firmware on the 5i25, so the lcd screen won't even work now.
[17:56:25] <jepler> your last commit introduced that u64 as well
[17:56:26] <jepler> - unsigned long long tmp = 0; //enough bits for 9 decimal digits.
[17:56:29] <jepler> + u64 tmp = 0; //enough bits for 9 decimal digits.
[17:56:39] <andypugh> Ah.
[17:56:59] <andypugh> My mistake then. I was _trying_ to make the code more robust.
[17:58:04] <andypugh> I am still unclear on when to use __u64, _u64, u64, unsigned long long....
[18:02:47] <andypugh> OK, I now have it so that sims compile. So now i have reconfigured for realtime to make sure _that_ still compiles.
[18:03:13] <andypugh> It's rather frustrating when code that absolutely can't be used in a sim breaks the sim compiles.
[18:09:04] <jepler> then should it be moved to drivers/ ?
[18:09:31] <jepler> I wish I remembered what went wrong the last time I tried to introduce use of the C99-style <stdint.h> names everywhere
[18:09:41] <jepler> uint64_t and friends
[18:09:42] <jepler> bbl
[18:09:47] <andypugh> Well, actually, I guess that component will _work_ in a sim
[18:11:15] <andypugh> It was written to support the 7i73 (which clearly won't work in a sim) but if anyone wanted to format hal pins one character at a time, they could use it for that.
[18:13:17] <linuxcnc-build> build #1426 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1426 blamelist: Andy Pugh <andy@bodgesoc.org>
[18:18:37] <KGB-linuxcnc> 03andy 05v2.5_branch 2ba536e 06linuxcnc 10src/hal/components/lcd.c * Un-break the sim builds (well, I can hope)