Search results for all lists

10000 messages found
Sort by
List: discuss@lists.openscad.org
From: Torsten Paul
 
Re: python support for openscad
Sun, Jul 23, 2023 11:21 AM
nSCAD. There's hundreds of this kind of projects, in all sorts of languages, mostly in that state (16 commits, 5 years old). I don't see much benefit from those, it's largely cosmetic value where the additional features could be achieved by generating data file to feed into the OpenSCAD code. ciao, Torsten.
List: discuss@lists.openscad.org
From: Rogier Wolff
 
Re: python support for openscad
Sun, Jul 23, 2023 8:34 PM
layer in the XY plane. This can benefit from the fillet from strength. That said: I think also a fillet in the other direction will help with strength. I have seen objects delaminate exactly in the stresspoint where a fillet would have helped. And even if it doesn't help, it looks nice and less "openscad-like". Roger. > > On Sun, 23 Jul 2023, 20:24 Adrian Mariano, wrote: > > > Are you thinking that the layers break the propagation of stress through > > the model, causing stress to concentrate at each layer, instead of > > concentrating at a corner? Have you observed that models which fail by > > layers shearing do so and random places in the model? > > > > > > On Sun, Jul 23, 2023 at 3:18 PM nop head wrote: > > > >> I am not sure 3D fillets are any use in FDM printing because of the > >> layers. I only use 2D fillets to get rounded tool paths. > >> > >> On Sun, 23 Jul 2023, 20:08 Adrian Mariano, wrote: > >> > >>> I've been working on BOSL2 for a while with Revar, and we have 60k lines > >>> of OpenSCAD code. Based on that experience, I think that the problem with > >>> the OpenSCAD language is NOT fundamentally that it is functional. The > >>> benefit of python is NOT fundamentally that it is procedural. There are > >>> two basic problems with OpenSCAD for doing more complicated user space > >>> processing. One is the inability to gain access to geometry, so to do user > >>> space design, everything from the ground up has to be done "outside" of the > >>> OpenSCAD geometry engine. The second problem is about efficiency. > >>> OpenSCAD has no data structures. Graphics algorithms assume access to > >>> sophisticated and efficient data structures like a priority queue or a tree > >>> or other kinds of things that are impossible to implement efficiently in > >>> OpenSCAD. So, yeah, you can implement the data structure, but instead of > >>> being O(log N) or whatever it will be O(N^2). So then trying to implement > >>> that process that uses that data structure in user space becomes > >>> intractable. It's not clear to me that this limitation is fundamentally > >>> about the language being functional. > >>> > >>> Note that the filleting process displayed by Sanjeev is straight forward > >>> to implement in principle. You just find the intersection of two things > >>> and put a fillet there. Two complications arise for doing this in > >>> userspace in OpenSCAD. The first is representing the things, because > >>> again, you can't use the geometry engine to do it. Now maybe a solution to > >>> that problem is coming? The second complication is dealing with > >>> self-intersections of the resulting polyhedron, because that's intractable > >>> in OpenSCAD. Really it seems like OpenSCAD should have a primitive that > >>> accepts a series of profiles and links them together into a polyhedron, > >>> even if it's self-intersecting. > >>> > >>> Here's examples of doing the fillet problem entirely in OpenSCAD > >>> userspace. There are many examples at the link below. I show a single one > >>> in this message. > >>> > >>> > >>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism > >>> > >>> [image: image.png] > >>> > >>> > >>> On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < > >>> sprabhakar2006@gmail.com> wrote: > >>> > >>>> Sure > >>>> I will try to explain the logic maybe in a day or two for the benefit > >>>> of all who maybe interested in geometry manipulations. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OpenSCAD mailing list > >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org > >>>> > >>> _______________________________________________ > >>> OpenSCAD mailing list > >>> To unsubscribe send an email to discuss-leave@lists.openscad.org > >>> > >> _______________________________________________ > >> OpenSCAD mailing list > >> To unsubscribe send an email to discuss-leave@lists.openscad.org > >> > > _______________________________________________ > > OpenSCAD mailing list > > To unsubscribe send an email to discuss-leave@lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
List: discuss@lists.openscad.org
From: Guenther Sohler
 
