SWPadnos: I realized that while IO is always "mapped", I probably have to do something in a kernel module to set up the memory-mapped I/O region if I'm going to talk to the 8255 that way...
otherwise who knows what's at that spot in the kernel's virtual address space...
not that that has any bearing on why the present version of the code locks things up...
ok, looks like instance & port rtapi_snprintf(buf, HAL_NAME_LEN, "pci8255.%d.%d", i, j);
r = export(buf, &inst[i].ports[j],
right - pci_request_region or similar
tomp2, yes, two .0.0: pci8255.<boardnum>.<8255_num>.<portname><bitnum>
skunkworks: meanwhile, do you have your machine handy?
the one with the 8255
sorry - no. it is at work..
I have a "diagnostic" program and I'm interested in seeing its output
I say burn it
in some environmentally safe way
its been running a few minutes, did a lot of 'show's stilll ok http://pastebin.ca/1009941
not my fault fred and fred not have same color sox
thanks; that's a valuable data point
its jeplers 8255.hal with only change "0xB000"
wow. that sucks. :)
anything youd like me to poke at, lemme know
i got 2 cards, and docs
you're not running the .0.1 or .0.2 read functions
SWPadnos: no, I'm not either
you guys want 'em? tompDASHtagATsbcglobalDOTnet
that's why the .0..* opins and -not pins have the same values
ah same color sozx is ok :)
tomp2 is talking in code
tomp2: do you have the ability to take a photo or scan of the board that would let me read chip date codes and the like? I wonder if yours is from a different batch than sam's
(sam, it's one of your cards that I have, right?)
I have say - running the stepper_inch with the read functions in the servo thread - for me it might lock up instantly - or it might run for quite a while. but it seemed to lock up a lot quicker if I tickled the inputs.
tomp2: if you want to mail me the windows demo exe firstname.lastname@example.org that would help
np, tonight from home tho
tomp2: OK, that's fine ..
and i can photo the pcb too
tomp2: where are you located?
in fact I'd be better off if I quit working on this for the night and took care of a few real-life obligations
neat - trempealeau
tomp2: you'll come down to cnc workshop, right?
hi guys - about to leave, but...
jepler: I saw you talking very briefly about memory mapping and such for PCI
tomp2: bring one of the cards then, unless we get this thing resolved in the meantime
jmkasunich: I'm sure I can figure it out if I read the m5i20 driver ..
you might want to look at upci.h and .c for that stuff (if you are doing user space test programs - in the kernel you're on your own)
jmkasunich: or that
i was thinking people could ship stuff here ( got a dock ) and i could get a van for a small crew from ORD to Galesburg
upci does the mapping for you and hands you a pointer (IIRC)
i can send the card to those who need em
I'm gone too
oh, I lied - it doesn't return a pointer, it provides a function to do the reading or writing for you
the read/write functions don't care whether you are using memory or I/O, they know what the region is and do the right thing
EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/components/debounce.c: from TRUNK: make debounce cfg= parameter match the documentation
EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note change
addf'ing all the reads and writers got me my first lockup.
i'm taking pictures, and will send the .exe's
jepler's .hal file ran for over an hour before i quit emc and added the .1 .2 reads & writes ( and then locked )
tomorrow i will see if the board can perform the same way or has changed
i have another board i will not try until thats known
ok, w$ demos on the way, photos taken
if the phots dont turn out well...
the only codes i think are important are on the Tiger 320 | www.tjnet.com | 0509 F6N4P-001
the board silkscreen say ET-PCI8255 V3
the top leftmost chip sez 8255#1(C0H-CFH), then smaller 8255#1(C0H,C4H,C8H, CCH)
the top middle chip sez 8255#2(D0H-DFH), then smaller 8255#2(D0H,D4H,D8H, DCH)
the top rightmost chip sez 8255#3(E0H-EFH), then smaller 8255#3(E0H,E4H,E8H, ECH)
the only jmprs on board are bottom right , labeled 'CARD ID' and Bit0 and Bit1 , both can be set HIGH or LOW labeled side. Both are at HIGH ( = 3? )
and no reply to my request for src of thier library
Good morning. Sorry to ask a Q that's probably been asked many times already, but I don't see the answer in the header or on the website. How long until a new heron/8.04 ISO is released?
jepler: you wanted me to test something?
tomp: thanks for that update -- I think that in my case, more or more frequent reads from the card are correlated with the lock-ups..
skunkworks_: looks like I can't get at the file I wanted you to run at the moment...
skunkworks_: I think I left the machine turned off
cradek_ is now known as cradek
jepler: Thanks for the link
At The EMC Fests, are there ever any seminars on "intro to linux software development" or some such? I've done embedded systems programming and CNC retrofits and programming, and I think I could contribute if I sat through a tutorial on the linux way of doing things to get me started. CVS, diffs/patches, linux IDEs, that sort of thing. Plus attending the EMC Fest, of course.
joeKr, There certainly will be folk there who do those things every day.
rayh: OK, thanks. I wanted to go last year but didn't make it. I'll try again this year, if it isn't canceled. I heard one of the organizers has health issues. How many showed up last year?
I spoke with Roland yesterday and he is certain it will happen.
He is the main guy for it.
probably 150+ people showed up over the course of the week
joeKr, I'm not sure we'll have a class on writing software for Linux/EMC2, but you can almost always pop on here if you have questions
and I'm sure someone can help you out if you have reasonably specific questions at the workshop
yes, that too :)
I was thinking of a session on becoming a developer but probably would limit it to getting all the software and an anon checkout and make.
comp would be a good thing to go over
a class is appropriate if the "student" doesn't know enough yet to guide the learning/syllabus. that is obviously not the case here since you already have topics in mind that you need help with
itr sure makes making modules easy
so, I think the best thing to do is for you to ask questions about the things you can't figure out.
Can you recommend a good teach-yourself website to learn linux software development? To get started generally, I mean?
Big qt4 update to 8.04 this morning
I can't. "Linux Development" is a very very big subject
since it covers everything from the kernel to applications like OpenOffice ...
Do you have a programming background joeKr
there are docs on the linuxcnc website that describe how EMC works, though I'm not sure exactly where they are right now
I can send you a paper on the history of EMC, which includes some description of how the pieces fit together
do you have a Linux system to use to fiddle around with the code?
Yeah, that's why I was hoping to sit down with somebody, to ask Qs. But we may have some developers (of different things) near me, I'll check my local Linux user group.
I'm trying to be very concrete so I know how to help - what specifically do you want to bring to the project, and what are your obstacles to doing that?
Yes, I have done embedded programming and PLC programming both by icon and by list. And CNC programming and fixturing. And CNC repair.
I've never tried to develop any software (except for a little Perl once) in Linux.
so if you knew how to get and compile the source, you could work with it? is that the obstacle right now?
There are some interesting python tutorials laying around.
"get and compile the source" There is a workshop session.
Haven't been around Linux long enough to have joined either of its two major religions... vi or emacs ;) I still rely on gEdit because it's most like notepad.
I disagree - that's a wiki page: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
I use Kate a lot of the time, and try out integrated environments like Anjuta from time to time
or gedit :)
I think "here's some commands to type" is a waste of class time
editor doesn't matter. the source is made up of text files. use whatever you like.
joeKr: (that link above was for you)
I never heard of Kate or Anjuta, I'll Google them later.
Kate is the notepad-like editor for KDE (rather than Gnome)
I kinda agree but kinda disagree. A certain bit of hand holding or watching over a guys shoulder can ease the tension a bit.
Anjuta is a somewhat promising environment with some cool features like word completion and that sort of thing
yes, a class that lets people knowwhat they're supposed to see is a good thing - it breaks a fear barrier
But you are right, Chris that the wiki is the place to start and IRC can handle any issues.
What types of things are on you guy's to-do list lately? What's at the top, the 8.04 switchover?
but why compile emc if you're scared of it like that. it's not necessary anymore, we have a polished packaging system, and trying to make the average joe comfortable with compiling software just sets off the "yeah but you have to be a programmer to use it!!" folks we hear every year
Yep and I understand those folk will be back this year.
well, that's true too
you can't make developers by giving classes. developers come to the project with their skills, wanting to help
but you CAN make users by giving classes that show how easy it is to use, and how well it works
Yeah, retrofitting for the average guy is tough enough what with setting (& understanding) parameters, figuring out I/O, etc., etc.
Without any "internal" programming
Someone mentioned "comp" a bit ago.
What types of things are on you guy's to-do list lately? What's at the top, the 8.04 switchover?
getting enough testing on that would be good
joeKr: in the CVS version we're working with stuff like improved support for "non-trivkins" machines, 5-axis tool length compensation, new hardware drivers, and some other goodies
sorry for the double, gotta be careful when scrolling back, LOL
but the next major user-visible thing will be the official packages and live CD for Ubuntu 8.04 LTS
there's also a (blessedly short) bug list
my favorite 80%-done addition is a new cutter diameter compensation algorithm
Yea yea that too.
also I think we're going to do an integrated spam filter and web browser in the next version
What about lathes? Is that a seperate version, or is EMC2 sufficiently adaptable?
there's good lathe support already
I'm thinking a 2.3 final feature set will come from fest.
How about "non-trivkins" lathes?
lathe will also benefit from the new diameter comp
spindle-synchronized motion, feed-per-revolution, constant surface speed, and canned threading cycle are the main lathe-specific features
hmmm. what would a non-trivkins lathe look like?
that's a new one on me
a robot arm moving the cutter for a lathe?
I saw a hexapod lathe a few years ago.
It moved the spindle against a stationery wall of tools.
well, it hasn't been done, and at the moment it would probably be a difficult configuration to do
No barfeed though.'
correction: I don't know of anyone who has used EMC2 for a non-trivkins lathe
it may have been done :)
passes parts back and forth between two chucks (one extends, both open & close). Cutters coming in at all kinds of different angles, not just X & Z (though each probably is X & Z in it's own world), more?
oh, ok. that's kind of trivkins with some extras
when we talk about kinematics, we're more talking about having to deal with coordinate transforms - like a radial arm robot or that kind of thing
(not a 1:1 mapping of motors/actuators to cartesian axes)
emc's gcode interpreter is not well suited to a system where you have more than one "controlled point" (cutter tip)
that's different than trivkins vs non-trivkins
an example of a non-trivkins machine: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Koppi's_Toy
also 5-axis machines are nontrivkins because when a rotary moves, the table often has to move too, to keep the tooltip stationary. (also, that movement changes when the tool length changes)
or this http://www.youtube.com/watch?v=mxxdq6y8z8M
* skunkworks_ thinks it is so neat
so, on a slightly related topic, I've been talking to people about USB step generators (like the G-Rex and smoothstepper), and I'll be meeting with some of them over the weekend
I'd like to have a good list of reasons why it's not an ideal solution (even though it can work for a lot of machines)
I was away watching the threading movie. Reminds me of an old cartoon where they were taking logs and making toothpicks out of them. Neat trick, but would you do with a variable pitch threaded item?
joeKr: there's a related blog entry http://jmkasunich.com/cgi-bin/blosxom/shoptask/fusee-1.html
JMK built that to harness the power of a mousetrap and turn it into rotary motion for a robot.
the fusee shape has a lot of uses (really)
not EMC, but here you go: http://www.youtube.com/watch?v=oGq-9NNmr3o
(about 1:30 into it, I think)
watches/clocks use/used it for torque equalization of a spring drive
oh - 0:56 into it
SWPadnos, why do you think USB is "not an ideal solution?"
time and feedback
I've had an email exchange with the smoothstepper guy, and I'll be meeting him this weekend
When EMC was a NIST, SENSE-MODEL-ACT was their mantra.
unless you put it all into the remote device, you can't do things like electronic gearing or spindle sync
you also lose feedforward if you just provide a list of positions (even for a servo controller)
(for the most part anyway)
depending on the machine type, you may need all following error tracking to be done in the remote device
emc's pid must be internally calculating velocity and acceleration for the ff1, ff2 terms .. it doesn't have velocity or acceleration inputs, and motion doesn't generate them as outputs
What would the USB device you're talking about do?
essentially, if you can run EMC on the USB device, then all is well :)
joeKr: there *is* no USB device
but a lot of people show up and ask the content-free question "why doesn't emc work on usb"
joeKr, there are USB devices that generate smooth step streams
jepler, there are USB devices
they just don't work with EMC, and they aren't
my basic view is that USB is fine for some open-loop applications, but I don't like it :)
Has the recent addition of CAN to the kernel done anything for you guys?
no. kernel drivers are not realtime
I thought EMC2 was running a RT kernel?
it is, but most drivers aren't part of the realtimesystem
yes, but normal linux kernel device drivers cannot be used from "realtime" code.
you can get errors which will require retransmission, so even with some baud rate and packet size, you can't guarantee reception within a given timeframe
and that's just the physical layer - it sayts nothing about how long the system will take to respond to a packet
though I should qualify that - I'm talking about fast realtime. if you have something that has to respond in 1 second or 0.1 seconds, it's probably fine
(emc checks position feedback and sends new position commands every 1ms in all the default configurations)
Ethernet is also non-deterministic but has nonetheless been adapted successfully to some high-speed real-time uses.
which uses physical ethernet hardware but a completely different protocol - it's time-sliced
I believe it uses error checking, and doesn't retransmit automatically. so the application has to know how to deal with communication errors
(ie, the app will see that there was an error or no data arrived, but it's up to the programmer to deal with it)
OK, work calls, but you guys have got an interesting channel. Maybe I'll come back and hang around? When are the biggest crowds here? Or is that never, LOL?
usually during the afternoon and evening in north america
Where do most of the developers live?
mostly in north america :)
Close to the Fest location?
though it depends on how you define "developer" - there are translators all over the place
not me, it's a 2-day drive each way
6-7 hours for me, I think
few things are close together in north america
I'm also 6-7 hrs away from the fest, according to mapquest
Where do people stay while at the fest?
various crappy motels in Galesburg :)
if you have a tent or camper, there's a big field next to the workshop
there are a couple of reasonable hotels too, at around $80-90/night
Not just *one* favorite crappy motel? Well, *that* complicates things, LOL
search google for "galesburg hotel", and you'll get the full list
there was a list on the cnc workshop website last year, but it hasn't been updated
OK, I'd better go. Thanks for the chat, all. Back later.
see you joeKr
Hey SWPadnos you still around. I've got one experience with usb and a lathe doing threading.
what USB device?
I didn't get a chance to look in. It was a China factory.
Looked to me to be USB to parallel and back.
almost like a computer in a box.
ok, so the motion controller was running on the USB device, and the computer was telling it where to go
No the motion was really timed by the computer anyway.
So once it got into a thread pass it would cut fine.
But had a very hard time getting the start of the thread pass right.
what do you mean hard time?
Sometimes you'd see it come back to the starting position and take off right into the next pass.
Other times it had to wait until it got it's USB ducks in a row
Almost like saying, "How about now"
the "gearing" was done on the USB device though, right? ie, the computer didn't get spindle speed/position and then tell the Z motor "go now!"
though that can be hard to tell when just looking at a device :)
I think so.
there is a tradeoff between faith and electronic gearing
people use faith to do tapping all the time
The spindle to axis interlock had to be on the outboard side of the USB
for some appications (trivkins machines, simple gearing/slaving, no PID ...), a device like that can work
I wonder if a VFD spindle would be constant speed enough to thread with "faith" only
and I only see one reason why EMC2 shouldn't support those devices - people will wonder why they can't tap or do gantry stuff or hexapods later on
with no feedback?
cradek, VFD spindle and a floating tap holder works great
even with no VFD
yes or minimal feedback (rpm from the vfd)
maybe for 1 pass :)
SWPadnos: yes I bet so
skunkworks_: well yeah, there is that
It looked to me like they had a tiny window on the outboard and USB had to hit it.
a tapmatic is a few hundered $$ new, and is much easier to use and set up than spindle encoders and stuff
SWPadnos: I'm not arguing against tapping heads, I just wonder how little smarts you can get by with and still cut "usually usable" threads
If you have a step generator and trajectory planner out there you still have the problem of feedrate override and abort/estop.
sure - I'm just pointing out the argument that some people have: you don't need rigid tapping to tap :)
rayh, with protocol control, you can get around that
but that does raise the problem of paths that change depending on speed
err - feed
Don't you have to assume constant rotary velocity and constant linear velocity to do open loop threading.
sure, you can use faith (T/C holder and rig your speed/feed) instead
rayh: yes definitely
on a lathe, yes
on a mill with a tap holder, not so much
rayh: constant linear is easy. constant spindle is what I wonder about - maybe you can come close enough
So the cutting load has to be tiny compared to the inertia of the spindle
yes, or the spindle needs to have closed loop speed control
it's funny - I had this discussion after the ESC talk, with someone from Rockwell and someone from Hitachi
Or you have to have load sensing and good speed correction.
when I mentioned that you need feedback to thread, they said, well, not if the spindle motor is servoed or big enough
which is what everyone says about not using feedback: if the motors are big enough, then you don't need to worry about it
that's the stepper mantra too - make sure the motors have enough torque that they will *never* lose a step under normal operating conditions
It seems like feedback is easier to do than for me to make the assumption about my spindle.
it's an error-checked solution, rather than an assumption
which may be why I like it better too
acting, thank you!
typoing 101 was my best course.
so I guess if the USB device does everything you want it to do, then it would be fine. if you may want upgrades later, or you need something that wasn't put into the device, then you need something else
With open loop, My eyes and ears are the sense part.
that's more like act - SCREEEEE - react
Yes it is during the integration phase.
But I'm with you about motors big enough to handle the task.
heh, then you lower the max_vel, and all is well
Sure that is one good way.
I remember getting that 32 stepper to 6k rpm on the bench here.
I just couldn't get it to stop without loosing steps.
I guess it's like putting a 200HP engine in a compact car. that way, you guarantee that you will be able to pass someone, whether you're going uphill, at 70 MPH, with 4 passengers and luggage ...
one thing DeskCNC has is accel/decel limits that go down as speed increases
since the motor has less torque
SWPadnos: a better comparison is: that way, you can approximate cruise control with a brick on the gas pedal
sure a nonlinear accel/decel
In the old days they had a knee in accel
oh, at the torque knee?
you got it
that would be a real PITA for the planner
well, if you want to be able to stop by the end of the known segments, then you need some square-law decel calculation instead of linear
Most of the machines I worked with had pretty quick accel so I don't know that much planning was needed for cutting speeds.
rayh_ is now known as rayh
* alex_joni never got feedback on the last livecd
alex_joni, I'll try it out this weekend, on several machines
I just haven't had a chance to do it yet
Well alex_joni it worked great here.
guess I'll wait a while..
rayh: that's good to hear.. I also have it running on a couple machines
You bet. As far as I'm concerned I'd vote for an official release.
lets see if it'll boot on my laptop first. at least it'll be another data point
taking a short trip tp germany on friday
but after that I'll be back & available for "official" support
I think I'll have access to some Dell machines over the weekend
rayh: stuttgart again
SWPadnos: remember the 'irqpoll' bootoption if all fails
don't know how many models
You seeing any of our folk there.
rayh: nope, don't think so
I'm back on saturday morning
so it'll be a short trip
Not long at all.
slightly over 24h
I've noticed real slowdowns with 8.04 soon after updates but once things clear up it seems to run very well
Anyone have experience with pcmcia parport cards and EMC?
I ran one once
(but it was a bit of a fight :)
I only managed to get it working after installing the linux driver
rmmod parport_cs (and whatever is dependent)
then modprobe hal_parport cfg=...
And then you could directly address it.
yeah.. until then it didn't want to run
I can see that.
but I read some stuff afterwards, and I didn't check if I had PnP disabled in the BIOS
PnP makes it easier?
I think it needs to be disabled
that way BIOS enables the card, and doesn't rely on the OS to do so
<- might be full of hot air though
no, not this time :)
Hey that helps. Got someone sending me a card to try.
rayh: same here :D
setting the BIOS to "non PnP OS" will cause it to do some more initialization of PnP devices
or at least it should
I see that.
SWPadnos: right.. should
but you also need a "non-buggy BIOS" for that to work ;)
So if the device is in there during boot it may find out more about it.
in my case it was a laptop (go figure.. with a pcmcia)
I don't know that the BIOS will ever enable PCMCIA cards though
Quatech SPP-100 G is the card
They say something about linux and some card mode.
this one is labeled Delock
I'm guessing they were thinking spp only.
alex_joni: I only booted the livecd on two machines, but it looked OK on both
32 bit cardbus -> parport
jepler: i have 'halrun pci8255.hal' running again. (board is not broke by 1 lockup :) should i be running some read loop?
quatech pcmcia par http://pcmcia-cs.sourceforge.net/ftp/SUPPORTED.CARDS
tomp2: what emc version do you have - 2.2.5, or something older?
wheee.. just found a 4.10 LiveCD ;)
jepler: EMC2 pre-2.3 CVS Head kernel 2.6.15 magma rtai 3.0
tomp2: when did you check out / update it? I am trying to establish if you have the bugfix "zeroing out the wrong size structure" which was checked in on TRUNK on 2008/03/29.
looking at time stamps is all i can think of....
look at src/hal/pci_8255.c
look at src/hal/CVS/Entries (the version with the fix is 1.3)
er, add "drivers" in both cases
$ grep pci_8255 src/hal/drivers/CVS/Entries
/pci_8255.c/1.3/Fri Apr 4 16:18:46 2008//
^^ in my case, shows that I have revision 1.3 that I got on April 4
jepler: src/hal/drivers/pci_8255.c jan 21 2007
OK, you should either use version 2.2.5 or an up-to-date CVS and then repeat the test where you added the other read functions.
will do, need come cat5 or widfi nic
or, using just port 0, you could try to verify whether inputs actually work (HAL pins change when you present signals on them)
either one is helpful to me
can do that too, i think i have some breakouts & breadboard... but later
this change in revision 1.3 of the file fixes a different lockup issue, so it might be why you locked up when adding the second read and write functions. or maybe the pattern is "more reads, more lockups" (due to the card design being bad), and I want to establish which one.
but related to that is whether the reads actually work -- on my card they don't, even when it's not locking up the system
jepler: "Touch Off is a way of setting the G54 coordinate system based on the current location of the axis and the entered value. Touch Off ignores G93 coordinate offsets even if they are currently in effect." Do you know what you meant to say instead of G93 here?
cradek: I think I meant G92
jepler: your inputs don't seem to work?
ok I figured. but, I don't know if the statement is correct
skunkworks_: nnot lately
I know G43 is not ignored.
skunkworks_: well, let me put it a different way. I ran a test program which should read back a known value (not from the input pins on an 8255 chip but from the internal configuration register of the 8255 chip) but it doesn't read back the expected value.
cradek: not sure
I verified that the statement is correct with G92 there
cradek: All I can say is, I must have thought it was true when I wrote it
I have to get back to work ..
tomp2: I'll look later at anything else you say, but I have to go for now
haha - just got an email from IEEE about an "Innovation Forum", with this great line in it:
"During this 1.5-day intensive seminar, we'll provide you with cutting-edge training in innovation, so that you can enhance both your career and your organization."
That's what I need, innovation training
cutting-edge, no less
to enhance your organization..
well.. that might have something
* alex_joni hears SWPadnos is a bit disorganized
organizationally challenged, thank you very much
jepler: now running pci8255 with todays cvs trunk, run-in-place. no complaints so far with original 8255.hal
tomp: can you see inputs changing?
will dig up some p/u res & jmprs to fiddle inputs
idc brkout needed
when testing parports I usually use a wire to connect an output to an input
might work for 8255 too :)
thx (got inet on the box now :)
floppy drive cables...
I just cut an end off and stripped a few.
best to use a resistor between the two pins so that if you set them both as outputs from 8255 they do not fight
*fight = Smoke
latest hardy livecd is installing on 256mb with no issues.
skunkworks: the inputs are already toggling. why? nothing connected but jepler has the hal connected to charge pump. i dont see how that can work
i went to check the state so i could pull up or not, and saw them toggling
...has them 'hal-connected' to the charge pump...
jepler: they are already toggling
you mean they randomly change state?
I was seeing that..
no, on/off/on/off, will halscope now
tomp2: well that's .. interesting
they seem to have no pull ups/down resisters.
the datasheet I've been most frequently referring to shows that the ports have "bus-hold" circuitry
the 8255 outputs should retain state until explicitly written to again
(if that's what you were talking about)
on port A the "bus-hold circuitry" will maintain high or low as long as the current is under 400uA, and B and C will maintain high as long as the current is under 400uA
I'm not 100% certain if this is a feature of all 82c55 chips or just the Harris-branded one in this datasheet.
it sounds like their chips may be designed to be defective ;)
on the other hand, the bus contention theory of the malfunction would cause things like ground bounce which might make current on those pins temporarily exceed the hold current, or other weird stuff
the whole point of an 8255 is to latch some state
halscope sez its toggling at fixed freq... will zoom in & lllok
2.5ms period, dead even trapezoid
where's that hal file again?
wasn't it on jepler's site?
[20:34:01] <jepler> http://emergent.unpy.net/files/sandbox/8255.hal
the charge pump signal should appear on all the "b" pins; if it's coupled onto any of the "a" or "c" pins then there's something wrong.
well I was wondering about that too
ah, it's the funny halscope way of drawing single data points as 2 line segments
[20:36:36] <tomp> http://pastebin.ca/1011050
pci8255.0.0.a dont change and .c dont change
ok, good :)
how is the chargepump wired to the inputs physically? saying words like 'net blah bl;ah blah' doesnt make current flow
i sthe scope correct?
you're looking at internal signals that are going to outputs on the card - that has nothing to do with the inputs
yes, what SWPadnos said
how can the inputs change with no phys connection
the scope is correct, but you have to understand that it draws traces in what I consider to be a weird way
those aren't inputs
all the B are set to output
ah it's the "direction" confusion
that makes sense if they're outputs
inputs to the driver connect to output pins
input pins are outputs to HAL
input physical pins are reflected by HAL output pins
re: halscope plotting, the horizontal length of each sample is split into two halves. the first half gets a (possibly) diagonal line connecting the previous sample level to the current sample level
the second half is a flat line at the current sample level
so what would look like a square wave (maybe with a 1-pixel shift in the middle of the vertical lines) ends up looking like a nice trapezoid in Halscope
i didnt get the change, the slope didnt bother me as much ( my hal probe needs adjustment anyways, wheres the trim pot? :)
you get _/-\_ instead of -|_|- (pardon the ascii art, I have no "top bar" character :) )
yah, got that, i make bad joke about adjusting a real scope probe for sqr wave
yeah, got it ;)
the adjustment is in scope_disp.c I think ;)
it is called - upping the base period.
bbl shutdown to cnx cables
I swear - I didn't think they could make installing ubuntu easier - but they did. What - like 4 screens and it is installing.
(and easy questions at that.. )
yeck. 2 dells here both have 60+us latency.
i hooked port A pin 25 (+5V) to 2.2K to pin1 (pulled up pci8255.0.0.a0) hung immed
shutdown, pulled board, sniffed & put lips on chisp to find 8255 warm lower right
removed pullups and reseated & rebooted, immed hung
shut down removed 8255 rebooted, now ok 8255 dead
if it's ttl compat, then +5 to 2.2k to input shoulda been ok
running now sans chip#1
these have 82865 intel chips.. wonder if I disable smi.
wiki says 82845
heh - too funny
I was in the emc2/src dir, and wanted to show threads, so I typed halcmd show thr<tab><tab>, and thread showed up
I thought - whoah, this is older halcmd, and shouldn't have that completion stuff in it
then I realized that there are hal comps called threads and threadtest in that dir :)
I only half-implemented completion in bash of halcmd, anyway
smi was it. insmod rtai_smi.ko and now the latency test is sub 10us
I think it's time to consign those futurlec 8255 boards to the trash heap
wouldn't it be a good emc_fest project.. Then we can throw them into one of rolands punch presses?
i got xtra 8255s, i'll try the w$ software
this is cool http://imagebin.ca/view/bmhQu9.html
it is cool now that the rtai_smi module is in the rtai directory.
that's good new
still going. rock solid. Neat.
alex_joni: ^ your latest livecd installed.
there was an earlier discussion about threading without an encoder, and the "if the spindle motor is big enough you only need 1ppr" school of thought
I agree, and would like to make a HAL comp that takes 1ppr input and turns it into something that looks like a canonical encoder
measure the period between pulses, calc the speed from that, then make position advance at the calculated speed between pulses, resetting to the exact position on each index pulse
that's a good idea, though the statement was more aimed at the idea of solving open-loop problems by using a bigger hammer (motor)
btw - what was changed to make the velocity more accurite from the hal encoder? I assume it initally was just time between pulses/distance?
initially it was just "number of pulses this servo period" divided by "length of a servo period"
it's that a timestamp is captured when an encoder edge occurs, so there's no uncertainty in delta T (which there is when you don't know if you're sampling just before or just after a count)
now it notes the actual time of the first and last pulses in the servo period (with resolution determined by base period)
and with hardware counters that timestamp, the resolution is waaaaay better (though probably not needed)
better is good, waaay better is probably overkill
uS resolution is significantly better than base period resolution, nS resolution is overkill
hmmm. is there's separate encoder function to update counts/velocity/"position", right (I guess there has to be since that uses FP)
basically the resolution of the velocity output is the better of "1/counts per servo period" and "timestamp resolution/servo period"
SWPadnos: there is a "capture" that is called at the servo rate - it does the math
"count" is called at the base rate to do the actual raw counting
ok, I was thinking about atomic updates, and that the function to calculate velocity has to get two pieces of consistent data (last timestamp and count)
the improvement touched both - count now records the timestamp, and capture does more math (including estimation for cases where there may only be 1 count every several servo periods)
I'd have to look at the code, but I think I solved the atomic problem
right - assume that the next timestamp will be "just after now" and extend the period accordingly
I think there's a double-read or something there
that should always succeed
something like that
gotta go, back in a few hours