Back
[00:11:42] <jmkasunich> skunkworks_: there is little need for protection of the comparator
[00:12:06] <jmkasunich> a 0.015 ohm resistor to ground is pretty good protection all by itself
[00:12:34] <jmkasunich> regarding separation - you mentioned something about the sense resistor - it is at the low side so doesn't need high voltage separation
[00:20:09] <skunkworks_> jmkasunich: I am mainly talking about the left side.. The top pads are pretty close to the right side motor trace.
[00:36:15] <jmkasunich> ah, I see
[00:36:27] <jmkasunich> it a leaded part - bend the leads
[00:36:47] <jmkasunich> (change the symbol for the resistor to reduce the end-to-end pin spacing by 0.050 or 0.100
[00:37:05] <jmkasunich> or just eliminate the top side pads
[00:38:56] <skunkworks_> well - that would work...
[00:39:11] <skunkworks_> :)
[00:39:28] <jepler_> if only you could get eagle to do that
[00:39:52] <skunkworks_> * skunkworks_ was thinking post gcode editing...
[00:40:24] <jmkasunich> that won't be easy (eliminating a pad at the g-code level)
[00:40:55] <jmkasunich> you made the library symbol didn't you (I can't imagine eagle having a 4 terminal resistor symbol the right size)
[00:41:08] <skunkworks_> yes - I made it
[00:41:17] <jmkasunich> edit it (or make another), with smaller pads and smaller spacing between the two ends
[00:41:27] <jmkasunich> those pads are huge
[00:41:43] <skunkworks_> heh :)
[00:55:44] <jepler_> SWPLinux: in 2.2.5 the margin was much smaller -- 5%, not 25%.
[00:55:49] <jepler_> unfortunately, 2.2.6 isn't out yet
[00:55:58] <SWPLinux> o
[00:56:00] <SWPLinux> k
[00:56:12] <SWPLinux> I'm obviously looking at trunk :)
[01:14:01] <skunkworks_> hmm - my resistor isn't in the library here. kinda looks like I need to edit it on the other computer
[03:53:59] <CIA-35> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/m7i43_hm2.comp: deprecate the m7i43_hm2 driver in favor of hostmot2
[04:06:37] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/m7i43_hm2.comp: Deprecate the m7i43_hm2 driver in favor of hostmot2.
[04:12:12] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa7i43_gpio.comp: deprecated the mesa7i43_gpio driver in favor of hostmot2
[04:14:48] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: marked my old mesa drivers as deprecated, any hypothetical users should switch to hostmot2
[12:30:02] <skunkworks> The only other thing that would be nice to have would be a led that will light when disabled or current limit.. But I really don't know if I could make if fit.
[12:48:43] <skunkworks> It is funny how I don't think I would have ever thought about making the sense resistor pads smaller
[14:49:57] <pmbdk> Is it a problem to use various non-blocking system-calls within the rt hal routines? I'm not using anything faster than the servo-loop...
[14:51:45] <cradek_> which specifically?
[14:53:08] <pmbdk> Well, just a user-specified hal component
[14:53:59] <pmbdk> With the response I've had in here I guessed it would at least make sense to test the latency using a rt kernel and my hexapod... :-)
[14:54:35] <pmbdk> So I'd like to implement my serial routines within a hal component running at the servo-rate
[14:55:17] <cradek_> hmm, I don't know the answer then, you might have to twiddle the uart yourself to avoid calling into the kernel
[14:55:25] <cradek_> let's see what the smart people say :-)
[14:55:33] <jepler_> pmbdk: you're talking about your own "don't really care about realtime", userspace-only emc hack right?
[14:55:39] <pmbdk> Currently I'm just using sampler as baseline, but I guess I could do it from scratch, maybe even using the comp builder (?)
[14:55:41] <jepler_> then you can do whatever you want
[14:56:05] <cradek_> yes you can do nonrealtime hal components
[14:56:09] <cradek_> cradek_ is now known as cradek
[14:56:13] <jepler_> jepler_ is now known as jepler
[14:57:30] <jepler> if you're talking about a realtime component that will run in a realtime kernel, the the answer is "no"; see
http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTAI_FAQs under "Can I use all linux kernel functions normally from my RTAI task"
[14:57:38] <pmbdk> jepler_: Well, I still don't care much about realtime... However it _would_ be nice to have some sort of guarentee that my program is not interupted by someone opening firefox... :-) Which basically means firefox... :-) Now, I know that I would have to write my own driver for the hardware, but this is not an option as I'm using usb (currently)
[14:58:20] <jepler> pmbdk: but basically you're starting with the environment you get from ./configure --enable-simulator, not with any rt kernel
[14:58:25] <jepler> ?
[14:59:28] <jepler> in that case the so-called realtime components are just running in normal linux userspace; you don't have any timing guarantees at all, so doing nonblocking linux syscalls can't make things any worse
[14:59:33] <pmbdk> jepler: That was my initial idea
[14:59:52] <pmbdk> However for testing I would like to use a realtime kernel as well
[15:00:15] <jepler> OK, in the case of a realtime kernel the answer from the rtai.dk wiki applies
[15:00:29] <jepler> you will crash the system if you use certain linux kernel APIs
[15:00:31] <pmbdk> But from the faq it seems i'm not allowed to do it.. .:(
[15:02:51] <pmbdk> Seems someone already had this problem...
http://people.mech.kuleuven.be/~psoetens/portingtolxrt.html
[15:04:40] <jepler> emc2 doesn't presently use lxrt; the realtime stuff runs in kernel space, not userspace.
[15:06:14] <pmbdk> jepler: yep, I should have googled first... :)
[17:19:52] <skunkworks> someone want to take a stab on how much current the ouput can do?
http://focus.ti.com/lit/ds/symlink/cd4071b.pdf
[17:21:25] <skunkworks> source I would guess.
[17:22:08] <skunkworks> at 85deg C - 2.8ma?
[17:22:27] <skunkworks> that seems really small. I was hoping to run a LED
[17:22:56] <alex_joni> at 2mA it hardly lights
[17:23:15] <alex_joni> but it's -2.8 only at 15V Vdd
[17:23:35] <skunkworks> why is that not making sense to me?
[17:23:46] <alex_joni> what do you mean?
[17:24:07] <skunkworks> it just seems awfully small.
[17:24:14] <alex_joni> it's a CMOS
[17:24:22] <alex_joni> those are usually pretty smallish
[17:24:57] <skunkworks> hmm - might have to nix the led then.. it was the only place I had a little room :)
[17:28:36] <skunkworks> flip flop is the same way.. Oh well.
[18:15:07] <cradek> huh, I wonder if Nic's problem is related to the once-in-a-blue-moon-it-skips-arcs problem two people have reported
[18:26:19] <alex_joni> the segfault?
[18:26:24] <cradek> yes
[18:26:47] <cradek> he says it happens in all versions, but for sim only, but it's a kernel error
[18:27:03] <cradek> so I don't think we have anything like the whole story
[18:27:38] <cradek> he might mean an rtai build, but picking a sim/something configuration
[18:28:01] <cradek> but it seems impossible for the arc code to care about what ini file you have picked
[18:32:40] <jepler> which problem are you talking about?
[18:33:55] <cradek> one I've never seen firsthand. sometimes, arcs in the program are skipped. it feeds in a straight line to the endpoint of the arc, or maybe to the endpoint of the following line
[18:34:08] <cradek> one guy reported this, sent me a screenshot which I've surely lost, and then dropped out of existence
[18:34:28] <jepler> and who says there's a segfault?
[18:34:30] <cradek> stuart has seen it once or twice on his machine that was running an old trunk checkout and has been subsequently updated
[18:34:49] <cradek> 'Nic', on the mailing list
[18:35:15] <cradek> I bet you stopped reading before the end of his message
[18:36:15] <jepler> probbaly
[19:34:59] <skunkworks> ok - I give up. No current limit/disable led.
[19:37:41] <skunkworks> I could use one of the un-used inverters but I just don't have the room
[19:40:45] <cradek> that's what the wire-wrap wire and silicone wire glue is for
[19:42:44] <skunkworks> heh
[19:43:11] <skunkworks> if the or gate could sink a little more current..
[19:43:45] <jepler> I could barely read the datasheet so I'm not sure where you got that 2.8mA limitation
[19:45:56] <skunkworks> it is hard to understand imho.. if you look at the output high (source) current. at 13.5v and 85deg C it says it will source -2.8ma
[19:45:57] <jepler> oh I see it now on the very first page
[19:46:05] <jepler> do you have to use the same output to drive something else and the LED?
[19:46:11] <skunkworks> yes
[19:46:14] <skunkworks> at the moment
[19:46:42] <jepler> ok then that makes more sense -- I was looking at the current vs output voltage diagram on the next page and seeing that you can get 20mA no problem
[19:47:03] <jepler> but that pulls the output voltage up high enough that it's not a good logic "0" output
[20:05:11] <alex_joni> jepler: the FPGA logic analyser looks nice
[20:05:27] <alex_joni> * alex_joni always wondered if one couldn't be built with a 5i20
[20:05:30] <alex_joni> or even 5i22
[20:16:48] <micges> hello again all
[20:17:54] <micges> about segfault in emc
[20:19:00] <micges> on my axis in one program (anly arcs) there is an error:
[20:19:01] <micges> Exception in Tkinter callback
[20:19:03] <micges> Traceback (most recent call last):
[20:19:03] <micges> File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1345, in __call__
[20:19:03] <micges> return self.func(*args)
[20:19:03] <micges> File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 456, in callit
[20:19:03] <micges> func(*args)
[20:19:05] <micges> File "/home/michu/EMC2/laser/emc/bin/axis", line 543, in actual_tkRedraw
[20:19:07] <micges> self.tkRedraw_perspective()
[20:19:09] <micges> File "/home/michu/EMC2/laser/emc/bin/axis", line 487, in tkRedraw_perspective
[20:19:11] <micges> self.redraw()
[20:19:13] <micges> File "/home/michu/EMC2/laser/emc/bin/axis", line 640, in redraw
[20:19:15] <micges> glEnd()
[20:19:17] <micges> e
[20:19:31] <micges> error: (1282, 'invalid operation')
[20:20:49] <micges> that is on 6.06
[20:21:05] <micges> on 8.04 there is segfault
[20:29:44] <jepler> alex_joni: if you don't require much trace storage it would not be hard -- use the fpga's block ram instead of external sram.
[20:29:52] <jepler> micges: this is with a specific gcode file? can you post the file somewhere?
[20:33:31] <jepler> alex_joni: but I think that the amount of block ram on an xc2s200 is much smaller than the 256Kx32 on the S3BOARD meaning that you can't capture very long traces
[20:35:30] <jepler> xc2s200 has only 1792 bytes x 32 bits worth of block RAM, a pathetic amount
[20:37:19] <jepler> you might be able to make a daughtercard with SRAM on it connected to two of the I/O connectors..
[20:43:20] <micges> jepler:
http://pastebin.com/m671b57c9 - this is error file
[20:44:06] <jepler> micges: and for you this reliably causes the 'invalid operation' error?
[20:44:43] <micges> yup
[20:45:01] <jepler> what version of emc?
[20:45:54] <micges> this is fully corect file :
http://pastebin.com/m5a837296
[20:46:17] <micges> 2.2.5 from cvs 2 months ago
[20:47:02] <jepler> does it happen to you when you use sim/axis.ini?
[20:47:19] <cradek> that's what I'm doing, and it looks fine so far.
[20:48:06] <jepler> same here, however I am using TRUNK
[20:48:11] <micges> error happen when I'm sending G10 code and immadietly after that reload the preview
[20:48:22] <cradek> I am using 2.2.5
[20:48:44] <cradek> I used touch off to recenter it before running it
[20:48:45] <jepler> micges: OK maybe you'd better tell me the exact steps to reproduce the problem
[20:49:06] <micges> no
[20:49:15] <micges> better paste code that do that
[20:49:43] <micges> simmilar to open_guts function
[20:50:24] <jepler> oh -- if you have made modifications to emc, and the problem only occurs when you use the modified code, then I am wasting my time trying to reproduce the problem here.
[20:52:20] <micges> ok sorry for taking time, one question: is the preview in axis thread safe in anyway ?
[20:53:04] <jepler> no. all of axis except a tiny part (the position logger) is intended to run in a single thread
[20:54:14] <micges> error: (1282, 'invalid operation') - this is known error in opengl ?
[20:55:46] <micges> or in axis ?
[20:56:04] <jepler> that is an opengl error -- it indicates that the OpenGL APIs have been used in an improper way
[20:56:17] <jepler> for example, if you have a glEnd without a corresponding glBegin, you get an 'invalid operation' error
[20:56:51] <micges> oh ok
[20:59:17] <micges> thanks for help
[20:59:20] <micges> gnight
[20:59:24] <jepler> good luck
[20:59:39] <micges> thanks
[23:23:36] <CIA-35> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/config/stepconf.lyx: small thinko fix
[23:23:58] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: from branch: small thinko fix