Back
[01:28:54] <archivist> the only new website thing i have bothered with is mobile friendly, making it responsive to the screen width
[01:53:54] <linuxcnc-build_> build #1127 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1127 blamelist: Moses McKnight <moses@texband.net>
[01:55:11] <seb_kuzminsky> that looks like a buildbot bug, not a problem with the new debian/configure stuff
[02:13:47] <tinkercave> tinkerer
[07:20:45] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/147831
[07:35:18] <skunkworks> https://github.com/machinekit/machinekit/issues/657
[07:44:15] <jthornton> seb_kuzminsky, did you get a chance to look at 2.7_Docs?
[08:25:34] <archivist> skunkworks, I spent a while staring at the code of the latency test, I think that has a similarity
[08:27:50] <mozmck> It ignores actual invocation time?
[08:32:40] <cradek> skunkworks: sounds like you have to be a programmer to use mach4
[08:32:53] <skunkworks> cradek, yes.
[08:33:21] <skunkworks> there have been a few references to it being 'just like linuxcnc' now..
[08:33:26] <cradek> haha
[08:33:46] <skunkworks> If you want to do anyting - you have to be a programmer and the developers don't listen to the users. ;)
[08:34:15] <cradek> to be fair, it's hard to balance configurability and sensible defaults (like having keyboard jogs)
[08:34:38] <archivist> they dont realise how distributed the "developers" are
[08:36:00] <skunkworks> sure. It sounds like they have tried to make it very flexable...
[08:36:40] <skunkworks> brian (owner?) is always saying after we get done with X we will work on your issue..
[08:36:45] <skunkworks> I don't think X is done yet
[08:37:16] <cradek> well he's one guy who decided to rewrite everything from scratch
[08:37:17] <KGB-linuxcnc> 03John Thornton 052.6 cda45fe 06linuxcnc 10docs/src/common/User_Concepts.txt fix broken image * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cda45fe
[08:37:35] <cradek> how can that even work?
[08:38:04] <archivist> it can, but, expensive and slow
[08:38:29] <cradek> meanwhile your product that actually works gets no maintenance
[08:38:37] <archivist> he came over here, sounds a sensible person
[08:39:07] <archivist> well when you bought some old crap, what choices :)
[08:39:54] <mozmck> Oh, there are more than one guy working on it.
[08:40:07] <mozmck> I don't know how many - but at least one more.
[08:40:40] <archivist> its the sort of job you need a large team for I would have thought
[08:40:54] <cradek> (sorry I said anything)
[08:40:56] <mozmck> seems like what machinekit is trying to do
[08:41:38] <skunkworks> if linuxcnc is the 'dark side..' what is machinekit?
[08:42:06] <skunkworks> (what mach users have called it)
[08:42:23] <cradek> still not windows, so also the 'dark side'
[08:43:09] <mozmck> probably so. I'm sure glad a lot of embedded development is done on linux now.
[08:43:19] <skunkworks> opaque side? ;)
[08:43:26] <pcw_home> measuring actual time and compensating for it is a nice idea but a pretty big job to make system wide
[08:43:54] <cradek> yes it's surely a good idea
[08:44:17] <cradek> it seems like pid could be helped by that somehow, maybe the tp, but I don't know that much else cares
[08:44:22] <mozmck> pcw_home: but I wonder how hard to just do more critical components?
[08:45:23] <pcw_home> like cradek said PID and say encoder and stepgen might not be too bad
[08:45:45] <cradek> several years ago mah suggested that someone figure out how to quantify the impact thread variance has on actual machine performance. that would still be a good idea
[08:45:59] <mozmck> do components get passed actual invocation time in linuxcnc? Looks like the extended thread API he mentions is machinekit specific.
[08:46:07] <cradek> starting with a full rewrite of hal that gets rid of pins and breaks every component everywhere, probably not a good first approach
[08:46:31] <mozmck> heh
[08:46:33] <skunkworks> now now..
[08:46:55] <mozmck> and ini files, and...
[08:47:00] <pcw_home> ( the DPLL now works with stepgen, quad encoders and absolute encoders so thats my workaround )
[08:47:36] <cradek> pid's ddt inputs are another useful workaround
[08:48:11] <cradek> I look forward to seeing what they come up with
[08:50:11] <pcw_home> Yeah, in my experience, the main problem is the position sampling jitter
[08:50:12] <pcw_home> causing a apparent position error that gets multiplied by the PID gain
[08:50:14] <archivist> I want to use test gear to measure errors
[09:00:58] <pcw_home> freeby.mesanet.com/nodpll.png
[09:00:59] <pcw_home> freeby.mesanet.com/dpll.ping
[09:02:01] <skunkworks> wow
[09:09:07] <pcw_home> whats left over after fixing the position sampling time:
[09:09:09] <pcw_home> freeby.mesanet.com/stepgen-residual-errors.png
[09:11:44] <JT-Shop> zlog
[09:20:46] <pcw_home> There are 2 noticeable residual errors: errors cause by jitter in the write
[09:20:48] <pcw_home> These cause errors only during acceleration and can be seen as broad peaks in the
[09:20:49] <pcw_home> error that match the jitter ( so mimic the DPLL phase error )
[09:20:51] <pcw_home> the other error is because FF2 is late and shows up as a sharp spike at the begin and end
[09:20:52] <pcw_home> of the velocity ramp:
[09:20:54] <pcw_home> freeby.mesanet.com/lateff2.png
[09:20:55] <pcw_home> whether the residual errors are worth fixing is debatable
[09:24:30] <archivist> I have wondered at the current stepper ramp, too, should that be closer to what steppers are best at
[09:24:57] <pcw_home> you mean limit accel at higher speeds?
[09:26:07] <archivist> the makers recommend a curve not a straight line acceleration iirc
[09:29:36] <pcw_home> sounds rather difficult to integrate with the already complex TP
[09:30:10] <cradek> yeah all levels would have to know about that
[09:33:27] <pcw_home> another thing with step motors might be to have a acceleration proportional "lead"
[09:33:41] <archivist> on a printer we just straight lined between n points on the curve depending in where it was at the time
[09:34:30] <cradek> if you're not coordinating with other motors, I bet you could do a lot of things more easily
[09:34:47] <pcw_home> for a raster its a lot easier :-)
[09:35:01] <mozmck> you would have to modify the TP for a non-constant accel, and then enter an accel range for each motor
[09:36:00] <pcw_home> another possibility for 3d printers/other things with 0 cutting force is to "lead" the position depending on accel
[09:36:20] <mozmck> "lead" the position?
[09:36:53] <pcw_home> base on the torque of the step motor at that particular speed
[09:36:58] <pcw_home> based
[09:37:13] <archivist> printers have offsets so stuff is inline so they lead
[09:37:38] <archivist> time of flight of the ink
[09:39:30] <pcw_home> yeah so at a 1/2 max torque accel the stepmotor is behind about 70% of a step (guessing)
[09:40:40] <pcw_home> ( 70% of a full step )
[09:41:25] <archivist> do a self test on an ink jet and there is a vertical bar pattern, and a selection for the best you enter
[09:42:28] <pcw_home> I remember those
[09:43:56] <pcw_home> dont think I have any inkjets left, way too much trouble/expense
[09:43:57] <archivist> being an evil person I used that counter on my anti copy in the code, the head would fly across ant hit the side, if a pin was not grounded :)
[09:46:29] <JT-Shop> dang laser printers are < $100
[09:47:36] <archivist> we were retailing at £800 for ink jets at the time
[09:47:39] <pcw_home> we ruin them fairly regularly with labels
[09:48:08] <mozmck> I've been pretty impressed with the brother laser printers we've used lately.
[09:48:19] <mozmck> cheap but seem to last well
[09:48:54] <pcw_home> last inkjet we got was free ( just an enticement to buy ink)
[09:49:47] <mozmck> yeah, and it's hardly even worth using up the ink that comes with it.
[09:50:51] <pcw_home> We use a brother laser printer for labels and its pretty good ( lasted better than the HP or Fujitsu before it )
[09:50:52] <archivist> ink jet ink is about the most expensive fluid on the planet if you pay retail prices
[09:53:42] <pcw_home> the ones we had were never used enough so they clogged up before all the expensive ink was used anyway
[10:04:41] <pcw_home> I guess you could also use "lead" to compensate for spring in the axis (especially for flimsy things like 3D printers)
[10:06:49] <pcw_home> ( just a first step to a dynamic model of the mechanics )
[10:09:17] <skunkworks> http://ibin.co/23BDKefM0Z9Z
[10:09:31] <skunkworks> ^2:12 minutes
[10:10:19] <skunkworks> ^logging linuxcnc running through the printer port.
[10:10:23] <skunkworks> http://ibin.co/23BDclOzXI5J
[10:10:40] <skunkworks> ^1:40 minutes
[10:10:53] <skunkworks> ^logging mach through the printer port
[10:11:31] <skunkworks> http://ibin.co/23BE2zQwvU7P
[10:11:50] <skunkworks> averaging accelleration over 60ms
[10:12:06] <skunkworks> 30in/s^2 and 500ipm
[10:13:10] <skunkworks> (running gcode file is set to 1000ipm)
[10:19:03] <skunkworks> cradek, a long time ago when I posted some of this on the mach yahoo group - I had showed them some gcode from the tort.ngc that caused really bad violations. They said 'well - no one would run gcode like that...'
[10:20:23] <skunkworks> I would test mach 4 but I don't think you can get a demo of it.
[10:21:11] <skunkworks> from what I have heard from a few resellers - it has the exact same trajectory planner.
[10:21:13] <archivist> heh I ran tort on my mill many years ago for a giggle
[10:22:15] <skunkworks> I want to try grbl in the arduino also.. it seems to have decent performance (somehting like 15 line lookahead)
[10:22:48] <skunkworks> ^I am ddt'ing in a slower thread. 60ms..)
[10:23:25] <skunkworks> otherwise accelleration looks like noise.. I want to do a running average but it needs some work for lower resoluions.
[10:24:02] <skunkworks> I believe it is working ok becasue linuxcnc seems pretty close to correct.
[10:26:11] <skunkworks> Plus you can see the slope of the velocity in halscope
[10:26:14] <mozmck> skunkworks:
http://www.machsupport.com/software/downloads-updates/#tabs-2
[10:26:22] <mozmck> mach4 has a demo download.
[10:26:31] <mozmck> I should try it sometime I guess
[10:26:46] <skunkworks> The Parallel Port plugin requires a license
[10:27:16] <mozmck> oh, maybe so - $25 I think?
[10:27:38] <skunkworks> probaby. I could probably swing that :)
[10:28:39] <skunkworks> I wonder if you can pay for the printer port plugin without the purchasing mach4?
[10:29:11] <mozmck> that I don't know! I don't see a place to get a printer port license either
[10:34:28] <cradek> so funny
[10:42:26] <skunkworks> Not looking at it too close - it seems to be the de-acceleration where mach violates the most. 'oh crap - I am going to fast to stop..'
[10:42:42] <skunkworks> maybe a feature by design..
[10:50:31] <archivist> the machine friction will help to stop....it hopes
[10:50:35] <pcw_home> You could get away with significant acceleration violations on step motor systems if they only occur at low speeds
[10:51:54] <pcw_home> ( since the accel limits need to be low enough to avoid stalls at rapids speed )
[10:55:51] <pcw_home> _but_ if you look at the mach velocity plot, the highest acceleration happens at the peak velocity
[11:00:53] <pcw_home> I get ~ 180 IPS/S at the beginning of the velocity drop
[11:00:54] <pcw_home> (using the patented lay a piece of paper on the screen technique)
[11:02:14] <skunkworks> heh
[11:03:04] <archivist> hey that violates my cardboard patent!
[11:03:32] <skunkworks> Halscope has DDT as you mouse over the trace - pretty cool.
[11:03:39] <pcw_home> _your_ cardboard patent?
[11:03:42] <skunkworks> (you have to sort of average what you see...)
[11:04:19] <pcw_home> yeah whats the slope of the sand pile if you look too close...
[11:04:50] <archivist> one lump, infinite
[11:43:41] <mozmck> I think the drought is over here:
http://www.weather.com/safety/floods/news/southern-plains-oklahoma-texas-flooding-photos
[11:48:15] <seb_kuzminsky> yikes
[11:49:21] <skunkworks> mozmck, how close was all that to you?
[11:52:21] <mozmck> seb_kuzminsky: have you seen jthornton's html doc changes?
[11:54:04] <seb_kuzminsky> i saw that he's been working on it, but i haven't looked at it in detail
[11:54:08] <seb_kuzminsky> have you?
[11:54:32] <mozmck> yes, and it would be really nice to get that in 2.7
[11:54:40] <mozmck> let me find a link...
[11:55:14] <seb_kuzminsky> i know the branch
[11:55:27] <seb_kuzminsky> i just havent made time to look closer at it yet...
[11:56:19] <mozmck> http://buildbot.linuxcnc.org/doc/scratch/v2.7.0~pre6~2.7-Docs~7158ed2/html/
[11:56:52] <mozmck> There's the result, and here is another one:
http://gnipsel.com/linuxcnc/html/navcol.html
[11:57:45] <mozmck> The idea is to put the TOC on the side persistently, plus the expanding catagories.
[11:59:07] <seb_kuzminsky> i see the expanding categories but not a persistent TOC
[11:59:15] <seb_kuzminsky> (on the buildbot)
[11:59:20] <mozmck> skunkworks: we are about 4 hours north of Austin, but we have had flooding here too. Nothing quite that bad, but they were rescuing people out of their cars on the highway about 8 miles away.
[11:59:51] <seb_kuzminsky> heh, "by version 2.1 everything should be updated",
http://buildbot.linuxcnc.org/doc/scratch/v2.7.0~pre6~2.7-Docs~7158ed2/html/hal/canonical-devices.html
[12:00:49] <mozmck> seb_kuzminsky: jthornton did a sample that is in the link on gnipsel, with the idea to do the rest that way if it is accepted.
[12:01:18] <mozmck> JT-Shop: jthornton: you there? He can tell you better than I.
[12:02:16] <seb_kuzminsky> one drawback that comes immediately to mind with the docs on gnipsel (linked above) is that you can't find a section of a document and easily get the url to it, for pasting into irc or an email
[12:02:48] <seb_kuzminsky> i often find myself navigating (bumblingly) to the docs that answer a user's question, then linking them to it
[12:03:08] <seb_kuzminsky> that's functionality that i dont want to lose
[12:04:01] <archivist> the current html is not that good either, pages are too long
[12:04:37] <archivist> so you have to go index, jump to the offset, then copy url
[12:11:39] <mozmck> hmm, that is true. But finding things and going back and forth in the documentation would be much easier I believe.
[12:12:26] <archivist> a long page is ok for doing a browser search in a section but then you cannot grab the link for the irc user easily
[12:12:58] <archivist> where a real search would come into its own
[12:13:14] <mozmck> you can put targets in a page and link to them - I wonder how hard that would be.
[12:13:25] <archivist> that is what is there now
[12:13:59] <archivist> the index at the top points at the targets
[12:14:30] <mozmck> oh, ok. so what is wrong with that?
[12:15:43] <archivist> the work to get a link to a section for someone else
[12:16:47] <mozmck> hmm
[12:17:35] <archivist> I have to load a 2mb page to then browser search it, then see which heading it had, go back to index jmp to it, only now can I copy the url
[12:18:19] <mozmck> oh, I see.
[12:20:17] <archivist> I just got the page size by running pagespeed test on
http://gnipsel.com/linuxcnc/html/getting-started/index.html
[12:22:32] <mozmck> heh, that's a large page. I wonder if there is a way to do a persistent TOC and have a box with the current page URL in it that can be copied?
[12:27:21] <seb_kuzminsky> the tricky bit is that you really want the anchor of the enclosing section when you send a link to someone
[12:52:39] <archivist> the pdf of the same doc has 73 pages, and uses 321mb in evince, sends this box into swap
[12:57:40] <seb_kuzminsky> html is probably more appropriate on that machine
[12:58:36] <archivist> well that page in firefox probably uses a similar amount of memory
[12:59:37] <seb_kuzminsky> lynx may be more appropriate on that machine ;-)
[13:01:05] <archivist> 2.5 g of memory
[13:01:52] <skunkworks> I parse the html emacs
[13:09:35] <archivist> I think the page sizes may be putting off some of the noobs, some are definitely not reading docs properly
[14:23:29] <skunkworks> fyi - I installed the linuxcnc wheezy iso - I think it had 2.6.3 on it. When I did a apt-get update/upgrade - linuxcnc was held back. I had to do a dist-upgrade
[14:23:50] <skunkworks> (if that made sense)
[14:23:56] <cradek> that's normal
[14:24:20] <cradek> because a missing dependency was added
[14:29:48] <skunkworks> ah - ok
[15:28:13] <jthornton> seb_kuzminsky, that's the reason I didn't do the persistent TOC on the 2.7_Docs branch because it did not work 100% yet. The documentation on 2.7_Docs is ready to merge, the docs on gnipsel are still not 100%
[15:28:55] <jthornton> I just got back from a road trip with the wild puppies gang so I'll look at the persistent TOC more tomorrow
[15:33:45] <Tom_itx> were they wild?
[15:36:20] <jthornton> not as wild as I thought they might be (the girls are the wild ones)
[15:36:42] <jthornton> lol they had fun and remembered it
[15:37:12] <Tom_itx> heh
[15:43:15] <seb_kuzminsky> jthornton: ok thanks, i'll check it out
[19:37:24] <Tom_itx> haha trying to import a project from ise 4 doesn't work so well
[19:38:12] <Tom_itx> trying to brush up a bit..
[19:40:14] <PCW_> ISE4 thats got to be pretty old, probably would need some intermediate versions
[19:40:43] <Tom_itx> yup, i'm just rebuilding the project file and importing the rest
[19:41:01] <Tom_itx> i'd hate to guess how old that was
[19:41:48] <Tom_itx> what will i need to jtag the FPGA when the dongle gets here?
[19:41:59] <Tom_itx> source or binary?
[19:42:23] <Tom_itx> i suppose source is proprietary on that
[19:44:00] <Tom_itx> had to install ise on the windows box since the dongle drivers failed to install on linux
[19:48:36] <PCW_> you use the Xilinx tool (Impact)
[19:48:45] <Tom_itx> right
[19:49:24] <PCW_> or fix the mesaflash source so it handles the 6I24 properly
[19:49:30] <PCW_> :-)
[19:49:31] <Tom_itx> will it accept a binary without a project file associated with it?
[19:49:45] <Tom_itx> the latter is above my paygrade
[19:50:52] <PCW_> well its awkward if you want to program the flash, in that case it needs a MCS file
[19:51:14] <Tom_itx> i'm guessing that's what i'm gonna have to do...
[19:51:34] <Tom_itx> nothing else so far seems to be responding right
[19:51:49] <PCW_> _but_ if you dont program the flash but instead just program the FPGA theres a much easier way to do it
[19:52:02] <Tom_itx> i saw your utility for that
[19:52:07] <Tom_itx> in one of the zip files
[19:52:10] <Tom_itx> dos utility?
[19:52:27] <PCW_> if you just program the FPGA, Impact will take bitfiles
[19:53:12] <Tom_itx> i assume i'm going to have to reprogram the FPGA at this point?
[19:53:44] <PCW_> so you program the FPGA with a (working) bitfile via JTAG then reboot the computer
[19:53:52] <Tom_itx> right
[19:54:06] <PCW_> Note I did not say power cycle
[19:54:31] <Tom_itx> yeah
[19:55:12] <PCW_> so the FPGA config stays and the BIOS enumerates he PCI on start up so its working (but still corrupt EEPROM)
[19:55:25] <Tom_itx> yup
[19:55:33] <PCW_> then you mesaflash in a working config
[19:55:43] <Tom_itx> that's kinda what i figured
[19:55:54] <Tom_itx> does the FPGA bitfile contain the fallback in it?
[19:56:03] <PCW_> (this is how we initialize 5I25 and Ethernet cards)
[19:56:24] <PCW_> no it doesnt have fallback or a boot sector
[19:56:41] <PCW_> you need to instal those with mesaflash
[19:57:43] <Tom_itx> i'm sure i'll need assistance when the time comes, just trying to get a feel for the steps
[19:58:02] <PCW_> the bitfiles we use have no fancy options (those are all in the boot sector)
[19:58:18] <Tom_itx> how does it get loaded?
[19:58:39] <PCW_> mesaflash always writes it if its not correct
[19:59:06] <Tom_itx> do i load the fallback bitfile differently than the regular pin file?
[19:59:45] <PCW_> yes there's a --fallback command line option
[20:00:02] <PCW_> (I think thats what its called)
[20:00:03] <Tom_itx> all i need jtag for is the initial FPGA bitfile right? then use mesaflash from there on
[20:00:10] <Tom_itx> i'll check for sure
[20:00:23] <PCW_> yes (or fix mesaflash)
[20:00:27] <Tom_itx> heh
[20:00:34] <Tom_itx> micges???
[20:01:02] <Tom_itx> i wanted to get a dongle anyway so i can mesa around with this board i've got here
[20:01:12] <Tom_itx> mess*
[20:01:24] <PCW_> if you are doing development its helpful
[20:01:40] <Tom_itx> more learning than developement at this point
[20:01:58] <PCW_> well makes recovery easier
[20:02:06] <Tom_itx> i know
[20:02:37] <Tom_itx> do you have the FPGA bitfile or is that something i'll have to generate?
[20:03:06] <PCW_> the 5i24 zipfile has many
[20:04:27] <Tom_itx> which one am i looking for?
[20:04:53] <Tom_itx> i see the 5i24_16_fallback.bit
[20:05:00] <PCW_> and its the only way to boot up a totally corrupted 5I25 or 5I24 or HM2 Ethernet card or 7I90
[20:05:51] <PCW_> a bad 6I24 I can fix here with smflash (and eventually mesaflash)
[20:06:29] <Tom_itx> it doesn't seem to be programming it on this pc, verify returns errors
[20:08:09] <PCW_> Maybe a BIOS thing (SMFlash depends on config space read/writes to the XIO2001 bridge via BIOS calls)
[20:09:46] <Tom_itx> the W10 jumper doesn't matter where it's set during all this right?
[20:17:52] <micges> Tom_itx: yes?
[20:18:18] <Tom_itx> would be a handy thing for the --recover to work on a couple more boards :)
[20:20:39] <micges> it shoud work same for 6i25 and 6i24, you need to disable fpga type
[20:20:46] <micges> checking
[20:24:05] <micges> Tom_itx: what's the status of your recover?
[20:25:18] <Tom_itx> i get board not found errors
[20:25:30] <Tom_itx> lemme load linux...
[20:32:22] <Tom_itx> ./mesaflash --device 6i25 --recover
[20:32:42] <Tom_itx> PCI device 6I25 (RECOVER) at 0000.01.00.0
[20:33:21] <micges> and when you trey to write flash?
[20:33:30] <Tom_itx> if i specify a --write xxx.bit i get a worng bitfile destination since it's for a 256 fpga instead of 144
[20:33:54] <Tom_itx> --recover --write 5i24.bit
[20:33:59] <Tom_itx> errors
[20:34:50] <Tom_itx> --device 5i24 --write 5i24.bit
[20:34:56] <Tom_itx> no 5I24 board found
[20:35:04] <micges> ok
[20:35:11] <micges> got newest mf source?
[20:35:17] <Tom_itx> not as of today
[20:35:22] <Tom_itx> maybe 3 days old
[20:35:26] <micges> ok
[20:35:41] <micges> goto eeprom.c
[20:36:08] <micges> comment out whole if at line 175
[20:36:11] <micges> make and try
[20:36:49] <Tom_itx> both if statements?
[20:37:22] <micges> yeah all from 175 to 181
[20:38:07] <Tom_itx> ok
[20:38:32] <micges> try --write
[20:38:51] <Tom_itx> should i power cycle first?
[20:39:00] <Tom_itx> still no 5i24 board found
[20:39:04] <micges> no no
[20:39:10] <micges> use only 6i25
[20:39:15] <Tom_itx> ok
[20:39:39] <micges> mf can't check if it's 6i25 or 6i24 in recovery mode
[20:39:42] <Tom_itx> no 6I25 board found
[20:40:16] <micges> try ./mesaflash --device 6i25 --recovery --write flash.bit
[20:40:43] <Tom_itx> erasing
[20:40:47] <Tom_itx> programming
[20:41:01] <Tom_itx> in area 16
[20:41:08] <micges> verify it
[20:41:13] <Tom_itx> from 0x100000
[20:41:26] <Tom_itx> no power cycle first?
[20:41:42] <micges> what firmware did you flashed?
[20:41:59] <Tom_itx> 5i24_16_justio
[20:42:22] <micges> ok, power cycle
[20:43:10] <Tom_itx> the leds are out this time
[20:43:52] <micges> ./mf --device 5i24 --readhmid
[20:44:28] <Tom_itx> returned nothing
[20:45:24] <Tom_itx> both leds are out now though
[20:45:40] <micges> maybe it's just plain io, not hostmot2 bitfilw
[20:46:11] <Tom_itx> not sure which one i need for hostmot2 bitfile
[20:46:19] <micges> now ./mesaflash --device 5i24 --verify 5i24_16_justio.bit
[20:47:18] <micges> then find 5i24 fallback in 5i24.zip and
[20:47:34] <Tom_itx> board configuration verified successfully
[20:47:47] <micges> ./mesaflash --device 5i24 --fallback --write fallback.bit
[20:48:52] <micges> and you can write now standard hostmot2 bitfile
[20:49:11] <micges> card will be fully reprogrammed
[20:49:16] <Tom_itx> erasing
[20:49:18] <Tom_itx> writing
[20:49:26] <Tom_itx> Board configuration updated successfully
[20:49:29] <Tom_itx> powercycle
[20:49:44] <Tom_itx> yay!
[20:50:12] <Tom_itx> right now it has no normal bitfile right?
[20:50:24] <micges> yep
[20:50:43] <micges> write hm2 bitfile, power cycle and see --readhmid ouptut
[20:51:45] <Tom_itx> just a standard bitfile?
[20:52:21] <micges> yes
[20:54:10] <Tom_itx> written.. powercycling
[20:55:19] <Tom_itx> lists the bitfile
[20:55:20] <Tom_itx> yay!
[20:55:30] <Tom_itx> thanks
[20:55:49] <micges> np
[20:55:59] <Tom_itx> are you gonna push those changes?
[20:56:49] <micges> checkings need to be diabled while recovering only
[20:57:12] <micges> I'll note to do it
[20:57:22] <Tom_itx> appreciate your help
[20:58:40] <micges> appreciate patience for program without manual ;)
[21:00:07] <Tom_itx> manual being written live
[21:01:12] <Tom_itx> i'll copy down the steps and put them somewhere
[21:02:09] <micges> sure, leave me link on github
[21:06:44] <Tom_itx> then you can correct any steps i missed
[21:07:17] <Tom_itx> i'll leave out the part about commenting the lines out in eeprom.c assuming you'll fix that?
[21:08:35] <micges> yes
[21:10:12] <Tom_itx> hold true for any pci pcie board?
[21:10:41] <Tom_itx> or just the 6i24 5i24?
[21:11:50] <PCW_> only 6I24 (7I24) and 6I25 can recover from blank/corrupted EEPROM
[21:11:59] <Tom_itx> ok
[21:12:26] <micges> note you must type 6i25 for all of them atm
[21:12:34] <Tom_itx> right
[21:12:42] <PCW_> 5I24 has 2 EEPROMS so you have to make a bad mistake twice to mess it up
[21:12:56] <Tom_itx> heh welcome to my world
[21:13:57] <PCW_> the 7I90 has a way to write protect one of the flash chips but I have not implemented it
[21:14:00] <micges> PCW_: same xio2001 bridge for all of above?
[21:14:07] <PCW_> yes
[21:14:38] <Tom_itx> fair to say: 5i24 6i24 7i24 & 6i25?
[21:17:48] <PCW_> yes
[21:18:03] <micges> Tom_itx: fetch latest mf sources, I've fixed it
[21:18:04] <Tom_itx> all those boards have the 2 leds?
[21:18:09] <Tom_itx> i will
[21:18:26] <PCW_> probably
[21:18:26] <Tom_itx> did you zip it?
[21:19:36] <micges> you will have latest fixes if you download zip from git
[21:19:42] <Tom_itx> ok
[21:20:23] <PCW_> sure glad I designed out the PLX bridge chips on the PCI/PCIE cards
[21:21:04] <micges> heh, not enough space for them
[21:21:50] <PCW_> PLXtech got bought out by Avago and the promptly doubled the bridge chip prices
[21:22:05] <PCW_> s/the/they/
[21:22:11] <Tom_itx> did i powercycle before the fallback bitfile?
[21:22:18] <Tom_itx> i don't think i did
[21:22:45] <PCW_> doesnt matter (and you dont need to power cycle anymore --reload will do that)
[21:22:52] <Tom_itx> yeah
[21:23:13] <micges> yeah most of latest bitfiles support --reload
[21:31:19] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/cnc/configs/recovery.txt
[21:31:22] <Tom_itx> look ok?
[21:34:14] <Tom_itx> micges,
http://tom-itx.no-ip.biz:81/~webpage/cnc/configs/recovery.txt
[21:34:20] <Tom_itx> steps look right?
[21:35:53] <micges> yeah, just latest verify makes more sense before --reload
[21:36:40] <micges> rest is ok
[21:37:20] <Tom_itx> refresh and see if that's ok
[21:37:42] <micges> yep
[21:38:05] <Tom_itx> i'll pretty it up with asciidoc or something and post it somewhere
[21:39:43] <micges> use github wiki at start
[21:40:04] <Tom_itx> the linuxcnc one?
[21:40:35] <micges> yeah
[21:40:43] <Tom_itx> ok
[21:54:23] <Tom_itx> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Recover_Corrupt/Blank_EEPROM_5i24%2C6i24%2C7i24%2C_6i25
[21:55:59] <micges> great
[21:56:03] <Tom_itx> question..
[21:56:17] <Tom_itx> on the first power cycle, what target would be used if you used --reload?
[21:56:27] <Tom_itx> 6i25 or yourboard
[21:56:43] <Tom_itx> line 6
[21:57:39] <micges> I don't think anything will work after --recover, just manually power cycle atm
[21:57:49] <Tom_itx> ok
[21:57:55] <Tom_itx> i'll leave it as is
[21:59:51] <micges> 'nite
[21:59:59] <Tom_itx> nite, thanks
[22:10:17] <Tom_itx> once again.. pretty hard to screw up a mesa board