Back
[02:22:50] <steves_logging> steves_logging is now known as steve_stallings
[02:47:14] <steve_stallings> Ping... any developers still awake?
[02:49:25] <steve_stallings> I'm getting ready to take another stab as setting up a Linux workstation in the hopes that if it is there, I will eventually learn and migrate.
[02:50:09] <steve_stallings> Since Ubuntu 6.10 is now out, I was wondering if I should use that for my non-realtime workstation.
[02:50:31] <cradek> I recommend using dapper (6.06) everywhere, since it's supported for years
[02:50:52] <steve_stallings> Is 6.10 different enough from 6.06 to confuse me when I switch from workstation to EMC?
[02:51:03] <cradek> you could look at the new edgy features and see if there are any you're excited about
[02:51:05] <steve_stallings> Will EMC be migrating to 6.10?
[02:51:14] <cradek> I haven't used 6.10
[02:51:34] <cradek> no, we don't intend to support EMC on 6.10
[02:51:55] <steve_stallings> I don't know Linux enough to identify the things that would excite me. Security seems the only point the attracts me.
[02:52:58] <cradek> both will have security fixes, 6.10 for 18 months I think, 6.06 for 3 or 5 years
[02:53:03] <steve_stallings> So we would expect another LTS version in a year or two and then migrate?
[02:53:32] <steve_stallings> I was referring to the "active" security claims for 6.10
[02:53:35] <cradek> I don't know when they plan to make another LTS but if we can jump from one to the next that would be great
[02:53:52] <cradek> using LTS minimizes our OS work and lets us concentrate on EMC
[02:54:34] <cradek> are you saying there are known unfixed bugs in 6.06 but not 6.10?
[02:54:36] <steve_stallings> Before I forget, the LinuxCNC.org download page refers to Ubuntu.org... should be Ubuntu.com ??
[02:55:03] <cradek> eek I will fix that
[02:56:38] <cradek> fixed
[02:56:46] <steve_stallings> OK, I'll go with 6.06 for my install. I know that it is best to have network live during install. What about having correct target monitor attached?
[02:57:03] <steve_stallings> I am building new system and don't have new monitor uncrated yet.
[02:57:11] <cradek> that's easiest but you can sure fix it later.
[02:58:00] <steve_stallings> I expect fun as it is a Dell 3007 on an Nvidia card.
[02:58:40] <cradek> nvidia can be trouble for realtime... you'll have to test the realtime performance and maybe switch to the vesa driver.
[02:58:45] <steve_stallings> Also expect fun with Grub not liking dual boot from a system with windows dynamic disks and mirrors.
[02:59:09] <steve_stallings> Don't expect to need realtime on this box, desktop workstation only.
[02:59:10] <cradek> I don't know what a windows dynamic disk is...
[02:59:16] <cradek> ah ok, nvidia is a good choice then.
[02:59:36] <cradek> hi jmk
[02:59:40] <jmkasunich> hi
[02:59:51] <cradek> do you like your new hostname cloak?
[02:59:59] <jmkasunich> ?
[03:00:01] <steve_stallings> Dynamic disk allows volume changes with reboot, and is needed for windows to support RAID.
[03:00:18] <cradek> jmkasunich [n=john@emc/board-of-directors/jmkasunich] has joined #emc-devel
[03:00:41] <steve_stallings> Best I can tell, Linux and work with it, but Grub doesn't understand it. Lilo is supposed to be able to work with it.
[03:00:42] <jmkasunich> fancy
[03:01:02] <steve_stallings> Hi John
[03:01:06] <jmkasunich> hi steve
[03:01:08] <cradek> steve_stallings: I see, sounds like trouble doesn't it
[03:01:35] <steve_stallings> I plan to reformat a few times until I get it right 8-(
[03:01:43] <jmkasunich> ouch
[03:02:01] <cradek> jmkasunich: tonight I found the vibrograf the first (most obvious) place I looked for it last night
[03:02:41] <steve_stallings> The W2K install seems to work nice. Two SATA2 drives with boot volume mirrored and swap volume striped.
[03:02:54] <jmkasunich> so while you were sleeping, it crept out of its hiding place and sat down in plain view?
[03:03:05] <cradek> yes that's my explanation too
[03:03:39] <cradek> steve_stallings: none of my machines really use swap for much anymore...
[03:03:41] <steve_stallings> It was in the same place all along, the molecular structure just changed from transparent to solid. 8-)
[03:04:22] <cradek> yes it may have been transparent last night. that's another good explanation.
[03:04:31] <steve_stallings> I don't expect to do much swapping with 4G of memory, but it is nice that it will be fast.
[03:05:15] <steve_stallings> On the other hand, it may take a while to notice programs that suffer from memory leaks.....
[03:05:17] <cradek> I don't ever swap with the 768k I have in my two primary machines... can't imagine needing 4G for anything
[03:05:22] <jepler> cradek: megs, you mean?
[03:05:29] <cradek> haha 768M
[03:05:51] <cradek> 30 people share our biggest machine with "just" 6G at work
[03:06:11] <steve_stallings> I have had PCB autorouter push into more than 1G of virtual.
[03:06:22] <cradek> wow
[03:06:36] <steve_stallings> Huge matrix search essentially.
[03:06:45] <cradek> what program do you use?
[03:06:52] <jepler> 768M in my laptop and there's a bit of stuff swapped; 2G in my "server" and it barely swaps. Wanted to use something that would have taken 5G the other day (raytracing gimmick) but decided it would probably be too slow.
[03:06:54] <steve_stallings> PADS
[03:07:51] <steve_stallings> Board was 14" x 20" with 1 mil feature grid, 20 layers (12 routing, 8 power).
[03:07:53] <cradek> total used free
[03:07:53] <cradek> Swap: 987956 18412 969544
[03:08:15] <cradek> wow that's quite a board
[03:08:35] <jmkasunich> what was that board for?
[03:08:37] <steve_stallings> Made my life miserable for over 2 months.
[03:09:14] <steve_stallings> OC3 matrix switch 128 by 128 ports, non-blocking.
[03:09:58] <jmkasunich> zoiks
[03:10:17] <steve_stallings> The autorouter did not actually have much to do because all the high speed differential was hand routed, but the matix was still huge when I turned it loose on the random logic.
[03:10:46] <jmkasunich> so how do you get 128channels of OC3 onto the board?
[03:11:24] <jmkasunich> 128 of anything gets to be a lot of connector pins (or fibers, or whatever OC3 is)
[03:11:25] <steve_stallings> PECL differential sigs on 3 level DIN connectors.
[03:12:41] <steve_stallings> Power was actually more of a problem. This was several years ago and the PECL is hungry. Over 55 amps per board.
[03:13:09] <steve_stallings> Had to install the connectors using a solder fountain.
[03:13:16] <jmkasunich> ;-)
[03:13:27] <steve_stallings> There were no thermal reliefs on the power pins.
[03:13:44] <jmkasunich> why not? would they have overheated?
[03:14:09] <steve_stallings> Needed full copper to carry the current without IR drop.
[03:14:19] <jmkasunich> what is the supply voltage for pecl?
[03:15:50] <steve_stallings> Power supply is 5V, signals lower. Lots of passive terminations.
[03:16:10] <jmkasunich> so about 275 watts per board....
[03:16:30] <steve_stallings> Local high tech assy house said we broke the record with over 7000 components on the board at that time.
[03:16:35] <jmkasunich> I suppose point-of-use stepdown regulators would have just made the board more crowded?
[03:17:38] <steve_stallings> It would have taken several per board and we would still have needed a big switcher for the box. Not economical.
[03:17:57] <steve_stallings> Used 1KW switcher with remote sensing instead.
[03:18:40] <steve_stallings> Oh, and 12 fans per box.....
[03:18:46] <jmkasunich> heh
[03:19:08] <steve_stallings> If you cannot guess who would buy such a beast, I'm not going to tell you..... 8-)
[03:19:36] <jmkasunich> I certainly can guess
[03:19:45] <SWPadnos_> Cisco?
[03:19:53] <SWPadnos_> DoD?
[03:19:56] <jmkasunich> guess correctly is another thing alltogether... but I can guess
[03:20:10] <SWPadnos_> that was my plan ;)
[03:21:43] <jmkasunich> I hope you charged them an arm and a leg
[03:23:00] <steve_stallings> I did charge a lot for the layout, but I was just a sub-contractor on the box and don't actually know what it ultimately cost. Each board did contain 12 chips at $900.00 each for the switches.
[03:23:36] <jmkasunich> plus 6988 other parts ;-)
[03:23:42] <steve_stallings> Blank PCBs were about $2500 each.
[03:24:01] <SWPadnos_> 2000 0.01 uF bypass caps
[03:24:30] <SWPadnos_> did it use 4 mil trace/space?
[03:24:35] <steve_stallings> There were about 300 other active parts, rest were terminators and filter caps.
[03:25:01] <steve_stallings> 5/5 controlled impednance
[03:25:11] <SWPadnos_> oh - ceramic substrate?
[03:25:46] <steve_stallings> No regular FR4, just thin layers, 0.093" for 20 layer board.
[03:25:52] <SWPadnos_> eek
[03:26:50] <jmkasunich> that kind of stuff just makes my head spin
[03:26:58] <steve_stallings> Oh, and I forgot to mention that it was a double sided assy, 5000 or so of the terms and caps were on the bottom.
[03:27:14] <jmkasunich> well, I kinda assumed that
[03:27:26] <jmkasunich> active parts on both sides too? or just passives on the bottom?
[03:27:27] <SWPadnos_> of course. the big chips have too dense a fanout to allow any filter caps to be placed close enough onthe top side
[03:28:26] <steve_stallings> All passive on the bottom thankfully. I got to use lots of replicated placement and routing for the high speed stuff, but it still drove me crazy.
[03:28:46] <jmkasunich> I can imagine
[03:29:12] <jmkasunich> coming to work each day and sitting down to route that must have felt like trying to eat an elephant
[03:29:20] <SWPadnos_> especially with PADS ;)
[03:29:24] <steve_stallings> There are not enough colors in the display to understand what you are seeing on the screen. And even if there were, things are too dense to see all the way thru the layers.
[03:29:39] <jmkasunich> eating an elephant with chopsticks ;-)
[03:29:53] <SWPadnos_> a live elephant that doesn't want to be eaten :)
[03:30:04] <jmkasunich> no
[03:30:15] <jmkasunich> that experience would be mercifully short by comparison
[03:30:19] <SWPadnos_> heh
[03:30:30] <SWPadnos_> but not with the intended outcome ;)
[03:30:36] <steve_stallings> We actually had two people working on it at times. I use layers 1-8, you use layers 12-20, I do inputs, you do outputs.....
[03:30:46] <SWPadnos_> oh man
[03:31:00] <jmkasunich> the merge must have been fun... how did you do that?
[03:31:22] <SWPadnos_> oh yeah - one thing I forgot to mention about Altium is that it can use CVS (or other revision control system), and will actually do graphical comparisons between board revisions
[03:31:53] <SWPadnos_> I'm not sure how a merge works though
[03:32:18] <steve_stallings> As always, using ASCII files. Delete everything but nets of interest in one database, export, then import into other database.
[03:32:51] <steve_stallings> We were working with structured netnames so confusion wasn't too bad.
[03:35:18] <steve_stallings> SWP - How much grief am I asking for if I install Ubuntu with small monitor attached to Nvidia and connect 3007 later.
[03:35:32] <SWPadnos_> hahahahaha
[03:35:38] <SWPadnos_> um - not much, I think
[03:35:49] <jmkasunich> what is 3007
[03:35:56] <SWPadnos_> is the small monitor a CRT ot flat panel (DVI?)
[03:35:56] <steve_stallings> Dell 30" monitor
[03:36:05] <SWPadnos_> 2560x1600 resolution
[03:36:16] <SWPadnos_> s/ot/or/
[03:37:00] <steve_stallings> Small monitor is on analog VGA output.
[03:37:27] <SWPadnos_> ok, and you're planning on changing to a single 3007?
[03:38:01] <steve_stallings> JMK - the 3007 is not user friendly as it cannot operate as VGA or EVGA, only 2560x1600 or exactly half that, DVI only.
[03:38:10] <jmkasunich> ah
[03:38:26] <jmkasunich> would it make sense to set the system up as dual head
[03:38:29] <SWPadnos_> no, I think it scales OK, it just has exactly one input - dual-link DVI-D
[03:38:42] <jmkasunich> use the little screen for boot and such, then kick the big one into action
[03:38:57] <SWPadnos_> no - the 3007 will show boot stuff just fine
[03:39:05] <SWPadnos_> though the text is a little wide ;)
[03:39:18] <steve_stallings> SWP - nope, no scaling hardware in the monitor, only pixel doubler
[03:39:35] <SWPadnos_> well, it works at boot on the 3007 (and dual 3007) setups I've had access to
[03:40:04] <steve_stallings> Quoting specs on my part, have not had power on it yet.
[03:40:30] <SWPadnos_> ok. I've seen them in action, with Nvidia hardware - that's what I've seen it do
[03:40:46] <SWPadnos_> it could have been a 640x400 mode (?) for the BIOS, which would be pixel quadrupling
[03:41:01] <jmkasunich> so then what is the problem?
[03:41:13] <jmkasunich> boot in 640x400
[03:41:44] <SWPadnos_> changing from analog to DVI may be one problem, and trying to run a resolution on the analog monitor that isn't 1280x800 or so may not show up when the panel is plugged in
[03:42:09] <SWPadnos_> I'm not sure you can change the BIOS boot mode, bu tit hasn't been an issue from what I've seen
[03:42:35] <steve_stallings> There is a DVI to analog dongle. Would attaching analog monitor thru that help?
[03:42:53] <SWPadnos_> nope
[03:42:58] <jmkasunich> I was serious about the dual boot thing... if getting it to "change" modes when you swap monitors is gonna be a pain, then don't try - just let it have two, each with their own setup
[03:43:03] <SWPadnos_> the card is DVI-I, dual-link
[03:43:24] <SWPadnos_> that means that there is a set of analog pins (the cross shaped group), and 3 sets of digital pins
[03:43:30] <SWPadnos_> single link is two sets of digital pins
[03:43:55] <steve_stallings> OK, I just need to get the 3007 attached before I install Ubuntu.
[03:43:57] <SWPadnos_> the adapter only brings out the RGB and DDC pins to the appropriate VGA connector pins
[03:44:14] <SWPadnos_> no - it'll work, you will just need some modelines that may not be standard
[03:44:29] <steve_stallings> Hopefully the installer will find something that works.
[03:44:31] <SWPadnos_> do a little looking on the net for ubuntu nvidia 3007 (or 2560x1600)
[03:45:13] <SWPadnos_> you may want to remove all other modes though
[03:45:29] <SWPadnos_> just leave the 2560x1600 mode listed
[03:45:49] <steve_stallings> Wouldn't I want to keep 640x400 for safety?
[03:46:19] <SWPadnos_> I'm not sure there is a graphics mode that's 640x400. one of the text modes may be
[03:46:33] <SWPadnos_> that may have been an EGA standarg
[03:46:35] <SWPadnos_> standard
[03:46:59] <SWPadnos_> actually it was, come to think of it
[03:47:10] <steve_stallings> Ah, VGA was 640x480? EGA was 350 vertical.
[03:47:19] <jepler> I know CGA 320x200 was displayed as 400 lines ("DoubleScan") on VGA systems..
[03:47:26] <SWPadnos_> that was in text mode, I think
[03:47:44] <SWPadnos_> heh - yep
[03:48:03] <SWPadnos_> nonetheless, the monitor will display as large an image as it can, centered in the display :)
[03:48:18] <SWPadnos_> so you can set it for 1600x1200, and that's what you'll get, in the middle of the large screen
[03:48:56] <steve_stallings> If the Nvidia is smart enough to do that, all is well.
[03:48:57] <SWPadnos_> (at least that's what I think it does, but I'm not positive since I think the BIOS setup filled the screen)
[03:49:09] <SWPadnos_> that's a function of the monitor
[03:49:41] <steve_stallings> OK, I'm still hung up on the "no scaling hardware" thing.
[03:49:49] <SWPadnos_> it may only be able to scale by integer factors (or powers of 2), but I think it still displays the other modes
[03:50:00] <SWPadnos_> jus twith black borders
[03:50:05] <SWPadnos_> letterboxing :)
[03:50:18] <steve_stallings> Well, I'm off to download 6.06 LTS. Wish me luck.
[03:50:31] <SWPadnos_> good luck
[03:51:18] <SWPadnos_> if you can either wait to install ubuntu, or reinstall if you can't get it working, then you should be all set
[03:53:13] <steve_stallings> I am expecting to have to try several times to get Linux working dual boot with W2K dynamic disks in mirror mode. No live data on the machine yet.
[03:54:54] <SWPadnos_> hmmm - there may be an issue with that monitor and ubuntu 6.06
[03:55:23] <SWPadnos_> at least one person on the Ubuntu forums says that they can't get it beyond 1920x1440
[03:56:56] <SWPadnos_> heh - I should grab a liveCD and just try booting on one of the machines with those montiors
[03:57:32] <SWPadnos_> what video card did you end up with again?
[03:58:43] <steve_stallings> PNY GeForce 7600GS with 512M
[03:59:07] <SWPadnos_> ok, htat's dual dual-link, so it's fine (for two 3007s)
[03:59:12] <SWPadnos_> that's
[03:59:36] <steve_stallings> nope, only one DVI, but it is dual link
[03:59:55] <SWPadnos_> hmmm - ok. I didn't know any of hte current generation had only one DVI port ;)
[04:00:27] <steve_stallings> One DVI, one 15 pin VGA
[04:00:36] <SWPadnos_> ok
[04:01:44] <steve_stallings> Plus some strange DIN to S-VHS and other weird stuff.
[04:01:52] <SWPadnos_> http://www.ubuntuforums.org/showthread.php?t=152943
[04:02:06] <SWPadnos_> scroll down to post #5 :)
[04:02:29] <steve_stallings> Ah, DIN also supports component HDTV
[04:02:33] <SWPadnos_> cool
[04:03:25] <SWPadnos_> odd -my Quadro FX3500 only has 3 pins in the DIN connector - must be for stereo glasses or something
[04:05:53] <steve_stallings> This one is a 9 pin micro-DIN
[04:06:03] <steve_stallings> Thanks for the link
[04:06:09] <SWPadnos_> roght. I think that's what my 7800GT has
[04:06:36] <SWPadnos_> sure - I thought it would be easy, but my only experience includes a dual monitor setup, which is slightly harder
[04:07:50] <steve_stallings> I am hoping to avoid multiple monitors. May have to as other box on KVM is analog out.
[04:08:13] <SWPadnos_> I think there's an X oddity that would make you want to avoid it anyway
[04:08:47] <SWPadnos_> the total desktop must be a rectangle, I think, so you'd have a lot of blank space "below" the smaller monitor
[04:08:58] <SWPadnos_> you can't have a 2560x1600 monitor on the analog port ;)
[04:09:12] <SWPadnos_> (of course, you could buy a *real* video card ;) )
[04:10:06] <steve_stallings> Yes, but a DVI version of a KVM is still expensive.
[04:10:14] <SWPadnos_> yep
[04:10:26] <SWPadnos_> getting lower, but still in the several $hundreds, I think
[04:13:05] <steve_stallings> Great, my 6.06 download just finished, and now I see the alternate install CD image needed to support LVM and RAID.
[04:13:13] <SWPadnos_> heh
[04:13:25] <SWPadnos_> that didn't take long, you could probably download another image ;)
[04:14:18] <steve_stallings> May as well burn a copy of each.
[04:14:30] <SWPadnos_> oh well, time to go kill people for a while. have fun with the install(s)
[04:15:19] <steve_stallings> Games? or do you really hate trick-or-treaters?
[04:16:04] <SWPadnos_> heh - games
[04:16:25] <SWPadnos_> we had exactly one visitor (actually a pair) tonight - now I get to eat the rest of the candy
[04:16:28] <SWPadnos_> muahahahahaha
[04:22:53] <jmkasunich> goodnight guys
[04:27:23] <cradek> I have several X machines with non-rectangular screens; it works fine
[04:38:32] <steve_stallings> steve_stallings is now known as steves_logging
[08:46:22] <anonimasu> :)
[14:24:52] <jepler> skunkworks: did you submit an sf support request about the mailing lists?
[14:25:06] <skunkworks> yes
[14:25:29] <jepler> do you have the URL for the request?
[14:27:26] <skunkworks> looking now. it is a pain to find it on sourceforge
[14:27:43] <skunkworks> wait - I think I have an email conformation - hold on
[14:28:36] <skunkworks> https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1585349&group_id=1
[14:29:16] <jepler> thank you
[14:29:31] <skunkworks> np
[14:31:02] <skunkworks> It always used to be slow in updating - just not this slow ;)
[14:55:57] <cradek> strangely, he changed "mail archive not updating" to "mailing list archive issue" which is a less precise description
[14:57:14] <SWPadnos> at least he changed the assignment to a person as well :)
[14:57:45] <jepler> It must be part of their "call a spade something else" system of downplaying problems
[14:58:01] <cradek> you mean "issues"?
[14:58:08] <jepler> "issue reports"?
[14:58:38] <SWPadnos> I searched for "archive" onthat mage, there are 1916 results
[14:58:41] <rayh> Whatever came of the DH list test that SWP was working on.
[14:58:45] <SWPadnos> ... on that page ...
[14:58:56] <SWPadnos> dunno - let's check lists.linuxcnc.org
[14:59:40] <cradek> looks familiar
[14:59:44] <SWPadnos> heh
[15:00:09] <SWPadnos> does SF use mailman?
[15:00:18] <cradek> yes
[15:00:20] <jepler> yes, but not for the archiving
[15:00:29] <SWPadnos> ok
[15:00:54] <SWPadnos> well, that could make a transfer easier (maybe)
[15:01:25] <jepler> mailman archives look more like this:
http://mail.python.org/pipermail/python-list/2006-November/thread.html
[15:01:39] <cradek> I think we don't have a problem with the mailing lists, only the archives
[15:01:50] <SWPadnos> right
[15:01:50] <cradek> the lists on sf work well almost all the time
[15:03:21] <SWPadnos> sure. they're a bit slow - I sometimes get messages a couple of days later, but that's not necessarily their fault
[15:03:48] <cradek> that happens sometimes but especially lately I haven't seen it.
[15:04:08] <cradek> usually it's a minute or less until I have my own message back
[15:04:36] <SWPadnos> that's pretty common for me as well, but lately (like the CL discussion), I'd get a response before the question
[15:04:58] <cradek> hmm
[15:04:58] <SWPadnos> I was never sure if someone got a private email and responded to the list
[15:05:26] <SWPadnos> again, that may be a transport issue, not a list issue
[15:06:51] <rayh> SWPadnos, you created a private list name on DH. Mind sharing it's name?
[15:07:08] <SWPadnos> sure: emc2mail@lists.linuxcnc.org
[15:07:35] <SWPadnos> send a mail with "help" as the subject and/or body for instructions
[15:07:44] <SWPadnos> I'm on the admin page right now
[15:09:41] <cradek> No such list emc2mail
[15:09:58] <SWPadnos> I may have to complete some setup first :)
[15:41:54] <SWPadnos> ok. the list seems to be active now. I just got a request to approve my help request message :)
[15:42:26] <SWPadnos> maybe I should have omitted my signature from that message
[15:45:29] <SWPadnos> oops - it was my mistake. you need to email emc2mail-request@lists.linuxcnc.org for help
[15:48:43] <SWPadnos> Ray's help request is in the admin queue
[16:20:45] <rayh> I got it back saying it bounced.
[16:22:10] <SWPadnos> hmmm. I haven't gotten a response to my help request yet
[16:22:21] <SWPadnos> I wonder if I need to define the help text myself
[17:05:13] <alex_joni> wonder if we can set up an account to send mail from the SF's lists too
[17:05:20] <alex_joni> just for indexing / searching purposes
[17:05:37] <alex_joni> can't hurt to duplicate the data
[17:23:00] <SWPadnos> I should be able to subscribe some user on linuxcnc, but getting it into a searchable archive would be the stumbling block, I think
[17:23:17] <alex_joni> unless it's a mailing list :)
[17:23:24] <alex_joni> with almost no users subscribed
[17:23:33] <alex_joni> but subscribed to the mailing list at SF
[17:23:36] <SWPadnos> indeed
[17:24:23] <alex_joni> heh.. this can get into trouble at some point :)
[17:24:35] <alex_joni> like messages bouncing forth and back
[17:24:42] <SWPadnos> yep
[17:25:33] <alex_joni> the DH list needs to be subscribed to SF and vice-versa
[17:25:57] <SWPadnos> yep. I think the DH list wouldn't send anything to the SF list though
[17:26:08] <alex_joni> it can be configured that way I hope
[17:26:09] <SWPadnos> unless the address changed
[17:26:23] <SWPadnos> well, it would only send error messages, I think
[17:26:27] <SWPadnos> err - wait
[17:26:49] <SWPadnos> no - itwould send all messages back to the SF list - it would be a ping-pong
[17:27:03] <alex_joni> right
[17:27:22] <SWPadnos> that wouldn't be ideal :)
[17:34:22] <SWPadnos> hmmm. if the DH list is subscribed to the SF list, that should work (other than some possible startup issues)
[17:34:37] <SWPadnos> the SF list doesn't need to be subscribed to the DH list
[17:34:42] <alex_joni> yes it does
[17:34:57] <alex_joni> DH subscribed to the SF list means that SF knows the DH address
[17:35:07] <SWPadnos> it needs to be allowed to send messages, but doesn't need to receive them
[17:35:10] <alex_joni> but the DH list won't accept mail from the SF address, cause it's not on it's list
[17:35:42] <alex_joni> but you can put the SF address on the DH list with mail delivery turned off
[17:36:12] <cradek> it's a bonus if anything the DH list might send to the SF list would be held for moderation
[17:38:28] <SWPadnos> hmmm. I'll need to look at the config pages a bit more - it looks like the archives are private (only searchable by members) by default
[17:38:33] <SWPadnos> I'm not positive that can be changed
[17:38:47] <jepler> lots of mailman systems have public archives
[17:39:00] <SWPadnos> ok - I think I found the settings
[17:40:17] <SWPadnos> yep - that worked
[17:40:43] <SWPadnos> so the emc2list-request address seems defunct (for me, so far), but the list appears to be functioning
[17:40:47] <SWPadnos> http://lists.linuxcnc.org/listinfo.cgi/emc2mail-linuxcnc.org
[19:35:28] <anonimasu> hm
[19:35:35] <anonimasu> I just did some testcuts..
[19:35:43] <anonimasu> to see if my spindle could handle it :9
[19:35:54] <alex_joni> you're still smiling...
[19:36:00] <anonimasu> yeah
[19:36:09] <alex_joni> ok then
[19:36:24] <anonimasu> 8x8mm cuts with a 10mm endmill :)
[19:36:36] <anonimasu> at 500mm/min
[19:36:46] <anonimasu> at 3000rpm :)
[19:37:08] <anonimasu> the spindle still sounded like it'd cut more :)
[19:37:15] <anonimasu> but, kind of scary without coolant..
[19:37:41] <anonimasu> I'm going to order a beltdrive to get it up to 5000rpm tomorrow
[19:37:45] <anonimasu> beltdrive/gears
[19:37:55] <anonimasu> ah #devel.. sorry :)
[19:39:04] <anonimasu> alex_joni: it's amazing how good it feels when everything works :)
[19:39:11] <alex_joni> nice
[19:39:19] <alex_joni> no more rugged circles?
[19:39:37] <anonimasu> yeah, but I think I've located it
[19:39:44] <anonimasu> it's the mount for the y axis that's moving
[19:39:46] <anonimasu> :)
[19:39:49] <alex_joni> ok
[19:39:50] <anonimasu> err no..
[19:40:09] <anonimasu> the nut/thread on the ballscrew has broken..
[19:40:24] <anonimasu> the preload nut.. :)
[19:40:58] <anonimasu> the bearings and the thread were too close to eachother so it's not a good thread..
[19:41:13] <anonimasu> same as last time it explains why backslash started to show up af the run went on :)
[19:41:30] <anonimasu> with the circles
[20:54:31] <jmk_away> jmk_away is now known as jmkasunich
[21:00:06] <SWPadnos> hi jmk
[21:00:28] <rayh> Hi john
[21:08:29] <jmkasunich> hi guys
[21:08:52] <cradek> hi jmk
[21:08:53] <alex_joni> hi john
[21:09:11] <jmkasunich> back home, a day + 3 hours early ;-)
[21:09:21] <SWPadnos> making up for Finland I guess :)
[21:09:57] <alex_joni> that probably means you had some success with the drive test :)
[21:10:06] <jmkasunich> actually, got back from .fi about 1 hour earlier than planned
[21:10:20] <SWPadnos> than originally planned?
[21:10:32] <jmkasunich> yeah
[21:10:38] <SWPadnos> ah - but had to leave ~6 hours early to do it
[21:10:45] <jmkasunich> something like htat
[21:10:46] <jmkasunich> that
[21:11:05] <jmkasunich> plus the 24 hours or so of wondering what we were gonna do
[21:11:05] <alex_joni> jepler: where's that picture of yours?
[21:11:07] <SWPadnos> well, it all averages out, so you should be expecting some unexpected delays soon ;)
[21:11:24] <alex_joni> jmkasunich:
http://emergent.unpy.net/files/sandbox/pwm-idea.png :)
[21:12:21] <SWPadnos> oh - I forgot to mention that the PWM quality from that circuit is dependent on the quality of the sawtooth/triangle wave generator
[21:12:44] <jmkasunich> so its really DtoA followed by PWM generation
[21:13:20] <SWPadnos> yep - decouples the PWM rate from the BASE_PERIOD
[21:13:32] <jmkasunich> seems feasable
[21:13:53] <jmkasunich> if I was gonna go to the trouble of making a board for it I'd probably be just a teeny bit more elaborate
[21:14:00] <SWPadnos> heh
[21:14:05] <jmkasunich> maybe a 2pole filter for the D/A part
[21:14:18] <jmkasunich> of course that means an opamp...
[21:14:32] <jmkasunich> the other part that could get interesting is making it biploar
[21:14:33] <SWPadnos> that's OK - there are probably extras in the package
[21:15:30] <jmkasunich> when emc goes from + to - the + output is guaranteed to stop pulsing when the - starts
[21:16:02] <jmkasunich> with two of those circuits, the + will gradually decrease in duty cycle and eventually stop, while the - will start very quickly and ramp up
[21:16:07] <jmkasunich> might have both going at once
[21:16:39] <SWPadnos> the trouble is that the accuracy of the output value is still dependent on BASE_PERIOD and the filter (you only have filter time (constant / BASE_PERIOD)+1 steps)
[21:17:02] <jmkasunich> right
[21:17:02] <SWPadnos> err -the word time should have been inside the parens
[21:17:14] <SWPadnos> so that's good for spindle, but not necessarily servos
[21:17:34] <jmkasunich> actually, I think its the other way around (maybe)
[21:17:51] <jmkasunich> the servos put the PWM inside a feedback loop, so small errors can be corrected
[21:17:53] <jmkasunich> spindle doesn't
[21:18:24] <SWPadnos> sure, but spindle can be filtered over a longer time, so there will be less error to start with
[21:18:33] <jmkasunich> true
[21:19:07] <jmkasunich> if I was going to go to the trouble of building that, I'd be really tempted to use real dacs
[21:19:17] <SWPadnos> I'd probably use a microcontroller :)
[21:19:21] <SWPadnos> and/or real DACs
[21:19:22] <jmkasunich> I guess the problem is figuring out how to interface them over the parport
[21:19:38] <SWPadnos> I've been working on the problem of isolated analog output (and input would be nice as well)
[21:19:40] <jmkasunich> true - if you really want only the PWM, uC makes more sense
[21:19:45] <SWPadnos> it looks like it's not a trivial problem
[21:19:59] <jmkasunich> I recently did a precision analog isolator design
[21:20:05] <SWPadnos> and expensive to build
[21:20:16] <jmkasunich> self oscillating pwm generator and a demodulator on the other side
[21:20:16] <SWPadnos> open source? ;)
[21:20:22] <jmkasunich> good to about 0.1%
[21:20:38] <SWPadnos> hmmm. is asymmetry in the optoisolator a problem?
[21:20:47] <jmkasunich> well, it was for work, but I might have the same idea while at home, and I might write it down somewhere on the net
[21:20:52] <SWPadnos> or do you use a transformer?
[21:20:58] <SWPadnos> I see
[21:20:58] <jmkasunich> neither (sort of)
[21:21:03] <SWPadnos> ok
[21:21:05] <jmkasunich> the magic ingredient is:
[21:21:17] <jmkasunich> goolging...
[21:21:31] <jmkasunich> (I mean, I'm googling for a url)
[21:21:47] <SWPadnos> Mariss posted a schematic for something that converts analog to PWM (unnecessary for me), then runs the PWM through an optoisolator, then filters / buffers the output of that
[21:21:48] <SWPadnos> sure
[21:21:58] <jmkasunich> http://www.analog.com/en/prod/0,2877,ADUM2402,00.html
[21:22:02] <jmkasunich> thats what I did too
[21:22:10] <SWPadnos> the solution I found was to use one if the TI isolated DC:DC converers (or similar)
[21:22:11] <jmkasunich> using the above for the isolator
[21:22:38] <SWPadnos> ok - the high speed gives you close enough to symmetric operation
[21:22:45] <SWPadnos> for PWM rates anyway
[21:22:58] <jepler> SWPadnos: that's the design of the spindle speed control on the nist lathe -- PWM -> opto -> filter
[21:22:59] <jmkasunich> the trick for accuracy and response time is that the PWM generator includes the isolator in the loop, so errors are compensated
[21:23:11] <jmkasunich> the only thing that isn't is channel mismatch between the isolators
[21:23:31] <SWPadnos> that's great when your loop is not an open one ;)
[21:23:49] <jmkasunich> I wasn't clear
[21:23:56] <jmkasunich> damn, I need a pencil
[21:24:05] <jmkasunich> lemme describe the concept
[21:24:19] <jmkasunich> first, you got a comparator, with about 5mV of hystersis
[21:24:32] <jmkasunich> the output of that drives a forward channel on the opto
[21:25:01] <jmkasunich> when it gets to the other side, its looped right around into a backward channel on the isolator (sorry, not really opto)
[21:25:12] <jmkasunich> there are RC filters on _both_ sides, matched
[21:25:21] <jmkasunich> the output of the filters is buffered on both sides
[21:25:33] <jmkasunich> on the input side, the output of the filter goes to one comparator input
[21:25:40] <jmkasunich> and the main input signal goes to the other
[21:25:50] <jmkasunich> the input filter has only a single pole
[21:26:00] <jmkasunich> the output filter has a second higher frequency pole
[21:26:28] <SWPadnos> ah, ok. you're adding a feedback loop for just the isolator chain
[21:26:36] <jmkasunich> so the output of the input side filter has some ripple on it - 5mV to be precise, because that is the comparator hystersis
[21:26:46] <jmkasunich> (it is a self oscillating PWM generator)
[21:27:01] <SWPadnos> right - got it now
[21:27:33] <SWPadnos> rayhczilla, I think your nick should be Rayzilla instead :)
[21:27:37] <jmkasunich> it can track far higher slew rates than a simple pwm/filter combo with the same outout ripple
[21:28:04] <SWPadnos> interesting. I was looking at parts like this one on DigiKey
[21:28:25] <SWPadnos> the idea is to make a serial board with a microcontroller, and isolation to the I/O
[21:28:33] <jmkasunich> for more "normal" voltages, they have a ADUM1xxx family, thats a little cheaper
[21:28:43] <SWPadnos> one possibility is to drive the isolator directly with RX and TX, and have the entire board on the "high side"
[21:28:56] <jmkasunich> (I needed higher isolation for 480/690V )
[21:29:15] <SWPadnos> oh yeah - 1500V isolation may be less than 5kV
[21:29:35] <jmkasunich> ?
[21:29:41] <SWPadnos> in cost
[21:29:51] <jmkasunich> I think the 1xxx family is 2.5KV, but I could be wrong
[21:29:54] <SWPadnos> 1500 was the number I saw on a lot of optos
[21:30:06] <SWPadnos> or 1300 or something - I don't recall :)
[21:30:09] <jmkasunich> the ADUM stuff kicks ass IMHO
[21:30:25] <jmkasunich> the only downside (and its only a downside in _some_ applications) is that you need power on both sides
[21:30:33] <jmkasunich> (rather than just turning on a LED)
[21:30:52] <SWPadnos> ah - that's a potential
[21:30:54] <SWPadnos> problem
[21:30:55] <jmkasunich> if you are doing an isolated 24V digital input I'd still use an opto
[21:31:05] <jmkasunich> but for serial comms and such, these things are a huge win
[21:31:34] <jmkasunich> cheap (compared to moderately fast optos), blazing fast, and multiple channels in one package
[21:33:21] <jepler> these "ADUM" gizmos just look like regular surface-mount ICs?
[21:33:57] <jmkasunich> yes
[21:34:00] <jmkasunich> wide soics
[21:34:21] <jepler> the transformer must be pretty small then
[21:34:30] <jmkasunich> oh, looks like the 1xxx series is narrow soics
[21:35:05] <jmkasunich> they call them "chip scale transformers"
[21:35:16] <SWPadnos> my idea was to use the serial port modem control pins as a power supply for the PC side, and then have a power supply on the other side that's isolated from the PC, but not from the device the board is connected to
[21:35:34] <SWPadnos> that saves me from needing a DC:DC transformer on the board
[21:35:35] <alex_joni> jmkasunich: I used the 1:1 transformers found on older ethernet cards before
[21:35:35] <jmkasunich> SWPadnos: probably possible
[21:36:01] <SWPadnos> the transformers are do expensive - like $8-$11 for 1W
[21:36:11] <SWPadnos> s/do/so/
[21:36:28] <jmkasunich> ADUM1201, one channel each direction, $1.37
[21:36:36] <SWPadnos> but no power ...
[21:36:37] <jepler> discarded ethernet cards are cheap as free around here
[21:36:44] <jmkasunich> 1.1mA/channel at 0-2Mbps
[21:37:00] <jmkasunich> 0.8mA/channel at 3V
[21:37:11] <jmkasunich> I bet you can get that from the serport control lines
[21:37:25] <jepler> * jepler pokes cradek
[21:37:32] <jepler> did you do anything with serport yet?
[21:37:37] <jmkasunich> narrow 8 pin soic - effin small
[21:37:38] <cradek> no
[21:39:12] <jmkasunich> do "all" PC serial ports pretty much emulate the same USARTs?
[21:39:40] <jepler> jmkasunich: yes, you can still program them like the original 8250
[21:39:42] <jmkasunich> such that you can write a single inb/outb level hard realtime driver and have it work for most any serial port?
[21:39:51] <jmkasunich> cool
[21:39:57] <jmkasunich> thats one advantage serport has over ethernet
[21:39:58] <jepler> some probably have the same PNP-type problems as we discovered on parport
[21:40:16] <jmkasunich> yeah, but once you find the damn thing, you're OK
[21:40:20] <jepler> yep\
[21:40:23] <SWPadnos> this is to use the modem control/status lines as I/O, not to use the port as a serial device
[21:40:35] <jmkasunich> I understand that jepler was doing that
[21:40:42] <jepler> yeah, that is checked in
[21:40:52] <jepler> with the use of realtime fifos, it would not be hard to add serial communication
[21:40:58] <SWPadnos> ok - is there also work on a serial packet driver or similar?
[21:41:08] <jmkasunich> I'm thinking of a smart device like the G-rex or jonE's stuff that is attached by serial, using the isolation idea you were just talking about
[21:41:28] <jmkasunich> SWPadnos: I wouldn't say there is "work"
[21:41:41] <jmkasunich> right at this very moment in this very IRC channel there is brainstorming
[21:41:43] <SWPadnos> heh
[21:41:46] <jmkasunich> dunno how far that will go
[21:42:03] <jmkasunich> how fast can you make a PC serport go?
[21:42:10] <SWPadnos> 921.6kbaud
[21:42:13] <alex_joni> isa fast
[21:42:15] <SWPadnos> unless you go way out there
[21:42:22] <jmkasunich> zoomy
[21:42:23] <alex_joni> he said serport not serial port
[21:42:28] <jepler> I think that when you use the 8250-compatible mode it tops out slower, 115200 maybe
[21:42:35] <anonimasu> hehe
[21:42:38] <SWPadnos> 115.2k is the fastest on an 8250 though
[21:42:56] <jmkasunich> aren't there some modes that are a little fancier than 8250, but still pretty universal?
[21:43:06] <jmkasunich> chips with 16 byte buffers rings a bell
[21:43:07] <cradek> 16550
[21:43:21] <alex_joni> * alex_joni remembers that number
[21:43:24] <SWPadnos> 16450, 16550, 16850 ...
[21:43:24] <jmkasunich> thank you - that number was on the tip of my tongue and was driving me nutx
[21:43:38] <SWPadnos> maybe 16950
[21:43:39] <alex_joni> old days playing with setserial and linux modems
[21:43:55] <jmkasunich> any even remotely modern mobo or serport is gonna emulate one of the newer chips
[21:44:44] <jmkasunich> if the packet size can be kept smaller than the UART fifo, you can send the message with very little overhead
[21:44:46] <SWPadnos> 16550, most likely
[21:45:04] <jepler> anyway -- the current "serport" driver in CVS talks just to the control lines. The I/O time seems to be similar to that of hal_parport, around 1uS per I/O, 3 I/Os to read and write all ports
[21:45:55] <jepler> http://linuxcnc.org/docs/html/man/man9/serport.9.html
[21:46:07] <jmkasunich> 10 bytes at 115K can fit in a millisecond with just a little time to spare
[21:46:11] <jmkasunich> what can you do with 10 bytes
[21:46:54] <jmkasunich> 4x 12bit DAC or PWM command plus 20 some dig outs
[21:47:08] <SWPadnos> and that's 10 bytes in each direction - it's full duplex
[21:47:13] <jmkasunich> right
[21:47:17] <jmkasunich> I was just getting to input
[21:47:20] <SWPadnos> heh
[21:47:49] <jmkasunich> encoder counts can get long, unless you transmit only the LSB and make it big enough to avoid rollover in a message period
[21:47:50] <SWPadnos> there has to be error checking and sequencing though, so take out 2-3 bytes for that
[21:47:50] <jepler> Or, on input, 4 encoder counts plus limit switches etc -- if ~2000 counts/ms is fast enough
[21:48:03] <jmkasunich> right
[21:48:12] <SWPadnos> only send the delta
[21:48:30] <jmkasunich> call them 12-bit "analog" values, whether DAC or PWM out, and whether ADC or encoder in
[21:48:47] <jmkasunich> swp: I'd send the low N bits (n = 8 or 12)
[21:49:04] <SWPadnos> ok, so 4 analogs at 12 bits, and 16 digitals in each direction, plus 2 bytes for overhead
[21:49:14] <jmkasunich> that way, one lost message doesn't make you lose counts, as long as the distance traveled between good messages doesn't involve a wrap
[21:49:43] <SWPadnos> true, but it's harder to detect a wrap (and not 100% effective)
[21:50:02] <jmkasunich> ?
[21:50:07] <SWPadnos> there's no difference between -1 and +255 for the low 8 bits of a word
[21:50:21] <SWPadnos> if I sent a 0, then a 255, you don';t know which way it went
[21:50:35] <jmkasunich> right, but if the max speed is less than +/-127 counts per period, you can always tell
[21:50:50] <jmkasunich> 8 bits would handle 128KHz, 12 would handle 2MHz
[21:50:51] <jepler> but if you want to be sure after one garbled packet, it has to be +-64 counts
[21:51:01] <SWPadnos> right
[21:51:03] <jmkasunich> ok, so 8 = 64KHz, 12 = 1MHz
[21:51:13] <jmkasunich> 12 is still plenty for all but the most insane encoders
[21:51:38] <SWPadnos> that's why I have overhead in there - packet sequence numbers are a good thing for error detection
[21:51:45] <SWPadnos> and checksums
[21:51:50] <jepler> if we're planning on a buffer then assume 16550 which will go above 115k -- give yourself 16 bytes to play with
[21:51:57] <jepler> 230kbps
[21:52:16] <jmkasunich> what about on the microcontroller end? do their uarts have buffers?
[21:52:22] <jepler> typically, no.
[21:52:31] <alex_joni> * alex_joni heads for bed
[21:52:34] <alex_joni> good night all
[21:52:35] <jepler> where "typically" refers to the non-mega AVRs
[21:52:47] <jmkasunich> bitbanging 230K is definitely out, is handling byte interrupts at 23K reasonable?
[21:52:59] <jmkasunich> 46 K actually, if full duplex
[21:52:59] <SWPadnos> it's generally immaterial though, since interrupt response time is in the very low microsecond range
[21:53:18] <SWPadnos> you handle interrupts for full buyes only, not bits
[21:53:22] <SWPadnos> yes, it should be fine
[21:53:25] <jepler> hence 23k
[21:53:56] <jmkasunich> so, 9 pin D shell and ADUM1201 for the serial isolation, power the PC side with control lines
[21:54:31] <jmkasunich> 4.7V zener or a cheap LDO regulator, in case you have real RS-232 levels
[21:54:43] <SWPadnos> unless it's a good thing to isolate I/O individually (such as to a VFD and a set of servo drives)
[21:54:46] <jmkasunich> but it will run on 3V so even a laptop serport should be able to power it
[21:55:02] <jepler> I'm sure you can do 230kbps serial on a micro, but maybe not if you want to do proper ECC on the data
[21:55:07] <SWPadnos> are the outputs rail to rail?
[21:55:28] <jepler> simple ip-style checksums would be doable
[21:55:30] <SWPadnos> ECC is typically a lookup table function on micros
[21:55:36] <jmkasunich> http://www.analog.com/UploadedFiles/Data_Sheets/ADUM1200_1201.pdf
[21:55:40] <SWPadnos> CRC32 and / or FEC
[21:56:00] <SWPadnos> yep - that's the one I'm looking at ;)
[21:56:20] <jepler> CRC32 is only error detection -- I'm not familiar with FEC.
[21:56:24] <jmkasunich> it is rail to rail
[21:56:33] <SWPadnos> I think I have AVR code that does CRC32 in 10 cycles per byte (including loading the table pointers)
[21:56:37] <jmkasunich> I wasn't thinking of correction, just detection
[21:56:44] <SWPadnos> Forward Error Correction - probably not useful here
[21:57:00] <SWPadnos> usually used on questionable channels, such as RF
[21:57:13] <jmkasunich> although with packets of only 80-100 bits, who knows
[21:57:49] <SWPadnos> a 2-byte CRC is guaranteed to detect any errors in a packet that small
[21:57:50] <jepler> how well/poorly will emc's pid deal with encoders that stick for 1ms then jump ahead again?
[21:58:07] <jepler> OTOH why would this have worse error characteristics than the various parallel-port schemes
[21:58:07] <SWPadnos> the pid runs at the same rate as the serial driver
[21:58:08] <jmkasunich> it would make a disturbance
[21:58:24] <SWPadnos> so it only corrects when it has a new value to work with
[21:58:26] <jmkasunich> I don't think the disturbance would be all that bad
[21:58:34] <SWPadnos> the problem is that they're out of phase
[21:59:01] <jmkasunich> if the packet coming from the hw is bad, it would be discarded, and the feedback value would remain frozen for 1mS
[21:59:17] <SWPadnos> ie, feedback is from timeslice 0, calculations are done in timeslice 1, and corrections are output in timeslice 2
[21:59:21] <SWPadnos> right
[21:59:42] <SWPadnos> this is the same problem as the USB 1ms issues, only with the added problem of having less bandwidth to work with ;)
[21:59:46] <jmkasunich> we could emulate that today with a mux configured as a sample/hold, and a pulse from a oneshot component (do we have on of those?)
[21:59:55] <SWPadnos> yes
[22:00:04] <SWPadnos> I think jepler made a comp for that
[22:00:10] <jmkasunich> but the added benefit of not dealing with USB chipset and setup issues
[22:00:26] <SWPadnos> sure
[22:00:32] <SWPadnos> though there are setup issues
[22:00:40] <SWPadnos> not all ports will be set to 115200 baud by default
[22:00:41] <jmkasunich> 1000 bit packets would be nice (ethernet or USB2), but I'm not gonna write a RT driver for that
[22:00:56] <SWPadnos> not all ports will operate at 115200 baud with a divisor of 1
[22:00:58] <jmkasunich> 80-100 bit packets over the serport is very doable with a simple driver
[22:01:23] <SWPadnos> Evert Lammerts has made a RTNet HAL driver
[22:01:24] <jmkasunich> well, there's always _some_ setup
[22:01:58] <jmkasunich> I don't know what Evert did, I suppose I need to ask
[22:02:00] <SWPadnos> his basically allows you to have HALs on two machines talk to each other via ethernet
[22:02:12] <SWPadnos> he emailed it to the list as a .tar.gz file
[22:02:18] <jmkasunich> ok, matching pins on both sides of the link?
[22:02:25] <SWPadnos> yep
[22:02:54] <jmkasunich> I've been too lazy to learn what is needed to get RTNet running, and add his stuff to our make system
[22:02:57] <SWPadnos> 9/6/2006, 9:36 AM is the timestamp in my inbox
[22:03:02] <SWPadnos> 20k or so
[22:03:15] <jmkasunich> our config would have to detect a RTNet install, and decide to build it, etc
[22:03:18] <rayh> I thing Evert got moved away from that to another project.
[22:03:20] <SWPadnos> subject "HAL driver for RTnet"
[22:03:31] <SWPadnos> yep, but he mailed his progress to the user list
[22:04:01] <SWPadnos> configuration is a nightmare, as is providing the correct kernel / other modules
[22:04:10] <jmkasunich> thats what I was afraid of
[22:04:24] <SWPadnos> I say that as a suspicion, not as an experienced person
[22:04:28] <jmkasunich> my energy level lately just hasn't been up to tackling things like that
[22:04:36] <jmkasunich> but the serport thing has me interested
[22:04:47] <SWPadnos> me too
[22:05:01] <SWPadnos> I may have the opportunity to design a serial board that we can use as well
[22:05:11] <SWPadnos> (and even get paid to do it! ;) )
[22:05:28] <jepler> UARTs on micros: Bigger AVRs, like atmega16, provide a 2-byte receive FIFO. Even small ARMs have a 16550 UART with 16-byte buffer.
[22:05:30] <jmkasunich> I should do some reading about the serport... see how "discoverable" its abilities are
[22:05:51] <anonimasu> discoverable?
[22:05:53] <SWPadnos> yeah - I don't remember how the detection works
[22:06:01] <jmkasunich> if the driver can identify a 230Kbit serport and use that rate without jumping thru too many hoops, the packet size starts to get _very_ interesting
[22:06:10] <SWPadnos> I think you write some of the extended registers and see if they read back correctly
[22:06:28] <anonimasu> ah ok
[22:07:03] <SWPadnos> setserial may actually have a function to tell you the type of serial ports
[22:07:20] <jmkasunich> I had been thinking of a m5i20, but maybe this is another approach for the project I'm noodling on
[22:07:35] <SWPadnos> better isolation than the m5i20 :)
[22:07:41] <SWPadnos> at least with that AD part
[22:08:00] <jmkasunich> in addition to 3 or 4 stepgen/pwmgen/dac and 3/4 encoders plus some digital I/O, I want 3 channels of PWM and 3 channels of ADC
[22:08:20] <jmkasunich> (for a spindle drive)
[22:08:25] <SWPadnos> yep
[22:08:47] <jmkasunich> the ADCs are two channels of current feedback and one for DC bus voltage
[22:08:54] <SWPadnos> ideally, bipolar PWM, several output bits, and a couple of input bits, plus a tach input and encoder input
[22:09:00] <jmkasunich> although I'd really want about 4KHz sample rate for that
[22:09:14] <SWPadnos> 3 PWM for direct AC drive strength?
[22:09:19] <SWPadnos> -strength
[22:09:22] <jmkasunich> yeah, 3 phase bridge
[22:09:25] <SWPadnos> cool
[22:09:31] <SWPadnos> no VFD required :)
[22:09:37] <jmkasunich> zactly
[22:09:56] <jmkasunich> the motor I have is permanent magnet, so an ordinary VFD would be a little tough to use
[22:10:36] <jepler> so -- a HAL component that talks to a PC 16550 serial port at 230kbps with 16-byte frames, which include 4 12-bit "analog channels" each with optional extension to 32-bits in the driver of the input channels, plus some number of digital I/Os, plus error detecting code...
[22:10:59] <SWPadnos> there are several microcontrollers and DSps that are optimized for motor control - with 3 or 6 PWM pairs, programmable deadtime, etc.
[22:11:32] <jmkasunich> SWPadnos: I know - we use some at work
[22:11:37] <SWPadnos> heh
[22:11:46] <jmkasunich> but the appeal of this idea to me is using the PC to do all the heavy lifting
[22:11:53] <SWPadnos> DSP56800E and the like
[22:11:58] <jepler> I'm not sure I'm up to designing the protocol but I can sure do the register-level stuff
[22:12:13] <jepler> serial loopback makes it easy to test, too
[22:12:37] <jmkasunich> all I want from the hardware is instantenous overcurrent protection (comparators and a latch), current sense (2 A/Ds), bus sensing (1 A/D) and pwm generation (3 channels)
[22:12:43] <SWPadnos> the protocol should be that a HAL driver dumps a packet of the right size, and the serial driver transmits it (and receives a packet into a buffer)
[22:13:03] <SWPadnos> so the serial driver is a timed packet tx/rx machine only
[22:13:02] <jepler> SWPadnos: except there are no HAL data types for "packets"
[22:13:12] <jmkasunich> two levels to the driver
[22:13:22] <jmkasunich> phys layer gets a packet from PC to uC
[22:13:25] <jmkasunich> and back
[22:13:42] <jmkasunich> upper layer maps some combination of hal pins into a packet, and unmaps a rx packet into pins
[22:13:43] <jepler> though there rtapi fifos
[22:13:57] <jmkasunich> don
[22:14:00] <SWPadnos> that's true, though for small packet sizes, one could have 16 pins that are bytes, or 4 u32s
[22:14:03] <jmkasunich> dont want fifos
[22:14:26] <jmkasunich> things like encoders would want the 12->32 bit extension in the driver...
[22:15:04] <SWPadnos> but the serial port deals with bytes, so just have a driver that deals with bytes
[22:15:18] <SWPadnos> and maybe checksums / CRCs
[22:15:32] <jmkasunich> I'm thinking the phys layer handles the crcs and such
[22:16:06] <SWPadnos> right (optionally, controlled by params)
[22:16:06] <jmkasunich> you sould specify packet size, and the driver would have tx and rx packet buffers
[22:16:22] <jmkasunich> the packer code would build a packet, then the low level driver would add CRC and send it
[22:16:30] <SWPadnos> actually, the driver can export a U32 pin that's the address of the current buffer :)
[22:16:44] <jmkasunich> scary
[22:16:53] <SWPadnos> yes
[22:16:58] <jepler> terrible idea
[22:17:01] <SWPadnos> heh
[22:17:23] <jmkasunich> I'm thinking the two "levels" I'm talking about are compiled into a single driver, matched to the board on the other end
[22:17:35] <SWPadnos> ah
[22:17:39] <jmkasunich> but different boards could use the same phys layer, with a different pack/unpack layer
[22:17:52] <jmkasunich> so I'd split up the code that way
[22:18:08] <SWPadnos> I was trying to think of a way that there could be one serial driver, but multiple consumers of the date
[22:18:10] <SWPadnos> data
[22:18:31] <SWPadnos> but you're thinking of hal_serial_lib or similar
[22:18:38] <jepler> and I was trying to simplify the other way, by pre-setting the packet format
[22:18:39] <jmkasunich> multiple _physical_ consumers? ie, a multidrop serial link?
[22:18:53] <rayh> yuck
[22:19:02] <SWPadnos> well, there could be multidrop, but that's not what I was talking about
[22:19:23] <SWPadnos> more like "I loaded hal_serial, and now I connect the bytestream to my_serial_packet_decoder"
[22:19:31] <jmkasunich> I don't think multidrop would work
[22:19:56] <jmkasunich> the PC->uC part might, but uC->PC would be horrible
[22:20:02] <SWPadnos> multidrop would have to work like RTNet (or USB) - with all nodes knowing when they're supposed to talk and listen
[22:20:10] <jmkasunich> the baud rate is too slow to have multiple uCs each send a packet
[22:20:11] <SWPadnos> so it's too much of a PITA to be useful
[22:20:32] <SWPadnos> nevermind multidrop - that's not what I was talking about
[22:20:47] <SWPadnos> it's more like separating PID from the motion controller
[22:21:53] <jmkasunich> we may be closer together than we think, and just not communicating well
[22:21:55] <SWPadnos> consider this: if we can figure out how to have a separate physical layer for serial in HAL, then we can use the same packet type for a USB device, or an ethernet device, by changing only the underlying physical HAL driver (and the remote device, of course)
[22:21:58] <SWPadnos> yep
[22:22:13] <SWPadnos> or parallel, for that matter
[22:22:22] <jmkasunich> I was thinking that few if any people would be interested in my AC drive version, but I'd certainly want to reuse the CRC code and such
[22:22:29] <SWPadnos> yep
[22:22:46] <SWPadnos> so you're thinking of a library that you like to drivers that want to use the seral port
[22:22:50] <SWPadnos> link, not like
[22:22:57] <jmkasunich> yeah
[22:23:07] <jmkasunich> but the idea of having several phys layers is interesting
[22:23:19] <SWPadnos> damn. got to run (the wife's out walking to dinner and I have to catch up with the car)
[22:23:22] <jmkasunich> we have a pack/unpack layer, than makes packets
[22:23:29] <jmkasunich> then you link it to the phys layer of your choice
[22:23:36] <SWPadnos> I think the problem is more getting multi-byte values around HAL
[22:23:43] <jmkasunich> I don't
[22:23:46] <SWPadnos> multi-word, that is
[22:23:47] <jepler> we shouldn't forget that we have the whole run-time linker available in the kernel
[22:24:01] <SWPadnos> right
[22:24:04] <jmkasunich> by the time HAL sees the values, I want them to be canonical encoders, dacs, etc
[22:24:17] <jmkasunich> I don't want to be passing raw binary data around in HAL, thats not what it was made for
[22:24:18] <SWPadnos> will you folks still be around in about 1-1.5 hours?
[22:24:27] <jepler> I'll be back sometime this evening
[22:24:34] <jepler> not entirely sure of my schedule
[22:24:34] <jmkasunich> probably not - going out for the evening around 6:30 or so
[22:24:36] <SWPadnos> ok. I've really got to go now :)
[22:24:45] <SWPadnos> I'm going out around 5:20 or so ;)
[22:24:55] <jmkasunich> its 5:24
[22:24:56] <jmkasunich> run!
[22:25:05] <SWPadnos> running - see you later maybe
[22:25:30] <jmkasunich> jepler: yeah, we shouldn't forget that
[22:25:52] <jmkasunich> but keep in mind - any particular I/O + phys combination will exist only because somebody has built hardware to match
[22:26:01] <jmkasunich> compiling a driver specifically for that hardware isn't unreasonable
[22:26:21] <jmkasunich> I should say, linking a driver at runtime for that hardware
[22:26:50] <jmkasunich> I don't anticipate joe user doing the linking, the guy who comes up with the board will do it
[22:27:03] <jmkasunich> but having the phys layer stuff already written will save him a lot of time
[22:27:25] <jmkasunich> and if we can define a way to customize the packer/unpacker without writing it from scratch that will save more time
[22:28:32] <jmkasunich> heh, somehow we got here from a simple PDM to analog to PWM circuit with 3 parts
[22:29:08] <jepler> yeah, somehow
[22:29:24] <jepler> I'm much better at circuits with 3 parts than this complicated stuff
[22:29:59] <jepler> but apparently the man problem with my circuit was that it needed more parts
[22:30:24] <jepler> main
[22:31:10] <jmkasunich> depends on what you want to do with it
[22:31:34] <jmkasunich> the conversation just suffered from a huge dose of creeping elegance
[22:31:46] <jmkasunich> if you are running a spindle, the circuit you have will work fine
[22:31:55] <jmkasunich> not sure how to handle reversal, or if you even care
[22:32:21] <jepler> not in this case
[22:32:29] <jmkasunich> 40KHz seems a little high, I'd go with just high enough that you can't hear it, to minimize switching losses in the power devices
[22:32:36] <jmkasunich> 16-20KHz
[22:32:48] <jepler> "numbers out of my ass" syndrome
[22:32:53] <jmkasunich> thats just a detail
[22:33:13] <jepler> hm, there really aren't any "transfer function" components yet
[22:33:21] <jmkasunich> ?
[22:33:26] <jmkasunich> like abs()
[22:33:36] <jepler> like gamma() or the inverse
[22:34:16] <jmkasunich> gamma(0) = 0, gamma(1) = 1, gamma(0.5) = something that depends on the gamma value, right?
[22:34:22] <jepler> right
[22:34:35] <jepler> say I know that my DAC doesn't have a linear response curve, I would use a transfer function component to correct for it
[22:34:36] <jmkasunich> what about gamme(-1) and gamma(32432.1235)?
[22:35:23] <jepler> btfoom
[22:35:30] <jepler> it was just a random thought going through my head
[22:35:31] <jmkasunich> I've wanted to make a lookup table component (with interpolation) but getting the table into kernel space has been the obstacle
[22:35:33] <jepler> of no important
[22:35:33] <jepler> ce
[22:35:35] <jepler> importance
[22:35:37] <jmkasunich> a poly component wouldn't be to hard
[22:36:03] <jmkasunich> for gamma, you'd just have to decide what to do for out-of-limit inputs
[22:36:12] <jmkasunich> probably just clamp to 0-1 and be done with it
[22:36:34] <jmkasunich> for poly, you could specify the order at insmod time, and export params for the coefficients
[22:37:14] <jepler> sometimes I've found myself wishing for a callback when a param is modified
[22:37:21] <jepler> "recalculate this now"
[22:37:37] <jmkasunich> would the callback be invoked as part of the RT thread?
[22:37:50] <jepler> right now, it's kluged around now by doing a "is param == old param" in a slow thread
[22:37:56] <jmkasunich> yeah
[22:38:17] <jmkasunich> doing that, but hiding it, isn't out of the question
[22:38:41] <jepler> once we had a good way to make RT calls from userspace, yeah -- you'd arrange to call a function in kernel space in order to set the parameter
[22:38:56] <jmkasunich> thats not the same as being in the rt thread
[22:39:19] <jepler> then I'd like to revise my answer to: "no"
[22:39:21] <jmkasunich> right now, the recalcs (whatever they are) don't really have to worry about being thread safe
[22:39:40] <jmkasunich> the exception is things like stepgen, where there are fast and slow functs
[22:39:58] <jmkasunich> but for normal single function components, the recalc happens, and then you run the normal code
[22:40:10] <jmkasunich> the callback idea could be done tho
[22:40:29] <jmkasunich> add a ptr to the callback funct when you export the param
[22:40:51] <jmkasunich> then at the beginning of your main RT funct, call "hal_check_params()"
[22:41:27] <jmkasunich> that would loop thru all params exported by this component (or instance), for any that have callbacks, it would check new vs old and call the callback if there was a change
[22:42:02] <jmkasunich> the old value could be stored somewhere in the param metadata, instead of making the component writer allocate it and do the checks himself
[22:42:23] <jmkasunich> but the code would still run in the RT thread, before the rest of the RT function, so its still threadsafe
[22:42:33] <jmkasunich> am I making sense, or just rambling?
[22:42:38] <jepler> or maybe just a "changed bit" which is set by setp
[22:43:05] <jepler> but the other thing I'm having trouble with is this: if you can recalculate these things and still meet the realtime requirement, just go ahead and do it that way.
[22:43:23] <jepler> this if(condition) { do something expensive } in a "RT thread" seems funky to me
[22:43:42] <jmkasunich> conditional recalc actually makes the worst case a tiny bit worse, which is less than ideal for realtime
[22:44:11] <jmkasunich> but it can dramatically reduce the average, which helps the CPU load, lets the GUI be a little more responsive, etc
[22:44:45] <jepler> hm, that makes sense
[22:45:04] <jmkasunich> if the something is _really_ expensive, it sure would be nicer to do it outside the RT thread completely
[22:45:13] <jmkasunich> as long as you can do that in a way that is thread save
[22:45:28] <jmkasunich> if you have to recalc 10 things, and are half way done when the RT code runs, ouch
[22:45:37] <jepler> yep
[22:45:52] <jmkasunich> but if its just a long complicated recalc of a single item that can be written atomically when done, that would be the best way
[22:46:57] <jmkasunich> I guess the current arrangement leaves it up to the programmer instead of providing an infrastructure
[22:47:36] <jmkasunich> results in more boilerplate code
[22:47:55] <jepler> maybe in the 2.2 cycle it will bubble to the top and a good answer will present itself
[22:48:09] <jmkasunich> I like the "changed bit" idea, but I don't know how the component would access that bit
[22:48:50] <jepler> and having one bit per component isn't what you want -- you don't want to recalculate something for all the freqgens when it changed on one
[22:48:55] <jepler> but maybe it doesn't matter that much
[22:48:57] <jmkasunich> in 2.2 I really do want to revisit all the things that I used to lump under "hal restructure"
[22:49:25] <jmkasunich> one bit per instance would be much better than one per comp
[22:49:35] <jmkasunich> I thought you were talking one per param
[22:50:15] <jmkasunich> actually, N per instance (at the coder's discretion) isn't that hard to do
[22:50:46] <jepler> "when param p is changed also set this bit"
[22:50:53] <jmkasunich> param_new(name, type, address, int *modified_flag_addr)
[22:50:55] <jmkasunich> right
[22:51:07] <jepler> man I didn't mean to stick around at the office so late
[22:51:12] <jepler> but if I'm not working it hardly matters
[22:51:17] <jmkasunich> ;-)
[22:53:56] <jmkasunich> if somebody needs to do a really expensive recalc, they _could_ do it in another thread, then set a flag saying "there are new values in a buffer <here>"
[22:54:15] <jmkasunich> the the RT thread says "if (<here> != NULL ) { copy the new values }
[22:54:21] <jmkasunich> run the rest of the function
[22:54:29] <jmkasunich> s/RT thread/RT function/
[22:54:55] <jmkasunich> and "another thread" can also be "user space" in that case
[22:56:06] <jepler> so to change the subject back to this physical-layer serial protocol -- how do you design the serial protocol so that it can reliably detect the start of a packet?
[22:56:17] <jmkasunich> uhhhhh
[22:56:51] <jmkasunich> traditionally, some start of packet reserved code
[22:57:15] <jmkasunich> with some form of insertion or translation if there is a risk of that code appearing in the data
[22:57:24] <jmkasunich> but that means the length of the message can be variable
[22:57:40] <jmkasunich> worst case is a message consisting of 10 copies of the start byte
[22:57:49] <jmkasunich> it could wind up 20 bytes long
[22:58:07] <jmkasunich> that way lies madness
[22:58:20] <jepler> yeah -- I think the fixed-length packet has a lot going for it
[22:58:30] <jmkasunich> there are also start and stop bits, but that is at the byte level
[22:58:48] <jepler> one scheme I considered would be that the high bit would be set only in the first byte and be zero in the rest. but then you throw away 1/8 of your available bits.
[22:58:49] <jmkasunich> interpacket pauses?
[22:59:23] <jmkasunich> it would be interesting to look at the modes available from the PC partport/UART
[22:59:49] <jmkasunich> traditional rs-232 has start and stop bits for every byte, so you are already sending 10 bits for every 8 of data
[22:59:55] <jepler> this is the basic 8250:
http://davidwallace2000.home.comcast.net/h8/8250.htm
[23:00:13] <jepler> it can't do anything with less overhead than 8N1
[23:00:57] <jmkasunich> hmm
[23:01:10] <jmkasunich> you can force the parity bit to be true or false
[23:01:14] <jepler> there is BREAK I guess
[23:01:23] <jmkasunich> so you could make the overhead 1 of 9 instead of 1 of 8
[23:02:54] <jmkasunich> looks hard to send break with a fifo
[23:03:01] <jepler> hm, who knows when that parity bit is read from the reigster when transmitting
[23:03:05] <jmkasunich> you have to sit there and watch stuff go out, then turn it off
[23:03:12] <jmkasunich> how about this off-the-wall idea
[23:03:30] <jmkasunich> send the first or maybe last with intentionally wrong parity (force it)
[23:03:43] <jmkasunich> never mind
[23:03:55] <jmkasunich> that assumes the rest also have parity which wastes a bit
[23:04:40] <jepler> using the "7th bit" idea that's still 112 bits in a 16-byte fifo before error detection
[23:05:04] <jepler> but that's going to be even worse to manipulate on the uC end -- AVRs don't have a barrel shifter, for instance
[23:05:19] <jepler> hi skunkworks
[23:05:28] <jmkasunich> do AVR uarts handle parity?
[23:05:41] <skunkworks> Hi
[23:05:45] <jmkasunich> hi skunkworks
[23:05:49] <skunkworks> Hi
[23:06:24] <jmkasunich> jepler: duh - we are forgetting the control lines
[23:06:50] <jmkasunich> an extra channel of isolation in the ADUM probably costs about $1
[23:07:10] <jmkasunich> so use one of the control lines as a "packet start"
[23:07:24] <jepler> now you have to turn it off at the right time too
[23:07:54] <jmkasunich> if your uC can interrupt on an edge of that line, it doesn't have to be on long
[23:08:07] <jepler> and will it work for the input direction?
[23:08:15] <jmkasunich> turn it on, queue up the packet in the fifo, and turn it off
[23:08:17] <jepler> at the start of your RT function you have a full 16-byte fifo...
[23:08:27] <jmkasunich> I'm thinking that the system is master/slave
[23:08:48] <jmkasunich> the uC will start sending its reply when it sees the first byte of the outgoing message
[23:08:51] <jmkasunich> or maybe the last
[23:09:01] <jepler> OK, that sounds good, but not for PC-to-PC
[23:09:04] <jmkasunich> either way, it doesn't need separate sync I don't think
[23:09:33] <jmkasunich> well, for PC to PC its gonna be interesting anyway
[23:09:42] <jmkasunich> because the RT threads will _not_ be synced
[23:09:53] <jmkasunich> one might be 1mS, and the other 1.00001mS
[23:10:04] <jepler> true too
[23:10:18] <jmkasunich> I was strictly thinking in terms of communication to/from periphials
[23:10:26] <jmkasunich> I can't spell that darn word
[23:11:33] <jepler> so .. control line to start transmission, 14 bytes + 2 bytes CRC-16 in each direction, 230kbps, max frame rate about 800uS
[23:11:55] <jepler> you can use parity too and still get in at under 800uS for transmission
[23:12:04] <jepler> so you get parity bits + CRC for error detection
[23:12:11] <jmkasunich> if we have CRC, parity is just a waste if bits isn't it?
[23:12:36] <jepler> there are enough bit times in 1ms though
[23:12:49] <jmkasunich> well, that brings up another messy topic
[23:13:02] <jepler> I don't know enough about error detection to guess whether CRC+parity is any better than CRC alone
[23:13:17] <jmkasunich> what if there is enough latency that we're still sending the last message (the one that was delayed by latency) when its time to send the next one
[23:13:31] <jmkasunich> some silent time in the 1mS period is pretty important I think
[23:14:04] <jmkasunich> if we could _count_ on the silent time, that could be the sync mechanism
[23:14:17] <jepler> 16 * 11 bits / (230 kilobit / second) = .765 millisecond
[23:14:27] <jmkasunich> basically have a watchdog in the uC, reset it on each received byte interrupt
[23:14:53] <jmkasunich> when it times out (more than say 1.5 byte times), you know the frame has ended, so reset for the next one
[23:16:15] <jmkasunich> actually, I'm liking the control line more and more
[23:16:23] <jepler> that sounds more likely to work
[23:16:28] <jmkasunich> you're actually gonna have two functions: get packet and send packet
[23:16:35] <jepler> every uC has an external edge-triggered pin
[23:16:43] <jmkasunich> get packet will run early in the thread, and send will be at the end
[23:16:44] <jepler> you mean two HAL functions?
[23:16:49] <jmkasunich> yes
[23:17:04] <jmkasunich> just like we separate "read_encoders" and "write_dacs" for a servo card
[23:17:39] <jmkasunich> so, get_packet reads the packet that already arrived from the rx fifo, then sets the control line high to tell the uc "time to send another packet"
[23:18:00] <jmkasunich> then later, send packet writes a packet to the fifo, and sets the control line low to tell the uC "fresh packet on the way"
[23:18:37] <jmkasunich> time for me to go
[23:18:40] <jepler> see you
[23:18:41] <jepler> I need to go too
[23:55:33] <SWPadnos> regarding parity + CRC: I don't think it helps, except that in cases where the parity bit is wrong, the microcontroller can set a flag that the buffer is known to be bad (though the CRC should pick that up anyway, unless it was the parity bit that was wrong)
[23:57:25] <SWPadnos> regarding synchronization: for a microcontroller based peripheral that expects to receive a fized size packet, you basically use a rolling buffer of serial bytes, and compute CRC on the entire buffer each time a byte is received. When the CRC matches, it's highly likely that you have exactly one valid packet in the buffer (all zeroes being an exception)
[23:58:09] <SWPadnos> but you also make sure that the buffer is "full", and you reset the received bytes counter to 0 whenever you "use" a packet
[23:59:17] <SWPadnos> if you get noise, then you'll have a problem until the next complete packet arrives - that's a place where FEC codes help, since you can detect 2-bit errors and correct 1-bit errors in a byte, with the downside that a byte takes 14 bits to transmit (plus serial overhead)
