Back
[00:03:26] <skunkworks> that sounds cool
[00:03:35] <alex_joni> SMOP
[00:03:46] <skunkworks> :)
[00:04:01] <skunkworks> alex_joni: how is it going?
[00:09:36] <alex_joni> skunkworks: it's 2am .. take a wild guess
[00:10:29] <alex_joni> skunkworks: pretty ok. can't get around to do much though
[00:10:45] <alex_joni> writing a simple program takes a couple days :/
[00:11:05] <alex_joni> simple : about 400 lines so far
[03:09:03] <tfmacz> LawrenceG, hey....
[03:11:24] <LawrenceG> tfmacz, ho
[04:16:03] <Dave911_> Dave911_ is now known as Dave911
[12:27:19] <jthornton> in 2.3.4 if I do a TnM6 in the MDI then any move I get the error "Queue is not empty after tool change" if I jog after the tool change I don't get the error
[12:27:38] <jthornton> when I do a move in the MDI after the tool change
[12:28:00] <jthornton> is this normal?
[12:44:18] <cradek> jthornton: is one of your hal tool prep or tool change loopbacks missing?
[12:46:44] <cradek> or are you trying to move before the tool change is done?
[12:46:50] <cradek> bbl
[12:48:34] <jthornton> I'm just using the axis sim
[12:48:43] <jthornton> it might be
[12:50:28] <jthornton> I didn't see the hal manual tool change popup window when I started the axis sim so the config might be missing something
[13:26:27] <cradek> if you ask for a tool change but ignore the popup and continue to enter MDI commands, I think you'll get that
[13:26:57] <cradek> when running a program it knows to wait until the tool change is done. but in mdi mode, it expects the user to do the same
[13:28:07] <cradek> if it's not just this, can you give me instructions to reproduce it
[13:28:35] <cradek> bbl again
[13:38:00] <jthornton> using the axis sim I don't get the tool change popup
[13:45:14] <jthornton> In the sim ini I changed/added
[13:45:16] <jthornton> #TOOL_CHANGE_POSITION = 0 0 2
[13:45:18] <jthornton> TOOL_CHANGE_QUILL_UP = 1
[13:45:19] <jthornton> TOOL_CHANGE_AT_G30 = 1
[13:45:21] <jthornton> Then set a G30.1 at some random position then did a TnM6 in MDI then did a G0xn and got the error
[13:45:22] <jthornton> I'll be gone most of the day, so I'll get back with you later on this.
[14:35:32] <skunkworks_> jeepers chris - you are so mean. ;)
[15:10:04] <cradek> holy crap
[15:10:34] <skunkworks_> heh
[15:10:37] <cradek> what the christ
[15:10:58] <cradek> skunkworks_: are you one of the ones running on smp?
[15:11:32] <skunkworks_> I did a while ago.. but not at the moment. eric is
[15:11:50] <cradek> I haven't for a while, either
[15:12:00] <jepler> that's not only an smp kernel, it's a 64-bit kernel
[15:12:11] <cradek> yeah I noticed that too
[15:12:23] <cradek> that's something I bet none of us have tried
[15:13:06] <cradek> milltask is userland. I still don't see any particular reason to be sure it's emc
[15:13:32] <cradek> in my experience, so many kernel+rtai builds just don't work right
[15:13:49] <jepler> I made a 64-bit smp rtai kernel on hardy but found it to be unstable on the only hardware I tried it on
[15:14:00] <jepler> (though that system was always flaky and then just died one day soooo...)
[15:15:15] <skunkworks_> I have been meaning to try erics smp kernel on the atom.
[15:15:42] <cradek> I'm really shocked by the outrage I triggered - wow - I had no idea I was being inflammatory
[15:16:08] <cradek> I see now the extra oopses are close in time - I was thinking of them as separate events
[15:16:14] <SWPadnos> there are several machines running an RTAI+HAL setup on the SMP kernel you (cradek) made a long time ago
[15:16:27] <cradek> but I think the rest of my message was fine
[15:16:28] <skunkworks_> my guess is he spent tons of time trying to build a kernel - and thought he had it.
[15:16:29] <SWPadnos> but they're using isolcpus
[15:16:48] <SWPadnos> he's a smart guy and a kernel developer. building a kernel isn't a problem for him
[15:17:10] <SWPadnos> (though I guess he has more experience on BSD or something)
[15:17:59] <SWPadnos> I wonder if it is a coincidence that the geforce driver is implicated in all the faults
[15:18:52] <jepler> maybe it's not fair or accurate, but I sure feel like emc (particularly the rt parts) is rock solid, but rtai is a crapshoot
[15:19:13] <jepler> and that attitude would sure color any response I made in a thread like that
[15:20:14] <SWPadnos> my guess is he's having a bad day. he's been quite helpful and positive in the past
[15:32:28] <jepler> hm, this
http://article.gmane.org/gmane.linux.kernel.adeos.general/1487 hits several keywords that might apply to Michael's kernel -- 64-bits, CONFIG_PREEMPT, IRQ
[15:35:18] <jepler> I suppose I should put that in a followup
[15:36:15] <SWPadnos> isn't that about 2.6.31?
[15:36:19] <SWPadnos> Michael is using 2.6.29
[15:40:02] <jepler> I agree that's what the messages say; without digging into it, who can say whether the same problems are in .29
[15:41:28] <SWPadnos> true. I guess it makes sense that fixing something later implies that it's probably there in earlier kernels
[16:26:01] <Dave911_> Dave911_ is now known as Dave911
[16:50:08] <jepler> weird. if I read the m5i20 source properly, the -invert of parameters defaults to set
[16:50:32] <jepler> is there some daughtercard -- the isolation one? -- that effectively adds a level of inversion?
[16:50:35] <jepler> rtapi_snprintf(name, HAL_NAME_LEN, "m5i20.%d.out-%02d-invert", boardId, channel);
[16:50:38] <jepler> if((halError = hal_param_bit_new(name, HAL_RW, &(this->out[channel].invert), componentId)) != 0)
[16:50:42] <jepler> break;
[16:50:44] <jepler> this->out[channel].invert = 1;
[16:53:10] <SWPadnos> I think all the daughtercards are active-low
[16:56:25] <cradek> yes, in hm2 to the mesa IO daughter card, for outputs, I have to invert the raw signals
[17:34:08] <pcw_home> All of our FPGA I/O assumes active low
[17:34:09] <pcw_home> This if for OPTO 22 compatibility: all high = all off at powerup
[17:34:11] <pcw_home> also Xilinx FPGAs have a pre-config pullup option on all I/O pins,
[17:34:12] <pcw_home> but no pre-config pulldown option. Historically I think the OPTO-22 active low drive
[17:34:14] <pcw_home> was done because of the greater low drive capability of TTL (DTL too).
[17:34:15] <pcw_home> So OPTOs were driven with LED anode to VCC and cathode to TTL output device
[17:34:17] <pcw_home> meaning an active low output turns on the OPTOs LED.
[18:28:03] <Dave911_> Dave911_ is now known as Dave911
[23:03:37] <KimK> KimK is now known as KimK_afk