2016-02-19 00:02 late movement from Linux foundation for introducint zephy? 2016-02-19 02:57 xiangfu has joined #qi-hardware 2016-02-19 03:23 fengling has joined #qi-hardware 2016-02-19 03:39 xiangfu has quit [Ping timeout: 240 seconds] 2016-02-19 03:39 xiangfu has joined #qi-hardware 2016-02-19 04:08 DocScrutinizer05 has quit [Disconnected by services] 2016-02-19 04:08 DocScrutinizer05 has joined #qi-hardware 2016-02-19 04:30 fengling has quit [Quit: WeeChat 1.4] 2016-02-19 04:42 fengling has joined #qi-hardware 2016-02-19 05:01 fengling has quit [Quit: WeeChat 1.4] 2016-02-19 05:04 fengling has joined #qi-hardware 2016-02-19 05:15 dandon has quit [Ping timeout: 276 seconds] 2016-02-19 05:27 xiangfu has quit [Remote host closed the connection] 2016-02-19 05:31 xiangfu has joined #qi-hardware 2016-02-19 06:06 alexst has joined #qi-hardware 2016-02-19 06:11 alexst has quit [Ping timeout: 250 seconds] 2016-02-19 06:24 kyak_ is now known as kyak 2016-02-19 06:24 fengling has quit [Ping timeout: 240 seconds] 2016-02-19 06:33 fengling has joined #qi-hardware 2016-02-19 07:01 xiangfu has quit [Remote host closed the connection] 2016-02-19 07:02 xiangfu has joined #qi-hardware 2016-02-19 07:17 xiangfu has quit [Ping timeout: 244 seconds] 2016-02-19 07:18 xiangfu has joined #qi-hardware 2016-02-19 07:19 dandon has joined #qi-hardware 2016-02-19 07:48 xiangfu has quit [Ping timeout: 244 seconds] 2016-02-19 07:48 xiangfu has joined #qi-hardware 2016-02-19 08:04 FDCX has quit [Remote host closed the connection] 2016-02-19 08:33 sb0_ has joined #qi-hardware 2016-02-19 08:35 sb0 has quit [Ping timeout: 248 seconds] 2016-02-19 09:00 jow_lapt1p is now known as jow_laptop 2016-02-19 09:05 fengling has quit [Ping timeout: 240 seconds] 2016-02-19 09:10 fengling has joined #qi-hardware 2016-02-19 09:47 xiangfu has quit [Ping timeout: 255 seconds] 2016-02-19 09:47 xiangfu has joined #qi-hardware 2016-02-19 10:07 pcercuei has joined #qi-hardware 2016-02-19 10:23 pcercuei has quit [Quit: brb] 2016-02-19 10:33 fengling has quit [Quit: WeeChat 1.4] 2016-02-19 11:09 pcercuei has joined #qi-hardware 2016-02-19 11:35 sandeepkr__ has joined #qi-hardware 2016-02-19 11:50 FDCX has joined #qi-hardware 2016-02-19 12:05 alexst has joined #qi-hardware 2016-02-19 12:10 alexst has quit [Ping timeout: 250 seconds] 2016-02-19 12:53 pcercuei has quit [Quit: bbl] 2016-02-19 13:18 xiangfu has quit [Ping timeout: 240 seconds] 2016-02-19 13:42 jwhitmore has joined #qi-hardware 2016-02-19 14:03 btw I found a full-time developer for that SolveSpace CAD 2016-02-19 14:03 cc DocScrutinizer05 wpwrak 2016-02-19 14:03 in a year or so it should be quite competitive with freecad 2016-02-19 14:04 well, in terms of features, in terms of usability it's already lightyears ahead 2016-02-19 14:08 I'd also quite like to integrate the rotting remains of HeeksCNC into it 2016-02-19 14:52 pcercuei has joined #qi-hardware 2016-02-19 15:18 arossdotme-planb has quit [Remote host closed the connection] 2016-02-19 15:25 alexst has joined #qi-hardware 2016-02-19 15:31 alexst has quit [Ping timeout: 255 seconds] 2016-02-19 15:36 CAM integration would certainly be a plus 2016-02-19 15:38 have you taken a look at solvespace yet? 2016-02-19 15:38 if not you can build this: https://github.com/whitequark/solvespace 2016-02-19 15:39 branch for-upstream, dpkg-buildpackage works 2016-02-19 15:39 or prebuilt debs: https://github.com/whitequark/solvespace/releases 2016-02-19 15:39 you may also want to look into slicing for path generation. if your model is basically 2.5D, this gives you very accurate results, and the algorithms aren't too bad: http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/sl2 2016-02-19 15:40 slicing is one CAM strategy, yes 2016-02-19 15:40 heekscnc is basically slicing (waterline) + hsm generation within each layer 2016-02-19 15:42 haven't looked much at solvespace yet. the premise sounds promising, though 2016-02-19 15:44 sandeepkr__ has quit [Ping timeout: 255 seconds] 2016-02-19 15:54 can it extrude along an arbitrary path ? i.e., if you wanted to make some sort of bucket, with a chamfered edge between bottom and walls, could you just define the cross-section (which may look a bit like http://solvespace.com/pics/tut-section-done.png), then move it along a path to make the bucket ? 2016-02-19 15:55 or would you need to break this down into straight line segments and do something else for (rounded) corners ? 2016-02-19 16:06 unfortunately not, the only 2d-to-3d operations it has is extrude along a line and rotate around axis 2016-02-19 16:06 well, in case of a round bucket specifically it's not a problem 2016-02-19 16:07 but if you want an elliptic bucket with chamfered edges... basically you're out of luck 2016-02-19 16:07 yeah, i was thinking of a more artistic bucket :) 2016-02-19 16:07 this is a rather known problem. the current plan is to plagiarize opencascade 2016-02-19 16:08 i.e. not drag in the whole thing with its horrible dependencies, but just take the relevant NURBS operations out of it and reimplement 2016-02-19 16:08 this should be doable in a reasonable amount of time *and* we get the only other FOSS NURBS operations library 2016-02-19 16:09 and, well, we don't get opencascade as a dependency, too 2016-02-19 16:11 other things i'd like to get sorted out is proper dxf export (with splines, annotations and such), *any* import (dxf at first), and editing more than one sketch at once, with propagation across inclusions 2016-02-19 16:12 the former is going to land any day now 2016-02-19 16:12 the last one requires massive, multi-month refactoring 2016-02-19 16:12 but as a side effect you'll be able to drive the geometric kernel from python, headless 2016-02-19 16:13 what would be so bad about having opencascase as dependency ? do they break the APIs often ? 2016-02-19 16:13 and also get parameterized sketches, eg Mn screw with variable N 2016-02-19 16:14 opencascade is an extremely large C++ codebase that is given away because the holding company is charging for consulting 2016-02-19 16:14 so they have no incentive to make it usable 2016-02-19 16:14 so it would be dragging in a million or so LOC of shit for a feature that's at most a few thousand LOC 2016-02-19 16:15 and then translating everything back and forth 2016-02-19 16:15 the problem is NURBS booleans. they have an annoyingly large set of edge cases and basically no library takes it onto itself to handle them all 2016-02-19 16:17 in principle it's possible to do everything using just meshes, but you don't get exact fits, and worse, you cannot infer features to constrain against from geometry itsefl 2016-02-19 16:17 since you don't get the algebraic representation of them 2016-02-19 16:18 that said, actually not all results of NURBS booleans can be represented exactly either 2016-02-19 16:19 wpwrak: anyway, i'd be quite interested in your feedback. you could use SS for something minor anelok-related 2016-02-19 16:20 ditto for DocScrutinizer05 2016-02-19 16:20 wpwrak: I was also thinking about PCB import. not sure about formats though, never used them so far 2016-02-19 16:28 what wuold be useful are just basic parameter input/output operations. so that one can write one's own wrappers. e.g., to import component positions from a pcb. or vice versa. 2016-02-19 16:35 yes, a SWIG interface exposed to Python or Lua is another priority 2016-02-19 16:37 whatever swig is :) i was more thinking of just gnuplot-style input/output data sets :) 2016-02-19 16:38 well, solvespace is in a C++, and SWIG is a binding generator 2016-02-19 16:38 s/a// 2016-02-19 16:38 whitequark meant: "well, solvespce is in C++, nd SWIG is binding genertor" 2016-02-19 16:38 qi-bot: stupid bot 2016-02-19 16:39 wpwrak: with the current file format you can do it yourself. 2016-02-19 16:39 try looking at it with `less` 2016-02-19 16:41 I'm going to migrate it to a binary format, since the current one is monstrously inefficient even on tiny models 2016-02-19 16:41 though the current one will remain readable forever anyway 2016-02-19 16:58 mmh, but aren't things calculated from parametric input ? you'd want the calculation results (for further processing), not the parameters from the source 2016-02-19 17:00 the format is a bit chatty (*) but doesn't look too inefficient 2016-02-19 17:01 (*) e.g., you could just remove "Entity" and such and use a global parameter space. then AddEntity et al. would read that global space and clear it. voila, saves a bunch of redundancy 2016-02-19 17:01 (and it's still line-by-line processor friendly :) 2016-02-19 17:03 entities and mesh are only written from imports 2016-02-19 17:03 you only actually need params, requests and constaints 2016-02-19 17:03 constraints* 2016-02-19 17:04 however, imported sketches aren't resolved, so the complete result is written. 2016-02-19 17:04 only written FOR imports. 2016-02-19 17:04 that said the format is actually a direct serialization of the internal data structures 2016-02-19 17:06 mmh, so you're saying that it contains the parametrized model and the results of processing it ? 2016-02-19 17:06 exactly. 2016-02-19 17:06 Entity.actPoint is the numeric result 2016-02-19 17:09 that said I'm pretty sure a proper Python/Lua interface and a way to run it in batch mode is what you *actually* want 2016-02-19 17:09 instead of a heap of ad-hoc hacks over an undocumented file format exposing internals 2016-02-19 17:10 I know, not user-hostile enough to be unix-way... 2016-02-19 17:10 sandeepkr__ has joined #qi-hardware 2016-02-19 17:25 pcercuei has quit [Quit: bbl] 2016-02-19 17:46 Ornoterm1s has quit [Ping timeout: 240 seconds] 2016-02-19 17:58 Ornotermes has joined #qi-hardware 2016-02-19 18:11 pcercuei has joined #qi-hardware 2016-02-19 18:12 pcercuei has quit [Client Quit] 2016-02-19 18:20 kristianpaul has quit [Quit: Reconnecting] 2016-02-19 18:21 kristianpaul has joined #qi-hardware 2016-02-19 18:21 kristianpaul has joined #qi-hardware 2016-02-19 18:22 pcercuei has joined #qi-hardware 2016-02-19 18:25 tumdedum has quit [*.net *.split] 2016-02-19 18:26 tumdedum has joined #qi-hardware 2016-02-19 18:27 archang has quit [*.net *.split] 2016-02-19 18:27 kanzure has quit [*.net *.split] 2016-02-19 18:27 kanzure has joined #qi-hardware 2016-02-19 18:28 archang has joined #qi-hardware 2016-02-19 18:45 jwhitmore has quit [Ping timeout: 276 seconds] 2016-02-19 18:50 rjeffries has quit [Read error: Connection reset by peer] 2016-02-19 19:05 kanzure has quit [Changing host] 2016-02-19 19:05 kanzure has joined #qi-hardware 2016-02-19 19:06 rjeffries has joined #qi-hardware 2016-02-19 19:31 alexst has joined #qi-hardware 2016-02-19 20:10 rjeffries has quit [Remote host closed the connection] 2016-02-19 20:11 rjeffries has joined #qi-hardware 2016-02-19 20:17 sandeepkr__ has quit [Ping timeout: 276 seconds] 2016-02-19 20:21 alexst has quit [Ping timeout: 252 seconds] 2016-02-19 20:25 alexst has joined #qi-hardware 2016-02-19 20:44 alexst has quit [Ping timeout: 240 seconds] 2016-02-19 21:02 whitequark: congrats and thanks for the fine news. I guess Neo900 could use it for stacking a PCB sandwich with only a 2.5mm headroom between PCB surfaces so height_a + height_b of components < 2.5mm, quite a requirement for layout resp component placing prior to layout 2016-02-19 21:05 pcercuei has quit [Quit: leaving] 2016-02-19 21:05 DocScrutinizer05: hmmm that needs IDFv3 import, right? 2016-02-19 21:05 whitequark: xslt etc comes to mind as alternative to lua/python binding, but of course a binding is waaay more powerful, particularly when it not only allows .get but also call of arbitrary object methods 2016-02-19 21:06 yes, it will allow arbitrary sketch modification 2016-02-19 21:06 and it's actually less work than xslt 2016-02-19 21:06 (IDFv3) I haven't even looked into it, not even pondered any details how to handle it at all 2016-02-19 21:07 kicad exports placement data into IDFv3 2016-02-19 21:07 yeah, prolly that's a first take on it 2016-02-19 21:08 I wouldn't even dare to think about interactive integration yet 2016-02-19 21:08 I'm currently evaluating that actually 2016-02-19 21:08 particularly as long as Neo900 is Eagle based 2016-02-19 21:08 ahhh right 2016-02-19 21:08 yeah eagle has idf export too but interactive is a nonstarter 2016-02-19 21:09 I seem to reecall sth about IDF export in eagle as well 2016-02-19 21:09 it uses an ULP plugin 2016-02-19 21:09 yep, exactly 2016-02-19 21:09 actually not *impossible* to do import but incredibly fragile and tedious 2016-02-19 21:09 yes 2016-02-19 21:10 ULP is rather powerful but icky 2016-02-19 21:10 particularly ULP doesn't allow any modification calls to objects 2016-02-19 21:10 ULP is actually one of the least bad homegrown EDA languages I've seen 2016-02-19 21:10 yes 2016-02-19 21:10 you're supposed to generate an SCR 2016-02-19 21:11 it's understandable, they don't want to duplicate all the consistency checking code for ULP too 2016-02-19 21:11 you do idiotic things like producing a script of macros that gets called after ULP quits 2016-02-19 21:11 since they already have it for the GUI and separately for SCR 2016-02-19 21:11 caught in their own bad design 2016-02-19 21:11 hehe, yes 2016-02-19 21:12 so, hm, I've read most of IDFv3 spec 2016-02-19 21:12 it's a good, sane format 2016-02-19 21:12 problem is it assumes an 1:1 correspondence between IDF file and ECAD/MCAD internal repro 2016-02-19 21:12 for bidirectional integration 2016-02-19 21:12 repetitve switch beween scr and ulp with mutual calls feels like worst 1978 coding hell 2016-02-19 21:13 I feel like I could do something like that after all 2016-02-19 21:13 it'd just be a fairly awkward mapping to a generic MCAD, parametric too 2016-02-19 21:13 and, well 2016-02-19 21:13 what do you even do with with things you can't store in IDF like constraints? 2016-02-19 21:14 right 2016-02-19 21:14 it's a complex problem, not easy to come up with a architecture for 2016-02-19 21:14 so like, just importing IDF in a representation you can constrain against is pretty easy 2016-02-19 21:15 possibly 2016-02-19 21:15 no, certainly, it has a straightforward mapping 2016-02-19 21:15 I already know how I'd do that 2016-02-19 21:15 generate a "zone file" overlay that devines allowable component height 2016-02-19 21:15 defines even 2016-02-19 21:15 are you talking ECAD->MCAD or MCAD->ECAD? 2016-02-19 21:16 the latter right now 2016-02-19 21:16 ah yeah 2016-02-19 21:16 so during layout and component pos I can check against such layer 2016-02-19 21:17 but stuff gets funny when I want to arrange stuff on the other surface to make space on this surface 2016-02-19 21:19 it's like the antique turtle race 2016-02-19 21:19 yeah 2016-02-19 21:20 so the IDF format is based around outlines 2016-02-19 21:21 it can specify a bunch of outlines, which are just loops defined by points+curvature 2016-02-19 21:21 not even bezier 2016-02-19 21:21 and every outline has some other properties like "component name" "board side" "locked by MCAD/ECAD" etc 2016-02-19 21:21 that's it 2016-02-19 21:21 that's the whole format 2016-02-19 21:21 yes 2016-02-19 21:21 shouls suffice 2016-02-19 21:22 component height particularly 2016-02-19 21:22 I can simply map those outlines to MCAD outlines 2016-02-19 21:22 and when there's a height you make an extrusion 2016-02-19 21:23 and all other operations except for drawing outlines on top/bottom and extrusion are disallowed 2016-02-19 21:23 then you calculate the free space headroom aka 2.5mm - component_height_a and inport that as restriction layer for survace_b in layout editor 2016-02-19 21:23 and vice versa whenever switchin to surface_a layout 2016-02-19 21:24 sorry, I can tell from my typos that I'm still asleep 2016-02-19 21:26 ideally you could export two sets of component objects incl height, for surface a and b and arrange components *in* SS so they all mechanically fit, then export both to eagle and see if you can do reasonable layout with that placement 2016-02-19 21:27 inside eagle there's no editor for such stuff 2016-02-19 21:27 where you could see collisions instantly 2016-02-19 21:28 in SS you could edit placement for both surfaces and instantly see and fix collisions 2016-02-19 21:28 (if I actually understood what's SS) 2016-02-19 21:29 not quite immediately "both" because I only know how to map *one* IDF file to a sketch 2016-02-19 21:29 but soon SS will learn how to edit two sketches at once 2016-02-19 21:29 right now you could only do stuff like: create two sketches from two IDF files, import two sketches into one assembly 2016-02-19 21:29 then: edit sketch, reload assembly 2016-02-19 21:29 even in two windows side by side 2016-02-19 21:30 but it's not quite as convenient as having it builtin 2016-02-19 21:31 basically the problem is relative positioning of imported IDF files against each other, they both want to be at origin 2016-02-19 21:31 which is why assembling is needed 2016-02-19 21:31 like for any other two parts 2016-02-19 21:32 yes :-) 2016-02-19 21:36 mhm this still needs import and export though... or more like IDF editing mode that also saves SS metadata somewhere 2016-02-19 21:40 jwhitmore has joined #qi-hardware 2016-02-19 21:40 alexst has joined #qi-hardware 2016-02-19 21:40 I wonder if a ULP could actually calculate allowable height vor a component at a particular given place in realtime, but here realtime is a sad joke because you need to manually trigger ULPs and it wouldn't help for moving components around 2016-02-19 21:41 I also wonder why I always use v insted f 2016-02-19 21:41 not awake, as I said 2016-02-19 21:43 alexst has quit [Client Quit] 2016-02-19 21:47 ((repetitve switch beween scr and ulp)) just had a nightmare daydream flash of SCR storing parameters into component properies, then calling next ULP segment aka file aka card. "Luckily" that's nonsense since SCRs have no conditionals so they are 100% deterministic and if they're not due to errors then there's no way to call an ULP conditionally 2016-02-19 21:53 ULP would indeed work rather fine if it hadn't this idiotic limitation of actions to chainloaded SCR which turns writing useful ULP into a coder's nightmare 2016-02-19 21:54 see the mess I had to do for something silly simple like http://neo900.org/stuff/eaglefiles/ulp/A_create_index.ulp 2016-02-19 21:56 ah nice 2016-02-19 22:35 I guess a ULP - for a particular component X on surface A - could go through all components C on surface B and check if their (C.height > (2.5mm - X.height)) and any of of C's frame coordinates is within the frame of X 2016-02-19 22:35 but then what to do with the result? 2016-02-19 22:35 change color of C? 2016-02-19 22:37 move C into an arbitrary direction so there's no more collision? 2016-02-19 22:40 write a marker rectange (or whatever shape of component X) into layout of surface B, highlight or focus the component C and jump into editor with the component already picked for moving? 2016-02-19 22:43 hmmm no clue