The calif coast can be cold if the wind is off the water.
The damp goes right through you.
it was just a little cooler than normal there, and a bit warmer than normal here - so we had 65 degrees while VT had 75 degrees
luckily we got out before the heatwave hit though - record highs around 95 or so
I just received a call from Roland Friestad. He has had a fairly severe heart attack. Got home from the hospital today and called me.
He remembered that I said that even if the cnc-workshop didn't go the fest would like to.
He plans to contact the other major players and want's to run the workshop in spite of the lateness of starting up the web site.
He and his wife will get the site going but would like us to take the responsibility for all of the EMC side of things.
I don't know how that would make it any different that the previous sessions. We've tended to do that anyway.
I'll plan to show up down there Thursday/Friday before and help arrange things. If a couple of you guys could do the same it would really help us and Roland.
I've already got approval for the week of the fest, and I'd like to be able to take a few days before
I will post a note to the developer and user lists about the reasons for the delay with registration.
but I have a deadline at work that will be cutting it very close
That would be great, john
I presume you plan to drive in?
Say I like the remodel. Looks great.
I was originally thinking of either taking friday off to load up, then driving on Sat, or loading fri nite
(depending on work)
thanks - got the drywall up last night, boxed in the window and working on a bit of trim, then I'm gonna prime tonight
Sure. If you get there during the day Sunday, you can take charge of quite a lot of the final setup.
I'll definitely be there Saturday evening
I don't remember much about that corner. Seems like things were facing the other way when I was there.
if work permits, I could be there earlier, Thur or Fri, but I won't know that for a while
Have you got a room reservation?
Where you thinking of staying?
hadn't thought that far
I know the feeling!
either the place from last year (on the traffic circle downtown) or the Econo
Was the place last year good?
it was OK
maybe a tad seedier than the Econo
If you can spend Sunday setting up the EMC2 developer area and lan it would help a lot.
that will be no problem
if its like last year, Chris and Jeff will arrive Sat. evening too
the three of us set up Sun morning, and swp arrived Sun afternoon
Okay. That will be great. You guys can get all that together.
I'll ask on our lists for volunteers to help him more directly with things like the presentation schedules and so forth.
steves_logging is now known as steve_stallings
YIKES - I hope Roland is doing OK. Running a show is lots of work and lots of stress.
Yes it is.
He sounded good. A bit dazed and confused at one specific set of questions but doing well for a guy with three new stents.
wow, glad to hear he's doing ok. that sounds serious.
of course I'll help however I can
You bet. He's doing well, i think.
I've not no worries about the developer setup. You guys can handle that.
what else can we do?
I'll handle my classroom/lab.
I just saw the note about Roland. I hope he's doing OK (and his family)
I should be able to come in early and help set up
I just got off the phone with Matt and we will plan to arrive Saturday afternoon and can provide some help with setup of sessions, or whatever.
there were around 100 or so attendees last year, right?
hmmm. maybe that was 2 years ago
I think more, but spread out over the week.
ok. I was just thinking of the size of the mailing list he sent out after the workshop 2 years ago
There were probably almost 200 hanging around for the drawing/food.
steve_stallings is now known as steves_logging
[10:28:17] <alex_joni> http://pastebin.ca/1002754
"a semi-large number" :)
Thanks Steven, Steve. I'll get a note off to Roland this morning.
on the latest amd64 rtai kernel I've had the emc2 latency-test running for 2 days .. system's fine so far. (this is the first time I've booted the -16 rtai kernel, all my crashes were on -12 .. but it's early to say, as sometimes the kernel was up for a week or more)
jepler: thinking about a amd64 livecd?
alex_joni: not yt
ran all night - still 101 tasks running
skunkworks_: sounds good
I did have it where the cone didn't move once when starting a program.. (The code was scrolling though). stopped and restarted the program and the cone moved. (It was so odd that I wasn't sure what was happening at first)
skunkworks_: if you had emc2 version 2.2.4~cvs that's not surprising. if you have version 2.2.5, it is
jepler: otoh at his system load it might not be surprising even with 2.2.5
I am not worried about it unless it happens consistantly. As alex said - the system was pretty taxed
jepler, I've got a stock 8.04 on an amd64. Can I modify sources.list and pick up your packages for emc?
rayh: you should be able to
rayh: the install script should apply to amd64 aswell
I don't quite understand that file. What exactly would that line look like.
maybe you can try it directly?
[12:40:00] <alex_joni> http://www.linuxcnc.org/hardy/emc2-install.sh
oh. okay. I'll try that.
* skunkworks_ thinks ray is loving his high speed internet.
rayh: how did you survive with dial-up all those years :D
I spent days waiting for downloads. Wget was my friend.
jepler: should I email saying that the 8255 may still have some bugs?
Looks like I've got a realtime system running. I'll update to the latest 8.04 and then do some testing.
rayh: on amd64?
* alex_joni runs home..
rayh: cool.. so no isses with the install script
nice to know
that is using smp then?
I couldn't get it to run. Ran it a line at a time.
This is a single 64 box
It did start running because it fixed the sources.list.
but I had to run the update and install by hand.
rayh: little testing.. http://imagebin.org/17222
load testing? ;)
Looks like it. This a 64?
no - that one was just a pent 4 2.4ghz
this was a dual core.. http://imagebin.org/17235
Okay. xorg does take a lot of cpu.
I've not tried a lot of other packages to distract it. I've seen xorg about 20% on a semperon.
EMC is running on the amd64 proc with asus a8 mobo and video card.
Did say unexpected realtime delay.
what is scrollkeeper and why does it use more than 50% of the cpu
have you run latency-test yet?"
is this onboard video? (shared video memory?)
No it's a cheapo card
No latency test yet. Running cds.ngc and that seems fine.
Now scrollkeeper has dropped way down and xorg is using about 25%. That's about the same as my semperon.
garfield3: what bug?
Wow. Some huge jitter -- 2820206
with glxgears, gimp doing some rendering, and office.
on the semperon it shows 7918 jitter
glxgears runs a lot slower on the 32 bit than the 64.
yikes.. Something is having issues.. Do you have a memory stick plugged in?
I should look at the bios on this box.
maybe some power saving settings in the bios?
what is the cheapo video card?
you could try setting it to visa..
after 48 hours my amd64 machine has pretty good latency -- 11278
That is nice.
Jepler: did you see my question about the 8255 card.. About posting on the list that it may issues at the moment?
skunkworks_: I guess ..
I still haven't gotten motivated to look into that problem
That is ok - I just don't want a bunch of people buying the card expecting it to work.
cradek_ is now known as cradek
open office hits jitter big time on the 64 bit
sounds like a video issue..
rayh: is 32-bit emc OK on this machine?
I've not tried 32 bit on that box.
I have it running well on a semperon 32 and that hangs right in with jitter.
That is the box I was getting near 80 pulses for stepper testing.
i found a minor bug in stepconf-wizard
what is the bug?
the axis moves in the "test axis" dialog over the limit
is your scaling correct?
if you decrase the acceleration while the axis is moving fast
if you decrease accel during a move, you may be making a set of constraints that are impossible to satisfy
you should expect the axis to move too far if you reduce accel drastically near a reversal point
"near" has different values depending on accel and velocity limits
The minimum is 1 and you dont need much spees ...
the mimimum accel value is 1?
that was changed becise zero was more fatal
how do you think stepconf should behave in this case?
it shold sample the acceleration und only update ich the axisspeed is acceptable
how do I know if the speed is "acceptable"?
the simplest way is zero
I didn't understand that
when the axis chage the direction it "stops"
but i think this point in not good to meet
sorry for using wrong words
no problem there - it's much better than me trying german :)
i donkt know how hard it is to calculate the remaining way for the new acceleration
on the other side it must be possible to use the current speed of the axis
the accel is applied when stopping for the reversal
if you reduce accel while it's decelerating, you make a mathematically impossible set of constraints
so something has to give, and at this point it's the end poisition
and how is is only update the acceleration while the axis is incrasing speed?
throughout the reversal is the full acceleration
i mean only for decrasing
the only time acceleration=0 is in the center of motion when it's moving the fastest
accel limit, not applied accel :)
jes. then ther is no update.
at the moment the acis is accelerating the new value is used
I guess it would be possible to only update the accel value at the start of a move
that would reduce the "interactivity" of the tester, but it should prevent overshoot
the incrase is no problem. only decrasing is a problem
then its possible there ar no sideeffekts
other than the surprise at being able to increase accel but not decrease it in the UI :)
only in one move
the next mov is decrased
and if the axis moves voll speed acceleration is void.
its not so easy as thought first
the only easy alternatives are to disallow changing acceleration during a run, or to allow changing it to any allowed value.
thats not a good alternative
there's no easy way to control when during a test move an acceleration change would be applied
unfortunately, software is compromise
but it looks as sampling the new acceleration for one situation is ok:
decrasing acceleration while axis is not acelerating speed
then the move is finisched with old parameters
at the next move the new acceleration is used
I'm not sure that the GUI knows when accel or decel are being applied
I think I understand what you are suggesting, but it is not easy to do, for the reason that SWPadnos gives
i dont know about stepconf internals
there is no way to make sure that the new acceleration setting is applied at the desired moment. To do that would actually require changes to emc's step generator component.
jepler, it may be possible to do it if stepgen has an "in-position" output
it is a PITA though
actually, it can be done even without in-position
SWPadnos: no, because accel is a parameter. even if you can determine which servo cycle is the one you want, you can't do anything until some userspace code runs.
the velocity of stepgen is readable...
i see its harder to do
but i think stepconf makes the move
in the end, we can't protect some users while still giving others the flexibility they need
gefink: please update that bug on sourceforge with your findings an opinions, so that the knowledge lasts longer than this conversation
(the bug that caused me to change the lower limit from 0 to 1)
is it possible to have a non-integer lower limit?
like 0.1 or something
no as lower tha value then bigger the Problem
the way you need to stop the axis get longer with decrasing acceleration
1mm/s2 is way too low. maybe that's the bug, and if so, it's easy to fix
yes alt all if the speed id high
i notied only while using under 5
I don't know of any machine that would need acceleration less than 50mm/s2
that's especially true for stepper driven machines
one idea is to unse something like speed/5 as minimum ?
no, since then when you changed the speed, the acceleration would surpisingly change too
i mean as hidden limit for the operator-knob
I understand. but that limit would change, which means the current value would sometimes need to change
i update my bugreport. maybe somone has a idea
but i dont find the tracker...
thanks. i allway git forwarded to wiki
cradek: I sent an email to the list that had the i/o from the 8255.. It says it is waiting for moderation because it is 27k.
skunkworks_: please fix your mailreader so it never sends html email to the lists
sure - sorry
then you won't have problems!
hm I wonder if gene is on the right track about an interrupt
I am surprised any kind of interrupt would be enabled by default!
nothing a simple trace cut can't cure :)
* skunkworks_ goes and gets a razorblade.. ;)
heh - too funny: http://www.pci8255.net/
oh - hmmm. the futurlec board actually has 8255s on it. I thought it was an integrated chip
SWPadnos: the version I have has a surface-mount PCI bridge chip plus three socketed DIP 8255s
like the photo
I set up an old computer boards pci with a 8255 on it. Don't remember anything about interrupt.
BDI days though.
different board though
I had to set it up using a stock linux driver.
That done it would run using emc fine.
the computer boards / measurement computing units I've used have all had jumpers or dipswitches to select interrrupts (if they supported ints at all)
yep. can't seem to find a manual though
I'd not heard of it at all. But then most of my experience is with ISA and 8255 boards
SWPadnos: not english.. http://emergent.unpy.net/01165433819
reading an 82c55a datasheet, the chip has some modes where output bits on "port c" are generated from internal logic (it calls them interrupts), but the emc driver shouldn't be operating them in that configuration, and the board shouldn't be connecting them to PCI interrupts anyway
hmmm. yeah, my thai (or whatever that is) is a bit rusty :)
I would think it would be the tiger chip issue
page 3 of the thai manual shows an interrupt line
in the tiger320
yeah I agree it does -- but I think that's just a block diagram copied from tiger320 datasheet, who knows what aux[7:0] is hooked to
it's described on page 4 (DMA interrupt)
but I can only read a few words ;)
hmm - didn't I get the english manual with the cards? jepler: did I send a cd to you?
or maybe I didn't
skunkworks_: I don't recall
I don't either..
skunkworks_, did you get the hard lock when any input was toggled, or only certain ones?
I should hook it up again - but I am pretty sure it would run a long time without touching the inputs.. but when I would physically toggle an input - it would lock after a few <20 toggles.
did you try using different ports as input?
ie, port A one time, B another, C another
well - on the first 24 inputs
Now - I did not try b or c
ABC are the ports for one chip :)
sorry 1 or 2..
How does emc handle configuring the chip for IO?
load-time parameters tell the driver how to configure each chip
I don't think it does anything with the tiger320 chip though
the tiger320 is configured not to send any interrupts over the pci bus by default
(tiger320 datasheet page 22, 23)
hmmm. yeah, it looks like it should play nice by default
I do write a few tiger320 configuration registers, near the comment // PIB reset low, 15 cycle operation in the source code
shouldn't WRITE(0x10, io[i]+3, 0) actually be WRITE(0.10, io[i], 3) ??
err - 0x10 there, not 0.10
I *think* that the PIB registers are 4 bytes apart, but that the tiger320 registers are 1 byte apart
it's hard to tell
[16:44:10] <jepler> http://www.etteam.com/download/10PC_INTERFACE/1008/ET_PCI8255_V3_delphi_5.pdf
it has the 8255 registers at 0xc0, 0xc4, ... but the configuration registers at 0x0, 0x1, ...
yes. there's a lot of evidence that they are byte-wide. DMA addresses take up 4 registers for example
it seems silly considering that it's an interface to a 32-bit bus
hm the delphi code takes care to preserve the other bits of register 0, while I don't.
it's possible that you're turning on contiuous loop DMA mode
but still -- why would it be sensitive to changes in I/O pins?
whee.. long backlog :)
skunkworks_: wonder if I should sign up there, or you can paste my reply
by. thanks for your work
skunkworks_: I noticed he wrote to the list too
so I'll keep it just there
jepler: seen http://www.cnczone.com/forums/showpost.php?p=446248&postcount=12
I'm not sure that's the proper fix ..
I'd rather have RTAI fixed than emc2 work around it
alex_joni: is this fix for amd64 or for i386? on amd64, the flag is passed already
I can't check on i386 right now..
alex_joni: you can see it by running something like this in a configured emc source directory:
touch hal/components/and2.comp | make KBUILD_VERBOSE=1 2>&1 | grep --colmcmodel=[a-z]*
er, first | should be ;
and the command is garbled anyway; let me try again
touch hal/components/and2.comp; make KBUILD_VERBOSE=1 2>&1 | grep --color=auto mcmodel=[a-z]*
jepler: I get nothing
I am pretty sure from the 'info gcc' that -mcmodel=kernel only applies on amd6
reading info gcc again, I see that just above the explanation of this flag, it says "these -m switches are supported in addition to the above on AMD x86-64 processors in 64-bit environments", so they wouldn't apply on 32-bit systems
might be.. I hope he can duplicate it on a 32-bit install aswell
(maybe by running the live-cd)
cool. I wonder if that SMI killer will work at least most ofthe time
heh.. I'm just checking the RTAI version of SMI (if it's sane..)
the RTAI version of SMI workaround looks sane (to the extent found on dapper)
SWPadnos: it doesn't look much more advanced than the RTAI version
ok. does the rtai_smi module disable all SMI functions?
yes, by default
the rtai smi contains 16 chipsets, the one on that page only 15
I bet the 15 are contained in the 16 from RTAI
grep / cut / uniq / sort ... :)
with SMI enabled, I can't get my laptop to overrun anymore
(previously if I would use Fn-F4 to turn brightness up it would overrun)
if I didn't touch Fn-foo it would wok ok-ish
does fm-f2 still change the brightness?
err - fn-f4
yeah, well.. can't have both
did you mean enabled or disabled up there?
RTAI smi module loaded
preventing SMI I guess
once the SMI disabling module is enabled :)
latency is around 19200, with glxgears maximized (I still get about 300 FPS)
I'd say it's an acceptable laptop :)
no parport though
same problem here
you on i386?
no parport ;)
ah.. I have a cardbus parport around
I don't have RT on any laptop at the moment (I loaned my older one out)
and I managed to get it working at some point
I wonder when rtai will get the correct solution: use virtualization extensions to virtualize smi.
I saw a note somewhere that this is a feature in the second-generation of that processor feature
fwiw running intel chips with SMI off is violating the thermal design, so I would be pretty reluctant to do it on a laptop
hmmm. I wonder if the SMI killer modules turn fans on before turning the interrupts off
SWPadnos: not here
yup.. otoh, the fan seldom turns on here
sometimes during a kernel compile..
hmmm. the right thing to do (in our case) is to set the processor speed to full, turn on the fans, and shut off the interrupt
this all sounds scary
hmm.. I have SMI off right now, and the fan is running
it can run, but it shouldn't change speed
it just switched off
it's not about fans
I wonder if they leave thermal stuff on
it's about CPU throttling
intel uses smi to throttle the CPU in order thatn the processor never exceeds the TDP (thermal design power)
it's about cooling or generating less heat. I think both functions can be controlled with SMI
without smi, there's no guarantee that your "23W" laptop processor won't make more heat than the rest of the cooling system is prepared to dissipate
intel datasheets admit that the TCC (thermal control circuit) will occasionally activate even when the rest of the cooling system is properly designed: "It is anticipated that the TCC would only be activated for very short periods of time when running the most power intensive applications"
cradek: get a stash of P3's
I think cradek has a stash of P3s
I have a feeling those will sell quite good in a couple of years :)
as long as you have the matching motherboards and memory
SWPadnos: I meant PCs
oh. that's different :)
not only processors
* alex_joni cuddles his athlon XP
SWPadnos: the other plugs also lock up the computer. (still have not found the ryhme or reason though) Sometimes I can switch the input many times - other times it locks up pretty quick.
If I don't touch it - it runs a long time.
* skunkworks_ goes and tries again to be sure
hmm. then I'm about as stumped as I can be, especially considering that I don't have the hardware: )
skunkworks_: do it without executing 'halcmd start' (you'll need a standalone hal file for this)
or without adding the 8255 functions to the threads
I have run it without the read functions.. And it seems to run forever.
hmmm. actually, you should be able to just load then unload the module, if you want to test whether the initialization code does it
that's a good idea too
(atleast I have not had it lock up without the read functions in the servo thread)
if it runs forever without the read function, that's a good indicator of where the problem could be :)
but I don't remember all the details of this behavior since I forget anything once it scrolls off irc
you need a taller screen ;)
jepler: I still remember where one can look once it's off the screen ;)
3 s32 RO 22788 pci8255.read-all.time
3 s32 RW 2002223624 pci8255.read-all.tmax
this seems .. bad
it seems to be about 100000 times too long there
yes something like that
as far as I can tell, it's the inb() instructions themselves that are introducing huge pauses; after a few moments it kills the machine
I was lucky to get that ^^
but it doesn't always give a huge pause, sometimes the .time is OK
that is mighty weird
I can't think of any reason why inb would pause for that long
or even for 1/1000000 that long
it seems to be the inb() or inl() itself
so it does the same thing whether you use inb or inl?
well for a moment I thought inl() fixed it
but I no longer think that
have you tried using the memory mapped I/O isntead of I/O (since multiplying by SHIFT in read/write)?
oh hmm. the multiply shouldn't be needed
[ 149.041194] spurious 8259A interrupt: IRQ7.
[ 149.041199] Default Trap Handler: vector 0: Suspend RT task f4a46800
[ 151.444808] psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
[ 160.231817] hda: dma_timer_expiry: dma status == 0x24
[ 170.213656] hda: DMA interrupt recovery
this is what I got the last time
[ 170.213663] hda: lost interrupt
(lspci shows a different irq number than 7 for the 8255 board)
the system died again as well
lots of reboots today :-P
any interrupts from that board would be a bad thing I would think
turn it off, it burns
it's supposed to be off already
unless the kernel (or BIOS) decides to enable interrupts/DMA for some reason
is there some init code for the 8255 that tells it to keep its bloody mitts off the IRQ lines?
I'm not sure the IRQ thing is the problem
neither am I
the tiger PCI interface chip would control that
but I'm not sure its NOT the problem
and the power-up states for the tiger chip would *not* ever cause PCI interrupts
I believe the 8255 has an "interrupt on input change" option
and the crashes have been associated with input changes
the tiger is acting like a traffic cop between the 8522 and the bus?
the tiger chip is the equivalent of the PLX chips on the Mesa cards
PCI <-> local bus interface
coming in late here - is there an 8255 on the local bus (or several), or is it some VLSI emulation of an 8255?
I thought it was some integrated thing, but I was wrong
so, if an 8255 asks for in interrupt but the tiger says no, will the 8255 sit there and pout the next time you try to access it?
dinnertime here .. don't spend too much time thinking about this, those of you who don't have any hardware
(if it somehow thinks its still doing interrupt cycles instead of read cycles)
jmkasunich: nothing that I saw in the 8255 datasheet led me to think that -- there are some modes which use part of one of the ports as an interrupt output, but I shouldn't be using those modes
and they shouldn't stop the device responding on the local bus to I/Os
I don't think the 8255s are doing anything interrupt-related
It seems much more likely that I'm somehow doing I/O to the wrong PCI bus ports, and just don't see why/how
as an aside, if it works using memory-mapped I/O I'd do that instead
it seems like it may not work, since there's commented code for that mode
(in the WRITE/READ functions)
* skunkworks is glad his isn't the only computer locking up..
skunkworks: I'm sad that it is :-P