ah, much better
$ uname -a; head -2 /proc/rtapi/status; emc2/bin/halcmd show thread
Linux tall 22.214.171.124 #2 PREEMPT Wed May 30 18:08:58 CDT 2007 x86_64 GNU/Linux
******* RTAPI STATUS ********
RT Modules = 3
Period FP Name (Time, Max-Time)
999980 NO thread ( 136, 2317 )
I must say: holy shit, I never expected to get here in less than 4 hours
I sure wouldn't have expected that either.
but I guess that only means that 4 hours in, you still don't know what the insurmountable problem will be :-)
cradek: I'm sure you're right
contrary to my fear/expectation, floating point doesn't immediately break everything: http://emergent.unpy.net/index.cgi-files/sandbox/siggen-realtime-amd64.png
now disturbingly, my load is 14 and it says I'm using 100% CPU...
I notice halscope works too
Unexpected realtime delay: check dmesg for details.
3D_Chips seems to be milling in tkemc
I must be doing something wrong, such as actually running the simulator
halcmd: loadrt hal_parport
hm this is not what I expected in the log:
[ 3830.008262] In recent history there were
[ 3830.008263] 2009142, 1908, 2010087, 2008173, and 2009117
[ 3830.008265] elapsed clocks between calls to the motion controller.
[ 3830.008266] This time, there were 2007608 which is so anomalously
[ 3830.008267] large that it probably signifies a problem with your
[ 3830.008268] realtime configuration. For the rest of this run of
[ 3830.008270] EMC, this message will be suppressed.
that one seems a little on the short side.
not if you add the magic number 2097152 or something
.. it's running the nist lathe ..
this is UP?
yes, amd64 but with UP kernel
OK, here's the first sign of weirdness: "Cannot move rotary axes with G76"
isn't that some peck drilling cycle or something?
threading canned cycle
that error makes sense to me, but I don't know if it's "normal"
there are no rotary axes defined
oh, well that could be a weirdness ;)
though I accidentally used an old tree, so it may be the "# joints" thing that got fixed in the last month or so
well, you've discovered a bug in the documentation - the fact that a rotary axis move isn't allowed with g76 isn't in the manual
lathe-pluto cut its first thread (using tool offsets, in non-native units)
again. You guys are unreal
it's such a relief to have the tool table working - I really need it for this machine
I ran a threading cycle in the air
the motors sounded good the whole time. on that run I didn't get the "unexpected realtime delay" message.
I can't believe you have that working already
there are a number of gross hacks in emc2
nah I can't believe that
gross as in large, or gross as in "ewwww"
of course, the two aren't mutually exclusive
[01:26:09] <jepler> http://axis.unpy.net/01180573281
<-- kernel configuration, emc2 patch, and general instructions just in case anybody else is interested in this
I'm definitely interested
I had a problem where the SMP kernel would boot if I used MODVERSIONS, but not without it
which didn't work so well with RTAI ...
I'm intersted even though I'm not going to use it
hmmm - did you just use "mkinitramfs", or was it mkinitrd? (and what command line options if any?)
from memory: mkinitramfs -o /boot/initrd.img-126.96.36.199 188.8.131.52
ok, so nothing special, just the name and version as expected
I used mkinitrd. I wonder if that was a problem (though I did the same thing for the working and nonworking kernels)
hm, I think my following errors might be due to power supply sag
you mean an actual hardware problem?
well, not sure I like it
what's the supply voltage/current?
don't run your lathe while the AC is on, I guess..
my 25v supply sags to about 15+-3 at full load (one axis)
what's the current rating?
the transformer is ... round
so it's rated for current then? ;)
rated for some current, yes
let's start from the other end then. what's the current rating of your motors? :)
yah - that could be a problem. :)
(I only ask because it's possible I have a higher capacity transformer you could swap in at Fest)
the motors are ... cylindrical
I think the stall is something like 1.5A
ok, now we're getting somewhere!
so in round numbers, then...
36890 are all round numbers
depending on the font
drat, I can't find my notes about the transformer
so if you had a 24V 5A supply, it would probably be enough?
you know, I'm measuring at the motor, I should measure at the supply
because maybe the motor wires are too small
it seems unlikely that you could handle a wire that's tioo small for 1.5A
without breaking it
they're pretty small.
[01:47:36] <cradek> http://timeguy.com/cradek-files/emc/dscn6313.jpg
this is two sweeps, the jaggy one is me twisting the motor off position
what am I looking at? :)
the other two (straight) lines are the virtually unloaded pwm
what's the sweep time?
ok, so the zigzag is due to PID, not you
no, the zigzag is 120Hz
4div = 8ms = 125Hz
right - close enough
so it looks like about 12-17v
that looks like an amazing amount of sag
I could add more caps, but that seems unlikely to help
I see 150ipm in your future ;)
yes this could explain why I seem to have a lot less headroom than before
I was using a very large switching supply
what's the max voltage your drivers can take?
the current limit is the problem really
I have a 24VAC 500VA transformer that might help a little
let me measure it at the transformer just for good, uh, measure
(that's a lot harder of course)
that transformer would give you ~33V at 8.18A or thereabouts
I bet it's big...
not small enough to fit in that slim case of yours
I don't have much room left unfortunately
but not too big
4.5" square, 3.75" high. the terminals stick out a little, making it more like 5.5 in one dimension
I see 17-23 in the box
I guess some would be lost in the H bridge, some in the wiring
17 is pretty low - I could probably help that some with capacitance
[02:06:14] <cradek> http://timeguy.com/cradek-files/emc/dscn6314.jpg
same kind of pic - three traces, ground, unloaded, loaded by twisting the motor
this is right on the rectifiers
That looks funny to be on the rectifiers - normally the leading edge is steeper, isn't it?
is "ground" the top trace, or?
ok, that explains the slope issue.
so it is steeper going away from GND
yep. brighter trace is GND.
yeah sorry for not explaining that
on the H bridge output I see about 13-20, so not much of the drop is in the wiring.
's ok - I need to think from time to time.
How much cap do you have?
about 2200 uF
I have room for another one - I could add that easily enough
if I can find one
I do have one more that size, I'll add it
there was a rule of thumb about how many uF/amp - googling now.
but it's really not going to help much I don't think
units "1A 1|120s /2200 micro F" "V"
so it will raise the minimum at most a volt or two?
yes, that sounds more or less right
Mariss' formula is 80000*I/V uF
though the "/V" part is so the ripple is some percentage of voltage, rather than some particular drop
sure sounds like I need a better transformer doesn't it
according to horowitz & hill, p-p ripple = IT/C when the load is constant-current (page 330)
I=C dV/dT (derivative WRT time, C is constant)
so I guess I am interested in hearing what adding C does -- doubling it should halve the ripple
so 3.78/2 V difference (in theory)
(if 1A is the right estimate of current)
with double the C, I get about 18-22V at the rectifiers
(or did I slip a decimal there?)
yes, 1/120 is 8333 micro
huh, that seemed to help a lot then
I said 13-20 before, now 18-22
let's see what it is at the motor now
(don't clip to ground, don't clip to ground)
ripple looked like 15V, so ~15 = I * 0.008333 / 0.0022
hey - that may have worked!
I don't think so -- 4A is the limit of an L298 package, and I think that's with heavy heatsinking
I don't think cradek saw 15V ripple
well, my eyechrometer may have read the ripple wrong
21:27:56 <cradek> I said 13-20 before, now 18-22
14-17 at the motor, no better really
so maybe 7V / 2A?
could well eb
yeah - I guess it looks like ~8V or so
the lines are pretty thick in that photo
won't the motor develop something less than the supply voltage across it, since the PWM duty cycle is limited to less than 100%?
I changed it to 100%
I'm not sure that would matter
SWPadnos: photo of an analog scope - be happy you get that much :-)
heh - I note that it's a ...orage scope :)
I think SWPadnos will be giving away free digital scope to everyone
you mean "rageoscope"
only if I win some lottery or something ;)
* skunkworks is still here also
funny it doesn't seem orange here
cradek: your seeing meat performs image processing algorithms all the time
jepler was right - it;'s a rageoscope
jepler: the camera is set for white balance for the flash - it must be very blue
I think you're right -- flashes are quite blue
haha those are terrible photos
cradek: I think we have the same scope.
thats the transformer I sent you?
jmkasunich: I demand my money back for this transformer
double my money back even
and free return shipping!
ok, that means you owe me twice the shipping cost
so is your scope upside down, or just the camera?
or did you biuld a postiive ground power supply?
brain is upside-down
whats the volts per div in those pics?
I was using add/invert for measuring at the motor, so it ended up upside-down
cradek: top left corner of the dsc6316.jpg is the model # and description - 66 rage oscope
jtr: I couldn't figure out what he was talking about
ok, so about 26V no load, 22-23 peak and 17 valley under load
any idea what the load current is?
is this a full wave bridge, or center tapped? (I don't recall the xfmr details
jmkasunich: once it's through the H bridge, it's more like 13v
divide and conquer - look a the supply first
yeah that's the 14 photo
thats the one I'm lookin at
the supply - center tap of xfmr grounded, two diodes from the ends pointing at the top of the cap?
you got two probes for that scope?
L298 source saturation voltage = 2V typ @ 2A, sink saturation voltage = 1.7V typ @ 2A (http://www.st.com/stonline/products/literature/ds/1773.pdf
put one on one end of the xfmr, other one on the top of the cap
(both grounds on circuit common of course)
jepler: and they call that a power switch?
so you want the probes across one diode?
I want two traces, one on each end of the diode
(not difference mode)
you want to see .. the conduction angle?
among other things
the side of the xfmr thats not conducting will be unloaded and have minimal droop
if the side that is conducting flattops, it points at transformer impedance being high (wimpy xfmr)
and the downslope during the non-conducting period tells us the current, assuming we know the total C
anything else while I have it set up?
it looks like ~2A or thereabouts
don't un-set up it until we look at the pic
I thought I did a crude analysis of that transformer and concluded it was about 120VA
the pain is getting the photos... one sec
so 24V at 2A shouldn't knock it down like that
I wonder what the market for an A/D card for the 5i20 would be?
'night guys - I'll have to get the rest from the logger.
[02:47:35] <cradek> http://timeguy.com/cradek-files/emc/dscn6315.jpg
mesa makes a few A/D cards, at least one of which has an FPGA on it as well (though fewer gates than the 5i20)
pretty sure I had them both zeroed - but don't trust my scope's calibration
I'm thinking more of an AD7886 - 1Msps 12 bit serial A/D in a 6 pin SOT-23 for something less than $5
the flat-topping is just horrible
damn, I thought that transformer had some balls
so AI should bring my transformer then? :)
and your enclosure enlarger
yeah that's the sad part
I can rent a sawz-all
:) thought maybe you where going to send your robot
I have an air powered nibbler...
the physical size of the transformer you already have doesn't match up with what we're seeing
could it be that most of the xfmr's output was intended to come from the lower voltage winding?
I thought we calculated that this was the high power winding
so did I
but that either has a lot of DCR, or a lot of inductance, or both
sadly, my scribbled notes about the measurements are gone
thats a real bummer
probably they're on google somewhere
(the xfmr, not the notes)
could it be damaged? shorted turn?
that would reduce V
when unloaded, is the transformer signal a nice sine wave, or is it still kinda flat on top?
still not very siney
are you using the other winding for anything?
it has corners, like a V with the point flattened
can you scope it - is it siney?
if a completely unloaded winding is distorted, either you have distorted input power (not bloody likely) or the transfomer core is being pushed close to saturation
Have fun guys. Night
jepler: # this is a hack until I find out how we're really supposed to do it
the unloaded one is just as bad
I want to run the py file from the directory it is in - src/hal/drivers/mesa_5i2x/firmware
whatever magic is being done to let py import from lib/python doesn't seem to work there
jmkasunich: during the build process, you mean?
when I'm building a new fpga config
cradek: so it looks kinda like the bottom half of the one you posted
jepler: from the make in the firmware directory
but right now I'm running it manually from within that directory
hey this has a setting for 100V mains - maybe I should switch it to that
might be interesting
at least I think I remember seeing that
the distortion might get even worse, but if it does, thats a data point
it would not be pretty, but it might be enough to cut parts
jmkasunich: for 'make', we should make sure a PYTHONPATH environment setting like the one created by emc-environment exists
jmkasunich: for running manually, you should ". scripts/emc-environment" assuming you are doing a RIP build
ok, thats what python reads to set sys.path?
jmkasunich: it's not complicated, except that emc-environment accomodates the case where PYTHONPATH already has a value and the case where it doesn't
(usually Python works just fine without a PYTHONPATH set)
(as long as everything is installed in the correct location)
I think this only has to worry about RIP mode
because I'm not really "running" emc at all
heh, I'm scared of these caps even though they're harmless at 24V, I'm used to working with 450V caps
cradek: I didn't know you were a drives guy?
or is it tubes
how about 45,900uF charged to 650V?
I'll be in the next room, thanks
how about ~100000 uF charged to 1300V? :)
30V unloaded now
SWPadnos: I'll be in the next state, thanks
jmkasunich: I guess the change I just checked in won't help you, since you're not running the top-level make
22-26 at the bridge now
that might just make the difference I need
jepler: well, eventually I'll figure out the right thing and put it in the fpga makefule
jmkasunich: it will be some variant of "set PYTHONPATH", I can tell you that much
that will be the only thing that invokes these two py programs
since you know the relationship between that dir and the lib/python location, you can code whatever you need
thats not the only path fixes I need - the xilinx tools have a script that you need to source to set up their env vars too
then maybe "use emc-environment" is good enough
good night all
cool, that keeps it around 20V at the motor
cradek: keep an eye on the transformer, make sure it doesn't heat up at that setting
if you're pushing the rated voltage, core loss will go up
ok, not warm yet
it will be a slow process
just don't ignore it for a couple hours
or go to sleep with it powered up
ok I'll run some programs for a while
(at least until you know how warm it does/doesn't get)
hmm. I guess it's time for bed. night guys
halscope is so very cool
watching pid output and FE in roll mode...
its a curse I tell you
the compile farm ALWAYS decides its time for a full build while I'm hare
can it do it during the day when I'm at work? nooooooo
can it do it 2 hours ago while I was out? nooooooo
have I gotten off my ass and moved the farm to the new machine yet? nooooooo
cradek: what the heck is this bug report for halscope?
you want grayed out menu items?
do I look like a GUI programmer or something?
(notice I didn't assign it like I usually do)
hey my program runs now
barely - I can see pid occasionally saturating
jmkasunich: no detectable warmth in an hour or so
why am I having so many problems understanding emc as a whole...
hmmm. it might be because you don't get it. :)
there are a lot of parts, and the connections between them are not obvious at first
the code deffinatly looks worth learning
oh, the code will take lots longer to understand
I think lack of good IDE is my problem
hmmm. ther eare some who would say that dependence on an IDE is the root problem there ;)
im just using pad
pad? programmer's notepad?
gedit to be exact
gedit or kate (as long as you remember not to trigger the crash that occurs when you try to compare the buffer to a changed file on disk)
I like kate a bit better becaus eit has the nice file list, plus an integrated terminal that tracks what directory the active file is from
and I can usually remember not to diff ;)
yay! time to wire up this Yaskawa motor and controller. bbl
has anyone seen MFD cut rack and pinion
would be neat to see a sample cut out
make the pinion like a flower
use a little bit of fantastic plastic to stick the pinion on
does anyone here use an IDE ?
Im allmost ready to give code::blocks a chance on linux
I'll try to import it into Kdevelop
Unit41: personally I'm a die-hard vim user, but I try not to evangelize it too much
we use both kinds of development environments here: vi and emacs
I have never used a Visual Studio-type IDE, but my editor allows me to easily go to the definition of a function, macro or variable through "tags", to go to sites where an identifier is used through "swish" full-text search, and to execute the build process and easily visit lines where the compiler had errors or warnings.
I like being able to see what functions are where and a nice easy list to click on to open source files
specially for foreign code
alien more like
I'm pondering another interp change.
if tool offsets (G43) are in effect when you change tools, you get the new offsets automatically
if G43 is in effect and you unload the tools (T0) they cancel (like G49)
what if a tool offset from G43.1 is active?
unload the tool
jepler: as I have it written, it would be replaced with the one from the tool table
it could do anything else of course
(right now we don't keep track of G43 vs G43.1 in effect
is G49 about the same as G43.1 I0 K0 ?
in fact that changes to G49 in "active g codes"
this would change the meaning of some legal (but probably buggy/wrong) ngc programs
currently you can change tools with g43 active, and the offsets don't change
jepler: strange, you and petev think the g43 part of the spec says lengths should be positive; I think it says indexes should be positive
(it certainly isn't clear though)
a negative index is dumb
let me read it again...
it *does* say that after M6, "no other changes will be made"
"It is expected that all entries in this table will be positive."
(I've noticed you can change tools while in radius comp mode too)
this had to mean "length", because it's established separately that the indexes must be nonnegative
jepler: well it CAN'T mean that, since the spec talks about negative diameters
ok I think you're right
I think that what they anticipated is that you would make a length of 0 be the spindle with no tool inserted .. there is *some* length that is shorter than all tools you can possibly use
this is not true on lathes, though
right (I agree with both statements)
but I'm not sure why my line of reasoning doesn't also apply to tool diameter
it seems like there is *some* diameter that is smaller than all possible tools
sure, it's 0
but, negative diameters have a special meaning in ngc
indeed, that was my guess
yeah, they mean "whoops, I actually meant the Other Left"
this doesn't really matter, I shouldn't have brought it up
perhaps "negative tool lengths are permitted" bears mentioning in the Differences section, and at least the "expected to be positive" text should be removed from the G43 specification
so it does matter and I'm glad you brought it up
someone who knows about canned cycles should try switching units between them - I bet it's the last thing that's still broken
yeah, the sticky "retract height" is probably in undefined units
and the repeat distance
maybe other things are sticky
wait, are repeat distances sticky?
(I've never used those)
I don't know, I've never used them either
I bet the documentation says
s/someone who knows/someone who cares/
jepler: all M are executed before the G, so Tx M6 G43 will give the expected thing
I was trying to remember something related to this that bit ray a while back - I think it was G21 G1 X10 F600
huh, how lucky for everyone who wants to divide by 12 that the segment called "c" is on for all digits but "2".
(though I'm still not sure I understand the full trick -- it's only alluded to by this "4026" datasheet)
was just wundering if any one in here could give us a quick hand on an EMC setup prob im having?
Actually - this might be better on #emc channel
whee, I think I just finished integrating all the 64 bit rtai patches into TRUNK
I'll come back later to check on the farm output :-P
jepler: the build is broekn for me
/usr/src/linux-headers-2.6.17-rtai3.5/include/asm-generic/bitops/fls64.h:10: error: 'fls' was not declared in this scope
cradek: thanks for letting me know
fwiw sim+ppc does build
can you pastebin me your fls64.h?
[23:42:00] <cradek> http://pastebin.ca/526790
I assume you have $ASM_BITOPS_H_USABLE from configure?
try forcing it to 'no'
BITOPS_DEFINE = -DASM_BITOPS_H_USABLE
looks fine without that so far
ah crap I forgot to cvs up first
forgot to cvs up? I assume you were trying this with the latest trunk..
yes I had done -D"hour ago"
trying again now
that had made it work OK?
of course it did
yes it builds with that change
I wonder if anything *doesn't* build with -UASM_BITOPS_H_USABLE
I think that all x86, x86-64, and ppc would work with -UASM_BITOPS_H_USABLE and that's approximately the whole world