| 00:02.31 | kristianpaul | late movement from Linux foundation for introducint zephy? |
| 02:57.28 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 03:23.39 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 03:39.45 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 04:08.20 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:42.13 | *** join/#qi-hardware fengling (~fengling@111.198.29.54) |
| 05:04.35 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 05:31.51 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 06:06.46 | *** join/#qi-hardware alexst (~alexander@109.188.125.3) |
| 06:33.04 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 07:02.58 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 07:18.01 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 07:19.58 | *** join/#qi-hardware dandon (~dandon@88.151.79.199) |
| 07:48.55 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 08:33.44 | *** join/#qi-hardware sb0_ (~lekernel@212.91.24.78) |
| 09:10.07 | *** join/#qi-hardware fengling (~fengling@111.198.29.54) |
| 09:47.48 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 10:07.40 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 11:09.37 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 11:35.10 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 11:50.57 | *** join/#qi-hardware fdcx (~fdcx@ceata/consiliu/FDCX) |
| 12:05.54 | *** join/#qi-hardware alexst (~alexander@109.188.125.6) |
| 13:42.59 | *** join/#qi-hardware jwhitmore (~jwhitmore@host86-154-188-204.range86-154.btcentralplus.com) |
| 14:03.17 | whitequark | btw I found a full-time developer for that SolveSpace CAD |
| 14:03.25 | whitequark | cc DocScrutinizer05 wpwrak |
| 14:03.52 | whitequark | in a year or so it should be quite competitive with freecad |
| 14:04.10 | whitequark | well, in terms of features, in terms of usability it's already lightyears ahead |
| 14:08.38 | whitequark | I'd also quite like to integrate the rotting remains of HeeksCNC into it |
| 14:52.02 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 15:25.10 | *** join/#qi-hardware alexst (~alexander@83.220.239.190) |
| 15:36.20 | wpwrak | CAM integration would certainly be a plus |
| 15:38.36 | whitequark | have you taken a look at solvespace yet? |
| 15:38.59 | whitequark | if not you can build this: https://github.com/whitequark/solvespace |
| 15:39.05 | whitequark | branch for-upstream, dpkg-buildpackage works |
| 15:39.17 | whitequark | or prebuilt debs: https://github.com/whitequark/solvespace/releases |
| 15:39.37 | wpwrak | 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 |
| 15:40.04 | whitequark | slicing is one CAM strategy, yes |
| 15:40.27 | whitequark | heekscnc is basically slicing (waterline) + hsm generation within each layer |
| 15:42.23 | wpwrak | haven't looked much at solvespace yet. the premise sounds promising, though |
| 15:54.13 | wpwrak | 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 ? |
| 15:55.06 | wpwrak | or would you need to break this down into straight line segments and do something else for (rounded) corners ? |
| 16:06.39 | whitequark | unfortunately not, the only 2d-to-3d operations it has is extrude along a line and rotate around axis |
| 16:06.58 | whitequark | well, in case of a round bucket specifically it's not a problem |
| 16:07.16 | whitequark | but if you want an elliptic bucket with chamfered edges... basically you're out of luck |
| 16:07.39 | wpwrak | yeah, i was thinking of a more artistic bucket :) |
| 16:07.51 | whitequark | this is a rather known problem. the current plan is to plagiarize opencascade |
| 16:08.10 | whitequark | i.e. not drag in the whole thing with its horrible dependencies, but just take the relevant NURBS operations out of it and reimplement |
| 16:08.26 | whitequark | this should be doable in a reasonable amount of time *and* we get the only other FOSS NURBS operations library |
| 16:09.31 | whitequark | and, well, we don't get opencascade as a dependency, too |
| 16:11.51 | whitequark | 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 |
| 16:12.18 | whitequark | the former is going to land any day now |
| 16:12.29 | whitequark | the last one requires massive, multi-month refactoring |
| 16:12.48 | whitequark | but as a side effect you'll be able to drive the geometric kernel from python, headless |
| 16:13.03 | wpwrak | what would be so bad about having opencascase as dependency ? do they break the APIs often ? |
| 16:13.09 | whitequark | and also get parameterized sketches, eg Mn screw with variable N |
| 16:14.06 | whitequark | opencascade is an extremely large C++ codebase that is given away because the holding company is charging for consulting |
| 16:14.13 | whitequark | so they have no incentive to make it usable |
| 16:14.59 | whitequark | so it would be dragging in a million or so LOC of shit for a feature that's at most a few thousand LOC |
| 16:15.04 | whitequark | and then translating everything back and forth |
| 16:15.54 | whitequark | 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 |
| 16:17.21 | whitequark | 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 |
| 16:17.34 | whitequark | since you don't get the algebraic representation of them |
| 16:18.08 | whitequark | that said, actually not all results of NURBS booleans can be represented exactly either |
| 16:19.04 | whitequark | wpwrak: anyway, i'd be quite interested in your feedback. you could use SS for something minor anelok-related |
| 16:20.16 | whitequark | ditto for DocScrutinizer05 |
| 16:20.33 | whitequark | wpwrak: I was also thinking about PCB import. not sure about formats though, never used them so far |
| 16:28.46 | wpwrak | 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. |
| 16:35.51 | whitequark | yes, a SWIG interface exposed to Python or Lua is another priority |
| 16:37.28 | wpwrak | whatever swig is :) i was more thinking of just gnuplot-style input/output data sets :) |
| 16:38.27 | whitequark | well, solvespace is in a C++, and SWIG is a binding generator |
| 16:38.32 | whitequark | s/a// |
| 16:38.32 | qi-bot | whitequark meant: "well, solvespce is in C++, nd SWIG is binding genertor" |
| 16:38.45 | whitequark | qi-bot: stupid bot |
| 16:39.35 | whitequark | wpwrak: with the current file format you can do it yourself. |
| 16:39.47 | whitequark | try looking at it with `less` |
| 16:41.05 | whitequark | I'm going to migrate it to a binary format, since the current one is monstrously inefficient even on tiny models |
| 16:41.23 | whitequark | though the current one will remain readable forever anyway |
| 16:58.55 | wpwrak | mmh, but aren't things calculated from parametric input ? you'd want the calculation results (for further processing), not the parameters from the source |
| 17:00.06 | wpwrak | the format is a bit chatty (*) but doesn't look too inefficient |
| 17:01.12 | 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 redundancy |
| 17:01.39 | wpwrak | (and it's still line-by-line processor friendly :) |
| 17:03.45 | whitequark | entities and mesh are only written from imports |
| 17:03.53 | whitequark | you only actually need params, requests and constaints |
| 17:03.55 | whitequark | constraints* |
| 17:04.11 | whitequark | however, imported sketches aren't resolved, so the complete result is written. |
| 17:04.27 | whitequark | only written FOR imports. |
| 17:04.52 | whitequark | that said the format is actually a direct serialization of the internal data structures |
| 17:06.21 | wpwrak | mmh, so you're saying that it contains the parametrized model and the results of processing it ? |
| 17:06.28 | whitequark | exactly. |
| 17:06.57 | whitequark | Entity.actPoint is the numeric result |
| 17:09.36 | whitequark | 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 |
| 17:09.49 | whitequark | instead of a heap of ad-hoc hacks over an undocumented file format exposing internals |
| 17:10.18 | whitequark | I know, not user-hostile enough to be unix-way... |
| 17:10.56 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 17:58.20 | *** join/#qi-hardware Ornotermes (~ornoterme@78-67-39-53-no180.tbcn.telia.com) |
| 18:11.25 | *** join/#qi-hardware pcercuei (~pcercuei@2a03:a680:2020:ff62:1af4:6aff:fec5:1c8f) |
| 18:21.10 | *** join/#qi-hardware kristianpaul (~kristianp@ec2-52-3-242-38.compute-1.amazonaws.com) |
| 18:21.10 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 18:22.39 | *** join/#qi-hardware pcercuei (~pcercuei@2a03:a680:2020:ff62:1af4:6aff:fec5:1c8f) |
| 18:26.13 | *** join/#qi-hardware tumdedum (~tumdedum@unaffiliated/espiral) |
| 18:28.08 | *** join/#qi-hardware archang (~archang@111.198.29.54) |
| 18:28.27 | *** join/#qi-hardware kanzure (~kanzure@bryan.fairlystable.org) |
| 19:05.49 | *** join/#qi-hardware kanzure (~kanzure@unaffiliated/kanzure) |
| 19:06.27 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-106-217-43.snloca.dsl-w.verizon.net) |
| 19:31.08 | *** join/#qi-hardware alexst (~alexander@109.188.125.56) |
| 20:11.26 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-106-217-43.snloca.dsl-w.verizon.net) |
| 20:25.55 | *** join/#qi-hardware alexst (~alexander@109.188.125.56) |
| 21:02.09 | DocScrutinizer05 | 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 |
| 21:05.29 | whitequark | DocScrutinizer05: hmmm that needs IDFv3 import, right? |
| 21:05.41 | DocScrutinizer05 | 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 |
| 21:06.11 | whitequark | yes, it will allow arbitrary sketch modification |
| 21:06.18 | whitequark | and it's actually less work than xslt |
| 21:06.43 | DocScrutinizer05 | (IDFv3) I haven't even looked into it, not even pondered any details how to handle it at all |
| 21:07.08 | whitequark | kicad exports placement data into IDFv3 |
| 21:07.42 | DocScrutinizer05 | yeah, prolly that's a first take on it |
| 21:08.09 | DocScrutinizer05 | I wouldn't even dare to think about interactive integration yet |
| 21:08.22 | whitequark | I'm currently evaluating that actually |
| 21:08.35 | DocScrutinizer05 | particularly as long as Neo900 is Eagle based |
| 21:08.39 | whitequark | ahhh right |
| 21:08.55 | whitequark | yeah eagle has idf export too but interactive is a nonstarter |
| 21:09.05 | DocScrutinizer05 | I seem to reecall sth about IDF export in eagle as well |
| 21:09.14 | whitequark | it uses an ULP plugin |
| 21:09.18 | DocScrutinizer05 | yep, exactly |
| 21:09.30 | whitequark | actually not *impossible* to do import but incredibly fragile and tedious |
| 21:09.37 | DocScrutinizer05 | yes |
| 21:10.00 | DocScrutinizer05 | ULP is rather powerful but icky |
| 21:10.37 | DocScrutinizer05 | particularly ULP doesn't allow any modification calls to objects |
| 21:10.40 | whitequark | ULP is actually one of the least bad homegrown EDA languages I've seen |
| 21:10.41 | whitequark | yes |
| 21:10.48 | whitequark | you're supposed to generate an SCR |
| 21:11.01 | whitequark | it's understandable, they don't want to duplicate all the consistency checking code for ULP too |
| 21:11.12 | DocScrutinizer05 | you do idiotic things like producing a script of macros that gets called after ULP quits |
| 21:11.12 | whitequark | since they already have it for the GUI and separately for SCR |
| 21:11.25 | whitequark | caught in their own bad design |
| 21:11.32 | DocScrutinizer05 | hehe, yes |
| 21:12.00 | whitequark | so, hm, I've read most of IDFv3 spec |
| 21:12.04 | whitequark | it's a good, sane format |
| 21:12.28 | whitequark | problem is it assumes an 1:1 correspondence between IDF file and ECAD/MCAD internal repro |
| 21:12.35 | whitequark | for bidirectional integration |
| 21:12.40 | DocScrutinizer05 | repetitve switch beween scr and ulp with mutual calls feels like worst 1978 coding hell |
| 21:13.05 | whitequark | I feel like I could do something like that after all |
| 21:13.31 | whitequark | it'd just be a fairly awkward mapping to a generic MCAD, parametric too |
| 21:13.36 | whitequark | and, well |
| 21:13.48 | whitequark | what do you even do with with things you can't store in IDF like constraints? |
| 21:14.02 | DocScrutinizer05 | right |
| 21:14.21 | DocScrutinizer05 | it's a complex problem, not easy to come up with a architecture for |
| 21:14.53 | whitequark | so like, just importing IDF in a representation you can constrain against is pretty easy |
| 21:15.06 | DocScrutinizer05 | possibly |
| 21:15.21 | whitequark | no, certainly, it has a straightforward mapping |
| 21:15.29 | whitequark | I already know how I'd do that |
| 21:15.36 | DocScrutinizer05 | generate a "zone file" overlay that devines allowable component height |
| 21:15.57 | DocScrutinizer05 | defines even |
| 21:15.59 | whitequark | are you talking ECAD->MCAD or MCAD->ECAD? |
| 21:16.11 | DocScrutinizer05 | the latter right now |
| 21:16.16 | whitequark | ah yeah |
| 21:16.47 | DocScrutinizer05 | so during layout and component pos I can check against such layer |
| 21:17.34 | DocScrutinizer05 | but stuff gets funny when I want to arrange stuff on the other surface to make space on this surface |
| 21:19.43 | DocScrutinizer05 | it's like the antique turtle race |
| 21:19.47 | whitequark | yeah |
| 21:20.36 | whitequark | so the IDF format is based around outlines |
| 21:21.09 | whitequark | it can specify a bunch of outlines, which are just loops defined by points+curvature |
| 21:21.12 | whitequark | not even bezier |
| 21:21.33 | whitequark | and every outline has some other properties like "component name" "board side" "locked by MCAD/ECAD" etc |
| 21:21.42 | whitequark | that's it |
| 21:21.44 | whitequark | that's the whole format |
| 21:21.51 | DocScrutinizer05 | yes |
| 21:21.57 | DocScrutinizer05 | shouls suffice |
| 21:22.05 | DocScrutinizer05 | component height particularly |
| 21:22.07 | whitequark | I can simply map those outlines to MCAD outlines |
| 21:22.14 | whitequark | and when there's a height you make an extrusion |
| 21:23.10 | whitequark | and all other operations except for drawing outlines on top/bottom and extrusion are disallowed |
| 21:23.16 | DocScrutinizer05 | 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 |
| 21:23.43 | DocScrutinizer05 | and vice versa whenever switchin to surface_a layout |
| 21:24.20 | DocScrutinizer05 | sorry, I can tell from my typos that I'm still asleep |
| 21:26.46 | DocScrutinizer05 | 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 |
| 21:27.20 | DocScrutinizer05 | inside eagle there's no editor for such stuff |
| 21:27.34 | DocScrutinizer05 | where you could see collisions instantly |
| 21:28.33 | DocScrutinizer05 | in SS you could edit placement for both surfaces and instantly see and fix collisions |
| 21:28.56 | DocScrutinizer05 | (if I actually understood what's SS) |
| 21:29.12 | whitequark | not quite immediately "both" because I only know how to map *one* IDF file to a sketch |
| 21:29.25 | whitequark | but soon SS will learn how to edit two sketches at once |
| 21:29.46 | whitequark | right now you could only do stuff like: create two sketches from two IDF files, import two sketches into one assembly |
| 21:29.52 | whitequark | then: edit sketch, reload assembly |
| 21:29.58 | whitequark | even in two windows side by side |
| 21:30.07 | whitequark | but it's not quite as convenient as having it builtin |
| 21:31.04 | whitequark | basically the problem is relative positioning of imported IDF files against each other, they both want to be at origin |
| 21:31.15 | whitequark | which is why assembling is needed |
| 21:31.21 | whitequark | like for any other two parts |
| 21:32.24 | DocScrutinizer05 | yes :-) |
| 21:36.29 | whitequark | mhm this still needs import and export though... or more like IDF editing mode that also saves SS metadata somewhere |
| 21:40.11 | *** join/#qi-hardware jwhitmore (~jwhitmore@host86-154-188-204.range86-154.btcentralplus.com) |
| 21:40.17 | *** join/#qi-hardware alexst (~alexander@109.188.125.56) |
| 21:40.38 | DocScrutinizer05 | 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 |
| 21:41.16 | DocScrutinizer05 | I also wonder why I always use v insted f |
| 21:41.30 | DocScrutinizer05 | not awake, as I said |
| 21:47.47 | 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 conditionally |
| 21:53.01 | DocScrutinizer05 | 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 |
| 21:54.33 | DocScrutinizer05 | see the mess I had to do for something silly simple like http://neo900.org/stuff/eaglefiles/ulp/A_create_index.ulp |
| 21:56.42 | whitequark | ah nice |
| 22:35.06 | DocScrutinizer05 | 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 |
| 22:35.25 | DocScrutinizer05 | but then what to do with the result? |
| 22:35.40 | DocScrutinizer05 | change color of C? |
| 22:37.42 | DocScrutinizer05 | move C into an arbitrary direction so there's no more collision? |
| 22:40.24 | DocScrutinizer05 | 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? |
| 22:43.17 | whitequark | hmmm no clue |
,){kind=link}