Back
[00:02:06] <jepler> 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...
[00:02:22] <jepler> otherwise who knows what's at that spot in the kernel's virtual address space...
[00:02:38] <jepler> not that that has any bearing on why the present version of the code locks things up...
[00:03:42] <tomp2> ok, looks like instance & port rtapi_snprintf(buf, HAL_NAME_LEN, "pci8255.%d.%d", i, j);
[00:03:42] <tomp2> r = export(buf, &inst[i].ports[j],
[00:04:00] <tomp2> trying now
[00:05:15] <jepler> OK, bbiaf
[00:06:34] <SWPadnos> right - pci_request_region or similar
[00:14:53] <SWPadnos> tomp2, yes, two .0.0: pci8255.<boardnum>.<8255_num>.<portname><bitnum>
[00:16:06] <jepler> skunkworks: meanwhile, do you have your machine handy?
[00:16:18] <jepler> the one with the 8255
[00:16:21] <skunkworks> sorry - no. it is at work..
[00:16:24] <jepler> skunkworks: OK
[00:16:33] <skunkworks> Ideas?
[00:16:41] <jepler> I have a "diagnostic" program and I'm interested in seeing its output
[00:16:51] <SWPadnos> I say burn it
[00:17:00] <SWPadnos> in some environmentally safe way
[00:18:52] <tomp2> its been running a few minutes, did a lot of 'show's stilll ok
http://pastebin.ca/1009941
[00:19:40] <tomp2> not my fault fred and fred not have same color sox
[00:20:39] <jepler> thanks; that's a valuable data point
[00:20:44] <tomp2> its jeplers 8255.hal with only change "0xB000"
[00:20:52] <tomp2> thk you
[00:21:23] <skunkworks> wow. that sucks. :)
[00:21:24] <tomp2> anything youd like me to poke at, lemme know
[00:21:42] <tomp2> i got 2 cards, and docs
[00:22:10] <SWPadnos> you're not running the .0.1 or .0.2 read functions
[00:22:15] <jepler> SWPadnos: no, I'm not either
[00:22:17] <tomp2> you guys want 'em? tompDASHtagATsbcglobalDOTnet
[00:22:53] <SWPadnos> that's why the .0.[12].* opins and -not pins have the same values
[00:23:08] <tomp2> ah same color sozx is ok :)
[00:23:16] <jepler> tomp2 is talking in code
[00:23:20] <SWPadnos> heh
[00:23:41] <jepler> 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
[00:23:46] <jepler> (sam, it's one of your cards that I have, right?)
[00:23:49] <skunkworks> 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.
[00:24:01] <skunkworks> jepler: yes
[00:24:14] <jepler> tomp2: if you want to mail me the windows demo exe jepler@unpythonic.net that would help
[00:24:40] <tomp2> np, tonight from home tho
[00:24:52] <jepler> tomp2: OK, that's fine ..
[00:24:56] <tomp2> and i can photo the pcb too
[00:24:58] <skunkworks> tomp2: where are you located?
[00:25:05] <tomp2> Chicaga
[00:25:09] <tomp2> <a>
[00:25:16] <jepler> 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
[00:25:17] <skunkworks> neat - trempealeau
[00:25:25] <jepler> tomp2: you'll come down to cnc workshop, right?
[00:25:28] <jmkasunich> hi guys - about to leave, but...
[00:25:32] <jepler> hi jmkasunich
[00:25:36] <tomp2> hope so
[00:25:47] <jmkasunich> jepler: I saw you talking very briefly about memory mapping and such for PCI
[00:26:00] <jepler> tomp2: bring one of the cards then, unless we get this thing resolved in the meantime
[00:26:10] <jepler> jmkasunich: I'm sure I can figure it out if I read the m5i20 driver ..
[00:26:11] <jmkasunich> 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)
[00:26:17] <jepler> jmkasunich: or that
[00:26:43] <tomp2> 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
[00:26:46] <jmkasunich> upci does the mapping for you and hands you a pointer (IIRC)
[00:27:21] <tomp2> i can send the card to those who need em
[00:27:25] <tomp2> bye
[00:27:33] <jepler> tomp2: night
[00:27:38] <jepler> I'm gone too
[00:27:56] <jmkasunich> oh, I lied - it doesn't return a pointer, it provides a function to do the reading or writing for you
[00:28:29] <jmkasunich> 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
[02:02:08] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/components/debounce.c: from TRUNK: make debounce cfg= parameter match the documentation
[02:05:30] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note change
[02:57:49] <tomp> addf'ing all the reads and writers got me my first lockup.
[02:58:05] <tomp> i'm taking pictures, and will send the .exe's
[02:59:30] <tomp> jepler's .hal file ran for over an hour before i quit emc and added the .1 .2 reads & writes ( and then locked )
[03:01:08] <tomp> tomorrow i will see if the board can perform the same way or has changed
[03:01:42] <tomp> i have another board i will not try until thats known
[03:01:55] <tomp> +
[03:19:53] <tomp> ok, w$ demos on the way, photos taken
[03:24:46] <tomp> if the phots dont turn out well...
[03:26:13] <tomp> the only codes i think are important are on the Tiger 320 | www.tjnet.com | 0509 F6N4P-001
[03:27:01] <tomp> the board silkscreen say ET-PCI8255 V3
[03:28:27] <tomp> the top leftmost chip sez 8255#1(C0H-CFH), then smaller 8255#1(C0H,C4H,C8H, CCH)
[03:29:15] <tomp> the top middle chip sez 8255#2(D0H-DFH), then smaller 8255#2(D0H,D4H,D8H, DCH)
[03:30:41] <tomp> the top rightmost chip sez 8255#3(E0H-EFH), then smaller 8255#3(E0H,E4H,E8H, ECH)
[03:32:26] <tomp> 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? )
[03:32:44] <tomp> and no reply to my request for src of thier library
[03:32:50] <tomp> gnite
[09:02:43] <joeKr> 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?
[12:31:11] <skunkworks_> jepler: you wanted me to test something?
[12:33:27] <jepler> joeKr:
http://thread.gmane.org/gmane.linux.distributions.emc.devel/947
[12:34:19] <jepler> 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..
[12:34:55] <jepler> skunkworks_: looks like I can't get at the file I wanted you to run at the moment...
[12:36:33] <jepler> skunkworks_: I think I left the machine turned off
[12:44:59] <skunkworks_> heh
[12:45:07] <skunkworks_> no problem
[13:13:35] <cradek_> cradek_ is now known as cradek
[13:16:42] <joeKr> jepler: Thanks for the link
[13:21:49] <joeKr> 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.
[13:22:59] <rayh> joeKr, There certainly will be folk there who do those things every day.
[13:39:02] <joeKr> 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?
[13:44:08] <rayh> I spoke with Roland yesterday and he is certain it will happen.
[13:44:32] <rayh> He is the main guy for it.
[13:44:44] <SWPadnos> probably 150+ people showed up over the course of the week
[13:45:03] <rayh> Mornin Steven.
[13:45:07] <SWPadnos> morning
[13:46:20] <SWPadnos> 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
[13:46:41] <SWPadnos> and I'm sure someone can help you out if you have reasonably specific questions at the workshop
[13:47:23] <cradek> or here
[13:48:02] <SWPadnos> yes, that too :)
[13:49:02] <rayh> 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.
[13:49:17] <SWPadnos> comp would be a good thing to go over
[13:49:18] <cradek> 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
[13:49:23] <SWPadnos> itr sure makes making modules easy
[13:49:59] <cradek> so, I think the best thing to do is for you to ask questions about the things you can't figure out.
[13:50:34] <joeKr> Can you recommend a good teach-yourself website to learn linux software development? To get started generally, I mean?
[13:50:47] <rayh> Big qt4 update to 8.04 this morning
[13:50:55] <SWPadnos> I can't. "Linux Development" is a very very big subject
[13:51:10] <SWPadnos> since it covers everything from the kernel to applications like OpenOffice ...
[13:51:18] <rayh> Do you have a programming background joeKr
[13:51:44] <SWPadnos> there are docs on the linuxcnc website that describe how EMC works, though I'm not sure exactly where they are right now
[13:52:15] <SWPadnos> I can send you a paper on the history of EMC, which includes some description of how the pieces fit together
[13:52:41] <SWPadnos> do you have a Linux system to use to fiddle around with the code?
[13:53:15] <joeKr> 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.
[13:53:39] <cradek> 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?
[13:55:10] <joeKr> Yes, I have done embedded programming and PLC programming both by icon and by list. And CNC programming and fixturing. And CNC repair.
[13:56:07] <joeKr> I've never tried to develop any software (except for a little Perl once) in Linux.
[13:56:58] <cradek> so if you knew how to get and compile the source, you could work with it? is that the obstacle right now?
[13:56:58] <rayh> There are some interesting python tutorials laying around.
[13:58:12] <rayh> "get and compile the source" There is a workshop session.
[13:58:28] <joeKr> 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.
[13:58:30] <cradek> I disagree - that's a wiki page:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2 (section 3)
[13:59:05] <SWPadnos> I use Kate a lot of the time, and try out integrated environments like Anjuta from time to time
[13:59:11] <SWPadnos> or gedit :)
[13:59:12] <cradek> I think "here's some commands to type" is a waste of class time
[13:59:29] <cradek> editor doesn't matter. the source is made up of text files. use whatever you like.
[13:59:45] <cradek> joeKr: (that link above was for you)
[13:59:52] <joeKr> I never heard of Kate or Anjuta, I'll Google them later.
[14:00:10] <SWPadnos> Kate is the notepad-like editor for KDE (rather than Gnome)
[14:00:32] <rayh> I kinda agree but kinda disagree. A certain bit of hand holding or watching over a guys shoulder can ease the tension a bit.
[14:00:37] <SWPadnos> Anjuta is a somewhat promising environment with some cool features like word completion and that sort of thing
[14:01:10] <SWPadnos> yes, a class that lets people knowwhat they're supposed to see is a good thing - it breaks a fear barrier
[14:03:02] <rayh> But you are right, Chris that the wiki is the place to start and IRC can handle any issues.
[14:03:41] <joeKr> What types of things are on you guy's to-do list lately? What's at the top, the 8.04 switchover?
[14:03:41] <cradek> 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
[14:04:29] <rayh> Yep and I understand those folk will be back this year.
[14:05:01] <SWPadnos> well, that's true too
[14:05:29] <cradek> you can't make developers by giving classes. developers come to the project with their skills, wanting to help
[14:05:44] <cradek> but you CAN make users by giving classes that show how easy it is to use, and how well it works
[14:05:52] <joeKr> Yeah, retrofitting for the average guy is tough enough what with setting (& understanding) parameters, figuring out I/O, etc., etc.
[14:06:19] <joeKr> Without any "internal" programming
[14:06:39] <rayh> Someone mentioned "comp" a bit ago.
[14:06:44] <SWPadnos> yep
[14:07:00] <joeKr> What types of things are on you guy's to-do list lately? What's at the top, the 8.04 switchover?
[14:07:21] <joeKr> oops
[14:07:42] <SWPadnos> getting enough testing on that would be good
[14:07:49] <jepler> 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
[14:07:50] <joeKr> sorry for the double, gotta be careful when scrolling back, LOL
[14:08:04] <jepler> but the next major user-visible thing will be the official packages and live CD for Ubuntu 8.04 LTS
[14:08:18] <SWPadnos> there's also a (blessedly short) bug list
[14:08:56] <cradek> my favorite 80%-done addition is a new cutter diameter compensation algorithm
[14:09:21] <rayh> Yea yea that too.
[14:09:33] <jepler> also I think we're going to do an integrated spam filter and web browser in the next version
[14:09:40] <cradek> ha
[14:09:43] <joeKr> What about lathes? Is that a seperate version, or is EMC2 sufficiently adaptable?
[14:09:50] <SWPadnos> suficiently adaptable
[14:09:51] <cradek> there's good lathe support already
[14:10:12] <rayh> I'm thinking a 2.3 final feature set will come from fest.
[14:10:12] <joeKr> How about "non-trivkins" lathes?
[14:10:14] <cradek> lathe will also benefit from the new diameter comp
[14:10:21] <jepler> spindle-synchronized motion, feed-per-revolution, constant surface speed, and canned threading cycle are the main lathe-specific features
[14:10:33] <SWPadnos> hmmm. what would a non-trivkins lathe look like?
[14:10:40] <jepler> that's a new one on me
[14:10:43] <SWPadnos> a robot arm moving the cutter for a lathe?
[14:10:49] <cradek> brb
[14:10:50] <rayh> I saw a hexapod lathe a few years ago.
[14:11:15] <rayh> It moved the spindle against a stationery wall of tools.
[14:11:18] <SWPadnos> well, it hasn't been done, and at the moment it would probably be a difficult configuration to do
[14:11:24] <SWPadnos> cool
[14:11:43] <rayh> No barfeed though.'
[14:11:58] <SWPadnos> correction: I don't know of anyone who has used EMC2 for a non-trivkins lathe
[14:12:01] <skunkworks_> joeKr:
http://www.youtube.com/watch?v=ACvRilmIKDQ
[14:12:05] <SWPadnos> it may have been done :)
[14:12:38] <joeKr> 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?
[14:12:56] <SWPadnos> oh, ok. that's kind of trivkins with some extras
[14:13:25] <rayh> Live tooling?
[14:13:40] <SWPadnos> 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
[14:13:51] <SWPadnos> (not a 1:1 mapping of motors/actuators to cartesian axes)
[14:13:51] <jepler> emc's gcode interpreter is not well suited to a system where you have more than one "controlled point" (cutter tip)
[14:13:58] <jepler> that's different than trivkins vs non-trivkins
[14:14:54] <jepler> an example of a non-trivkins machine:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Koppi's_Toy
[14:20:03] <cradek> 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)
[14:20:41] <skunkworks_> or this
http://www.youtube.com/watch?v=mxxdq6y8z8M
[14:21:15] <skunkworks_> or
http://www.youtube.com/watch?v=7WCrqqoZkPg
[14:21:21] <skunkworks_> * skunkworks_ thinks it is so neat
[14:21:23] <SWPadnos> 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
[14:21:44] <SWPadnos> 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)
[14:22:03] <joeKr> 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?
[14:22:40] <jepler> joeKr: there's a related blog entry
http://jmkasunich.com/cgi-bin/blosxom/shoptask/fusee-1.html
[14:22:50] <rayh> JMK built that to harness the power of a mousetrap and turn it into rotary motion for a robot.
[14:23:07] <jepler> also
http://jmkasunich.com/cgi-bin/blosxom/shoptask/eng-week-02-21-08.html
[14:23:10] <cradek> the fusee shape has a lot of uses (really)
[14:23:13] <SWPadnos> not EMC, but here you go:
http://www.youtube.com/watch?v=oGq-9NNmr3o
[14:23:43] <SWPadnos> (about 1:30 into it, I think)
[14:23:49] <cradek> watches/clocks use/used it for torque equalization of a spring drive
[14:24:05] <SWPadnos> oh - 0:56 into it
[14:24:46] <rayh> SWPadnos, why do you think USB is "not an ideal solution?"
[14:24:52] <SWPadnos> time and feedback
[14:25:23] <SWPadnos> I've had an email exchange with the smoothstepper guy, and I'll be meeting him this weekend
[14:25:45] <rayh> When EMC was a NIST, SENSE-MODEL-ACT was their mantra.
[14:26:28] <SWPadnos> unless you put it all into the remote device, you can't do things like electronic gearing or spindle sync
[14:26:53] <SWPadnos> you also lose feedforward if you just provide a list of positions (even for a servo controller)
[14:27:01] <SWPadnos> (for the most part anyway)
[14:27:32] <SWPadnos> depending on the machine type, you may need all following error tracking to be done in the remote device
[14:27:35] <jepler> 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
[14:27:36] <SWPadnos> etc. etc.
[14:27:49] <SWPadnos> that's true
[14:28:05] <joeKr> What would the USB device you're talking about do?
[14:28:08] <SWPadnos> essentially, if you can run EMC on the USB device, then all is well :)
[14:28:14] <jepler> joeKr: there *is* no USB device
[14:28:26] <jepler> but a lot of people show up and ask the content-free question "why doesn't emc work on usb"
[14:28:29] <SWPadnos> joeKr, there are USB devices that generate smooth step streams
[14:28:35] <SWPadnos> jepler, there are USB devices
[14:28:44] <SWPadnos> they just don't work with EMC, and they aren't
[14:28:47] <SWPadnos> "realtime"
[14:29:15] <SWPadnos> my basic view is that USB is fine for some open-loop applications, but I don't like it :)
[14:29:30] <joeKr> Has the recent addition of CAN to the kernel done anything for you guys?
[14:29:39] <jepler> no. kernel drivers are not realtime
[14:30:15] <joeKr> I thought EMC2 was running a RT kernel?
[14:30:30] <SWPadnos> it is, but most drivers aren't part of the realtimesystem
[14:30:39] <jepler> yes, but normal linux kernel device drivers cannot be used from "realtime" code.
[14:30:41] <joeKr> Is CAN?
[14:30:52] <SWPadnos> not really
[14:31:22] <SWPadnos> 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
[14:31:59] <SWPadnos> and that's just the physical layer - it sayts nothing about how long the system will take to respond to a packet
[14:33:01] <SWPadnos> 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
[14:33:58] <jepler> (emc checks position feedback and sends new position commands every 1ms in all the default configurations)
[14:34:29] <joeKr> Ethernet is also non-deterministic but has nonetheless been adapted successfully to some high-speed real-time uses.
[14:34:39] <SWPadnos> that's RTnet
[14:34:57] <SWPadnos> which uses physical ethernet hardware but a completely different protocol - it's time-sliced
[14:36:14] <SWPadnos> I believe it uses error checking, and doesn't retransmit automatically. so the application has to know how to deal with communication errors
[14:36:38] <SWPadnos> (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)
[14:37:11] <joeKr> 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?
[14:37:24] <jepler> usually during the afternoon and evening in north america
[14:37:45] <joeKr> Where do most of the developers live?
[14:37:58] <SWPadnos> mostly in north america :)
[14:38:16] <joeKr> Close to the Fest location?
[14:38:20] <SWPadnos> though it depends on how you define "developer" - there are translators all over the place
[14:38:27] <SWPadnos> not me, it's a 2-day drive each way
[14:38:36] <SWPadnos> (Vermont)
[14:38:42] <jepler> 6-7 hours for me, I think
[14:38:45] <cradek> few things are close together in north america
[14:39:49] <joeKr> I'm also 6-7 hrs away from the fest, according to mapquest
[14:41:16] <joeKr> Where do people stay while at the fest?
[14:41:57] <SWPadnos> various crappy motels in Galesburg :)
[14:42:27] <SWPadnos> if you have a tent or camper, there's a big field next to the workshop
[14:43:18] <SWPadnos> there are a couple of reasonable hotels too, at around $80-90/night
[14:43:27] <joeKr> Not just *one* favorite crappy motel? Well, *that* complicates things, LOL
[14:43:50] <SWPadnos> search google for "galesburg hotel", and you'll get the full list
[14:44:34] <SWPadnos> there was a list on the cnc workshop website last year, but it hasn't been updated
[14:46:17] <joeKr> OK, I'd better go. Thanks for the chat, all. Back later.
[14:48:36] <jepler> see you joeKr
[14:54:45] <rayh> Hey SWPadnos you still around. I've got one experience with usb and a lathe doing threading.
[14:55:14] <SWPadnos> yes
[14:55:21] <SWPadnos> what USB device?
[14:56:01] <rayh> I didn't get a chance to look in. It was a China factory.
[14:56:07] <SWPadnos> ok :)
[14:56:26] <rayh> Looked to me to be USB to parallel and back.
[14:56:53] <rayh> almost like a computer in a box.
[14:57:14] <SWPadnos> ok, so the motion controller was running on the USB device, and the computer was telling it where to go
[14:57:22] <SWPadnos> ?
[14:57:53] <rayh> No the motion was really timed by the computer anyway.
[14:57:59] <SWPadnos> hmmm. ok
[14:58:23] <rayh> So once it got into a thread pass it would cut fine.
[14:58:43] <rayh> But had a very hard time getting the start of the thread pass right.
[14:59:00] <cradek> what do you mean hard time?
[14:59:07] <skunkworks_> yeck
[14:59:12] <rayh> Sometimes you'd see it come back to the starting position and take off right into the next pass.
[14:59:29] <rayh> Other times it had to wait until it got it's USB ducks in a row
[14:59:52] <rayh> Almost like saying, "How about now"
[14:59:52] <SWPadnos> 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!"
[15:00:01] <SWPadnos> though that can be hard to tell when just looking at a device :)
[15:00:02] <rayh> I think so.
[15:00:26] <cradek> there is a tradeoff between faith and electronic gearing
[15:00:42] <cradek> people use faith to do tapping all the time
[15:00:42] <rayh> The spindle to axis interlock had to be on the outboard side of the USB
[15:00:58] <SWPadnos> for some appications (trivkins machines, simple gearing/slaving, no PID ...), a device like that can work
[15:01:36] <cradek> I wonder if a VFD spindle would be constant speed enough to thread with "faith" only
[15:01:48] <SWPadnos> 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
[15:01:50] <skunkworks_> with no feedback?
[15:02:05] <SWPadnos> cradek, VFD spindle and a floating tap holder works great
[15:02:08] <SWPadnos> even with no VFD
[15:02:09] <cradek> yes or minimal feedback (rpm from the vfd)
[15:02:25] <skunkworks_> maybe for 1 pass :)
[15:02:28] <cradek> SWPadnos: yes I bet so
[15:02:37] <cradek> skunkworks_: well yeah, there is that
[15:02:42] <rayh> It looked to me like they had a tiny window on the outboard and USB had to hit it.
[15:02:43] <SWPadnos> a tapmatic is a few hundered $$ new, and is much easier to use and set up than spindle encoders and stuff
[15:03:29] <cradek> 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
[15:03:32] <rayh> If you have a step generator and trajectory planner out there you still have the problem of feedrate override and abort/estop.
[15:03:58] <SWPadnos> sure - I'm just pointing out the argument that some people have: you don't need rigid tapping to tap :)
[15:04:13] <SWPadnos> rayh, with protocol control, you can get around that
[15:04:26] <SWPadnos> but that does raise the problem of paths that change depending on speed
[15:04:30] <SWPadnos> err - feed
[15:04:36] <SWPadnos> like G64P--
[15:04:37] <rayh> Don't you have to assume constant rotary velocity and constant linear velocity to do open loop threading.
[15:04:39] <cradek> sure, you can use faith (T/C holder and rig your speed/feed) instead
[15:04:50] <cradek> rayh: yes definitely
[15:04:59] <SWPadnos> on a lathe, yes
[15:05:08] <SWPadnos> on a mill with a tap holder, not so much
[15:05:09] <cradek> rayh: constant linear is easy. constant spindle is what I wonder about - maybe you can come close enough
[15:05:31] <rayh> So the cutting load has to be tiny compared to the inertia of the spindle
[15:05:45] <cradek> yes, or the spindle needs to have closed loop speed control
[15:05:46] <SWPadnos> it's funny - I had this discussion after the ESC talk, with someone from Rockwell and someone from Hitachi
[15:05:55] <rayh> Or you have to have load sensing and good speed correction.
[15:06:09] <SWPadnos> when I mentioned that you need feedback to thread, they said, well, not if the spindle motor is servoed or big enough
[15:06:34] <SWPadnos> which is what everyone says about not using feedback: if the motors are big enough, then you don't need to worry about it
[15:06:58] <SWPadnos> that's the stepper mantra too - make sure the motors have enough torque that they will *never* lose a step under normal operating conditions
[15:07:34] <rayh> It seems like feedback is easier to do than for me to make the assumption about my spindle.
[15:08:02] <SWPadnos> it's an error-checked solution, rather than an assumption
[15:08:16] <SWPadnos> which may be why I like it better too
[15:08:28] <rayh> Sense-Model-
[15:08:32] <rayh> Act
[15:08:36] <SWPadnos> acting, thank you!
[15:08:54] <rayh> typoing 101 was my best course.
[15:08:57] <SWPadnos> heh
[15:09:49] <SWPadnos> 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
[15:09:51] <rayh> With open loop, My eyes and ears are the sense part.
[15:10:06] <SWPadnos> that's more like act - SCREEEEE - react
[15:10:10] <rayh> Sure.
[15:10:29] <rayh> Yes it is during the integration phase.
[15:10:45] <rayh> But I'm with you about motors big enough to handle the task.
[15:10:46] <SWPadnos> heh, then you lower the max_vel, and all is well
[15:10:59] <rayh> Sure that is one good way.
[15:11:27] <rayh> I remember getting that 32 stepper to 6k rpm on the bench here.
[15:11:41] <rayh> I just couldn't get it to stop without loosing steps.
[15:12:03] <SWPadnos> 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 ...
[15:12:10] <SWPadnos> heh
[15:12:22] <rayh> exactly
[15:12:24] <SWPadnos> one thing DeskCNC has is accel/decel limits that go down as speed increases
[15:12:31] <SWPadnos> since the motor has less torque
[15:12:41] <cradek> SWPadnos: a better comparison is: that way, you can approximate cruise control with a brick on the gas pedal
[15:12:46] <SWPadnos> yes :)
[15:12:46] <rayh> sure a nonlinear accel/decel
[15:13:11] <rayh> In the old days they had a knee in accel
[15:13:27] <SWPadnos> oh, at the torque knee?
[15:13:34] <SWPadnos> hmmm]
[15:13:38] <rayh> you got it
[15:13:50] <SWPadnos> that would be a real PITA for the planner
[15:14:12] <rayh> I suppose
[15:14:50] <SWPadnos> 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
[15:17:54] <rayh> Most of the machines I worked with had pretty quick accel so I don't know that much planning was needed for cutting speeds.
[15:57:47] <rayh_> rayh_ is now known as rayh
[17:18:23] <alex_joni> hi guys
[17:18:35] <skunkworks_> hi alex
[17:38:51] <alex_joni> * alex_joni never got feedback on the last livecd
[17:39:29] <SWPadnos> alex_joni, I'll try it out this weekend, on several machines
[17:39:36] <SWPadnos> I just haven't had a chance to do it yet
[17:39:55] <rayh> Well alex_joni it worked great here.
[17:39:58] <alex_joni> guess I'll wait a while..
[17:40:10] <alex_joni> rayh: that's good to hear.. I also have it running on a couple machines
[17:40:38] <rayh> You bet. As far as I'm concerned I'd vote for an official release.
[17:40:59] <SWPadnos> lets see if it'll boot on my laptop first. at least it'll be another data point
[17:41:04] <rayh> With 2.2.5
[17:41:06] <alex_joni> taking a short trip tp germany on friday
[17:41:13] <alex_joni> s/tp/to/
[17:41:25] <rayh> Where?
[17:41:28] <alex_joni> but after that I'll be back & available for "official" support
[17:41:32] <SWPadnos> I think I'll have access to some Dell machines over the weekend
[17:41:32] <alex_joni> rayh: stuttgart again
[17:41:45] <alex_joni> SWPadnos: remember the 'irqpoll' bootoption if all fails
[17:41:46] <SWPadnos> don't know how many models
[17:41:47] <rayh> You seeing any of our folk there.
[17:41:48] <SWPadnos> ok
[17:41:58] <alex_joni> rayh: nope, don't think so
[17:42:15] <alex_joni> I'm back on saturday morning
[17:42:19] <alex_joni> so it'll be a short trip
[17:42:23] <rayh> Not long at all.
[17:42:35] <alex_joni> slightly over 24h
[17:43:28] <rayh> I've noticed real slowdowns with 8.04 soon after updates but once things clear up it seems to run very well
[17:44:17] <rayh> Anyone have experience with pcmcia parport cards and EMC?
[17:44:29] <alex_joni> I ran one once
[17:44:36] <alex_joni> (but it was a bit of a fight :)
[17:44:49] <alex_joni> I only managed to get it working after installing the linux driver
[17:45:03] <alex_joni> (modprobe parport_cs)
[17:45:08] <alex_joni> cat /proc/ioports
[17:45:18] <alex_joni> rmmod parport_cs (and whatever is dependent)
[17:45:27] <alex_joni> then modprobe hal_parport cfg=...
[17:45:29] <rayh> And then you could directly address it.
[17:45:42] <alex_joni> yeah.. until then it didn't want to run
[17:45:56] <rayh> I can see that.
[17:46:05] <alex_joni> but I read some stuff afterwards, and I didn't check if I had PnP disabled in the BIOS
[17:46:27] <rayh> PnP makes it easier?
[17:46:40] <alex_joni> I think it needs to be disabled
[17:46:46] <rayh> Oh okay.
[17:46:52] <alex_joni> that way BIOS enables the card, and doesn't rely on the OS to do so
[17:47:08] <alex_joni> <- might be full of hot air though
[17:47:21] <SWPadnos> no, not this time :)
[17:47:29] <alex_joni> SWPadnos: usually?
[17:47:32] <rayh> Hey that helps. Got someone sending me a card to try.
[17:47:40] <alex_joni> rayh: same here :D
[17:47:40] <SWPadnos> setting the BIOS to "non PnP OS" will cause it to do some more initialization of PnP devices
[17:47:45] <SWPadnos> or at least it should
[17:47:56] <rayh> I see that.
[17:47:56] <alex_joni> SWPadnos: right.. should
[17:47:58] <SWPadnos> but you also need a "non-buggy BIOS" for that to work ;)
[17:48:10] <rayh> So if the device is in there during boot it may find out more about it.
[17:48:24] <alex_joni> in my case it was a laptop (go figure.. with a pcmcia)
[17:48:35] <SWPadnos> I don't know that the BIOS will ever enable PCMCIA cards though
[17:48:37] <rayh> Quatech SPP-100 G is the card
[17:49:06] <rayh> They say something about linux and some card mode.
[17:49:23] <alex_joni> this one is labeled Delock
[17:49:23] <rayh> I'm guessing they were thinking spp only.
[17:49:24] <jepler> alex_joni: I only booted the livecd on two machines, but it looked OK on both
[17:49:43] <alex_joni> 32 bit cardbus -> parport
[17:49:56] <tomp2> jepler: i have 'halrun pci8255.hal' running again. (board is not broke by 1 lockup :) should i be running some read loop?
[17:50:16] <tomp2> quatech pcmcia par
http://pcmcia-cs.sourceforge.net/ftp/SUPPORTED.CARDS
[17:50:17] <jepler> tomp2: what emc version do you have - 2.2.5, or something older?
[17:50:24] <tomp2> checking
[17:51:40] <alex_joni> wheee.. just found a 4.10 LiveCD ;)
[17:54:38] <rayh> Yipee.
[17:54:58] <tomp2> jepler: EMC2 pre-2.3 CVS Head kernel 2.6.15 magma rtai 3.0
[17:56:17] <jepler> 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.
[17:57:21] <tomp2> looking at time stamps is all i can think of....
[17:57:29] <jepler> look at src/hal/pci_8255.c
[17:58:05] <jepler> look at src/hal/CVS/Entries (the version with the fix is 1.3)
[17:58:32] <jepler> er, add "drivers" in both cases
[17:58:38] <jepler> $ grep pci_8255 src/hal/drivers/CVS/Entries
[17:58:38] <jepler> /pci_8255.c/1.3/Fri Apr 4 16:18:46 2008//
[17:58:49] <jepler> ^^ in my case, shows that I have revision 1.3 that I got on April 4
[17:59:47] <tomp2> jepler: src/hal/drivers/pci_8255.c jan 21 2007
[18:00:29] <jepler> 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.
[18:00:52] <tomp2> will do, need come cat5 or widfi nic
[18:00:54] <jepler> or, using just port 0, you could try to verify whether inputs actually work (HAL pins change when you present signals on them)
[18:01:00] <jepler> either one is helpful to me
[18:01:26] <tomp2> can do that too, i think i have some breakouts & breadboard... but later
[18:02:33] <jepler> 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.
[18:03:00] <jepler> 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
[18:03:44] <alex_joni> bbl..
[18:05:18] <cradek> 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?
[18:06:04] <jepler> cradek: I think I meant G92
[18:06:16] <skunkworks_> jepler: your inputs don't seem to work?
[18:06:19] <cradek> ok I figured. but, I don't know if the statement is correct
[18:06:21] <jepler> skunkworks_: nnot lately
[18:06:24] <skunkworks_> huh
[18:06:32] <cradek> I know G43 is not ignored.
[18:07:47] <jepler> 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.
[18:07:54] <jepler> cradek: not sure
[18:08:08] <cradek> I verified that the statement is correct with G92 there
[18:08:08] <jepler> cradek: All I can say is, I must have thought it was true when I wrote it
[18:08:46] <jepler> I have to get back to work ..
[18:09:01] <jepler> tomp2: I'll look later at anything else you say, but I have to go for now
[19:41:06] <SWPadnos> haha - just got an email from IEEE about an "Innovation Forum", with this great line in it:
[19:41:16] <SWPadnos> "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."
[19:41:24] <SWPadnos> That's what I need, innovation training
[19:41:29] <alex_joni> haha
[19:41:37] <SWPadnos> cutting-edge, no less
[19:41:39] <alex_joni> to enhance your organization..
[19:41:44] <alex_joni> well.. that might have something
[19:41:53] <SWPadnos> heh
[19:41:54] <alex_joni> * alex_joni hears SWPadnos is a bit disorganized
[19:41:55] <SWPadnos> :P
[19:42:12] <SWPadnos> organizationally challenged, thank you very much
[19:42:31] <alex_joni> haha
[19:44:44] <tomp> jepler: now running pci8255 with todays cvs trunk, run-in-place. no complaints so far with original 8255.hal
[19:45:00] <alex_joni> tomp: can you see inputs changing?
[19:45:02] <tomp> will dig up some p/u res & jmprs to fiddle inputs
[19:45:12] <tomp> not yet
[19:45:42] <tomp> idc brkout needed
[19:45:45] <alex_joni> when testing parports I usually use a wire to connect an output to an input
[19:45:53] <alex_joni> might work for 8255 too :)
[19:46:23] <tomp> thx (got inet on the box now :)
[19:51:15] <skunkworks_> floppy drive cables...
[19:51:26] <skunkworks_> I just cut an end off and stripped a few.
[20:03:04] <jepler> best to use a resistor between the two pins so that if you set them both as outputs from 8255 they do not fight
[20:03:30] <skunkworks_> *fight = Smoke
[20:03:33] <skunkworks_> ;)
[20:23:26] <skunkworks_> latest hardy livecd is installing on 256mb with no issues.
[20:23:30] <skunkworks_> so far
[20:25:05] <tomp2> 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
[20:25:25] <tomp2> i went to check the state so i could pull up or not, and saw them toggling
[20:26:44] <tomp2> ...has them 'hal-connected' to the charge pump...
[20:27:19] <tomp2> jepler: they are already toggling
[20:27:31] <skunkworks_> you mean they randomly change state?
[20:27:43] <skunkworks_> I was seeing that..
[20:27:47] <tomp2> no, on/off/on/off, will halscope now
[20:28:02] <jepler> tomp2: well that's .. interesting
[20:28:28] <skunkworks_> they seem to have no pull ups/down resisters.
[20:29:24] <jepler> the datasheet I've been most frequently referring to shows that the ports have "bus-hold" circuitry
[20:29:59] <SWPadnos> the 8255 outputs should retain state until explicitly written to again
[20:30:06] <SWPadnos> (if that's what you were talking about)
[20:30:12] <jepler> 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
[20:30:42] <jepler> I'm not 100% certain if this is a feature of all 82c55 chips or just the Harris-branded one in this datasheet.
[20:31:00] <SWPadnos> it sounds like their chips may be designed to be defective ;)
[20:31:16] <jepler> 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
[20:31:18] <SWPadnos> the whole point of an 8255 is to latch some state
[20:32:02] <tomp> halscope sez its toggling at fixed freq... will zoom in & lllok
[20:33:10] <tomp> 2.5ms period, dead even trapezoid
[20:33:24] <SWPadnos> where's that hal file again?
[20:33:43] <tomp> will pastebin
[20:33:57] <SWPadnos> wasn't it on jepler's site?
[20:34:01] <jepler> http://emergent.unpy.net/files/sandbox/8255.hal
[20:34:16] <SWPadnos> thanks
[20:34:32] <jepler> 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.
[20:35:41] <SWPadnos> 2.5ms?
[20:35:46] <jepler> well I was wondering about that too
[20:35:50] <SWPadnos> heh
[20:36:15] <SWPadnos> ah, it's the funny halscope way of drawing single data points as 2 line segments
[20:36:36] <tomp> http://pastebin.ca/1011050
[20:37:49] <tomp> pci8255.0.0.a dont change and .c dont change
[20:38:50] <SWPadnos> ok, good :)
[20:39:48] <tomp> how is the chargepump wired to the inputs physically? saying words like 'net blah bl;ah blah' doesnt make current flow
[20:39:53] <tomp> i sthe scope correct?
[20:40:24] <SWPadnos> you're looking at internal signals that are going to outputs on the card - that has nothing to do with the inputs
[20:40:25] <jepler> huh?
[20:40:38] <jepler> yes, what SWPadnos said
[20:40:41] <tomp> how can the inputs change with no phys connection
[20:40:47] <SWPadnos> the scope is correct, but you have to understand that it draws traces in what I consider to be a weird way
[20:40:52] <SWPadnos> those aren't inputs
[20:41:00] <SWPadnos> all the B are set to output
[20:41:01] <jepler> ah it's the "direction" confusion
[20:41:09] <tomp> that makes sense if they're outputs
[20:41:10] <SWPadnos> inputs to the driver connect to output pins
[20:41:18] <SWPadnos> input pins are outputs to HAL
[20:41:35] <SWPadnos> input physical pins are reflected by HAL output pins
[20:41:42] <tomp> stereo-ese oh
[20:42:40] <SWPadnos> 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
[20:42:50] <SWPadnos> the second half is a flat line at the current sample level
[20:43:22] <SWPadnos> 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
[20:44:00] <tomp> i didnt get the change, the slope didnt bother me as much ( my hal probe needs adjustment anyways, wheres the trim pot? :)
[20:44:17] <SWPadnos> you get _/-\_ instead of -|_|- (pardon the ascii art, I have no "top bar" character :) )
[20:45:01] <tomp> yah, got that, i make bad joke about adjusting a real scope probe for sqr wave
[20:45:10] <SWPadnos> yeah, got it ;)
[20:45:22] <SWPadnos> the adjustment is in scope_disp.c I think ;)
[20:50:43] <skunkworks_> it is called - upping the base period.
[20:50:49] <skunkworks_> lowering?
[21:14:48] <tomp> bbl shutdown to cnx cables
[21:21:50] <skunkworks_> I swear - I didn't think they could make installing ubuntu easier - but they did. What - like 4 screens and it is installing.
[21:24:39] <skunkworks_> (and easy questions at that.. )
[21:34:15] <skunkworks_> yeck. 2 dells here both have 60+us latency.
[21:41:07] <tomp2> i hooked port A pin 25 (+5V) to 2.2K to pin1 (pulled up pci8255.0.0.a0) hung immed
[21:41:33] <tomp2> shutdown, pulled board, sniffed & put lips on chisp to find 8255 warm lower right
[21:41:56] <tomp2> removed pullups and reseated & rebooted, immed hung
[21:42:20] <tomp2> shut down removed 8255 rebooted, now ok 8255 dead
[21:43:02] <tomp2> if it's ttl compat, then +5 to 2.2k to input shoulda been ok
[21:43:23] <tomp2> running now sans chip#1
[21:44:51] <skunkworks_> these have 82865 intel chips.. wonder if I disable smi.
[21:46:21] <skunkworks_> wiki says 82845
[21:49:01] <SWPadnos> heh - too funny
[21:49:26] <SWPadnos> I was in the emc2/src dir, and wanted to show threads, so I typed halcmd show thr<tab><tab>, and thread showed up
[21:49:48] <SWPadnos> I thought - whoah, this is older halcmd, and shouldn't have that completion stuff in it
[21:50:09] <SWPadnos> then I realized that there are hal comps called threads and threadtest in that dir :)
[22:03:09] <jepler> I only half-implemented completion in bash of halcmd, anyway
[22:03:11] <skunkworks_> smi was it. insmod rtai_smi.ko and now the latency test is sub 10us
[22:03:23] <jepler> tomp2: ouch
[22:04:02] <jepler> I think it's time to consign those futurlec 8255 boards to the trash heap
[22:09:23] <skunkworks_> wouldn't it be a good emc_fest project.. Then we can throw them into one of rolands punch presses?
[22:09:54] <tomp2> i got xtra 8255s, i'll try the w$ software
[22:10:31] <skunkworks_> this is cool
http://imagebin.ca/view/bmhQu9.html
[22:11:21] <skunkworks_> it is cool now that the rtai_smi module is in the rtai directory.
[22:11:44] <jepler> that's good new
[22:11:45] <jepler> s
[22:15:18] <skunkworks_> still going. rock solid. Neat.
[22:15:46] <skunkworks_> alex_joni: ^ your latest livecd installed.
[22:31:49] <jmkasunich> 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
[22:32:21] <jmkasunich> 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
[22:33:05] <jmkasunich> 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
[22:33:58] <SWPadnos> 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)
[22:34:14] <skunkworks_> btw - what was changed to make the velocity more accurite from the hal encoder? I assume it initally was just time between pulses/distance?
[22:34:25] <jmkasunich> yeah
[22:34:55] <jmkasunich> initially it was just "number of pulses this servo period" divided by "length of a servo period"
[22:35:24] <SWPadnos> 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)
[22:35:27] <jmkasunich> now it notes the actual time of the first and last pulses in the servo period (with resolution determined by base period)
[22:36:43] <skunkworks_> neat
[22:37:14] <SWPadnos> and with hardware counters that timestamp, the resolution is waaaaay better (though probably not needed)
[22:37:31] <jmkasunich> better is good, waaay better is probably overkill
[22:37:36] <SWPadnos> yeah
[22:37:56] <jmkasunich> uS resolution is significantly better than base period resolution, nS resolution is overkill
[22:38:24] <SWPadnos> hmmm. is there's separate encoder function to update counts/velocity/"position", right (I guess there has to be since that uses FP)
[22:38:35] <SWPadnos> s/there's/there a/
[22:38:50] <jmkasunich> basically the resolution of the velocity output is the better of "1/counts per servo period" and "timestamp resolution/servo period"
[22:39:15] <jmkasunich> SWPadnos: there is a "capture" that is called at the servo rate - it does the math
[22:39:32] <jmkasunich> "count" is called at the base rate to do the actual raw counting
[22:40:08] <SWPadnos> 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)
[22:40:17] <jmkasunich> 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)
[22:40:47] <jmkasunich> I'd have to look at the code, but I think I solved the atomic problem
[22:40:55] <SWPadnos> right - assume that the next timestamp will be "just after now" and extend the period accordingly
[22:41:05] <SWPadnos> I think there's a double-read or something there
[22:41:10] <SWPadnos> that should always succeed
[22:41:12] <jmkasunich> something like that
[22:41:40] <jmkasunich> gotta go, back in a few hours
[22:42:06] <SWPadnos> see ya