skunkworks_: there is little need for protection of the comparator
a 0.015 ohm resistor to ground is pretty good protection all by itself
regarding separation - you mentioned something about the sense resistor - it is at the low side so doesn't need high voltage separation
jmkasunich: I am mainly talking about the left side.. The top pads are pretty close to the right side motor trace.
ah, I see
it a leaded part - bend the leads
(change the symbol for the resistor to reduce the end-to-end pin spacing by 0.050 or 0.100
or just eliminate the top side pads
well - that would work...
if only you could get eagle to do that
* skunkworks_ was thinking post gcode editing...
that won't be easy (eliminating a pad at the g-code level)
you made the library symbol didn't you (I can't imagine eagle having a 4 terminal resistor symbol the right size)
yes - I made it
edit it (or make another), with smaller pads and smaller spacing between the two ends
those pads are huge
SWPLinux: in 2.2.5 the margin was much smaller -- 5%, not 25%.
unfortunately, 2.2.6 isn't out yet
I'm obviously looking at trunk :)
hmm - my resistor isn't in the library here. kinda looks like I need to edit it on the other computer
EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/m7i43_hm2.comp: deprecate the m7i43_hm2 driver in favor of hostmot2
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/m7i43_hm2.comp: Deprecate the m7i43_hm2 driver in favor of hostmot2.
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa7i43_gpio.comp: deprecated the mesa7i43_gpio driver in favor of hostmot2
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: marked my old mesa drivers as deprecated, any hypothetical users should switch to hostmot2
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.
It is funny how I don't think I would have ever thought about making the sense resistor pads smaller
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...
Well, just a user-specified hal component
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... :-)
So I'd like to implement my serial routines within a hal component running at the servo-rate
hmm, I don't know the answer then, you might have to twiddle the uart yourself to avoid calling into the kernel
let's see what the smart people say :-)
pmbdk: you're talking about your own "don't really care about realtime", userspace-only emc hack right?
Currently I'm just using sampler as baseline, but I guess I could do it from scratch, maybe even using the comp builder (?)
then you can do whatever you want
yes you can do nonrealtime hal components
cradek_ is now known as cradek
jepler_ is now known as 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"
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)
pmbdk: but basically you're starting with the environment you get from ./configure --enable-simulator, not with any rt kernel
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
jepler: That was my initial idea
However for testing I would like to use a realtime kernel as well
OK, in the case of a realtime kernel the answer from the rtai.dk wiki applies
you will crash the system if you use certain linux kernel APIs
But from the faq it seems i'm not allowed to do it.. .:(
Seems someone already had this problem... http://people.mech.kuleuven.be/~psoetens/portingtolxrt.html
emc2 doesn't presently use lxrt; the realtime stuff runs in kernel space, not userspace.
jepler: yep, I should have googled first... :)
someone want to take a stab on how much current the ouput can do? http://focus.ti.com/lit/ds/symlink/cd4071b.pdf
source I would guess.
at 85deg C - 2.8ma?
that seems really small. I was hoping to run a LED
at 2mA it hardly lights
but it's -2.8 only at 15V Vdd
why is that not making sense to me?
what do you mean?
it just seems awfully small.
it's a CMOS
those are usually pretty smallish
hmm - might have to nix the led then.. it was the only place I had a little room :)
flip flop is the same way.. Oh well.
huh, I wonder if Nic's problem is related to the once-in-a-blue-moon-it-skips-arcs problem two people have reported
he says it happens in all versions, but for sim only, but it's a kernel error
so I don't think we have anything like the whole story
he might mean an rtai build, but picking a sim/something configuration
but it seems impossible for the arc code to care about what ini file you have picked
which problem are you talking about?
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
one guy reported this, sent me a screenshot which I've surely lost, and then dropped out of existence
and who says there's a segfault?
stuart has seen it once or twice on his machine that was running an old trunk checkout and has been subsequently updated
'Nic', on the mailing list
I bet you stopped reading before the end of his message
ok - I give up. No current limit/disable led.
I could use one of the un-used inverters but I just don't have the room
that's what the wire-wrap wire and silicone wire glue is for
if the or gate could sink a little more current..
I could barely read the datasheet so I'm not sure where you got that 2.8mA limitation
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
oh I see it now on the very first page
do you have to use the same output to drive something else and the LED?
at the moment
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
but that pulls the output voltage up high enough that it's not a good logic "0" output
jepler: the FPGA logic analyser looks nice
* alex_joni always wondered if one couldn't be built with a 5i20
or even 5i22
hello again all
about segfault in emc
on my axis in one program (anly arcs) there is an error:
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1345, in __call__
File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 456, in callit
File "/home/michu/EMC2/laser/emc/bin/axis", line 543, in actual_tkRedraw
File "/home/michu/EMC2/laser/emc/bin/axis", line 487, in tkRedraw_perspective
File "/home/michu/EMC2/laser/emc/bin/axis", line 640, in redraw
error: (1282, 'invalid operation')
that is on 6.06
on 8.04 there is segfault
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.
micges: this is with a specific gcode file? can you post the file somewhere?
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
xc2s200 has only 1792 bytes x 32 bits worth of block RAM, a pathetic amount
you might be able to make a daughtercard with SRAM on it connected to two of the I/O connectors..
- this is error file
micges: and for you this reliably causes the 'invalid operation' error?
what version of emc?
this is fully corect file : http://pastebin.com/m5a837296
2.2.5 from cvs 2 months ago
does it happen to you when you use sim/axis.ini?
that's what I'm doing, and it looks fine so far.
same here, however I am using TRUNK
error happen when I'm sending G10 code and immadietly after that reload the preview
I am using 2.2.5
I used touch off to recenter it before running it
micges: OK maybe you'd better tell me the exact steps to reproduce the problem
better paste code that do that
simmilar to open_guts function
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.
ok sorry for taking time, one question: is the preview in axis thread safe in anyway ?
no. all of axis except a tiny part (the position logger) is intended to run in a single thread
error: (1282, 'invalid operation') - this is known error in opengl ?
or in axis ?
that is an opengl error -- it indicates that the OpenGL APIs have been used in an improper way
for example, if you have a glEnd without a corresponding glBegin, you get an 'invalid operation' error
thanks for help
EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/config/stepconf.lyx: small thinko fix
EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: from branch: small thinko fix