jepler: I think so
4076 85227 649303 ../html/Master_User.html
this HTML file is probably a bit too big to be useful ..
cradek: I believe that, contrary to what you've said, the [EMCMOT]TRAJ_PERIOD value is used
cradek: I made motion.debug-s32-0 increment each time tpRunCycle is called, and .debug-s32-1 increment each time get_pos_cmds is called, and the one value has a much greater slope than the other when running a gcode program
all the configs loadrt [EMCMOT]EMCMOT ... traj_period_ns=[EMCMOT]TRAJ_PERIOD ...
yes, that's true
if I understood what chris told me once, he thought that the value was ultimately ignored, even though it passes through several layers of code
all I can remember is that traj and servo period run at the same cycle time, although they should be 5x-10x apart
yeah - running servo at the traj rate seems not so useful
for trivial machines, do the GUIs use the free planner or the teleop planner?
I have no idea!
is the free planner the coordinated motion planner?
no, that's the other one
ah, free is the jog mode / homing mode one
EMCMOT_MOTION_COORD is used for running gcode
EMCMOT_MOTION_FREE moves in joint space, and EMCMOT_MOTION_TELEOP moves in axis space
ok, so yes, trivial machines do use the free planner for jogs and homing (I think)
EMCMOT_MOTION_TELEOP seems to use the [TRAJ]DEFAULT_ACCELERATION value as a limit
and teleop / coord have the same effect, even if they're different sections of code
that makes sense. teleop doesn't know if it's on trivkins or complexkins, so it can't use joint limits
err - nevermind. using DEFAULT as a limit makes no sense
there are a lot of layers involved so I'm not sure of this..
jepler: it depends if you are using world or joint coords
if s.motion_mode == emc.TRAJ_MODE_TELEOP:
/*! \todo FIXME FIXME FIXME - need to put a rate divider in here, run it at the traj rate */
I wonder what the output of `grep -Ri "FIXME FIXME FIXME" * | wc -l` would be :)
not hard to find out
it is on this windows machine
in emcmotController, everything always gets run
I don't see any kind of divider
$ ./scripts/swish FIXME | wc -l
hmm, but I spell it "XXX"
somehow tkemc gets it right, although looking at the code it seems to be doing it wrong
fenn: gets what right?
ah.. and who doesn't?
axis had some problems after uvw was added
has anyone tested tkemc with 9 axes?
doesnt seem to know about uvw
and strangely enough, abc is out of order
I know I ran tkemc with 6 axes, and it used to be fine
i copied axis_9axis.ini and changed it to use tkemc.. now it shows XYZCAB but when you click on A it jogs B and B jogs C and C jogs A
* alex_joni smiles at the reason
tkemc assumed XYZ ABC (or RPW)
RPW maps to ABC 1:1
so the W in there screws up the ABC
bogus assumption.. trying a fix now
ok, XYZABC work right now
but UVW still don't appear
look for the number 6 somewhere ;)
what, tkemc counts from 0?
bleah.. this is a major diff
I think ray never heard of loops
probably not when he started tkemc
is this normal? http://pastebin.ca/733242
[17:24:01] <skunkworksguts> http://pastebin.ca/733243
nope, but you'll never know that
hard memlock. that can't be good
or maybe it doesn't matter
* alex_joni didn't look
thought it was odd
trying one more time
it looked like it was trying to load modules at install time - that's not a good thing
now I'll be damned
[17:29:23] <alex_joni> http://imagebin.org/10997
where;s the G-code listing? :)
out of my screen
right - oops
well - maybe this hardware isn't suited..
1.4ghz pentium 4 rambus.
sure sure blame the computer
I just tried to re-install emc deb and got the exact same error. I think I followed the same steps I did yesterday on different hardware.
fenn: can you jog UVW in world?
using AXIS I mean..
with tkemc I can jog, but the readout doesn't change
only when in joint mode
argh.. I can't change the fontsize :/
you cant jog in teleop mode because UVW isnt part of the XYZABC coordinate system
ok.. in joint mode it works
[17:38:09] <alex_joni> http://imagebin.org/10999
fenn: can you test tkemc if I commit this?
I'm sure it counts as a bugfix
hmm - now the computer hard locked..
juve@taurus:~/emc2.TRUNK/tcl$ cvs diff -u | wc -l
fenn: commited now.. let me know how it works
hrm. how am i supposed to start tkemc and axis at the same time?
* alex_joni forgot the details
but you go to the config dir (e.g. configs/sim)
and then ../../tcl/tkemc.tcl right?
../../tcl/tkemc.tcl -ini foo.ini
ah right duh :)
when i try to jog uvw in world mode, it actually does update uvw in axis, but stays at 0 in tkemc
ah, that's what I was asking..
* alex_joni goes look
found the culprit
hang him up by his toes!
fenn: it's been hanged
man everything that's been touched by 'indent' sucks
(puzzling through emcsh.cc)
fenn: let me know how it works
the lines are broken in bizarre places to unnecessarily keep things under 80 columns
you mean the .. yeah
line breaks have some conceptual meaning when the programmer does them
yeah that crap
holy shit. what programmer would make a program capable of mangling code that badly?
well, it probably does exactly what it's asked (make it < 80 cols)
it's just that running it is a mistake
editors have this neat feature called 'word wrap'
letting it break at non-whitespace characters is a mistake
Joseph Arceneaux, Carlo Wood & David Ingamells
well they're stupid! ;)
my favorite so far is Interp::find_ends()
I had to wade through that crap recently
hahaha look at line 212
it's < 80 columns, I'll give you that
you mean line 212..218
^^ and this is one of the lines...
ON) ? (...)
alex_joni: tkemc looks the same
and it appears that I faithfully copied the existing "style" too
fenn: what do you mean?
that makes me an idiot or a genius practical joker, I'm not sure which
cradek: check out 296,297
uvw still read 0 in world mode
fenn: you did recompile.. didn't you?
this was a change in emcsh
at emc2/ i did cvs up -dPA; cd src; make
fenn: it works here..
and emcsh got updated
fenn: can't think of any reason for it not to work
you're using axis_9axis.. right?
why are axes 3..8 in their own "else"?
and is that "FIXME -- no rotational offsets yet" stuff just outdated?
cradek: I think the own else was because they used to be rotational axes at some point
no idea why the own else though.. it doesn't harm though, so I didn't change it
and I also wonder what's wrong with switch()
but now I'm just complaining
* alex_joni tries to swallow a response
if I rewrote everything that was written stupidly ... I'd be busy and introduce a lot of bugs
* alex_joni agrees
jepler: did you see the error I was getting?
skunkworks: no, I missed it
[ 486.928987] RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED
cradek: brings up memories? ;-)
jepler: that was from skunkworks' pastebin
well then there was this http://pastebin.ca/733242
I am thinking it may be me though.. this is a bit odd hardware wise
[ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
yeah this does seem familiar
so try lapic and tell us what happens :-P
skunkworks: can you try 'ulimit -a' ?
the 'hard memlock 20480' is a harmless message
yeah, still.. it's interesting to see what his limit is set to
on this dapper box it's set to unlimited
on gutsy, the amount of locked memory a user can have is set to a fairly low value. that's the line which increases the limit, which I look for with a 'grep' before adding it (again)
I didn't silence the grep, so if you're installing the package a second time, the grep prints the existing line
fenn: still not working?
yeah I've seen that before
you can rebuild ... something ... to fix it
kernel obviously :)
or maybe rtai
I don't remember
woo.. this is interesting
* alex_joni is running 3D_Chips in the 9axis config
and I wonder why ABCUVW change values
err.. UVW don't (they just changed from mm to inch), but ABC reliably go through a lot of values when 3D_Chips starts
alex_joni: sorry i got distracted. tkemc now displays uvw right
however, mdi no longer works
fenn: ok :)
linear move in MDI would exceed limits
if i g0 any axis
i get it with axis too
you probably have some offsets
I don't see anything wrong with abcuvw running 3d_chips
cradek: don't ABC change values?
Machine configuration directory is '/usr/local/src/emc2.trunk/configs/sim'
Machine configuration file is 'axis_9axis.ini'
* alex_joni was running tkemc
looks ok in AXIS
something makes me think you don't have tkemc right yet...
yah its displaying some crazy numbers here
I have a few-days-old tkemc here; it displays XYZABC and ABC stick at 0
let me see what happens if I 'cvs up'
when in world mode, all the coordinates change by a factor of 25.4
fenn: that depends on the G2x chosen
and is to be expected.. I think
but what I see is that if I keep ABC at 0, nothing happens when running 3D_Chips
even for abc?
why would switching to teleop scale by 25.4?
if they are != 0, then they change in the beginning.. no idea why
g20/g21 do not affect abc
cradek: obviously because it's broken
from what I look at it : it always does inches in joint mode
and in world mode it converts to mm
(all joints: 0..8)
that sounds somewhat backwards to me
even ABC and UVW
* alex_joni won't try to fix this
units issues are not terribly well thought out in tkemc </understatement>
come to think of it, axis probably displays UVW wrong
unless cradek tested it
or maybe it's right
what do you think I am, an amateur? oh, wait
heh, the ABC issue is in AXIS too
axis displays the same thing that halcmd does
cradek: try jogging ABC to some nonzero positions
which one (teleop?)
then run 3D_Chips
I issued "g0x1a1u1" with gcode in inches. Then I switched between inch and mm displa. x and u change, a stays the same
jepler: ok that's right
alex_joni: I don't understand
jepler: in the old tkemc?
cradek: start axis_9axis.ini
cradek: jog XYZABC to non-zero positions
all of them
then load 3D_Chips.ngc
oh you're not saying there's a units thing wrong in AXIS
it's a 'tool change position' bug
no.. I'm saying the numbers change
I'll find it
at the start, it moves to the tool change position (which includes A0B0C0)
I don't think it's a bug
then it moves back to the old ABC on the next move after the tool change
* alex_joni forgot about that
that's the bug
well in this config TOOL_CHANGE_PSOTION is 0 0 2
so, should it move ABC at all? I dunno
moving it both direcionts is probably wrong
why the hell can't I type
does it move uvw too?
fenn: toolchange can't move uvw
tool change position is ill-thought-out
and I made it worse when I halfassedly added support for ABC position
* alex_joni postpones this for 2.4.0
all the way up to 2.4.0 now?
first we get joints/axes right for 2.3.0
that's a fine goal as long as I don't have to do it
* alex_joni started a couple times
ended up fixing it by doing up -dPC
might need its own branch
cvs up -dPC
or you could learn git if you're selfish :)
when inside a realtime hal typical read/write function, are hardware interrupts disabled?
strange, I don't spot the bug I expected in CHANGE_TOOL()
the interpreter has to fetch the internal position after a tool change, since it may have changed .. that's what I first thought of
probin: I think so
jepler: you're right, it must be up a level
a "slow" HAL thread can be interrupted by a "faster" one, but execution of any non-realtime code in the linux kernel should not be possible.
ok, but if a hardware interrput, say from the ethernet PCI card comes in, will it interrupt the realtime HAL write fuction
let me be more precise
I installed rtnet
in that case, the answer is "I don't know"
rtnet runs in realtime using rtai
if it was a linux kernel driver for the network card, you could be assured its driver code wasn't entered while a HAL thread is executing
but I don't know the answer when the other code is RTAI real-time code
I think hardware interrupts are disabled while RT code is running
at least that's how hard RTOS'es do it..
ethernet cards have a small amount of buffering right?
you might consider a polling approach instead of an interrupt-driven approach, if rtai allows it. write one packet each thread execution, and read up to one packet each thread execution.
does anyone know if work has been done to integrate rtnet with EMC2. I have been playing with it and can send packets in a HAL "write" function. I am now looking at ways to receive back packets as fast as possible. Receiving packets is interrupt based in rtnet so it is a bit tricky
jepler, that is exactly what I want to do
probin: there was a guy who did it a while ago
integrate rtnet with HAL
but to do it means modifying each ethernet card dirver I want to support. I am looking at alternatives
check the mailing list archive.. he sent his results
probin: what happens when you attempt to allow these interrupts?
I am about to try this. I want to try it also to get a time scale of the overhead involved in using the interrupt mechanism instead of polling
there is quite a bit of code executed in rtnet when a packet is received. Overkill for CNC typc applications
And slows things down
All I nned is to write one 64 byte packet and read one back right aften. No tcp/ip stack invloved
that gives a roundtrip under 2us
alex_joni, are you thinking of Eric Johnson and the remote shell?
I have the read working
the write, sorry
probin, I haven't looked at the code lately, but I suspect that interrupts are not disabled while inside HAL functions
there are functions tai_cli() / rtai_sti() / rt_enable_irq() / rt_disable_irq() in rtai_usi.h -- perhaps some calls to these needed to be added in rtai_rtapi.c in the correct places, if indeed it is correct to disable these interrupts during rtapi thread execution.
I don't believe there's any difference to HAL whether the function is running in a high priority thread or in a low priiority thread. If that's true, then some interrupts must be enabled so that higher priority threads can interrupt low priority threads
I don't believe it is correct in the general case
can HAL function be preempted by RTAI ?
yes, or it wouldn't be possible for a high priority HAL thread to interrupt a lower priority HAL thread
Is there a problem in running a EMC HAL function at the highest priority?
no, there's always a highest priority ;)
the BASE_THREAD has the highest priority of any HAL threads. I'm not sure how that maps to RTAI priorities
the problem there is that the highest priority thread in HAL is always the fastes thread
so if you want to look at ethernet every 1ms, but you don't want to get interrupted while doing it, then that must be the fastest HAL thread
is there a way to set the priority of a HAL thread besides using the BASE_THREAD name
not at the moment, AFAIK
that is ok for my setup
if you want to earn the eternal gratitude of the EMC community (or at least one or two of them), you could add "interrupt threads" to HAL
the "servo" thread is the fastest and that is the one talking to ethernet
that's a feature that has been discussed before, but nobody has ever gotten the time (or willpower) to do it :)
if someone changes your config, then that will break
ie, they decide to add another quadrature input in software, and make a 100 uS thread to do it
break it , I am not sure
add delay, yes
it would no longer ne tje joghest priority thread
depends how fast the other thread finishes
so it could get interrupted
wow, that was a bad mis-spelling!
it would no longer be the fastest thread, so it would be interruptible
gotta run - bbiab
So my issue is similar to the mutiproccessor kernel cradek had built - doesn't work on older hardware very well?
skunkworks: you tried lapic and it didn't work?
crap - missed that. hold on.
wait - is that something I can run from terminal - or add in the boot thingy
add in the grub bootloader
ok - I remember trying this with cradeks. let me see if I can make it work.
the kernel has to support it, and there may also be a BIOS setting for local APIC
iirc skunkworks's machine just won't work
or that ;)
it's what made me give up on a smp kernel for the cd
wait - it was my fault?
it actaully didn't work on my single proccessor portable also
(non dual core/hypertreading/duo)
I think a lot of non-intel machines don't work
(I don't know all the details)
seemed the bit I played with it - multi proccesor or anything including or above hyperthreading seemed to work ok.
but it has been a while.
this computer is an Intel P4
you'd think that would work
huh - that is what this is
or are you talking about mine..
that's what I was talking about. I don't have any of those :)
yah yah - we have 2 of these things - good luck finding ram
oh it's easy to *find*
not so easy to buy
[20:14:53] <SWPadnos> http://www.geeks.com/details.asp?invtid=256RIMM800ECC-N&cpc=SCH
*seemed like a good idea at the time..
SWPadnos: interesting, I thought it was more.
the last time I looked - no one had any in stock
if you had plenty of slots, that wouldn't be too bad
that's about the cost of 1G of DDR2/DDR3, but still :)
you can probably get loads of memory and other spare parts by buying whole systems from www.retrobox.com
hmmm - or whatever they are now
[20:17:38] <cradek> http://www.use-enco.com/CGI/INSRIT?PMAKA=240-2874&PMPXNO=4840178&PARTPG=INLMK3
can anyone guess whether this has a taper in it, or is just a hole?
I need one of these but would like it to have the taper so I can use it for length setting too
(I don't think measuring from the flange is any good)
if I'm going to pay $80 it better do both things!
maybe I should call (which is always fun)
so - I can just add a line to the grub while booting? just add a line with lapic?
hitting escape at the boot time.
yes you can do it while booting
skunkworks, you can edit the line for testing purposes
append it to the kernel command line
just lapic or no lapic?
select the line to edit, the press e at the menu
move down to the kernel line, press e again
make the changes, press enter, then b to boot (if you go back to the main menu, the changes are lost)
the error message looked like it wanted the apic enabled
dunno the incanctaion to make that work, if it isn't automatic
lapic is what you want to add
cradek, there's a small description of the use of that tightener here: http://www1.mscdirect.com/CGI/NNPDFF?PMPAGE=1624&PMT4NO=30804959&PMT4TP=*ITPD&PMITEM=84941251&PMCTLG=00
of course, they're too stupid to use PDF files for catalog pages, so you need flash
wow, their prices are much higher...
hmm "to radially hold"
I wonder what that means
maybe I should just make what I want. the taper could be Al with a steel plate and pins on top
if only we could turn polygons ;)
hmm I'm not sure the sherline could turn that size.
and I hesitate to try to turn any taper on the sloppy manual lathe
well, guess I need a new lathe to save $84
that makes sense
well, you'd only save around $75 or so - you still have to buy stock
cnc too, because everyone knows you can't turn a taper without cnc
you can't turn a polygon without CNC, that's for sure
this computer sucks
[20:36:13] <skunkworks> http://www.electronicsam.com/images/KandT/gutsy.png
it gets latency errors running the 50us period.
nice encoding problem there
yeh - that to
hm is that the copy of latency-test that you downloaded yourself?
I'll bet cvsweb or firefox screwed it up, but I could be wrong
ran it from your link yestday with the bash command
well - as you can see :)
but lapic seemed to make it work.
"work" with 300us latency?
well - yeah. I thought it was 30us
missed a decmal place.
bad. but it is staying at 300us :)
I could compile a kernel image without apic, which is the way all the other kernels are
but I read something on the rtai list that says apic gives less latency
actually, something to the effect of 'you got bad latency because you disabled apic', but I can't find it now
doesn't it also give access to the higher resolution timers?
yes, the timer resolution is higher
not sure if that's important or not
I was just reading the intel developers handbook. I wish I could remember what it said about APICs
it's for P4-era chips also, so it may be a little out of date
still have the odd issue with the windows acting funny - the axis preview likes to be on top of whatever I have in the foreground. this is a different video card (ati radion)
I bet they broke mesa
they're probably trying to make jiggly windows work or something
[20:49:10] <skunkworks> http://www.electronicsam.com/images/KandT/Oddvideo.png
if mesa is broken, gutsy is no use to us
the cone is screwed up also.
cradek: in fairness it's not released yet
wonder if they have bug reports about it yet (surely so)
I thought though that it was a week or 3 away..
skunkworks: do you have all the updates? I had a ton after I installed from whatever CD image, and a ton a week later..
on the other hand, if you updated since I did two weeks ago, *you* have the newer X server
I didn't have this problem but mine's an on-board nvidia
the two cards you've mentioned, ati and intel, both have some degree of opengl acceleration
(and they probably want very much to get something that's at least usable for jiggly windows..)
* cradek makes a face
skunkworks: anyway, I appreciate you trying out these packages
jepler: yes - updated - there wasn't that many as I had downloaded the iso yesteday again.
skunkworks, send that image to Ubuntu with a bug report
it's not a hardware "viewport" problem, because the window border is drawn over the 3D image
though it is interesting that the shadow area is a black bar inside the preview area
(the window shadow)
I will also install it on my computer I have at home (1.7ghz pentium.) that I was running the hermes.
I know that one worked well with dapper
that would be a great data point for your bug report
looking now where to send it.
(anyone's first inclination would be to blame your hardware)
looks like some reading https://help.ubuntu.com/community/ReportingBugs
I can definatly do a before and after picture :)
jepler: your not seeing that at all?
skunkworks, I'm not sure that's the place for Guty beta bugs
I guess I got there from here. http://www.ubuntu.com/community/participate/TechnicalUsers
ok, could be right. it just seemed more targeted for released versions
* alex_joni really thinks we should invest energy only in LTS versions
I don't think LTS matters much actually
it's only longer support oin the "desktop"
SWPadnos: dapper sure was more stable than feisty
sure - they went from stable to radically unstable, on purpose :)
I think edgy was more "normal"
I don't know if it'll be a pattern though: LTS, then experimental, then a couple of normal, then LTS again
the trouble is that hardware changes so fast that the Dapper release won't even boot on some newer motherboards (and that's as of 6 months ago)
(that happened to Ray - he had good luck with a particular ITX motherboard but when he got new ones, using the same part number, the liveCD wouldn't boot)
skunkworks, the gutsy testing page points you to the same place, so it's probably right
I was guessing I would pick the package I was bugging about.
heh - good luck ;)
well, I think I can say that it's not just EMC/RTAI that get better performance when you load one core doing nothing
glxgears also gets faster by a few percent when I have a do-nothing loop running in another shell (while true ; do echo "nothing" > /dev/null ; done)
jmkasunich_ is now known as jmkasunich