* alex_joni is off to bed
g'night again ;)
Guest252 is now known as skunkworks
jepler: I have an odd issue..
I thought that 0xfff would set all the pins to inputs. Which it seems to do - but 5 times now - the computer hard locsk
that's no good
Initially - I would set the hal file to 0x000. This works - I can toggle outputs. Then I change the hal file to 0xfff - the computer will lockup.
increase your period
hm, I used a 1ms period and it seems to have killed my machine too
must be a bug :-P
If I reboot - It seems to run wth 0xfff - but when I try to set an input to low or high - I don't see a change on halmeter
it locked up after I issued "halcmd start"
having added 'write-all' to the thread
that is what I am using I think.. I am running the 8255 in the servo period
er, maybe 'read-all' -- I already forgot what I did
and then I closed the terminal on the crashed machine
I could see if I can figure out the exact steps.. It will be running thru emc-axis though
I don't do the fancy hal only stuff ;)
sounds like a race condition.. (j/k I thought I would throw buzz phrase out there.)
it must be some bonehead error on my part
I'll try to look at it sunday -- I have no excuse, since I have the board in a machine
Cool - thanks jepler.
* skunkworks is glad it may not be all him
jepler: also - do you think the pins should have an -in or -out like the printer port pins do?
skunkworks: oh probably
skunkworks: what driver? pci_8255?
seems like it would be easy to spot, but I don't spot it
the macros don't help
I wonder if you can set them to all inputs if you don't call the write functions. that would narrow it down.
I can try that. hold on
still locks up - removing the addf pci8255.write-all servo-thread -1
did you still have write-relay?
I took them both out.
what exactly are you doing? setting dir = 0xfff?
that narrows it down to export()?
(not what I expected)
but it doesn't crash until you do halcmd start?
jepler said that
then the crash isn't export
oh that's true, hmm
read is in a thread too?
asking me? yes. http://pastebin.ca/961064
(I had just commented out the two writes.)
I rebooted and ran again - same result.
so its read that must be dying
can you also remove read from the thread and see if still hangs?
I see something suspicious in export
inst is passed in as "ptr to port"
but then it does memset(inst,0,sizeof(struc state))
struct state is 3x plus bigger than struct port
It didn't lock up instantly.. Gave it some time and then added the function in halcmd. Didn't loock up instantly but did after about 20 seconds.
ding ding ding
the size thing?
yeah that's gotta be bad
might not be the particular bad that we're chasing, but worth a test
skunkworks: you are working from a CVS checkout, right?
once you reboot, open src/hal/drivers/pci_8255.c in your favorite editor
line 63, change from "sizeof(struct state)" to "sizeof(struct port)"
yes - ok
wait a sec
interesting - struct port and struct state both have ioaddr fields
ok, export is clearly dealing with a port
skunkworks: yes, make that change, the run make
if it is the memset thing, I wonder why it only breaks with fff
oh - for outputs, there is a param invert, for inputs its a pin -invert
if that data is getting stomped, stomping a param doesn't hurt
stomping a pin means there is a pointer off into the wild somewhere
and read does a write using that pointer
let me reboot
what a pain :-)
I'm a little unnerved by the fact that there is a global inst = ptr to struct state, but inst is also used in several functions and macros as a local ptr to port
but I don't think that's actually an issue
where is the data for this board?
(I'm curious about SHIFT in the inline functs READ and WRITE
I think they mailed a cd with the card, but I'm not sure
this board looks like it only uses the low byte of every 32-bit word
(or at least thats what the code says - it does outb and inb to offset*4
skunkworks: when you use a dir value that doesn't make it crash, have you tested the actual physical outputs?
turn them on/off and check with a meter?
the fff is all inputs
with all outputs, it seems to run, and at least halmeter shows the pins working
but are the physical outputs working?
the card addressing could be totally wrong, and the hal pins wouldn't show that
if skunkworks sends me one, I'll test it
OTOH, if the correct outputs do change state, then the addressing is probably right
Outputs seem to work ( I have only tested a few pins on the first plug)
ok - the fact that some work is usefull info
On a side note with 0xff now the first 8 bits are outputs now after the reboot.. and no lockup - of cource.
I mean 0xfff
(that is what I thought)
skunkworks: talk slower and try again :-)
I thought fff meant "all inputs" and that caused lockups?
wait. let me past it.
sorry - I was wrong. but it is running right now - no lockup and they all seem to be inputs.
Let me see if I can change the state
after that code change it's working with all inputs 0xfff?
after it locked up initially.. And I rebooted
don't change anything - we need to understand exactly what is going on here
:) what do you need?
a while ago, it locked up, then I asked you to make an edit after rebooting
you made the edit, did the compile, then tried the exact same thing
it locked up again
then you rebooted again, and tried the exact same thing, and it didn't lock up?
yes - exactly
so there is no difference between the last two runs, but one worked and one didn't
I may have tried a 0x000 before the change.. during the same session - just to make sure I could flip an output.
before the change - what does that mean?
then changed it to 0xfff and it locked - reboot - now working.
before you edited?
sorry - don't remember.
ok, from now on, please tell us exactly what you are doing before you do it
I know - I know - You have scolded me before about that.
I will learn
that memset bug modifies memory that it shouldn't regardless of the value of dir
so if you rebooted, ran the old code (with dir=000), it may not have locked, but it might have corrupted someting - then you did the edit, compiled, and ran again, but maybe it was already corrupted
(that is just speculation....)
I could believe that..
right now, with the change, it is running with dir=fff?
yes - and I just tested the input - thru the voltmeter - when I change the probe to ground - the pin is false - when I put the probe to +5 it is true. First time I have gotten any input responce.
it looks like the memset bug was it, but I'm disturbed that you didn't see it fixed right after making the change
I am chalking it up to running it before the source edit.. (if that is what I did)
well - let me switch from0x000 and 0.fff a few times
even if you did, I'd be astonished if the corruption persisted after you shut down HAL and restarted it again after the edit and make
anyway, I'm convinced that the memset is _a_ bug, even if I'm not sure it was _the_ bug
do you have commit access?
me? heck no.
ok, I'll commit it
this driver is only in trunk, right?
it's also in 2.2
hmm - when I set an output to true (+5) and exit emc - it is still +5... that doesn't seem right
nothing cleared it
ok - I for some reason thought emc would leave it as it had started..
I guess that is what posthalmumble file isfore
cradek: I'm confused by this: http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/pci_8255.c?graph=1
or a charge pump
oh, never mind
shit - I locked up
might be informative to watch dmesg in the time before the lockup
this driver isn't very verbose
sometimes rtai tells you things...
only after the lockup I bet
at which point its too late
yeah, long shot.
I exited emc - changed the hal file to 0x000 - ran emc - set the first output to 5v (true) (worked) then exited emc - changed the hal file to 0xfff started emc - went to halmeter to pick an input - locked up
have you been using emc all along, or just halcmd?
you did compile it right? and you're sure you're running the one you compiled?
not calling you stupid - but we all screw up those steps sometimes
I did a make - I saw the 8255 file fly by
I am going to have to call it a night.
Thanks for trying.
jepler said something about looking at it in sunday - he's gonna be away till then?
jepler will be able to spot it, he even has the card too
Yes - he said maybe sunday
cradek: you do agree that the memset is a bug, right?
I'll commit that fix now, and leave the rest for jeff
EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/pci_8255.c: zeroing out the wrong size structure
jmkasunich: I got half of my frame done tonight. It would have been better if I had done the brazing instead of letting my friend the raccoon (who was apparently drunk) do it.
(I'm not quite an expert at that)
it's sloppy, so I couldn't have done it
but maybe I'm misremembering
EMC: 03jmkasunich 07v2_2_branch * 10emc2/src/hal/drivers/pci_8255.c: zeroing out the wrong size structure
I've always been better at metal removal technologies than metal addition ones
but I have to take the dog to the vet tomorrow at 9
which means the alarm is going to go off pretty much normal workday time
uh-oh, is he sick?
the good news is that the first operation is done on all 20 of my parts
no, routine maintainence - change the oil, rotate the tires, etc ;-)
shots and such
what's the second op?
face the other end to length
easy by comparison to the first
what are these?
I'll install the studs in the parts (in the hole I made first op), chuck up a nut in the three jaw, screw part in, start program, unscrew, repeat
2x2x1 with a M12 stud sticking out about 5/8"
cool, sounds really easy.
they glue the bottom to a tile, attach a bayonet type widget to the stud, and stick it in a tensile tester to pull the tile off of a concrete substrate, to check bond strength
the wiget mates it with the tester
then need a bunch of them because they test large batches
then they bake them to break down the glue and clean for reuse
the 2nd op is relatively easy, but will still be slow
I'm still facing off a square, with all the pounting that implies
and with no css
still running a large diameter range, so slow speed
I have to take off about 0.100
I wonder if it would actually be more secure to put them in the 4-jaw like I did for the first op
I guess it doesn't matter if they're centered
well, I know it would be more secure, I guess I wonder if I need that security
not sure how you'd get them flat though
seat the already machined face against the front of the chuck
oh right, they're bigger than the hole
oh well, thats tomorrows problem
EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/drivers/mesa7i43-firmware/.cvsignore: a bit more CVS silencing
EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/ini_homing_fr.lyx: French translation update
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr_axis.po fr_rs274_err.po): French translation update
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: Enable READY in PLX 9030 LASxBRD registers if the EEPROM forgot to.
sometimes when I run 0xfff it will run for a few minutes - up to maybe 20 on a fresh boot. and the inputs work. but after that - hardlock
arg - worst possible scenario for debugging
how about running top to see if memory is being eaten up?
I am not sure how kernel memory shows up on top... less user space ram?
LawrenceG: I bet it doesn't eat that much memory up
it's rather that it writes outside of it's bounds and does some data corruption
death by pointers... can be hard to spot
LawrenceG: on another topic - I finally got in touch with CentryCo (those screw covers)
a cover that is 15.75" long extended, 1.18" long compressed, 1" ID, and 1.7" OD, is $72.30 and two weeks
minimum order is $150
the travel range might be marginal for a shoptask X, especially if you ever remove the tailstock and run the saddle way down there
the next size up is 19.69" extended, 1.18" compressed, 1" ID, 1.93" OD
and I didn't think to ask the price
probably not a lot more, maybe $80ish
its more than I had hoped, but not enought to make me want to spend hours improvising something that probably won't work as well
hmmm... kind of pricey.... I will live with what I have for now
I can understand that ;-/
since they are so pricey, the minimum order really isn't an issue, I'll need two, and that will be enough
I think I'm gonna do the Y ballscrew first though
credit card is kinda smoking this month, let it cool off, then do Y, then a month later do X ;-)
I am building another small table for doing pcb's.... it should be better backlash wise as I can use small antibacklash nuts
gonna plant it on top of the regular table? or is this an entirely separate machine for PCBs?
I am happy you are getting some lathe experience on the shoptask... new machine is a toally new table and spindle.. about 6x8x3" work area
not that much different from the shoptask actually
but finer screws and slower
faster spindle I hope?
I have a plan for doing PCBs, but it requires getting/making a faster spindle first
trim router... still need to build speed controller... should probably do 10k-30k
I have a (probably unwarranted) bias against motors with brushes in them
but maybe I should get over it ;-)
pcb's are working on the shoptask, but because of spindle speed, I can only cut at about 4ipm
and backlash limits my pcb accuracy
I just had a vision of a rube goldberg contraption
a small steel cable or rope, attached to the table and heading off at a 45 degree angle back and toward the tailstock, to a pulley that aims it toward the floor, and 30-50 lbs of barbell weights
the angle means it preloads both X and Y
the pulley would have to be a few feet away, hooked to the wall or something
I like the idea of air cylinder uses as a spring.... regulator sets force... but it needs a relief valve when compressing