Back
[10:06:02] <seb_kuzminsky> be
[10:06:12] <seb_kuzminsky> ...
[10:06:17] <cradek> I have that one down
[10:06:35] <seb_kuzminsky> i may need more coffee before i try to keyboard
[10:06:49] <cradek> still working on excel, flourish
[10:07:06] <seb_kuzminsky> i try to stay away from microsoft products
[10:08:27] <seb_kuzminsky> i'm looking at
https://sourceforge.net/p/emc/bugs/402/
[10:09:09] <seb_kuzminsky> probe_parport is still useful in some situations, right? it wakes up PnP parports on systems that dont use parport_pc
[10:09:48] <seb_kuzminsky> we no longer recommend blacklisting parport_pc, so it shouldnt be an issue on new installs, but old installs still need it
[10:09:58] <cradek> I don't know
[10:10:14] <cradek> do you mean old installs that blacklisted parport_pc?
[10:10:29] <seb_kuzminsky> yeah
[10:11:02] <cradek> so if you remove it in 2.7 and put an unblacklist instruction in UPDATING it's all good?
[10:11:16] <seb_kuzminsky> or other installs that dont load parport_pc for some reason, like Marius Liebenberg's machine
[10:12:02] <seb_kuzminsky> yeah that seems like a good way to go
[10:12:10] <pcw_home> so probe_parport was used to poke at parallel port hardware (for chipset specific setup) in cases that the driver needed to be blacklisted?
[10:12:26] <seb_kuzminsky> pcw_home: not quite
[10:12:28] <cradek> hm I missed that one. do you know what was unusual about his setup?
[10:12:45] <seb_kuzminsky> it poked the PnP controller to wake up a parport
[10:13:14] <seb_kuzminsky> normally parport_pc (the standard linux parport driver) would do that, but our hal_parport was incompatible with linux's parport_pc until... some time in the past
[10:13:30] <seb_kuzminsky> cradek:
https://sourceforge.net/p/emc/bugs/410/
[10:14:25] <seb_kuzminsky> see the lsmod.txt a couple of messages down
[10:14:38] <pcw_home> are there any PNP ports on post ISA MBs?
[10:14:42] <seb_kuzminsky> parport_pc is missing, he never got back to me with why
[10:15:31] <seb_kuzminsky> pcw_home: i think pnp is an extension to isa
[10:15:58] <seb_kuzminsky> so it only exists on motherboards towards the end of the isa era
[10:16:26] <seb_kuzminsky> so i feel a bit silly even thinking about how to support this...
[10:17:06] <seb_kuzminsky> i think cradek's right (as usual) and i should remove it in 2.7 and tell people to use parport_pc
[10:17:10] <seb_kuzminsky> and update all the configs
[10:17:14] <seb_kuzminsky> and stepconf
[10:21:22] <cradek> I can do the remove if you will do the tell people
[10:31:14] <seb_kuzminsky> cradek: yes please
[10:36:35] <seb_kuzminsky> it was commit 8b0268299f79 (in 2009) that made hal_parport not need probe_parport any more, it's in 2.4 and newer
[10:38:01] <seb_kuzminsky> parport_pc was un-blacklisted at about the same time (in 2.4)
[10:38:53] <cradek> huh where's kgb?
[10:39:02] <cradek> buildbot is chewing on cradek/remove-probe-parport now
[10:39:21] <seb_kuzminsky> thanks
[10:39:50] <pcw_home> must be in about every hal file
[10:39:54] <seb_kuzminsky> KGB-linuxcnc: welcome back!
[10:39:56] <cradek> KGB-linuxcnc: slacker
[10:40:02] <KGB-linuxcnc> seb_kuzminsky: My master told me to not respond.
[10:40:04] <KGB-linuxcnc> cradek: My master told me to not respond.
[10:40:20] <cradek> creepy
[10:40:24] <seb_kuzminsky> KGB-linuxcnc: but ironically you did
[10:40:24] <KGB-linuxcnc> seb_kuzminsky: My master told me to not respond.
[10:40:49] <cradek> KGB-linuxcnc: you have the right to remain silent, but you have to tell us that's what you're doing
[10:40:49] <KGB-linuxcnc> cradek: My master told me to not respond.
[10:41:04] <seb_kuzminsky> it's always weirded me out when software refers to itself
[10:41:37] <seb_kuzminsky> "Thou shalt not make a machine in the likeness of a man", one of the Dune commandments i can really get behind
[10:43:33] <seb_kuzminsky> cradek: that's the kind of conflicting instruction that melts down thinking machines
[10:44:27] <cradek> thank the roberts court
[10:44:55] <seb_kuzminsky> https://www.youtube.com/watch?v=q-k2y5NooyE
[10:48:58] <mozmck> huh, git gui tells me the linuxcnc repository has about 2048 loose objects and wants me to compress the database?
[10:49:01] <mozmck> what does that mean?
[10:49:25] <seb_kuzminsky> git stores objects in two ways: loose and packed
[10:49:44] <seb_kuzminsky> loose objects are quicker to write, but packed objects are quicker to read and more compact on disk
[10:50:02] <seb_kuzminsky> packing objects is also kind of a slow operation
[10:50:20] <seb_kuzminsky> so git writes objects loosely first, then every once in a while goes back and packs them all
[10:50:22] <mozmck> huh, so saying ok won't hurt anything then
[10:50:33] <seb_kuzminsky> no, it will make things better
[10:50:39] <mozmck> ok
[10:50:40] <seb_kuzminsky> it just will take a few seconds
[10:51:01] <mozmck> How can I view the differences between 2 branches?
[10:51:11] <seb_kuzminsky> git diff branch1..branch2
[10:51:36] <seb_kuzminsky> or gitk branch1..branch2 if you like pretty pictures
[10:52:00] <mozmck> oh, I see. I use for my own stuff, but don't often have to do something like that.
[10:52:33] <mozmck> Do you know when joints_axes6 was last rebased from master? will it have the new TP in it?
[10:53:00] <seb_kuzminsky> i think cradek rebased it at the texas hackfest, so yes it should have the new tp in it
[10:53:12] <cradek> yes it's post-new-tp
[10:53:49] <cradek> that one was hard - a new rebase would be easy if you want newer stuff
[10:53:59] <mozmck> ok. So what is the procedure to pull in the latest patches to the TP (or anything else)?
[10:54:09] <mozmck> oh, a new rebase?
[10:54:41] <cradek> yeah you could just rebase it again
[10:54:57] <cradek> it will probably not have any major conflicts (maybe none at all)
[10:56:05] <seb_kuzminsky> cradek: did you see the imerge "rebase with history" technique? it overcomes the "rebase loses history" problem that you pointed out
[10:56:06] <cradek> nope, it has some
[10:56:16] <cradek> brb
[10:56:26] <mozmck> ok, I may try that then.
[10:57:04] <mozmck> seb_kuzminsky: how often are changes to 2.6 and 2.7 merged into master?
[10:57:37] <seb_kuzminsky> mozmck: almost every time anything changes on any branch, they're merged up
[10:57:46] <mozmck> ok
[11:25:40] * cradek unconflicts all seventyeleven copies of shcom
[11:27:12] <mozmck> cradek: are you doing a new rebase?
[11:27:22] <cradek> yeah ... I thought it would be trivial
[11:27:43] <mozmck> heh! ok
[11:31:52] <mozmck> cradek: If I want to use the work you started on synchronized homing, how can I pull that over and merge it into a branch in a different repository?
[11:32:42] <cradek> you can add a remote with the git url the web page shows, git://timeguy.com/linuxcnc.git
[11:32:51] <cradek> then fetch the branch from that and merge it like normal
[11:33:20] <mozmck> ah, I see. I cloned your repo and was trying to figure out how to merge that way.
[11:38:47] <cradek> yeah that's not the best way
[11:39:15] <cradek> after a while you will build up a nice list of remotes, which is much better than a bunch of clones
[11:41:12] <mozmck> that makes sense.
[11:51:16] <cradek> yurrrgh halui
[11:56:48] <linuxcnc-build> build #2342 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2342 blamelist: Chris Radek <chris@timeguy.com>
[11:57:07] <linuxcnc-build> build #2338 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2338 blamelist: Chris Radek <chris@timeguy.com>
[11:57:46] <linuxcnc-build> build #2342 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2342 blamelist: Chris Radek <chris@timeguy.com>
[11:58:54] <cradek> figures
[11:59:17] <cradek> whoops
[11:59:43] <cradek> and I'm in the middle of my rebase so I can't fix it
[12:00:18] <cradek> it's too bad about how git is
[12:01:33] <linuxcnc-build> build #1177 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1177 blamelist: Chris Radek <chris@timeguy.com>
[12:08:02] <cradek> yurrrgh keystick
[12:08:06] <cradek> I think I'm gonna cry
[12:08:23] <cradek> every place we send any nml message has changed
[12:08:49] <skunkworks> imerge! ;)
[12:08:53] <cradek> and all these old guis have their own copies, which I think will be get deleted later in the rebase
[12:09:26] <mozmck> NML changed?
[12:09:44] <cradek> yeah the clashing serial number crap is all fixed now
[12:09:52] <cradek> so it's totally worth it, but still a pain
[12:10:14] <mozmck> oh, I didn't know about the clashing serial numbers.
[12:10:41] <cradek> yeah the bug reports were things like "my multiple gui setup sometimes stops responding for 30 seconds"
[12:17:25] <linuxcnc-build> build #2340 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2340 blamelist: Chris Radek <chris@timeguy.com>
[12:18:04] <linuxcnc-build> build #2337 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2337 blamelist: Chris Radek <chris@timeguy.com>
[12:22:33] <linuxcnc-build> build #401 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/401 blamelist: Chris Radek <chris@timeguy.com>
[12:22:37] <linuxcnc-build> build #908 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/908 blamelist: Chris Radek <chris@timeguy.com>
[12:23:40] <linuxcnc-build> build #907 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/907 blamelist: Chris Radek <chris@timeguy.com>
[12:24:33] <linuxcnc-build> build #362 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/362 blamelist: Chris Radek <chris@timeguy.com>
[12:26:57] <linuxcnc-build> build #610 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/610 blamelist: Chris Radek <chris@timeguy.com>
[13:44:21] <cradek> hahaha keystick has six copies of this, one for each jog key
[13:44:26] <cradek> that's just amazing to me
[13:55:43] <mozmck> copies of what?
[13:55:54] <mozmck> code that could have been it's own function?
[14:02:10] <cradek> yep it's horrible
[14:18:29] <skunkworks> andypugh,
http://bbs.homeshopmachinist.net/threads/65685-Washing-machine-motor-re-purposed-as-a-stepper
[14:21:06] <andypugh> I have tried to explain, but he won’t have it.
[14:21:43] <skunkworks> oh. darn
[14:21:58] <skunkworks> (as have I now...)
[14:22:08] <andypugh> You can even see the hall sensor board in his first photo
[14:48:08] <cradek> there is a separate case for each of the six jog keys and for incremental and continuous, so 12 copies
[14:54:01] <cradek> ahh xemc is slightly less bad, and then shcom is less bad than that
[14:54:07] <cradek> at least it improved over time
[14:55:29] <skunkworks> I resemble that rant
[14:56:10] <skunkworks> I think the name for the song is fitting
https://www.youtube.com/watch?v=IXrYOM0VSKI&feature=youtu.be
[15:00:29] <skunkworks> andypugh, how did you know where to put the hal sensors? is it just common that you align (center) them to the coils?
[15:00:54] <skunkworks> or did you have to then adjust the alignment in hal?
[15:01:24] <andypugh> They can be in a number of possible places, but the bldc component can handle all the sensible ones. Between three adjacent pole pieces is easy though.
[15:36:25] <KGB-linuxcnc> 03Chris Radek 05cradek/joints_axes7 5b703af 06linuxcnc New branch with 167 commits pushed, 10183 files changed, 038776(+), 045062(-) since master/04828fe
[15:38:13] <KGB-linuxcnc> 03Chris Radek 05cradek/remove-probe-parport 7cd12f1 06linuxcnc 10(18 files in 15 dirs) Remove probe_parport, which is unneeded since we now cooperate with parport_pc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7cd12f1
[15:38:20] <mozmck> cradek: wow! looks like that was a good bit of work.
[15:39:00] <cradek> mozmck: yeah I named it cradek/... because it was pretty extensive. if buildbot is happy I'd love it if you'd try it out.
[15:39:14] <cradek> if you have decent results I'll rename it joints_axes7
[15:39:23] <mozmck> I'll certainly plan to shortly.
[15:42:39] <mozmck> will the buildbot compile it automatically?
[15:43:05] <cradek> yes it's chewing on both my test branches
[15:43:10] <mozmck> ok
[15:43:36] <cradek> it's doing ja7 now
[15:44:41] <mozmck> Is it possible to do more frequent merges of master to ja*, and then rebase on master later just before merging ja* to master?
[15:45:04] <cradek> not really, you can't mix merge and rebase that way without causing pain
[15:45:13] <andypugh> what’s new in ja7?
[15:45:24] <cradek> the rebase is very easy, except when it isn't (like when someone changes all the nml-issuing sites)
[15:45:46] <mozmck> ok. at this rate we'll have ja97 and all the branches in between someday :)
[15:45:53] <cradek> andypugh: it's on top of the new master, so whatever's new in master
[15:46:22] <cradek> mozmck: for simple rebases I'd just reuse the old name, but whenever it's nasty I like to keep the old one around
[15:46:30] <mozmck> I see.
[15:46:30] <andypugh> JA has been waiting patienly in the wings since the very first time I logged in to the IRC
[15:46:50] <cradek> yep it's sure old
[15:47:01] <cradek> up to ja3 were cvs branches
[15:47:34] <mozmck> So will it be easier to get ja fixed or add world mode incremental jogging to master?
[15:47:43] <cradek> some of us have worked hard to flog it along, but none of us have worked hard enough to finish the last little things
[15:48:20] <cradek> mozmck: finishing and merging ja is the only reasonable one of your two alternatives
[15:48:42] <mozmck> Well, I have some incentive, we'll see how it works out.
[15:48:47] <cradek> yay that's wonderful
[15:48:54] <cradek> I'll help if/as I can
[15:49:05] <mozmck> I'm sure I'll need help :)
[15:49:20] <andypugh> In the parallel universe where I have infinite spare time I am working on conforming to joint dt and ddt limits in world mode.
[15:49:40] <andypugh> Sadly this is not that universe.
[15:49:42] <cradek> andypugh: that would be wonderful too
[15:50:15] <cradek> andypugh: in your other universe do you have an algorithm in mind?
[15:50:31] <andypugh> It looks not-too-hard as at the point where kins is called the old result is available.
[15:51:05] <andypugh> The last call to the kins and the next call are effectively a discrete derivative of the kins.
[15:51:13] <cradek> I don't think you can do it there, I think you have to do it when you plan the whole move initially
[15:51:32] <andypugh> So then you “just” need to bring in a feed adaption if any joint is nearing the limit...
[15:51:46] <cradek> imagine moving close to the center of a polar machine - during the move the situation gets worse and worse, and you have to go back in time and not get going so fast
[15:52:06] <cradek> I think you have to examine the whole move before you start it
[15:52:19] <andypugh> I would like to try it and see.
[15:52:59] <andypugh> There is definitely a problem, you can see it claerly in the 5-axis gantry sim.
[15:52:59] <mozmck> I still need a better overall picture of how linuxcnc works... It's probably out there if I keep digging.
[15:53:15] <cradek> my attempt would be to chop up the move into a reasonable number of chunks (probably iteratively and adjusting your recursive chopping if you detect singularities) and do experimental discrete derivs using a few extra kins invocations
[15:53:54] <cradek> and if you see violations, scale back the whole move proportionally
[15:55:19] <cradek> argh I need to retire so I have time for everything
[15:55:38] <andypugh> How would jogging fit into that scheme?
[15:56:02] <andypugh> (I am not sure how much like a move a jog looks)
[15:56:10] <cradek> hmm good question
[15:56:39] <cradek> I am not even sure how world mode jogging is implemented nowadays (in ja land)
[15:57:44] <cradek> if you find that you're going to violate constraints you could stop the jog
[15:57:52] <cradek> I think you might have to fall off the desired path a bit
[15:58:09] <cradek> I can't quite picture it
[15:58:40] <cradek> interestingly, joint jogs can violate world constraints too. I don't think we care though
[15:59:47] <cradek> emc1 used to do jogging by shooting a vector in the desired direction and planning a world mode move to the endpoint at the world volume's edge
[15:59:59] <andypugh> No, I can’t see why you would even have world constraints.
[16:00:03] <cradek> once you have move planning I think you can do the same thing for jogging
[16:01:01] <cradek> it would be funny/sad if we eventually have to revive emc1's approach
[16:01:09] <andypugh> It occurred to me that the kinematics of a laser galvanometer system are not even governed by relativity.
[16:01:36] <cradek> heh because the radius can be long?
[16:02:01] <andypugh> Yes, but the controlled-point is non-physical
[16:02:08] <cradek> yeah
[16:02:14] <cradek> interesting
[16:06:30] <andypugh> Hmm, why isn’t there a free 4-axis CAM package out there?
[16:07:31] <PCW> other phenomena travel faster than physical velocity (wave crashing on beach)
[16:07:35] <mozmck> Is there even a free 3D CAM package out there?
[16:07:54] <PCW> FreeCAD
[16:07:59] <mozmck> not CAM
[16:08:00] <andypugh> PyCAM
[16:08:07] <PCW> it has CAM
[16:08:27] <mozmck> oh? I saw talk of doing it, but didn't know it had it yet.
[16:08:40] <mozmck> I've heard of pyCAM, where is that?
[16:09:40] <mozmck> ah,
http://pycam.sourceforge.net/
[16:10:23] <andypugh> It’s quite nice, but some of the toolpath modes are unusably slow.
[16:12:52] <mozmck> great, there's another freeCAD:
http://www.ar-cad.com/freecad/index.html
[16:16:11] <mozmck> andypugh:
https://code.google.com/p/simplemultiaxiscam/
[16:17:27] <andypugh> Ooh! OSX too!
[16:18:52] <mozmck> oh groan, it's in java.
[16:50:17] <mozmck> zlog
[16:51:03] <mozmck> did the buildbot finish on ja7?
[16:51:11] <cradek> not quite yet
[16:51:19] <mozmck> ok
[16:51:19] <cradek> but it's generating docs, so I bet it's going to succeed
[16:51:29] <mozmck> oh good!
[16:54:18] <cradek> yep the first one finished
[16:54:44] <cradek> cradek/remove-probe-parport is starting
[16:54:59] <Tom_itx> ok, my update from 2.5 to 2.6 went smooth _and_ mesaflash worked without a hitch!
[16:55:08] <cradek> awesome
[16:55:10] <Tom_itx> just letting you guys know ... patting on back
[16:55:18] <Tom_itx> appreciate all your efforts
[16:56:40] <micges> Tom_itx: that's good
[16:57:13] <Tom_itx> once i get the wiring sorted for these new boards i'll make the move to 2.7
[16:59:59] <Tom_itx> mesaflash 3.1
[17:43:21] <seb_kuzminsky> Tom_itx: it's always nice when something works :-)
[17:44:14] <Tom_itx> i've still got a ways to go before i turn it loose but that part works
[18:20:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 87dfa68 06linuxcnc 10docs/src/getting-started/Updating_LinuxCNC.txt docs: don't load probe_parport any more * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87dfa68
[18:58:49] <andypugh> I am playing with Autodesk Inventor HSM Expres CAM. It has an EMC postprocessor. I wonder how we persuade them to change the name?
[19:02:00] <Tom_itx> explain the issue to them
[19:02:14] <Tom_itx> link the note about it
[19:02:21] <Tom_itx> i'm not sure where it is now...
[19:04:26] <skunkworks> robs latest branch solves the issues with non moving axis (vel/acc) effecting moving axis...
[19:28:52] <mozmck> skunkworks: has that been merged into master or is it something new?
[19:47:31] <skunkworks> there was some issues found that rob is fixing.. not in master yet
[19:53:41] <mozmck> ok
[20:40:15] <cradek> > Yes, there is a sensor board on that motor but that is just a convenient picture I found on line, I do not have a sensor
[20:40:42] <cradek> ha, wow was I scrolled back
[20:46:30] <KGB-linuxcnc> 03Chris Radek 052.7 18a933a 06linuxcnc 10(18 files in 15 dirs) Remove probe_parport, which is unneeded since we now cooperate with parport_pc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=18a933a
[20:46:40] <KGB-linuxcnc> 05cradek/remove-probe-parport 7cd12f1 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7cd12f1
[20:52:36] <seb_kuzminsky> aww yea
[21:20:41] <cradek> ha, thinking back to the old cvs irc bot who gave one announcement for every directory you touched
[21:30:48] <pcw_home> Nice that that didn't...
[21:32:03] <Tom_itx> PCW, do you think i should add loading the config with mesaflash to the bitfile tutorial for the newer boards?
[21:32:12] <Tom_itx> or leave it as a separate utility
[21:34:17] <pcw_home> You might just mention the mesaflash is the tool for loading flash based FPGA cards
[21:35:19] <pcw_home> (or programming non flash ones as well or reading IDROM contents etc etc, its kind of a swiss Army Knife)
[21:35:43] <Tom_itx> can i read content on older cards with it as well?
[21:35:50] <Tom_itx> i never used it until now...
[21:36:03] <pcw_home> Yes
[21:37:08] <pcw_home> the latest can print out sserial remote data bases as well
[21:37:21] <Tom_itx> 3.1?
[21:37:24] <Tom_itx> nice
[21:37:31] <Tom_itx> i'll be trying that out soon
[21:37:54] <Tom_itx> just by addressing the primary card?
[21:38:09] <pcw_home> I think 3.2 is needed for that (also eventually should be able to make .xml files)
[21:38:28] <Tom_itx> is 3.2 available now?
[21:38:37] <pcw_home> I dont know if it support multiple cards
[21:38:39] <Tom_itx> i just downloaded 3.1 not that long ago
[21:39:04] <pcw_home> No its not released, these are just rumors....
[21:43:45] <pcw_home> What nice is the mesaflash works on the PCI (both Flash and older non flash), EPP, Ethernet, and maybe even serial FPGA cards
[21:43:52] <pcw_home> is that
[21:44:27] <Tom_itx> things just keep getting better...
[21:45:38] <pcw_home> just initialized 50 7I92s with mesaflash today
[21:46:42] <Tom_itx> default configs?
[21:47:29] <pcw_home> you can program flash with JTAG but its terribly slow so I program the FPGA with JTAG, then run mesaflash
[21:47:30] <pcw_home> to install the fallback and default config (7I92 is ethernet)
[21:47:58] <Tom_itx> nice, is it about ready to hit the store?
[21:48:10] <pcw_home> tommorow
[21:48:27] <Tom_itx> i bet skunkworks wants to own #1
[21:48:54] <pcw_home> He already has a Ethernet FPGA card from us
[21:49:12] <skunkworks> heh - what is the 7i92?
[21:49:44] <mozmck> a baby 7i80 ;)
[21:49:48] <pcw_home> low cost limited I/O Ethernet FPGA card (basically a Ethernet 5I25)
[21:50:08] <pcw_home> same price as 5I25
[21:51:40] <mozmck> could they have two IDC headers instead of one IDC and one DB25?
[21:53:20] <pcw_home> Yeah thats planned (already have a male DB25 connector version)
[21:53:36] <mozmck> ok, good!
[21:53:56] <mozmck> might order some tomorrow.
[21:54:05] <cradek> ooh!
[22:02:06] <mozmck> hmm, building needs tclx in joints_axes7?
[22:04:12] <skunkworks> yes
[22:04:21] <skunkworks> 2.6 on I think..
[22:04:56] <mozmck> I was building 2.7 without it...
[22:05:10] <skunkworks> it was added about a month ago..
[22:05:32] <mozmck> hmm, I know I've built since then
[22:20:46] <Tom_itx> wiki updated
[22:22:12] <skunkworks> well - you can never have too many fpga's