Re: python support for openscad
Sun, Jul 23, 2023 8:23 PM
enscad of course you specity a point list and a faces list containing indices. but its immediately translated to this stupid coordinate-only format. it would be much better if openscad object would interally contain: * a list of vertices * a list of polygons whereas each polygon is just a list of indices. This is what i am currently working on and Marius appears to appreciate it, but he wants a "Polygon Builder" in addition. On Sun, Jul 23, 2023 at 10:15 PM Steve Lelievre < steve.lelievre.canada@gmail.com> wrote: > I'm confused... > > On 2023-07-23 12:45 p.m., Guenther Sohler wrote: > > Polyhedra are composed of triangles which are stored as coordinates > > only! It would be much better to compose triangles from > > indices into a global vertex array. This is something I am right now > > working on. > > I must have misunderstood your statement as it seems to me to say that > you're working on something that OpenSCAD's polyhedron command already > does: it takes a single list of vertices and each face is defined by a > list of vertex indices. > > Could you clarify for me, please. > > Steve > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
List: discuss@lists.openscad.org
From: Steve Lelievre
 
Re: python support for openscad
Sun, Jul 23, 2023 8:25 PM
ation of openscad is actually triangles containing > coordinates instead of indices. > > if you use openscad polyhedron command in openscad of course you specity > a point list and a faces list containing indices. > but its immediately translated to this stupid coordinate-only format. > > it would be much better if openscad object would interally contain: > > * a list of vertices > * a list of polygons whereas each polygon is just a list of indices. > > This is what i am currently working on and Marius appears to appreciate > it, but he wants a "Polygon Builder" in addition. > > > > On Sun, Jul 23, 2023 at 10:15 PM Steve Lelievre < > steve.lelievre.canada@gmail.com> wrote: > >> I'm confused... >> >> On 2023-07-23 12:45 p.m., Guenther Sohler wrote: >> > Polyhedra are composed of triangles which are stored as coordinates >> > only! It would be much better to compose triangles from >> > indices into a global vertex array. This is something I am right now >> > working on. >> >> I must have misunderstood your statement as it seems to me to say that >> you're working on something that OpenSCAD's polyhedron command already >> does: it takes a single list of vertices and each face is defined by a >> list of vertex indices. >> >> Could you clarify for me, please. >> >> Steve >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > -- Cell +1 778 837 5771
List: discuss@lists.openscad.org
From: Steve Lelievre
 
Re: python support for openscad
Sun, Jul 23, 2023 8:14 PM
working on something that OpenSCAD's polyhedron command already does: it takes a single list of vertices and each face is defined by a list of vertex indices. Could you clarify for me, please. Steve
List: discuss@lists.openscad.org
From: Revar Desmera
 
Re: python support for openscad
Sun, Jul 23, 2023 9:44 PM
List: discuss@lists.openscad.org
From: Revar Desmera
 
Re: python support for openscad
Sun, Jul 23, 2023 9:36 PM
List: discuss@lists.openscad.org
From: Sanjeev Prabhakar
 
Re: python support for openscad
Mon, Jul 24, 2023 4:31 PM
ns. > > > >
List: discuss@lists.openscad.org
From: gene heskett
 
Re: python support for openscad
Mon, Jul 24, 2023 9:33 PM
benefit of >> all who maybe interested in geometry manipulations. >> And this looks as if a set of tool paths could be defined in gcode from it, RS-274-D IOW, respecting the machines spindle power & rpm ability for depth of cut. # of loops and final finish accuracy determined by how close the radius of the fillet matches the tool nose radius. If this can be done in a useful time frame, the finished code to do this for subtractive machining would be a good src of funds to bank for your retirement. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page
List: usrp-users@lists.ettus.com
From: Mahmood, Hamza
 
