Back
[09:10:32] <cradek> skunkworks: because of robert302's being sad that he wrote something we already had
[09:10:58] <cradek> I hope he's not frustrated - continuing on the comedi part would be great
[09:11:21] <cradek> oh he's back!
[09:11:32] <cradek> Robert302: sorry to talk about you like you weren't here
[09:12:31] <archivist> someone else used comedi and linuxcnc a year or two back
[09:12:35] <seb_kuzminsky> i've often thought it'd be cool if we could use all the comedi drivers
[09:12:57] <cradek> absolutely
[09:13:07] <seb_kuzminsky> i didn't know comedi already used rtai, that's great news
[09:14:14] <CaptHindsight> no cncfest this year?
[09:17:10] <cradek> I don't know of anything
[09:19:00] <CaptHindsight> cradek: the camview and camunits just need the extra plugins packaged for 12.04, everything works for 10.04
[09:19:50] <CaptHindsight> the howto just needs to be cleared up
[09:20:13] <cradek> that sounds like good news
[09:20:46] <CaptHindsight> you just add the repos, install the packages and modify 2 lines in the .ini for Axis in 12.04
[09:22:02] <cradek> so only updated docs are needed? or is everything fine?
[09:22:43] <CaptHindsight> I still have to test 10.04, but it works fine on 12.04
[09:24:09] <CaptHindsight> but the howto needs some clearing up since it skips steps for the non Linux savvy
[09:24:34] <CaptHindsight> and the info is a bit scattered vs step by step on one page
[09:25:14] <cradek> terrific
[09:25:20] <cradek> thanks for looking into it
[09:25:42] <CaptHindsight> I'll check on 10.04
[09:27:42] <CaptHindsight> camunits has a few plugins now for cross hair and circles, the next step will be to have an easy method for users to add additional plugins for image processing
[09:28:47] <CaptHindsight> edge detection, contrast enhancement, thresholding etc
[09:29:39] <CaptHindsight> i have to work on this anyway so I'll see about what I can put together
[09:30:04] <CaptHindsight> maybe another repo just for plugins and extra features
[09:30:39] <cradek> I'm not good at writing docs, but I do know some things about packaging. yell if you need help.
[09:40:50] <Robert302> hello, no i'm not frustrated ;-P. I only wan't to change my data logger to the already existing real time part of the halsampler because i think it's great to use existing parts. But the userspace part does not exist until now because i send the data from the "halsampler" via tcp to a matlab project.
[09:42:01] <cradek> great, I agree with your judgment and plan
[09:42:28] <Robert302> Today i started working with an comedi driver which should work for every kind of card so i allocate memory depending on the type of card.
[09:42:39] <cradek> awesome
[09:44:10] <Robert302> but it will take some time to create and test it because I'm a little bit busy now because i have to write a documentation about my measurements. I think i will have a tested version in 3 weeks around
[09:45:03] <cradek> we will be here!
[09:45:09] <Robert302> all right 09
[09:45:12] <Robert302> =)
[10:50:43] <seb_kuzminsky> Robert302: i like the idea of reusing existing stuff instead of rewriting it
[10:52:17] <seb_kuzminsky> to that end, did you see that the existing halsampler userspace program writes the data it gets to its stdout by default?
[10:53:12] <seb_kuzminsky> so you could do something like "halsampler | nc matlab.example.com 1234"
[10:54:06] <seb_kuzminsky> or if you need to transmogrify the data format, a thin shim that works on stdio: "halsampler | transform-data | nc matlab"
[10:54:11] <seb_kuzminsky> just a thought
[11:53:38] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 fe00c88 06linuxcnc 10docs/man/man9/hostmot2.9 docs: fix a formatting error in hostmot2 manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe00c88
[16:39:09] <cradek> memleak: do you know of any trouble with rtai + pae nowadays? we had to avoid pae years ago.
[17:23:56] <mozmck> heh, at 17:50, this die-hard C guy explains why C++ can be so nice.
http://www.youtube.com/watch?v=ON0A1dsQOV0 (He's talking about switching Subsurface from GTK to QT)
[17:42:17] <andypugh> There is a report on the forum that “biquad” segfaults.
[17:42:54] <andypugh> I have tried it once in halcmd / ssh and it did indeed crash. I am repeating the experiment
[17:46:43] <seb_kuzminsky> if the user sets Q to 0, you get a divide-by-zero
[17:46:50] <seb_kuzminsky> same if a0 becomes 0
[17:48:38] <andypugh> Does Q default to 0?
[17:51:19] <andypugh> It seems to use typedefs for no readily apparent reason.
[17:55:25] <andypugh> It is crashing for me with the default values. (ie, Q = 0.7071)
[17:56:45] <andypugh> The option data option seems to be deprecated now. I wonder if it would be more reliable using “variable”
[18:02:21] <andypugh> It checks for Q < 0.5, which includes 0
[18:03:19] <andypugh> It is more difficult to see if a0 can ever be zero. It needs a careful choice of Q, f and sample frequency to achieve that.
[18:10:13] <seb_kuzminsky> since you said 'segfaults', i assume you're running either sim or one of the ubc userspace thread models?
[18:10:37] <andypugh> Sorry, I was perhaps a bit imprecise.
[18:11:12] <andypugh> I have no idea how my setup crashes. The headless PC stops talking on ssh and I have to walk across the room to restart it.
[18:11:35] <seb_kuzminsky> that sounds fun
[18:12:04] <andypugh> The forum roprt shows Axis reporting “fault with vec-14, This fault may not be recoverable without rebooting”
[18:12:43] <andypugh> http://www.linuxcnc.org/index.php/english/forum/24-hal-components/27804-rt-component-biquad-bug#46733
[18:17:59] <seb_kuzminsky> it runs fine for me in sim (at least i haven't been able to get it to crash yet)
[18:18:31] <andypugh> interesting
[18:18:42] <seb_kuzminsky> except i can't get .valid to go True
[18:18:44] <seb_kuzminsky> hm
[18:18:44] <andypugh> I have no idea what branch I am on
[18:19:34] <seb_kuzminsky> haha
[18:20:28] <andypugh> halrun / loadrt threads / loadrt biquad / addf biquad… thread1 / setp biquad.0.enable 1 is a crash every time.
[18:21:01] <andypugh> I have tried recompiling without the data struct (variable int lastEnable instead) and that didn’t help
[18:21:21] <seb_kuzminsky> oh wait, here too, i just didn't notice
[18:21:26] <andypugh> The enum looks a bit strange.
[18:21:30] <seb_kuzminsky> May 8 16:57:24 steel kernel: [575239.353976] rtapi_app[14137]: segfault at 28 ip 00007f23418900b9 sp 0000000000e49ca0 error 4 in biquad.so[7f234188f000+2000]
[18:22:14] <andypugh> does addr2line work in comps?
[18:22:25] <seb_kuzminsky> it should
[18:22:37] <andypugh> (you might need to find a way to keep the intermediate c file)
[18:23:10] <andypugh> I say “you” because it’s past midnight here and I can’t be bothered to reboot that machine again.
[18:23:20] <seb_kuzminsky> np
[18:23:29] <seb_kuzminsky> thanks for pointing out the non-email bug report
[18:42:36] <cradek> seb_kuzminsky: you can turn on SIGFPE and run sim: git grep niftily
[18:58:58] <seb_kuzminsky> hm? that statement was too compact for my dazed post-work brain
[18:59:23] * seb_kuzminsky squints suspiciously at biquad's 'option data Internal'
[19:29:56] <seb_kuzminsky> very pointer
[19:30:03] <seb_kuzminsky> much indirection
[19:30:05] <seb_kuzminsky> wow
[20:05:19] <seb_kuzminsky> it's a bug in comp
[20:05:41] <seb_kuzminsky> i'll push a fix later tonight
[22:03:08] <skunkworks_> logger[psha]:
[22:03:08] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-09.html
[22:08:28] <seb_kuzminsky> f7u12
[22:25:07] <CaptHindsight> cradek: memleak is away for a few days, he should be around next week
[22:25:46] <skunkworks_> seb_kuzminsky: having issues?
[22:28:04] <seb_kuzminsky> skunkworks_:
[22:28:30] <seb_kuzminsky> i found the problem that andy relayed earlier, but it's hard to fix because of how comp generates C code
[22:30:42] <skunkworks_> yeck
[22:40:39] <seb_kuzminsky> comp does some tricks so the .comp author can refer to the hal pins & params as if though they're regular variable
[22:42:06] <seb_kuzminsky> those tricks consist of putting all the hal variables into a struct called __comp_state, and registering the hal functions so that each instance of the comp gets its own version of that struct
[22:42:46] <seb_kuzminsky> then there's some preprocessor tricks that make it so the .comp author doesn't have to care about that, they just use the hal pin name as a variable and all's well
[22:43:07] <seb_kuzminsky> the hal pin name is a #define macro that expands to this instance's __comp_state->pin_name
[22:43:41] <seb_kuzminsky> that's super convenient for the author, and it works great in the functions called directly by hal, such as "biquad.0"
[22:44:00] <seb_kuzminsky> it doesn't work at all in functions called indirectly, because they dont have a pointer to the __comp_state
[22:45:14] <seb_kuzminsky> somehow the comp function called directly by hal (which knows the pointer, because hal told it) must communicate the pointer to any functions it calls (either by argument or by global), or those called functions are not allowed to read or write any of the hal pins
[22:45:43] <seb_kuzminsky> a bug in comp causes a failure to obey this rule to be missed
[22:46:44] <seb_kuzminsky> only biquad behaves this way, no other .comp tries to access hal pins from functions called by their hal functions
[22:47:14] <seb_kuzminsky> i think biquad *never* worked, from day 1
[22:47:32] <seb_kuzminsky> it loads, but as soon as you try to enable it, it calls a function and crashes
[22:47:45] <seb_kuzminsky> it's bizarre
[22:47:47] <seb_kuzminsky> anyway
[22:48:31] <seb_kuzminsky> i think i will turn this .comp misbehavior into a compile failure (as opposed to a runtime crash like it is now), and fix biquad
[23:10:52] <seb_kuzminsky> sweet, i broke something while trying to fix this bug, and our test suite caught it