whitequark | hmm, seems like my Z missing steps problem was solved by limiting velocity to 1025mm/s | 00:13 |
---|---|---|
whitequark | from 1500mm/s | 00:13 |
whitequark | also I'm inclined to believe the .05mm repeat positioning accuracy, because if it didn't actually provide that, my holes wouldn't hold nuts | 00:14 |
whitequark | and they do | 00:14 |
whitequark | Aperture Science Object Attachment System, final version: http://i.imgur.com/W9zbvZ1.jpg | 00:53 |
whitequark | I broke five endmills doing that :/ | 00:53 |
whitequark | seems like there's something weird going on with Z axis and/or the table is not parallel to XY plane | 00:54 |
whitequark | so I experimented a bit with copper plating bath and graphite | 03:57 |
whitequark | result: copper is EVERYWHERE except where I want it to be | 03:57 |
whitequark | http://i.imgur.com/uNE8jBl.jpg | 04:01 |
whitequark | that is the *reverse* side of one-sided PCB | 04:02 |
whitequark | I actually tried to scratch off the copper and it is not easy | 04:02 |
whitequark | not significantly easier than with factory-made copper | 04:02 |
whitequark | the layer is about... 40 micron | 04:03 |
whitequark | but that's likely wrong figure affected by my ability to measure it | 04:04 |
whitequark | nah, comes right off if I try to tin it: http://i.imgur.com/wgBMNZy.jpg | 04:11 |
whitequark | which is... well, predictable | 04:12 |
whitequark | no reason for it to have good adhesion to surface, every reason not to | 04:12 |
DocScrutinizer05 | ((table is not parallel to XY plane)) quite possible | 11:38 |
DocScrutinizer05 | what I elaborated on yesterday(?) | 11:38 |
DocScrutinizer05 | ((15 mills)) ouch! | 11:38 |
DocScrutinizer05 | ((imgur)) LOL | 11:40 |
kristianpaul | wb | 14:04 |
wpwrak | welcome back, internet ! :) | 14:54 |
kristianpaul | lol | 15:27 |
zrafa | wpwrak: where is libubb living? if I try to build libswd I get a lot of | 18:59 |
zrafa | ben.c:(.text+0x4f8): undefined reference to `ubb_mem' | 18:59 |
zrafa | ben.c:(.text+0x524): undefined reference to `ubb_mem' | 18:59 |
zrafa | ben.c:(.text+0x550): undefined reference to `ubb_mem' | 18:59 |
zrafa | but I do not see ubb_mem defined in ubb.h or something like that | 18:59 |
wpwrak | the ben-blinkenlights project ;-) | 19:02 |
zrafa | well, I am tired right now, maybe that is the error :) | 19:02 |
wpwrak | undefined ubb_mem would suggest that you have the headers but not the library | 19:18 |
zrafa | wpwrak: the problem was that I modified Makefile and had a wrong CFLAG :P | 19:33 |
larsc | LDFLAG | 19:35 |
wpwrak | LDLIBS ? :) | 19:37 |
wpwrak | although a few years ago, you could still get away with putting libraries in LDFLAGS | 19:38 |
wpwrak | must have been gnu ld getting a bit stricter that ended that | 19:38 |
larsc | it now cares about the order of the libs or something | 19:48 |
wpwrak | yup. they probably removed a loop that should never have been there | 19:49 |
ysionneau | to get the same effect you can now use -Wl,--start-group and -Wl,--end-group or something like that | 19:50 |
ysionneau | (and put your lib list between those two) | 19:51 |
larsc | great, google's autocomplete suggests '-wl --start-group' when you type 'wl--start-g' | 19:52 |
larsc | of course it doesn't find anything because - infront of a searchterm means it shouldn't appear in the result | 19:52 |
larsc | 'Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.' | 19:53 |
ysionneau | well, for "small" projects with few libraries (which are not too big) you just don't care | 19:56 |
ysionneau | but when building Android ou Gecko ou whatever indeed you care :) | 19:56 |
ysionneau | you should not use that unless there is really a "circular dependency" | 19:56 |
ysionneau | using it by default is bad design | 19:56 |
wpwrak | having a circular dependency would probably constitute bad design on its own ;-) | 19:58 |
ysionneau | well, that depends, but usually it's not the case | 19:59 |
ysionneau | (I mean, usually you indeed don't have those) | 19:59 |
zrafa | larsc: wpwrak : the problem was a CFLAG because I commented out some var (# CC2543 = ../../ybox/fw/cc/) and then CFLAGS was no so nice with CFLAGS = -Wall -I$(LIBUBB)/include -I$(CC2543) | 21:27 |
zrafa | wpwrak: so It ran gcc $(CFLAGS) -c source file | 21:28 |
zrafa | dont know why then the error was showed by ld anyway (after that gcc of that source file it then runs gcc to build the binary with ld) | 21:29 |
wpwrak | hmm, what would you do with ybox/fw/cc ? that's firmware for a chip you don't have :) | 21:38 |
wpwrak | or does some other makefile invoke that ? | 21:40 |
Action: whitequark finally got to preparing the copper hypophosphite solution | 23:19 | |
zrafa | wpwrak: yes, libswd has usage of ybox/fw/cc and then I was removing cc stuff from Makefile | 23:31 |
zrafa | wpwrak: so some -I option of gcc was empty when running make | 23:32 |
wpwrak | yes, there's a header dependency. but you shouldn't need to build things over there, just have the files | 23:33 |
wpwrak | anelok/anelok and anelok/ybox currently have a highly incestuous relationship with includes and even vpaths going back and forth. so have your barf bag ready :) | 23:34 |
wpwrak | (if you get to building firmware, then ben-wpan/atusb/fw/ also becomes part of the family. but you don't need that) | 23:35 |
wpwrak | (at last not yet) | 23:35 |
whitequark | bleargh, ammonia stinks | 23:45 |
whitequark | like a thousand cats momentarily cried in terror and pissed all over the place | 23:45 |
whitequark | ooo, very interesting | 23:56 |
whitequark | http://we.easyelectronics.ru/HomeTech/metallorezist-rebyata.html#comment85692 | 23:56 |
whitequark | "persulphates etch on boundaries of copper crystals" | 23:59 |
--- Wed Mar 19 2014 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!