Back
[00:32:50] <cradek> yay, I finally have a working microphone/headset
[00:33:09] <cradek> now I can continue to never use ekiga/skype, but not blame it on hardware
[00:33:50] <DanielFalck> cradek: hi, I just wrote a small *dxf to *apt converter in python
[00:34:06] <DanielFalck> it was easy in python
[00:34:09] <cradek> interesting
[00:34:23] <cradek> apt defines geometry doesn't it?
[00:34:28] <DanielFalck> so now I can take Qcad files and convert them to the primitives in apt
[00:34:37] <DanielFalck> for a quick sketch
[00:34:41] <cradek> (I know nothing about apt)
[00:35:01] <DanielFalck> just circles and lines
[00:35:15] <cradek> sounds neat
[00:35:27] <cradek> I noticed my machinery's handbook has some stuff about apt - one day I'll read it
[00:35:35] <DanielFalck> but, man python is great
[00:36:00] <cradek> you found a dxf-reading python module?
[00:36:41] <DanielFalck> no, I just did a very simple parser from scratch and did a trial and error thing with Qcad output
[00:36:46] <DanielFalck> it was very simple
[00:37:02] <DanielFalck> probably not very robust, but heh, it works for me
[00:37:23] <cradek> good enough - you can replace it later if you want to support other dxfs
[00:37:54] <DanielFalck> I thought it would be good to start with Qcad, since it's on eveyone's linux distro these days
[00:38:37] <cradek> you can't go wrong by supporting free software first
[00:39:53] <CIA-6> 03alex_joni 07TRUNK * 10emc2/configs/puma/puma.ini: fix ini (widen limits, increase accels to sane? values, tilt joint5 at home)
[00:49:10] <skunkworksemc> just found an 800v 80a 3 phase bridge complete with heatsink :)
[00:50:59] <jmkasunich> bzzzzt
[00:51:10] <jmkasunich> handle with care
[00:51:34] <skunkworksemc> as always :)
[00:51:44] <skunkworksemc> it was out of a plasma cutter iirc
[01:00:59] <skunkworksemc> that pretty much complete the power supply :)
[01:01:15] <alex_joni> that's a bad-ass power supply
[01:02:22] <skunkworksemc> well - the power supply will be a bit smaller than that ;)
[01:02:39] <skunkworksemc> but we don't have to worry about destroying the diodes I hope.
[01:02:40] <alex_joni> let me guess 40V, 2A
[01:02:43] <alex_joni> :D
[01:02:46] <skunkworksemc> Riiight ;)
[01:04:34] <alex_joni> good night all
[01:08:46] <crepincdotcom> I have a motor driver with outputs for field and arm
[01:08:52] <crepincdotcom> will it only work for AC motors?
[01:08:58] <crepincdotcom> or can I use DC as well
[01:09:01] <crepincdotcom> (for servos)
[01:20:02] <jmkasunich> http://img237.imageshack.us/my.php?image=rednecktimeoutdd3.jpg
[01:21:50] <skunkworksemc> :)
[01:28:46] <skunkworksemc> He's back :)
[01:28:57] <SWPadnos> run away!
[01:29:22] <jmkasunich> too late, you've been spotted
[01:29:32] <jmkasunich> still in fla? or back in the frozen north?
[01:29:35] <SWPadnos> damn
[01:29:38] <SWPadnos> frozen north
[01:29:43] <jmkasunich> bummer
[01:29:48] <SWPadnos> though it got up to 40 or so today, I think
[01:30:00] <jmkasunich> 35 or so here
[01:30:03] <SWPadnos> nah - it was getting monotonous in FL - sun, beach, hot ...
[01:30:50] <skunkworksemc> lightning storms, hurricanes
[01:31:06] <SWPadnos> had a couple of those as well (lightning at least - I missed the tornadoes)
[01:33:11] <SWPadnos> only 111 messages on the user list to read now (I'm catching up)
[01:33:45] <SWPadnos> + 74 Geckodrive, 42 CCED, and 82 commits left - quite a week, huh?
[01:34:14] <jepler> SWPadnos: welcome back
[01:34:19] <SWPadnos> thanks
[01:35:20] <jmkasunich> we have more traffic than CCED?
[01:35:29] <SWPadnos> way more this last week
[01:35:37] <SWPadnos> not even counting the dev list
[01:37:17] <SWPadnos> and it looks like the monthly web bandwidth is in the 500GB range (~17GB/day)
[01:43:26] <skunkworksemc> things are picking up
[01:45:23] <jepler> what's that -- mostly .iso downloads?
[01:48:10] <SWPadnos> dunno the distribution - I can probably check though
[01:48:15] <jepler> doesn't matter
[01:48:24] <jepler> I can't imagine what else it would be
[01:49:11] <SWPadnos> yeah. though the deb repos are there as well, aren't they?
[01:49:17] <jepler> yes they are
[01:49:31] <jepler> but that's only a few megs per download, rather than 600
[01:50:15] <SWPadnos> though you only need one CD to do many installs, all of which will download updates
[01:55:05] <SWPadnos> wow - 2213 hits from the browser "Debian APT-HTTP/1.3"
[01:55:16] <jepler> now find how many unique hosts
[01:55:30] <jepler> I wouldn't be surprised if the update-manager hits several times a day
[01:55:33] <SWPadnos> yeah - divide by 30 (at least) for the number of users ...
[01:55:42] <SWPadnos> default is once per day
[01:55:50] <SWPadnos> plus whenever the user presses "reload"
[01:55:59] <jepler> though not all machines will be on every day..
[01:56:06] <SWPadnos> true
[01:57:05] <SWPadnos> 5387 requests for an .iso file, representing 96.46% of bytes transferred
[01:57:42] <SWPadnos> .pdf and .deb are the only others above 1% (1.31 and 1.33, respectively)
[01:58:44] <jmkasunich> 5000+ iso downloads in a month?
[01:58:43] <jmkasunich> wow
[01:59:11] <SWPadnos> I'm not sure those all succeeded, but there were that many requests
[01:59:37] <jepler> yeah those can't all be complete -- 5000 * 7000 MB is 3500GB, a lot bigger than the monthly bandwidth
[01:59:41] <SWPadnos> though that would jive with the total bandwidth used as well
[01:59:48] <SWPadnos> err - what he said
[01:59:59] <jepler> except I had an extra zero when I transcribed it to IRC
[02:00:06] <SWPadnos> heh
[02:03:39] <jmkasunich> based on the apt hits, we have about 60 installs that are on all the time
[02:03:43] <jmkasunich> 70
[02:03:51] <jmkasunich> ish
[02:03:57] <jmkasunich> 70*30 days = 2100
[02:05:22] <jmkasunich> the disparity between 5000 download requests and 70 some installs seems really large
[02:05:42] <SWPadnos> that would be 70 installs that are on continuously, or more that are intermittent
[02:05:47] <jmkasunich> right
[02:06:02] <jmkasunich> and would complete miss those that aren't net connectred
[02:06:09] <SWPadnos> yep
[02:06:26] <jepler> most people have so much bandwidth they will download OS installs they never bother to try
[02:06:30] <jepler> (yes, I speak from experience)
[02:06:42] <SWPadnos> then there's Ray .... ;)
[02:06:43] <jmkasunich> you must have more bw than I do then
[02:07:05] <jepler> i participated in at least 3 fedora core torrents that I never installed
[02:07:45] <SWPadnos> even moderate DSL is enough for that - you just set up several CD downloads at night, and they're ready in the morning
[02:07:44] <jmkasunich> I may have gotten casual about 1meg downloads, but I still don't grab 700M on a whim
[02:08:18] <SWPadnos> roughly an hour each, so too much to wait for, but not too much to download when you have other things to do
[02:09:01] <jepler> I think chris is up to 6.0M download, that's just 15 minutes for a CD
[02:09:04] <jmkasunich> the data transfer numbers that ifconfig prints are since the last time the interface came up, right?
[02:09:15] <jepler> jmkasunich: yes, though it used to wrap at 31 or 32 bits
[02:09:20] <jepler> I don't think that's true anymore
[02:09:38] <jmkasunich> in the last 8 days, I've done 452M down, and 150M up
[02:09:44] <SWPadnos> wimp
[02:10:00] <jepler> I tend to do 8-12GB/mo each direction
[02:10:22] <jmkasunich> does that include the bw on cvs.linux.cnc? or just your main box?
[02:10:31] <jepler> that's everything -- it's the ISP's bandwidth report
[02:10:50] <jmkasunich> unpythonic too? or is that hosted elsewhere?
[02:10:53] <jepler> that too
[02:11:02] <skunkworks1> http://www.electronicsam.com/images/KandT/conversion/diodes.JPG
[02:11:43] <jmkasunich> not bad
[02:11:49] <jmkasunich> odd heatsink for those modules though
[02:12:01] <jmkasunich> thats a hockey-puck extrusion
[02:12:14] <skunkworks1> I assume it is original
[02:13:03] <jmkasunich> could be the manuf bought lots of that extrusion for their big stuff, so they use it for the little ones too
[02:13:32] <skunkworks1> this is some odd ratings.
http://www.electronicsam.com/images/KandT/conversion/yservomaybe.JPG
[02:14:26] <jmkasunich> whats odd about it?
[02:14:32] <jmkasunich> missing units for torque
[02:14:33] <skunkworks1> torque is 242 what?
[02:15:04] <jmkasunich> and no rated amps
[02:15:05] <skunkworks1> assuming I don't think its ftlbs
[02:15:09] <skunkworks1> right
[02:15:10] <jmkasunich> no
[02:15:17] <skunkworks1> in-lbs maybe
[02:15:23] <jmkasunich> in-lbs I bet
[02:15:37] <jmkasunich> not likely to be metric
[02:16:04] <jmkasunich> dunno about oz-in - how big is the shaft
[02:16:22] <skunkworks1> atleast an inch
[02:16:24] <jmkasunich> its specd at 0 rpm - stall torque
[02:16:28] <jmkasunich> in-lbs it is then
[02:16:46] <jmkasunich> ft-lbs would put it at 100HP ;-)
[02:17:24] <skunkworks1> what is the Ja-LB.IN.SEC^2 .294?
[02:17:28] <jmkasunich> inertia
[02:17:31] <skunkworks1> ah
[02:17:50] <skunkworks1> that is in-lbs so maybe that is the torque rating also
[02:18:06] <jmkasunich> the torque rating has to be in-lbs
[02:18:13] <jmkasunich> nothing else makes sense
[02:18:21] <jmkasunich> 242 oz-in would need a 1/4" shaft
[02:18:26] <jmkasunich> and 242 ft-lb would be 100HP or more
[02:18:58] <SWPadnos> RPM 0 ?
[02:19:04] <jmkasunich> stall torque
[02:19:09] <skunkworks1> it has an integrated brake - might use it for the y axis
[02:19:18] <skunkworks1> (vertial)
[02:19:20] <jmkasunich> I know, in theory that means zero hp
[02:19:23] <skunkworks1> vertical
[02:19:25] <SWPadnos> ah - Max RPM is separate
[02:19:54] <jmkasunich> I find it odd that they don't list rated amps
[02:19:59] <skunkworks1> e-bay purchase ;)
[02:20:16] <jmkasunich> amps at 242 in-lb can be computed from the given data, but not trivially
[02:20:24] <skunkworks1> gives max pulse amps ;)
[02:20:37] <SWPadnos> that is one shitload of amps
[02:20:42] <jmkasunich> that the level that might demagnetize the magnets
[02:21:31] <jmkasunich> 85A = 242 in-lbs
[02:21:44] <jmkasunich> hope you got some big FETs
[02:21:47] <skunkworks1> wow
[02:21:54] <SWPadnos> that's quite a cont:max ratio
[02:22:23] <jmkasunich> its not clear if 242 is a cont rating or not
[02:22:30] <jmkasunich> the zero rpm makes me wonder
[02:22:39] <jmkasunich> even tho it says duty cont
[02:23:15] <SWPadnos> is that on a NEMA 56 frams?
[02:23:19] <SWPadnos> frame
[02:23:36] <skunkworks1> would have to measure it. it is a little smaller diameter than our moster ones.
[02:27:33] <SWPadnos> I guess it's a "SPINDLE MOTOR W/BRAKE FOR HARDINGE CHNC"
[02:27:36] <SWPadnos> http://www.uptimecorp.com/PartData.aspx?ID=61570
[02:28:26] <skunkworks1> Cool
[02:28:28] <skunkworks1> that is it
[02:28:39] <skunkworks1> won't work for a servo though.. ;)
[02:28:43] <SWPadnos> I'm waiting for another page to load - there may be specs for it
[02:29:18] <skunkworks1> the guy was selling hardige lathe parts.. that would explain it.
[02:29:22] <SWPadnos> I guess so
[02:30:19] <SWPadnos> so it's a 2 HP motor or thereabouts
[02:30:41] <SWPadnos> nope - no specs on the other page
[02:31:26] <skunkworks1> darn
[02:31:59] <jmkasunich> SWPadnos: where do you get 2HP?
[02:32:15] <SWPadnos> probably from faulty math, but here goes:
[02:32:23] <SWPadnos> 1 HP = 33000 FT-Lb/min
[02:32:23] <jmkasunich> IF it did 242 in-lb at 3500 RPM, that would be 13HP
[02:32:41] <jmkasunich> (unless I did funny math)
[02:32:58] <SWPadnos> could be, but that sounds high for a spindle motor (and a 56 frame at that)
[02:33:11] <jmkasunich> yeah
[02:33:13] <jmkasunich> hence the IF
[02:33:26] <jmkasunich> torque probably drops off with speed
[02:33:34] <SWPadnos> 33000 ~= 10x 3500 (RPM), so call it a factor of 10
[02:33:34] <jmkasunich> and/or the 242 is peak, not cont
[02:33:45] <SWPadnos> 242 in-lb = 20 ft-lb
[02:34:01] <SWPadnos> 20 ft-lb / (factor of 10) ~= 2 HP
[02:34:20] <jmkasunich> 20 ft-lb * 3500 RPM / 5252 = 13.3HP
[02:34:26] <jmkasunich> 5252 = magic number
[02:34:36] <SWPadnos> right
[02:34:37] <jmkasunich> which happens to be 33000 / 2pi
[02:34:45] <SWPadnos> right
[02:34:53] <jmkasunich> you forgot the 2pi
[02:35:05] <SWPadnos> ah - rads/min vs. revs/min
[02:35:26] <jmkasunich> they way I look at it, 20 ft-lb means 20 lbs at a 1ft radius
[02:35:48] <jmkasunich> but if you have a 1ft radius winch drum (2ft dia) it winds up 6.28 feet per rev
[02:36:08] <jmkasunich> so it can lift a 20 lb weight at 3500 * 6.28 feet per minute
[02:36:38] <skunkworks1> we find all the cool stuff - don't we? ;)
[02:40:43] <skunkworks1> here are what the machine used originally for position feed back.
http://www.electronicsam.com/images/KandT/conversion/accupins.JPG
[02:41:25] <jmkasunich> interesting
[02:41:28] <jmkasunich> what read it?
[02:41:58] <jmkasunich> can't tell scale - how big are the pins?
[02:42:13] <skunkworks1> .1 diameter
[02:42:41] <skunkworks1> it somehow induces a field and gets sin-cos out like a resolver for every pin
[02:43:18] <skunkworks1> (each pin is broken into .0001)
[02:44:25] <skunkworks1> .0001"
[02:45:08] <jmkasunich> that isn't very long if its only 0.1" pins
[02:45:15] <jmkasunich> how much travel is there?
[02:45:33] <jmkasunich> 10" maybe?
[02:45:47] <skunkworks1> oh - they are mounted in a row. that is only a 10"
[02:45:55] <jmkasunich> oh
[02:46:27] <jmkasunich> butted up against one another....seems like an opportunity for a thou or so of error
[02:46:55] <skunkworks1> you would think. but that machine - when it ran - was very accurite
[02:47:45] <skunkworks1> the spec was repeatability of .0005
[02:48:13] <skunkworks1> they where dowl-pinned in.
[02:48:17] <skunkworks1> dowel
[02:49:20] <skunkworks1> I think once we get it running with encoders - I want to play with a resolver - encoder chip and see what the scales would do.
[02:49:52] <skunkworks1> if there isn't 'any' backlash in the ball screws and such
[03:00:09] <skunkworks> that is the thought anyways.
[03:25:43] <skullworks-PGAB> anyone used these?
[03:25:49] <skullworks-PGAB> http://www.amtencoder.com/
[03:28:11] <cradek> they look neat
[03:28:38] <skullworks-PGAB> index channel is standard
[03:29:27] <skullworks-PGAB> was hoping it might be a cheaper alt to US digital - which gets expensive when you need the index channel
[03:29:31] <cradek> selectable resolution sounds neat (must have 2048ppr and built-in dividers)
[03:29:47] <jmkasunich> what do they cost
[03:29:49] <jmkasunich> ?
[03:29:58] <cradek> I was just wondering that too
[03:30:17] <SWPadnos> $29.95
[03:30:40] <skullworks-PGAB> well - Keling started stocking them, and they were using the US digital before
[03:31:13] <SWPadnos> comes with sleeves to fit most any shaft from 3mm to 8mm (including imperial sizes, like 1/4")
[03:31:32] <skullworks-PGAB> based in OR
[03:31:42] <jmkasunich> SWPadnos: where did you see that price?
[03:31:48] <SWPadnos> digikey
[03:31:58] <SWPadnos> AMT-102 and AMT-103
[03:32:03] <skullworks-PGAB> SWEET!
[03:32:16] <skullworks-PGAB> now to make them work
[03:32:25] <SWPadnos> goes down a little for 10 qty, quite a bit for 500-1000 qty
[03:32:30] <cradek> appears they'll just work, they're ttl
[03:33:10] <skullworks-PGAB> * skullworks-PGAB is not sure he could use up 500 units, in a timely fasion.
[03:34:16] <skunkworks> that is cool
[03:34:44] <jmkasunich> http://rocky.digikey.com/WebLib/CUI%20Inc/Web%20Photo/New%20Photos/AMT102-V.jpg
[03:34:51] <jmkasunich> it does NOT seem to use a traditional disk
[03:35:19] <jmkasunich> I think the black thing is the rotor (green/other colors are adapters for differnet shaft sizes)
[03:35:57] <jmkasunich> gotta wonder if its a relatively low PPR sin/cos kind of thing and they interpolate for higher res
[03:36:47] <skullworks-PGAB> might
[03:37:02] <jmkasunich> actually, I'm wrong
[03:37:11] <SWPadnos> the datasheet isn't exactly bursting with useful information
[03:37:11] <jmkasunich> the black thing is a splined hub
[03:37:14] <skullworks-PGAB> I know they mention the index channel is magnetic sense
[03:37:23] <jmkasunich> and it mates with a splined rotor that is part of the electronic part
[03:38:56] <jmkasunich> interesting - four different base pprs in one part
[03:39:07] <jmkasunich> 48, 100, 125, and 256
[03:39:21] <jmkasunich> each then multiplied by 1, 2, 4, or 8
[03:39:38] <jepler> yeah i was just wondering at that too
[03:39:45] <jmkasunich> there are no common denominators in those numbers
[03:39:56] <jepler> I expected to see powers-of-2 but then 16 divisors didn't make much sense
[03:40:13] <jmkasunich> 2^4 * 3, 2^2 * 5^2, 5^3, 2^8
[03:42:56] <SWPadnos> from the ASIC datasheet: "As the quadrature output of these encoders is based on interpolations of an analog function, the accuracy characteristics are more comparable to a resolver than to an optical encoder."
[03:43:27] <jmkasunich> do they actually spec the accuracy?
[03:43:49] <SWPadnos> +/- 15, 30, or 60 arc-minutes depending on base resolution
[03:44:05] <SWPadnos> (yes, arc-min, not arc-sec)
[03:44:15] <jmkasunich> 1/4 degree = 1 part in 1440
[03:44:35] <SWPadnos> 1 degree = 60 arc min, right?
[03:44:40] <jmkasunich> yeah
[03:44:52] <SWPadnos> so that's +/- 1/4 degree at best, 1/2 degree or 1 degree at worst ...
[03:44:56] <jmkasunich> yep
[03:45:16] <jmkasunich> not gonna put us digital out of business, but will put a dent in the low end
[03:45:34] <SWPadnos> sounds fairly crappy, but then again, that's equivalent to a 90-360 CPR encoder
[03:46:26] <skunkworks> I still want to get one of the automation direct low-end ones that supposedly has an index
[03:47:45] <skullworks-PGAB> too bad US digital won't make an E4P version with index.
[03:51:23] <SWPadnos> night folks
[03:51:30] <jmkasunich> goodnight
[03:51:36] <skullworks-PGAB> nite
[04:05:09] <skunkworks> Time for bed also
[04:05:22] <skunkworks> jmkasunich: thanks for running some number on the 'servo'
[04:05:34] <jmkasunich> you're welcome
[09:35:06] <Jymmmmmm> alex_joni anyway to search the logs?
[09:37:06] <skullworks-PGAB> Its been quite in her for hours
[09:37:15] <skullworks-PGAB> here
[09:37:15] <Jymmmmmm> ah
[09:37:26] <Jymmmmmm> skullworks-PGAB busy?
[09:37:38] <skullworks-PGAB> not real
[09:37:52] <skullworks-PGAB> not at all ctually
[09:38:03] <Jymmmmmm> heh
[09:38:21] <skullworks-PGAB> * skullworks-PGAB thinks its time to clean the kyb again.
[09:38:57] <Jymmmmmm> Toss it in the clothes washer on delicate =)
[09:39:10] <skullworks-PGAB> s u r e
[09:39:42] <Jymmmmmm> I *FINALLY* go the crimpers today.
[09:39:43] <Jymmmmmm> got
[09:40:11] <Jymmmmmm> Actually, I got the ALST pair they had, they held them for me.
[09:40:57] <skullworks-PGAB> I saw a topic on cnczone where a guy seperated the step/dir driver from the power h-bridge of the uhu servo driver.
[09:41:46] <skullworks-PGAB> since the processor code on the uhu has not been released
[09:42:01] <Jymmmmmm> what's "uhu"
[09:42:05] <Jymmmmmm> ?
[09:42:08] <skullworks-PGAB> still have to get them pre-loaded
[09:42:47] <skullworks-PGAB> so guy in germany made up a really powerfull servo driver - they call it the uhu
[09:43:14] <Jymmmmmm> ah
[09:43:29] <Jymmmmmm> * Jymmmmmm shoves skullworks-PGAB into the OTHER window
[09:43:29] <skullworks-PGAB> I'll find a link
[09:57:26] <Jymmmmmm> * Jymmmmmm shoves skullworks-PGAB into the OTHER window again
[09:57:41] <skullworks-PGAB> ouch
[09:58:16] <Jymmmmmm> skullworks-PGAB look at the other window
[09:58:49] <skullworks-PGAB> http://www.uhu-servo.de/
[09:59:03] <skullworks-PGAB> what other window?
[09:59:44] <Jymmmmmm> keep looking, it's there
[10:01:41] <Jymmmmmm> skullworks-PGAB I just sent you a message
[10:02:11] <skullworks-PGAB> yes on the 2nd window?
[10:02:28] <Jymmmmmm> I guess that really depends on what client you are using
[10:02:55] <skullworks-PGAB> crappy win prog - Icechat
[10:03:46] <skullworks-PGAB> the latest ver has been Vista sort of remodeled - makes me sick looking at it.
[10:04:39] <Jymmmmmm> heh
[10:05:59] <skullworks-PGAB> I was doing some cad/cam work earlier - hence windows/dos
[10:07:31] <skullworks-PGAB> I was doing some cad/cam work earlier - hence windows/dos Borland v3.1 compiler.
[10:08:02] <skullworks-PGAB> Oops - another feature...
[10:08:05] <Jymmmmmm> ah, ok.
[10:08:23] <Jymmmmmm> I have Bornald C v3 full suite.
[10:08:26] <Jymmmmmm> Borland
[10:08:31] <Jymmmmmm> used to work for them
[10:08:54] <skullworks-PGAB> I had ver 4.52 IIRC
[10:09:09] <skullworks-PGAB> but that was like 96
[10:09:16] <skullworks-PGAB> or some such
[10:09:39] <Jymmmmmm> Mine's still sealed. We get Borland Bucks, and had a friend order it for me.
[10:09:44] <skullworks-PGAB> never had time to use it.
[10:10:44] <skullworks-PGAB> yeager did CNCpro as part of his thesis
[10:11:10] <skullworks-PGAB> the motion portion was all done in assembler
[10:11:23] <skullworks-PGAB> clean tight code
[10:11:41] <skullworks-PGAB> whole exe file is 173K
[10:11:54] <skullworks-PGAB> including the UI
[10:13:11] <Jymmmmmm> that works
[10:14:33] <Jymmmmmm> skullworks-PGAB /join #xyz
[10:24:49] <K`zan> Night folks
[10:25:35] <skullworks-PGAB> nity
[10:44:45] <Martin_Lundstrom> Hello
[10:45:01] <Martin_Lundstrom> Dallur: Are you around?
[11:16:59] <alex_joni> morning
[11:17:37] <skullworks-PGAB> it is
[11:18:03] <skullworks-PGAB> meaning I should have gone to bed hours ago...
[11:20:29] <alex_joni> 13:11 < alex_joni> morning
[11:20:35] <alex_joni> not quite morning.. but close ;)
[11:21:32] <skullworks-PGAB> 0420 here - the alarm just went off...
[11:21:51] <alex_joni> ew.. hate it when that happens
[11:21:59] <alex_joni> guess you need to get up now
[11:22:39] <skullworks-PGAB> no - it just means that I will have to get up for work in less than 24hrs now.
[11:22:54] <alex_joni> hah
[11:27:31] <alex_joni> don't remind me :(
[11:56:25] <skullworks-PGAB> time for ZZZZZzzzzzzzz - later all
[17:14:18] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/motion/ (command.c motion.h): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
[17:14:22] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/nml_intf/ (canon.hh emc.cc emc.hh): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
[17:14:30] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/rs274ngc/ (interp_array.cc interp_convert.cc interp_internal.hh): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
[17:14:31] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/sai/saicanon.cc: add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
[17:14:33] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/task/ (emccanon.cc emctaskmain.cc taskintf.cc): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
[17:43:01] <CIA-6> 03cradek 07rigid_tap * 10emc2/src/emc/sai/saicanon.cc: little cut/paste error
[17:54:31] <CIA-6> 03cradek 07rigid_tap * 10emc2/src/emc/rs274ngc/ (rs274ngc_errors.cc interp_check.cc): require K word and forbid F word with G33.1; massage error messages accordingly
[17:57:22] <CIA-6> 03alex_joni 07rigid_tap * 10emc2/src/emc/rs274ngc/gcodemodule.cc: add RIGID_TAP
[18:57:40] <alex_joni> hi Peter
[18:58:05] <PeterW> Hi! trying Chatzilla
[18:58:16] <jmkasunich> is PeterW the Peter Wallace from Mesa?
[18:58:25] <PeterW> Yep
[18:58:30] <jmkasunich> welcome!
[18:59:09] <PeterW> Had some hints for Xilinx meeting timing
[18:59:17] <jmkasunich> oh good
[18:59:22] <jmkasunich> I was gonna ask you about that
[19:00:01] <jmkasunich> I've run the code you sent me thru the tools a couple times, and the best I get for the clock to output path is 24-16nS
[19:00:27] <PeterW> One this is to give as much slack as you can... actually 25 ns after clock is ok and may result in better P+R
[19:00:29] <jmkasunich> probably have some setting wrong somewhere
[19:01:35] <jmkasunich> ok - I think the .ucf file I have here has 22 or 23nS for that constraint
[19:01:55] <PeterW> A million setup options, one hour per test...
[19:02:32] <jmkasunich> yeah
[19:02:56] <PeterW> Yes I used that originally when design was small but 25 ns meets bridge chip timing
[19:03:10] <jmkasunich> I'm trying to set up either a script or a makefile that runs thru the process
[19:03:22] <jmkasunich> I don't like the gui at all
[19:04:14] <jmkasunich> I've also been experimenting with data2mem, as a way to change ROM contents without re-running the P&R
[19:04:26] <jmkasunich> got the stepgen driver pretty much working
[19:04:26] <PeterW> plus you can add a wait state (probably easier in the bridge chip - 1 wait state for reads - 55 nS clock to PAD
[19:05:18] <PeterW> I know about data2mem but i have been trying to use a few xilinx tools as possible
[19:05:37] <PeterW> Whats the bug in stepgen?
[19:06:17] <jmkasunich> not really a bug, but I want to tweak it
[19:06:33] <jmkasunich> if you set steplen to 5uS, the step pulse is 5uS as expecetd
[19:06:44] <jmkasunich> but it also means the space between pulses must be at least 5uS
[19:07:20] <PeterW> Also wondering about your P&R runtime I have about 15 min (1 GHz PIII But Xilinx ISE 6.3)
[19:07:50] <jmkasunich> 20-30 mins (1.6GHz AMD Sempron, ise 8.2)
[19:08:19] <jmkasunich> I think
[19:08:53] <jmkasunich> a few of my P&R runs happend while other things had my box loaded down
[19:09:10] <PeterW> Yes stepcycle time is just twice steplen (simple hack) probably not optimum for some indexers
[19:09:27] <jmkasunich> I'm gonna remove any hardware limitation on step spacing
[19:09:48] <jmkasunich> the driver will limit the commanded frequency, such that period is never less than steplen + stepspace
[19:09:58] <jmkasunich> so the HW doesn't need to worry about it
[19:10:26] <xemet> hi
[19:10:27] <PeterW> The step gen cycle time is really a leftover from the buffered version...
[19:10:33] <jmkasunich> ok
[19:10:35] <alex_joni> hi xemet
[19:10:35] <xemet> jepler are you there?
[19:10:43] <xemet> hi all
[19:11:09] <jmkasunich> I'm also thinking of removing the master DDS and using straight PCI clock
[19:11:43] <jmkasunich> whatever changes I make will wind up in EMC's cvs, and if you like I can send them direct to you as well
[19:12:06] <jmkasunich> the EMC version will wind up diverging somewhat from your version, to meet our needs and plans
[19:12:08] <PeterW> Straight PCI clock is fine with large DDS's
[19:12:14] <jmkasunich> but of course you are welcome to use any of it that you want
[19:13:07] <jmkasunich> I haven't done the math yet, but the 32 bit dds gives us a rediculous range
[19:13:16] <DanielFalck> xemet: join #cam for a bit
[19:13:28] <alex_joni> PeterW: hope you don't mind me asking.. I heard about a new version of the 5i20
[19:13:48] <jmkasunich> 0 to 33MHz, in steps of less than 0.01Hz ;-)
[19:13:58] <PeterW> One other minor thing to add (I already have a module) is a frequency counter using 50 MHz timebase
[19:14:32] <xemet> DanielFalk; how? I'm in the embedded java client in the website linuxcnc
[19:14:42] <PeterW> PCI clock is not well controlled, might be 33.3333 Mhz might be 33 might be 32 etc etc
[19:14:45] <DanielFalck> oh sorry
[19:14:54] <alex_joni> xemet: type /join #cam
[19:15:02] <alex_joni> /join #cam
[19:15:02] <DanielFalck> alex_joni: thanks
[19:15:09] <xemet> thanks alex
[19:15:14] <alex_joni> np
[19:15:14] <jmkasunich> PeterW: that explains why my outputs were about 1% high last night
[19:15:31] <jmkasunich> there is a 50MHz clock on the board, right?
[19:16:36] <PeterW> New version of 5I20 is 5I22 = 1.5 M gate FPGA 96 bits of 5V tolerant I/O bus mastering bridge (DMA capable)
[19:17:06] <alex_joni> PeterW: thanks, sounds like a big board :)
[19:17:41] <PeterW> yes 50 MHz thats whats used for generationg the 100 MHz PWM refence clock
[19:17:51] <jmkasunich> still a spartan 2, or something completely different?
[19:18:25] <jmkasunich> (on the 5i22)
[19:18:44] <PeterW> Spartan3 (with quickswitches for 5V->3V translation)
[19:18:54] <jmkasunich> ok
[19:19:10] <jmkasunich> * jmkasunich makes a note - try to avoid Spartan2 specific FPGA codre
[19:19:15] <jmkasunich> code
[19:19:51] <PeterW> (Same physical size as 5I20 but can be .2" shorter)
[19:19:49] <jmkasunich> using the 50MHz clock instead of / in addition to the 33MHz clock makes the bus interface a lot more "interesting" doesn't it?
[19:20:39] <PeterW> Yep crossing clock domains and avoiding metastables...
[19:20:49] <jmkasunich> although I seem to recall from the 9030 data that the "local bus" can be run on an independent clock
[19:20:55] <jmkasunich> does the board support that?
[19:21:24] <PeterW> but only the PWMs would use the 100 MHz reference and they are output only so its not too bad
[19:21:38] <jmkasunich> right
[19:21:51] <jmkasunich> another question - a couple of times you've mentioned burst reads and writes
[19:22:07] <jmkasunich> I'm just wondering how to ensure that the bursts actually happen
[19:22:21] <jmkasunich> I'm reading from C
[19:22:45] <jmkasunich> how does the bus/cpu know to combine several reads (that may be separated by multiple other instructions) into a burst?
[19:23:31] <jmkasunich> seem if I write:
[19:23:32] <PeterW> The 5I20 is hardwired to use the PCI clock for local bus< ive though aboout an option but 50 MHz is tough
[19:23:47] <jmkasunich> foo = ioread(some_addr);
[19:23:59] <jmkasunich> bar = ioread(some_addr+4);
[19:24:31] <jmkasunich> the second line won't execute until the first read is complete, so theres no way to burst the reads
[19:24:34] <PeterW> to insure bursts, there are a few things you need
[19:25:48] <PeterW> you need to read or write successive 32 bit aligned memory (not IO) locations
[19:25:59] <jmkasunich> right
[19:26:24] <jmkasunich> ioread is a linux function used to access memory that is being used as I/O (as opposed to regular, cached, memory)
[19:26:39] <jmkasunich> I think on x86 ioread turns into a simple indirection:
[19:26:43] <PeterW> plus you need to setup some bits in the PCI9030's. For reads you enable read-ahead
[19:26:49] <jmkasunich> ioread(foo) --> *foo
[19:27:24] <jmkasunich> so the 9030 will burst from the fpga, and cache the data for the cpu
[19:27:51] <PeterW> Yes, in the 9030s FIFO
[19:28:04] <jmkasunich> the cycle on the pci bus (cpu reading from 9030, not 9030 from fpga) will not be a burst I guess
[19:28:22] <jmkasunich> but it will be a bit faster, because the 9030 doesn't have to talk to the fpga
[19:28:51] <PeterW> right but the PCI bus cycle is not normally the speed bottleneck with the PCI9030
[19:29:29] <jmkasunich> gotta re-read the 9030 manual again
[19:29:39] <PeterW> More than a bit faster, amost twice as fast (in my tests about 250 nS per access instad of 450)
[19:30:04] <jmkasunich> in general, caching reads for I/O devices is avoided, because each read might have some side effects, and caching could change that
[19:30:17] <jmkasunich> but I think all the fpga stuff so far doesn't do things like that
[19:30:41] <jmkasunich> still don't want to get stale data, but the 9030 doesn't cache for very long does it?
[19:30:54] <jmkasunich> (flushes the fifo as soon as a non-sequential read happens I think)
[19:32:51] <PeterW> Dont think its a problem because of the FIFO flushing
[19:33:49] <jmkasunich> also gonna have to revisit how I do things in the driver
[19:34:10] <jmkasunich> right now I do "for n = 0 to number-of-stepgens ; read_stepgen(n) ; n++
[19:34:28] <jmkasunich> and read_stepgen() might access a couple of different things in the stepgen
[19:34:37] <jmkasunich> which would throw things out of order
[19:34:56] <jmkasunich> gotta decide if keeping the driver generic is worth the couple hundred ns per read
[19:34:59] <PeterW> Ill get the exact bits to change in the PCI9030 for read and write burst support
[19:35:35] <jmkasunich> don't spend much time on it - I may decide the penalty in driver messiness isn't worth the minor speed gain
[19:36:11] <PeterW> I think keeping sequential read and writes is a good thing
[19:36:35] <PeterW> Ultimately you may want to support DMA (10X faster)
[19:36:42] <jmkasunich> no way
[19:36:56] <jmkasunich> the goal for us is not to wring the last ns out of the code
[19:37:06] <PeterW> There sequential read and writes are required
[19:37:20] <jmkasunich> its to come up with portable and flexible stuff that can be reconfigured as needed
[19:38:08] <jmkasunich> I'll have to do some experimenting - like commenting out the actual hardware access and running the driver
[19:38:31] <jmkasunich> I'm sure it will be faster without the pci cycles, but not so much faster that its worth it
[19:38:57] <jmkasunich> our default cycle time is 1mS
[19:40:03] <PeterW> Well if your I/O cycles eat a large portion of your free time (An issue with large # of Axis) The I/O time is an issue
[19:40:25] <jmkasunich> I just started EMC
[19:40:46] <jmkasunich> the servo thread is averaging about 40,000 CPU clocks
[19:40:53] <jmkasunich> max 81000 (so far)
[19:41:04] <jmkasunich> thats the calculations and such
[19:41:22] <jmkasunich> adding a few hundred for I/O isn't gonna make a huge difference
[19:41:32] <jmkasunich> neither is saving a few hundred
[19:43:01] <jmkasunich> this particular configuration has a fast thread too, it is generating simulated encoder pulses (from a simulated motor/encoder combo) and then counting them in software
[19:43:25] <jmkasunich> that thread is averaging 600 or so clocks, with a max of 25000
[19:44:33] <jmkasunich> a 5i20 based system wouldn't have a fast thread - the fast thread is doing stuff that the 5i20 does in hardware
[19:44:38] <PeterW> I guess Im used to faster PID update rates but 8 reads at 450 ns is 3600 1 GHz cpu clocks
[19:44:57] <jmkasunich> true
[19:45:11] <jmkasunich> CNC machining is usually 3 axis, almost never more than 6
[19:45:22] <jmkasunich> and usually 1mS updates are plenty
[19:45:31] <jmkasunich> (for non-exotic machines)
[19:45:56] <jmkasunich> I can certainly see how things can get a lot more demanding in other applications
[19:45:56] <alex_joni> * alex_joni worked with an 18-axes robot system once..
[19:46:02] <PeterW> OK we have people running 20 Axis, there the access time becomes a problem...
[19:46:21] <skullworks-PGAB> John - are you counting the spindle as an axis? - you might need to
[19:46:32] <jmkasunich> so that makes 4
[19:47:27] <jmkasunich> my point is that throughout the code, we have chosen to favor clarity and ease of use/understanding over tweaking performance
[19:47:50] <skullworks-PGAB> i say that because when we get to the point that we add constant surface speed each move wil add a target rpm...
[19:47:52] <jmkasunich> if we needed to get more speed, there are all kinds of places where we might optimise
[19:48:29] <jmkasunich> skullworks-PGAB: understood
[19:49:15] <jmkasunich> on the ppmc board set, we did some caching of accesses to the hardware
[19:49:27] <jmkasunich> on that system, hw access costs about 1uS per byte
[19:49:43] <jmkasunich> on the 5i20, unoptimized access costs 0.5uS per 4 bytes
[19:49:58] <jmkasunich> and optimized costs 0.25uS or so per 4 bytes
[19:50:22] <jmkasunich> even unoptimized, the 5i20 is 8 times faster than the ppmc
[19:51:02] <PeterW> But it does not add much to the driver to prefer sequential read/writes...
[19:51:21] <jmkasunich> it depends on how the driver is constructed
[19:51:41] <jmkasunich> for example, the existing driver exports a function to read each stepgen, not one function that reads all stepgens
[19:51:53] <jmkasunich> that decision isn't cast in stone yet
[19:52:13] <jmkasunich> but with individual functions, somebody may choose to read some stepgens every 1mS, and others every 100uS
[19:52:22] <jmkasunich> its hard to sequentialize that
[19:52:52] <jmkasunich> if I did a "read all stepgens" function instead, it might be a bit faster
[19:53:14] <jmkasunich> but if that means they have to read the all every 100uS, even if only one actually needs that speed, the net result is not a gain
[19:54:10] <PeterW> My guess is that with a reasonably fast processor, all the read/writes done a particular time slot would get bursted anyway
[19:55:03] <PeterW> as long as they are sequential and your code time is < several PCI clocks
[19:55:04] <jmkasunich> for writes I can understand that - the code does a write, and continues on, if it does another write before the first one completes, the bus logic can burst them
[19:55:35] <jmkasunich> but for reads, how can the code continue on to a 2nd read before the first one finishes?
[19:56:25] <skullworks-PGAB> some of us holdout use stoneage computers, a few steps beyond the basic transistor, like a pIII-450 :)
[19:56:33] <jmkasunich> I guess the cpu can do some speculative execution, before it actually needs to use the result of the read
[19:56:42] <skullworks-PGAB> any hardware speed boost helps
[19:57:04] <PeterW> I think (dont have the PCI9030 DB handy) that you would just have to be faster than the single read speed
[19:57:47] <jmkasunich> I wonder if a ppmc style pre-read makes sense
[19:58:28] <PeterW> Anyway It really doent matter that much at 1KHz but I think its good idea to keep the burstible register layout
[19:59:07] <jmkasunich> yeah, I've come around on the register layout issue, its just a bunch of #defines, so no big deal
[19:59:26] <jmkasunich> the overall structure of the driver is the area where I've got "issues"
[19:59:52] <jmkasunich> right now, one function reads (or writes) one complete stepgen, or encoder, or whatever
[20:00:18] <jmkasunich> if I change that so it reads all stepgens, then bursting is far more likely to do some good
[20:01:33] <jmkasunich> that is an on-going issue - do you emphasize the ability to mix-and-match stuff, or do you optimize for the typical case at the expense of somebody who wants to do something wierd
[20:01:49] <jmkasunich> (like read on encoder every 100uS, three every 1mS, and the rest every 10mS)
[20:02:03] <PeterW> Thats what I was trying to explain before, as long as you dont have a lot of code in each function
[20:02:37] <jmkasunich> and as long as each function doesn't touch more than one address
[20:02:53] <PeterW> you may get the burst benefit without explicit low level changes (Processor cat do many inst per PCI clock)
[20:02:55] <jmkasunich> if function 1 touches 100 and 200, and function 2 touches 101 and 201, they'll never burst
[20:04:02] <jmkasunich> I get what you are saying though - if function 1 touches 100 and function 2 touches 101, then if they run in order, the accesses might burst even though I didn't change anything
[20:04:31] <petev> jmk, I missed most of this, but are u guys talking about the 5i20 in general, or just for stepgen?
[20:04:41] <jmkasunich> in general
[20:04:48] <jmkasunich> but the stepgen is the piece I'm working on right now
[20:05:04] <petev> then wouldn't it be better to spend time on interrupt driven io first?
[20:05:10] <petev> that would reduce sampling jitter
[20:05:11] <jmkasunich> same would apply to encoder counters, pwm, and general I/O
[20:05:34] <jmkasunich> that would be a major redo of the core of EMC
[20:05:40] <petev> why?
[20:05:45] <petev> if HAL supported interrupts
[20:05:53] <petev> the IO could be read every HW interrupt
[20:06:05] <jmkasunich> right now, the RTOS timer interrupt sets the timing for everything
[20:06:05] <petev> and then just retreived with HAL function
[20:06:36] <petev> hmm, I thought each thread was run at it's own rate
[20:06:45] <petev> is there some other interactions I'm missing?
[20:06:52] <jmkasunich> what happens when board A is sampling every 1.000mS on its interrupt, board B is sampling every 1.001mS on its interrupt, and the thread is running at 0.999mS on its timer interrupt?
[20:07:17] <petev> I would call that a poorly configed system
[20:07:39] <petev> but I do see issue with multiple boards
[20:08:18] <petev> I would think in a single board system, it wouldn't be too hard to make HAL use any interupt for master timing
[20:08:18] <jmkasunich> each thread does run at its own rate, as determined by the RTOS
[20:08:30] <jmkasunich> at the base of that is the timer interrupt
[20:08:46] <skullworks-PGAB> skullworks-PGAB is now known as skullworks-away
[20:09:03] <jmkasunich> in a single board system, in principle it would work fine
[20:09:03] <petev> so it's using an RTOS timer now, or does HAL wake the threads at the appropriate time?
[20:09:24] <jmkasunich> HAL threads are RTOS tasks
[20:09:36] <petev> yes, but how are they awaken?
[20:09:47] <jmkasunich> the RTOS handles that
[20:09:53] <petev> ok
[20:09:54] <jmkasunich> there is a scheduler
[20:10:01] <alex_joni> timer interrupt, then scheduler
[20:10:05] <jmkasunich> right
[20:10:18] <petev> yes, I thought maybe HAL had a master thread that was scheduling it's threads
[20:10:24] <petev> then it wouldn't be too bad
[20:10:30] <jmkasunich> something like "rt_task_make_periodic(task_id, period)" when the task is created
[20:10:41] <petev> ok
[20:10:51] <jmkasunich> no, we didn't implement our own scheduler
[20:10:52] <alex_joni> all HAL threads are registered to the RTOS in the same fashion
[20:10:55] <jmkasunich> that seemed redundant
[20:11:05] <petev> then it would take some work in HAL for external interrupts
[20:11:18] <petev> not scheduler, just a master thread that would wake the other threads
[20:11:25] <jmkasunich> although I must admit the idea of working directly over ADEOS instead of using RTAI has crossed my mind
[20:11:34] <petev> maybe they are block on a semaphore and the master thread wakes them when they should run
[20:11:46] <jmkasunich> well, there has to be priorities, so you need a scheduler somewhere
[20:12:14] <petev> the scheduler would handle the actual priorities and context switch
[20:12:32] <petev> but the master thread could actually be controlling the threads by unblocking them
[20:12:35] <petev> just a thought
[20:12:43] <jmkasunich> I think I understand
[20:13:14] <jmkasunich> but since the RTAI and RTLinux schedulers both had support for periodic threads built in, there didn't seem to be a reason to do it ourselves
[20:13:42] <petev> the only reason would be to use a HW interrupt as the master time source
[20:14:37] <jmkasunich> which does potentiall reduce jitter, since the hw can latch things on the interrupt so that latency before the sw gets around to reading it doesn't matter
[20:14:51] <jmkasunich> but at the expense of making a multi-board system more complicated
[20:15:03] <petev> true
[20:15:33] <PeterW> Thats how our original Hostmot hardware worked, latching the encoders at the hardware interrupt rate...
[20:16:00] <jmkasunich> the new encoder counter in the 5i20 reports 16 bits of count and 16 bits of timestamp when you read it, so jitter on encoder readings isn't much of an issue - you know when the most recent count actually happened
[20:16:42] <jmkasunich> and the driver is going to compute a nice velocity output that doesn't suffer from quantization error, even if you are only getting 1 or 2 counts per period
[20:17:10] <jmkasunich> PeterW: thats how any dedicated high performance motion control system should probably work
[20:17:31] <PeterW> Right we were also synchronous with PWM - no beats
[20:17:36] <petev> the time stamp is nice
[20:18:02] <jmkasunich> I've already put the timestamp based velocity output into the software encoder counter, it really smooths up velocity feedback
[20:18:15] <PeterW> It will be interesting to see how the timestamp works
[20:18:25] <jmkasunich> still limited though, because the time granularity is still 15-50uS depending on the configuration
[20:19:23] <jmkasunich> PeterW: synchronouse with PWM is how the drives I work on at my day job work
[20:19:35] <jmkasunich> 4kHz PWM, and a 4kHz thread
[20:20:08] <PeterW> We do that with SoftDMC also
[20:20:37] <jmkasunich> for 2kHz PWM, we run the thread at the peak and valley of the triangle, so its still 4KHz
[20:21:31] <jmkasunich> I imagine you run the softDMC a bit faster ;-)
[20:22:43] <PeterW> We can run 4 axis around 70 KHz in Spartan3
[20:23:02] <jmkasunich> what are you running that needs that kind of bandwidth?
[20:23:16] <jmkasunich> and what kind of power devices are you using that don't get clobbered by switching loss?
[20:24:01] <jmkasunich> our 690V drive is rated 1050A at 2KHz, but only 705A at 4KHz - switching loss is nasty on 1700V IGBTs
[20:24:15] <jmkasunich> 480V stuff doesn't take quite as bad a hit, but its still significant
[20:24:43] <PeterW> Voice coils are one application + little ironless core motors + everything gets better at higher PID rates
[20:24:55] <jmkasunich> ah, ok
[20:25:01] <jmkasunich> what I would consider very exotic motors
[20:25:10] <PeterW> For littel stuff Mosfets are pretty amazing
[20:25:27] <jmkasunich> for low voltages, yes.
[20:25:44] <jmkasunich> mosfet tradeoffs start getting ugly above about 500V
[20:26:01] <PeterW> right IGBTS limit you to around 20 KHz I guess
[20:26:07] <jmkasunich> lol
[20:26:15] <jmkasunich> not at the power levels we run
[20:26:20] <lerneaen_hydra> it's help-the-poor-swede time again: discrete is seperate objects, right (whereas discreet would be acting quiet-like or generally cautious)
[20:26:27] <jmkasunich> 10KHz for small drives (under 50HP)
[20:26:32] <lerneaen_hydra> I always seem to mix the spelling of the two up
[20:26:59] <jmkasunich> lerneaen_hydra: you got it right
[20:27:07] <lerneaen_hydra> ah, good
[20:27:10] <lerneaen_hydra> there is hope for me yet
[20:27:28] <jmkasunich> PeterW: we don't run the big stuff over 4KHz
[20:27:49] <jmkasunich> even the gate drivers can't handle much over that
[20:28:21] <jmkasunich> (gate capacitance on the big drives approaches a microfarad)
[20:29:48] <PeterW> Right, Also dint you have enough motor inductance so you dont have too much ripple/hysteresis loss
[20:30:20] <jmkasunich> yep
[20:31:09] <PeterW> Brush motors often have quite low armature inductance so high PWM rates help there (For small motors)
[20:31:22] <jmkasunich> especially the ironless rotor ones
[20:31:26] <PeterW> Yep
[20:31:49] <jmkasunich> the only brush motors I've worked with professionally used phase control
[20:31:56] <jmkasunich> so the ripple frequency was 360 Hz
[20:32:05] <jmkasunich> obviously they also had lots of L
[20:32:08] <PeterW> Ouch
[20:32:23] <jmkasunich> thats mainstream DC motor control though
[20:32:44] <jmkasunich> (for integral and up horsepower, not fractional or subfractional)
[20:33:08] <PeterW> BTW should I add the per-bit I/O option selection +PWM?
[20:33:36] <jmkasunich> I'm still trying to figure out how to deal with I/O vs. special functions
[20:34:02] <jmkasunich> it would be good to be able to select open collector, inversion, etc on a per bit basis, regardless of what the bit is being used for
[20:34:28] <jmkasunich> for example, you embedded polarity control in the stepgen
[20:34:54] <jmkasunich> I dunno if that is better or worse than associating the polarity control with the pin itself
[20:35:13] <PeterW> If the config is limited to a sign option per pin its not too much resources
[20:35:19] <jmkasunich> for driving a gecko, it would be nice to be able to make the pin open-collector too
[20:35:43] <jmkasunich> and again, that is something that would apply to all outputs, whether pwm, or step/dir. or general I/O
[20:35:58] <jmkasunich> so do we do it in the stepgen, and in the pwmgen, and in the gpio? or do it in one place?
[20:36:38] <PeterW> some I/O options like SelectOption/Invert/OC could be done on a per bit basis
[20:36:49] <jmkasunich> thats the way I was leaning
[20:37:15] <jmkasunich> but I haven't thought through all the implications
[20:37:41] <PeterW> other options are special function specific like stepdir/quadrature mode of the stepgen
[20:37:49] <jmkasunich> right
[20:38:00] <jmkasunich> btw, I'm planning on adding another mode: up/down
[20:38:16] <PeterW> or pwm specific options like swapind PWM and DIR pins for Locked antiphase
[20:38:47] <jmkasunich> yeah, pwm has lots of options
[20:38:54] <jmkasunich> single pin with PWM on it
[20:39:00] <jmkasunich> two pins, PWM + DIR
[20:39:16] <jmkasunich> two pins, PWM appears on one and the other is off, swap when polariaty changes
[20:39:32] <jmkasunich> two pins, high and low side switch drive (with deadtime between them)
[20:39:36] <jmkasunich> and probably more
[20:40:28] <PeterW> Simple I/O options are cheap deadtime costs a bit more
[20:40:40] <jmkasunich> yeah, deadtime is always a bitch
[20:41:22] <jmkasunich> for my own project, I'm tempted to use two optocouplers with the LEDs back to back, and a cap to control the time between when one turns off and the other turns on
[20:41:37] <PeterW> Maybe a basic PWM + a fancier one with deadtime
[20:41:38] <jmkasunich> connect the ends of the LEDs to two FPGA pins
[20:41:44] <jmkasunich> 00 or 11 = both off
[20:41:49] <jmkasunich> 01 = low on
[20:41:53] <jmkasunich> 10 = high on
[20:42:03] <jmkasunich> shoot-thru impossible
[20:42:40] <jmkasunich> yeah, maybe
[20:43:07] <jmkasunich> since the separate high/low switch drive is usually used with more than a simple H bridge
[20:43:11] <jmkasunich> like three-phase
[20:43:53] <PeterW> IMHO Deadtime should be implemented in the HBridge. Having Hiside and lowside drive out of the FPGA is something of a footgun
[20:44:06] <jmkasunich> ;-)
[20:44:17] <jmkasunich> you'd think so wouldn't you?
[20:44:39] <jmkasunich> but I've worked with multiple different manufactures and at least eight or nine different AC drives
[20:45:02] <jmkasunich> and every single one of them has control hardware outputs for all six IGBTs
[20:46:20] <jmkasunich> most have logic of some form or another to prohibit shoot-thru, but deadtime is done strictly in the pwm generator
[20:48:14] <PeterW> Sure but thats an integrated system, not mix+match. we are doing the same for low power = 2KW 3 phase amp we are working on but there will be no customer access to deadtime settings
[20:52:30] <jmkasunich> right
[20:52:52] <jmkasunich> if I was selling power stages, I'd certainly enforce deadtime and shoot-thru protection in the hardware
[20:56:39] <PeterW> Yep
[20:57:51] <jmkasunich> lemme think about this...
[20:58:17] <jmkasunich> the reason I wanted separate high and low switch signals was for A) deadtime, and B) the ability to turn both switches off
[21:00:48] <PeterW> Right, that allows fast or slow decay mode to be dynamically changed
[21:03:25] <jmkasunich> well, I dunno about fast/slow, cause I don't work with brush motors or H bridges
[21:03:39] <jmkasunich> I do three phase, when running we always have either high or low switch on
[21:03:44] <jmkasunich> but when off, we turn them all off
[21:03:53] <PeterW> Anyway, Ill work on the per bit stuff. I think simplest is a ddr source register, output source register, and invert register 3 more bits per I/O
[21:04:12] <jmkasunich> ok
[21:05:44] <PeterW> theres some meaningless combos but will do OC/push-pull/I/O/one option on a per pin basis
[21:08:42] <jmkasunich> I doesn't need to be an option
[21:08:54] <jmkasunich> every pin can be an input, even if something else is using it for output
[21:09:41] <PeterW> by option I meant special function output (inputs go eveywhere so they are no problem)
[21:09:44] <jmkasunich> ok
[21:10:40] <jmkasunich> special function inputs are interesting too - it might be nice to be able to config the pin as a GP output, while using the special function input - so you can put a test signal on the gp output
[21:10:50] <jmkasunich> I think what you are describing would work fine for that
[21:11:33] <PeterW> Gets uglier if you have more than one special function output per pin but thats probabably not realistic for Spartan2
[21:12:13] <jmkasunich> probalby not
[21:12:20] <PeterW> Sure all special inputs work all the time
[21:13:36] <PeterW> and on Spartan3 there may be enough gates to reassign pins dynamically (just to give you a headache)
[21:15:38] <PeterW> Got to go, need to feed bunnies...
[21:17:06] <jmkasunich> ;-)
[21:17:13] <jmkasunich> nice seeing you here PeterW
[21:17:50] <SWPadnos> hi there
[21:18:16] <SWPadnos> hey PeteW - are you going to be around for ESC this year? (April 1-5, at the San Jose convention center)
[21:18:46] <PeterW> Maybe, Not sure yet
[21:19:00] <alex_joni> hi Stephen
[21:19:07] <SWPadnos> ok. let me know - it would be fun to meet :)
[21:19:08] <SWPadnos> hi Alex
[21:19:19] <PeterW> Will do
[21:19:42] <SWPadnos> hey petev - how about Korean Palace again? :)
[21:20:42] <petev> sounds good
[21:20:43] <PeterW> Nice chatting jmkasunich Bye for now
[21:20:52] <petev> I'll get the directions first this time ;-)
[21:20:56] <SWPadnos> heh
[21:21:05] <SWPadnos> I may still have their business card if you need help ;)
[21:25:06] <lerneaen_hydra> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IRCquotes <-- yet another person immortalised in the irc quotes page :D