X410 Debug and Support
Tue, Jul 16, 2024 7:23 PM
generated any time the stream command would be set, regardless if a tone was present or not. [cid:image001.png@01DAD794.0F1FE0D0] The SW used was based of the rfnoc_rx_to_file script, with the addition solely being specifying the RFNoC block added. Other than that the script was not changed. It was observed that the frequency of the unknown tone would change as the LO was tuned via the "freq" flag. We then reverted to the default FPGA design usrp_x410_fpga_CG_400.bit and ran some of the benchmark tests provided (https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio#Benchmarking_your_system). Below are the commands and results: benchmark_rate --args type="x4xx,addr=192.168.1.123" --rx_rate 491.52e6 --tx_rate 491.52e6 [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.HEAD-0-g5fac246b [00:00:00.000395] Creating the usrp device with: type=x4xx,addr=192.168.1.123... [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.123,type=x4xx,product=x410,serial=328B3AD,name=ni-x4xx-328B3AD,fpga=CG_400,claimed=False,addr=192.168.1.123 [WARNING] [MPM.RPCServer] A timeout event occured! [INFO] [MPM.PeriphManager] init() called with device args `fpga=CG_400,mgmt_addr=192.168.1.123,name=ni-x4xx-328B3AD,product=x410,clock_source=internal,time_source=internal'. Using Device: Single USRP: Device: X400-Series Device Mboard 0: x410 RX Channel: 0 RX DSP: n/a RX Dboard: A RX Subdev: 0 RX Channel: 1 RX DSP: n/a RX Dboard: A RX Subdev: 1 RX Channel: 2 RX DSP: n/a RX Dboard: B RX Subdev: 0 RX Channel: 3 RX DSP: n/a RX Dboard: B RX Subdev: 1 TX Channel: 0 TX DSP: n/a TX Dboard: A TX Subdev: 0 TX Channel: 1 TX DSP: n/a TX Dboard: A TX Subdev: 1 TX Channel: 2 TX DSP: n/a TX Dboard: B TX Subdev: 0 TX Channel: 3 TX DSP: n/a TX Dboard: B TX Subdev: 1 [00:00:03.633884524] Setting device timestamp to 0... Setting TX spp to 352 [00:00:03.680705900] Testing receive rate 491.520000 Msps on 1 channels [00:00:03.687798660] Testing transmit rate 491.520000 Msps on 1 channels OUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUO[00:00:13.802629374] Benchmark complete. Benchmark rate summary: Num received samples: 2052512 Num dropped samples: 4905369254 Num overruns detected: 65 Num transmitted samples: 259443008 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 2529 Num late commands: 0 Num timeouts (Tx): 0 Num timeouts (Rx): 0 Done! RFNOC TO FILE COMMAND rfnoc_rx_to_file --args type=x4xx,addr=192.168.1.123 --rate 491520000 --radio-id 0 radio-chan 1 --ant RX1 --freq 10000000 --null --progress Creating the RFNoC graph with args: type=x4xx,addr=192.168.1.123 [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.HEAD-0-g5fac246b [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.123,type=x4xx,product=x410,serial=328B3AD,name=ni-x4xx-328B3AD,fpga=CG_400,claimed=False,addr=192.168.1.123 [INFO] [MPM.PeriphManager] init() called with device args `fpga=CG_400,mgmt_addr=192.168.1.123,name=ni-x4xx-328B3AD,product=x410,clock_source=internal,time_source=internal'. Using radio 0, channel 0 Requesting RX Freq: 10 MHz... Actual RX Freq: 10 MHz... Waiting for "lo_locked": ++++++++++ locked. Using streamer args: Active connections: * 0/Radio#0:0-->RxStreamer#0:0 Requesting RX Rate: 491.52 Msps... Setting rate on radio block! Actual RX Rate: 491.52 Msps... Press Ctrl + C to stop streaming... Issuing stream cmd OGot an overflow indication. Please consider the following: Your write medium must sustain a rate of 1966.08MB/s. Dropped samples will not be written to the file. Please modify this example for your purposes. This message will not appear again. OOOOOOOOOOOOOOOOOO 0.611378 MSps OOOOOOOOOOOOOOOOOOO 0.591188 MSps OOOOOOOOOOOOOOOOOOO 0.591123 MSps OOOOOOOOOOOOOOOOOOO 0.591482 MSps OOOOOOOOOOOOOOOOOOO 0.591422 MSps OOOOOOOOOOOOOOOOOOO 0.589247 MSps OOOOOOOOOOOOOOOOOOO 0.590293 MSps OOOOOOOOOOOOOOOOOOO 0.591623 MSps OOOOOOOOOOOOOOOOOOO 0.590881 MSps OOOOOOOOOOOOOOOOOOO 0.590878 MSps OOOOOOOOOOOOOOOOOOO 0.592178 MSps OOOOOOOOOOOOOOOOOOO 0.591354 MSps OOOOOOOOOOOOOOOOOOO 0.590965 MSps OOOOOOOOOOOOOOOOOOO 0.591035 MSps OOOOOOOOOOOOOOOOOOO 0.591483 MSps OOOOOOOOOOOOOOOOOOO 0.591056 MSps OOOOOOOOOOOOOOOOOOO 0.591314 MSps ^C Issuing stop stream cmd Done! The main question is where is the tone originating from when streaming if not through the signal generator, is there some internal DDS being configured upon tuning? Or what other scripts can be used to verify using the RFNoC SW API. Thanks!