#qi-hardware IRC log for Friday, 2016-02-19

kristianpaullate movement from Linux foundation for introducint zephy? 00:02
whitequarkbtw I found a full-time developer for that SolveSpace CAD14:03
whitequarkcc DocScrutinizer05 wpwrak 14:03
whitequarkin a year or so it should be quite competitive with freecad14:03
whitequarkwell, in terms of features, in terms of usability it's already lightyears ahead14:04
whitequarkI'd also quite like to integrate the rotting remains of HeeksCNC into it14:08
wpwrakCAM integration would certainly be a plus15:36
whitequarkhave you taken a look at solvespace yet?15:38
whitequarkif not you can build this: https://github.com/whitequark/solvespace15:38
whitequarkbranch for-upstream, dpkg-buildpackage works15:39
whitequarkor prebuilt debs: https://github.com/whitequark/solvespace/releases15:39
wpwrakyou 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/sl215:39
whitequarkslicing is one CAM strategy, yes15:40
whitequarkheekscnc is basically slicing (waterline) + hsm generation within each layer15:40
wpwrakhaven't looked much at solvespace yet. the premise sounds promising, though15:42
wpwrakcan 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 ?15:54
wpwrakor would you need to break this down into straight line segments and do something else for (rounded) corners ?15:55
whitequarkunfortunately not, the only 2d-to-3d operations it has is extrude along a line and rotate around axis16:06
whitequarkwell, in case of a round bucket specifically it's not a problem16:06
whitequarkbut if you want an elliptic bucket with chamfered edges... basically you're out of luck16:07
wpwrakyeah, i was thinking of a more artistic bucket :)16:07
whitequarkthis is a rather known problem. the current plan is to plagiarize opencascade16:07
whitequarki.e. not drag in the whole thing with its horrible dependencies, but just take the relevant NURBS operations out of it and reimplement16:08
whitequarkthis should be doable in a reasonable amount of time *and* we get the only other FOSS NURBS operations library16:08
whitequarkand, well, we don't get opencascade as a dependency, too16:09
whitequarkother 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 inclusions16:11
whitequarkthe former is going to land any day now16:12
whitequarkthe last one requires massive, multi-month refactoring16:12
whitequarkbut as a side effect you'll be able to drive the geometric kernel from python, headless16:12
wpwrakwhat would be so bad about having opencascase as dependency ? do they break the APIs often ?16:13
whitequarkand also get parameterized sketches, eg Mn screw with variable N16:13
whitequarkopencascade is an extremely large C++ codebase that is given away because the holding company is charging for consulting16:14
whitequarkso they have no incentive to make it usable16:14
whitequarkso it would be dragging in a million or so LOC of shit for a feature that's at most a few thousand LOC16:14
whitequarkand then translating everything back and forth16:15
whitequarkthe problem is NURBS booleans. they have an annoyingly large set of edge cases and basically no library takes it onto itself to handle them all16:15
whitequarkin 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 itsefl16:17
whitequarksince you don't get the algebraic representation of them16:17
whitequarkthat said, actually not all results of NURBS booleans can be represented exactly either16:18
whitequarkwpwrak: anyway, i'd be quite interested in your feedback. you could use SS for something minor anelok-related16:19
whitequarkditto for DocScrutinizer05 16:20
whitequarkwpwrak: I was also thinking about PCB import. not sure about formats though, never used them so far16:20
wpwrakwhat 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.16:28
whitequarkyes, a SWIG interface exposed to Python or Lua is another priority16:35
wpwrakwhatever swig is :) i was more thinking of just gnuplot-style input/output data sets :)16:37
whitequarkwell, solvespace is in a C++, and SWIG is a binding generator16:38
whitequarkqi-bot: stupid bot16:38
whitequarkwpwrak: with the current file format you can do it yourself.16:39
whitequarktry looking at it with `less`16:39
whitequarkI'm going to migrate it to a binary format, since the current one is monstrously inefficient even on tiny models16:41
whitequarkthough the current one will remain readable forever anyway16:41
wpwrakmmh, but aren't things calculated from parametric input ? you'd want the calculation results (for further processing), not the parameters from the source16:58
wpwrakthe format is a bit chatty (*) but doesn't look too inefficient17:00
wpwrak(*) 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 redundancy17:01
wpwrak(and it's still line-by-line processor friendly :)17:01
whitequarkentities and mesh are only written from imports17:03
whitequarkyou only actually need params, requests and constaints17:03
whitequarkhowever, imported sketches aren't resolved, so the complete result is written.17:04
whitequarkonly written FOR imports.17:04
whitequarkthat said the format is actually a direct serialization of the internal data structures17:04
wpwrakmmh, so you're saying that it contains the parametrized model and the results of processing it ?17:06
whitequarkEntity.actPoint is the numeric result17:06
whitequarkthat said I'm pretty sure a proper Python/Lua interface and a way to run it in batch mode is what you *actually* want17:09
whitequarkinstead of a heap of ad-hoc hacks over an undocumented file format exposing internals17:09
whitequarkI know, not user-hostile enough to be unix-way...17:10
DocScrutinizer05whitequark: 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 layout21:02
whitequarkDocScrutinizer05: hmmm that needs IDFv3 import, right?21:05
DocScrutinizer05whitequark: 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 methods21:05
whitequarkyes, it will allow arbitrary sketch modification21:06
whitequarkand it's actually less work than xslt21:06
DocScrutinizer05(IDFv3) I haven't even looked into it, not even pondered any details how to handle it at all21:06
whitequarkkicad exports placement data into IDFv321:07
DocScrutinizer05yeah, prolly that's a first take on it21:07
DocScrutinizer05I wouldn't even dare to think about interactive integration yet21:08
whitequarkI'm currently evaluating that actually21:08
DocScrutinizer05particularly as long as Neo900 is Eagle based21:08
whitequarkahhh right21:08
whitequarkyeah eagle has idf export too but interactive is a nonstarter21:08
DocScrutinizer05I seem to reecall sth about IDF export in eagle as well21:09
whitequarkit uses an ULP plugin21:09
DocScrutinizer05yep, exactly21:09
whitequarkactually not *impossible* to do import but incredibly fragile and tedious21:09
DocScrutinizer05ULP is rather powerful but icky21:10
DocScrutinizer05particularly ULP doesn't allow any modification calls to objects21:10
whitequarkULP is actually one of the least bad homegrown EDA languages I've seen21:10
whitequarkyou're supposed to generate an SCR21:10
whitequarkit's understandable, they don't want to duplicate all the consistency checking code for ULP too21:11
DocScrutinizer05you do idiotic things like producing a script of macros that gets called after ULP quits21:11
whitequarksince they already have it for the GUI and separately for SCR21:11
whitequarkcaught in their own bad design21:11
DocScrutinizer05hehe, yes21:11
whitequarkso, hm, I've read most of IDFv3 spec21:12
whitequarkit's a good, sane format21:12
whitequarkproblem is it assumes an 1:1 correspondence between IDF file and ECAD/MCAD internal repro21:12
whitequarkfor bidirectional integration21:12
DocScrutinizer05repetitve switch beween scr and ulp with mutual calls feels like worst 1978 coding hell21:12
whitequarkI feel like I could do something like that after all21:13
whitequarkit'd just be a fairly awkward mapping to a generic MCAD, parametric too21:13
whitequarkand, well21:13
whitequarkwhat do you even do with with things you can't store in IDF like constraints?21:13
DocScrutinizer05it's a complex problem, not easy to come up with a architecture for21:14
whitequarkso like, just importing IDF in a representation you can constrain against is pretty easy21:14
whitequarkno, certainly, it has a straightforward mapping21:15
whitequarkI already know how I'd do that21:15
DocScrutinizer05generate a "zone file" overlay that devines allowable component height21:15
DocScrutinizer05defines even21:15
whitequarkare you talking ECAD->MCAD or MCAD->ECAD?21:15
DocScrutinizer05the latter right now21:16
whitequarkah yeah21:16
DocScrutinizer05so during layout and component pos I can check against such layer21:16
DocScrutinizer05but stuff gets funny when I want to arrange stuff on the other surface to make space on this surface21:17
DocScrutinizer05it's like the antique turtle race21:19
whitequarkso the IDF format is based around outlines21:20
whitequarkit can specify a bunch of outlines, which are just loops defined by points+curvature21:21
whitequarknot even bezier21:21
whitequarkand every outline has some other properties like "component name" "board side" "locked by MCAD/ECAD" etc21:21
whitequarkthat's it21:21
whitequarkthat's the whole format21:21
DocScrutinizer05shouls suffice21:21
DocScrutinizer05component height particularly21:22
whitequarkI can simply map those outlines to MCAD outlines21:22
whitequarkand when there's a height you make an extrusion21:22
whitequarkand all other operations except for drawing outlines on top/bottom and extrusion are disallowed21:23
DocScrutinizer05then you calculate the free space headroom aka 2.5mm - component_height_a and inport that as restriction layer for survace_b in layout editor21:23
DocScrutinizer05and vice versa whenever switchin to surface_a layout21:23
DocScrutinizer05sorry, I can tell from my typos that I'm still asleep21:24
DocScrutinizer05ideally 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 placement21:26
DocScrutinizer05inside eagle there's no editor for such stuff21:27
DocScrutinizer05where you could see collisions instantly21:27
DocScrutinizer05in SS you could edit placement for both surfaces and instantly see and fix collisions21:28
DocScrutinizer05(if I actually understood what's SS)21:28
whitequarknot quite immediately "both" because I only know how to map *one* IDF file to a sketch21:29
whitequarkbut soon SS will learn how to edit two sketches at once21:29
whitequarkright now you could only do stuff like: create two sketches from two IDF files, import two sketches into one assembly21:29
whitequarkthen: edit sketch, reload assembly21:29
whitequarkeven in two windows side by side21:29
whitequarkbut it's not quite as convenient as having it builtin21:30
whitequarkbasically the problem is relative positioning of imported IDF files against each other, they both want to be at origin21:31
whitequarkwhich is why assembling is needed21:31
whitequarklike for any other two parts21:31
DocScrutinizer05yes :-)21:32
whitequarkmhm this still needs import and export though... or more like IDF editing mode that also saves SS metadata somewhere21:36
DocScrutinizer05I 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 around21:40
DocScrutinizer05I also wonder why I always use v insted f21:41
DocScrutinizer05not awake, as I said21:41
DocScrutinizer05((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 conditionally21:47
DocScrutinizer05ULP 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 nightmare21:53
DocScrutinizer05see the mess I had to do for something silly simple like http://neo900.org/stuff/eaglefiles/ulp/A_create_index.ulp21:54
whitequarkah nice21:56
DocScrutinizer05I 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 X22:35
DocScrutinizer05but then what to do with the result?22:35
DocScrutinizer05change color of C?22:35
DocScrutinizer05move C into an arbitrary direction so there's no more collision?22:37
DocScrutinizer05write 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?22:40
whitequarkhmmm no clue22:43
--- Sat Feb 20 201600:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!