complicated than it seems as I have an event and a subscriber method receiving data from a serial port.
In the code below, the strings received within myReceivedLines appear when connecting with the serial port (when connecttodevice is true). However they disapear when I launch another command (when homeallis true).
As you recommended in your reply, I have added the field called myReceivedLineswithin the class so that I could use the method String.Add() to all the feedback received and commands sent.
Why does the feedback dispear when a command is sent? Is the string going to myReceivedLine disappearing because they happen within a subscriber method or is it related to the DA.SetDataList() method used to assign myReceivedLinesto the output?
Many thanks!
public class SendToPrintComponent : GH_Component { //Fields List<string> myReceivedLines = new List<string>(); SerialPort port; //subscriber method for the port.DataReceived Event private void DataReceivedHandler(object sender, System.IO.Ports.SerialDataReceivedEventArgs e) { SerialPort sp = (SerialPort)sender; while (sp.BytesToRead > 0) { try { myReceivedLines.Add(sp.ReadLine()); } catch (TimeoutException) { break; } } } protected override void SolveInstance(IGH_DataAccess DA) { //Opening the port if (port == null) { string selectedportname = default(string); DA.GetData(1, ref selectedportname); int selectedbaudrate = default(int); DA.GetData(2, ref selectedbaudrate); //Assigning an object to the field within the SolveInstance method() port = new SerialPort(selectedportname, selectedbaudrate, Parity.None, 8, StopBits.One); //Enables the data terminal ready (dtr) signal during serial communication (handshaking) port.DtrEnable = true; port.WriteTimeout = 500; port.ReadTimeout = 500; } //Event Handling Method bool connecttodevice = default(bool); DA.GetData(3, ref connecttodevice); if (connecttodevice == true) { if (!port.IsOpen) { port.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler); DA.SetDataList(0, myReceivedLines); port.Open(); } } else if (port.IsOpen) { port.DataReceived -= new SerialDataReceivedEventHandler(DataReceivedHandler); port.Close(); } if (port.IsOpen) { DA.SetData(1, "Port Open"); } //If the port is open do all the rest if (port.IsOpen) { bool homeall = default(bool); DA.GetData(5, ref homeall); //Home all sends all the axis to the origin if (homeall == true) { port.Write("G28" + "\n"); myReceivedLines.Add("G28" + "\n"); DA.SetDataList(2, myReceivedLines); } } else { DA.SetData(1, "Port Closed"); } }}…
and 3d rapid prototyping using state of the art material simulation and optimisation. Participants will be guided through methods of advanced structural analysis and evolutionary algorithms implemented in Grasshopper, Karamba and Octopus in a 5 day workshop taught by Robert Vierlinger and Matthew Tam within the premises of the Academy of Fine Arts & Design in Bratislava, Slovakia. The workshop will cover the basics of setting up a karamba definition and more advanced form finding techniques with beams and shells through to preparing files for 3d printing and 2d documentation. For the Grasshopper newcomers there is a preparatory crash course on 20 July 2015 taught by Ján Pernecký. The workshop will be held entirely in English. VENUE Academy of Fine Arts and Design in Bratislava: VŠVU / AFAD, Hviezdoslavovo námestie 18, Bratislava, Slovakia ROOM 135 PRICING Early bird Student (until Jun 30, 2015) €320 Early bird Professional (until Jun 30, 2015) €380 Regular Student (from Jun 30, 2015) €400 Regular Professional (from Jun 30, 2015) €475 The fee covers only the tuition. Travel expenses, accommodation and food is to be covered by the participants. SCHEDULE Day 1 Lecture - Karamba in Projects from Competition to Construction Introduction to karamba - Setting up a basic karamba model Shells & Beams - Understanding the impact of load on geometries. Beams - Cross Section Optimization, Load Path Emergence Day 2 Extraction and Visualization of data from Karamba Complex Geometry - Processing of Free Forms for Karamba Force Flow - Understanding and Visualizing results on shells 3d Printing - Preparing geometries for rapid prototyping Day 3 Lecture - Form Finding in Karamba Isler Shells - Hanging Forms with karamba Shells - Shape Optimisation with Galapagos Trusses - Topology Optimization with Galapagos Columns - Positioning with Galapagos Multiobjective optimisation strategies with Octopus Day 4 Frequency Analysis & Non-Linear Analysis with Karamba Extraction and Visualization Part 2 BIS - Building Information Systems with karamba Day 5 Participant’s Examples and Topics Reviewing 3d Print Studies Large Complex Models Reviewing learn techniques and strategies Concluding lecture - public PARTNERS rese arch Academy of fine arts and design…
R_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh Butterfly is running blockMesh. PID: 1837 SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh
/*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1612+ | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : v1612+ Exec : blockMesh Date : May 22 2017 Time : 08:51:50 Host : "default" PID : 1837 Case : /home/ofuser/workingDir/butterfly/outdoor_airflow nProcs : 1 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10) allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time
Creating block mesh from "/home/ofuser/workingDir/butterfly/outdoor_airflow/system/blockMeshDict" Creating block edges No non-planar block faces defined Creating topology blocks Creating topology patches
Creating block mesh topology
Check topology
Basic statistics Number of internal faces : 0 Number of boundary faces : 6 Number of defined boundary faces : 6 Number of undefined boundary faces : 0 Checking patch -> block consistency
Creating block offsets Creating merge list .
Creating polyMesh from blockMesh Creating patches Creating cells new cannot satisfy memory request. This does not necessarily mean you have run out of virtual memory. It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library Runtime error (PythonException):
Butterfly failed to run OpenFOAM command! new cannot satisfy memory request. This does not necessarily mean you have run out of virtual memory. It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library Traceback: line 51, in script
I don't really have any knowledge in CFD simulation and only watched the tutorials and managed to get the sample files to work. So this time, I replaced the starting geometry my building which is a curve building, I wonder if that is the issue that caused this problem. Can anyone enlighten me on the issue?
Warm regards,
Annie…
http://www.pilkington.com/) dominates the planar market. Charges "around" 1K Euros per m2 for a "plain" system. Personally in bespoke projects I design my own stuff but due to economies of scale ... they cost a bit more (but they look far more sexier, he he) . On the other hand only in a bespoke project I could dare to suggest such a solution (for a large scale building we are talking lots and lots of dollars).
3. Several scales below (aesthetics) you can find static alu systems (either structural or semi-structural):
Or hinged systems (either structural or semi-structural) capable to adapt in contemporary double curvature facades/roofs/envelopes/cats/dogs etc etc ... pioneered worldwide many years ago by my best friend Stefanos Tampakakis (everybody in UAE knows that genius man: http://www.alustet.gr/company.html):
4. With the exception of some paranoid things that Guru Stefanos does for Zaha these days we are talking about planar "facets" (obviously a triangle is such a planar facet). The current trend is: the more edges the better (humans excel in vanity matters). But achieving planarity in, say, quads (like yours) it adds another "restriction" on what you are doing. Until recently Evolute Tools Pro was the only answer. But right now ... well let's say that in short time you'll be greatly surprised by some WOW things in this Noble Forum, he he.
5. MERO (and obviously custom systems) can adapt (at almost no extra charge) in anything imaginable. But in a bespoke building ... well.. you know ultra rich people: they don't want MERO anymore since "everybody" does MERO solutions. Vanity, what else?
6. Smart Glass would become a must in the years to come: Eco-Architecture MUST dominate everything you do. On the other hand spending millions to do some extra WOW stuff (Vanity) ... it doesn't look to me very Eco-Friendly/Whatever ... but let's pretend so, he he.
7. I'm Architect but a bit different from the norm: for instance I smoke cigars (highly politically incorrect stuff) I always talk openly (ditto) and I ride lethal bikes (ditto).
may the Force (as always the Dark Option) be with you: go out there and kill them all.
best, Peter
…
ity...? How to define this parameters and simulate them? How to simulate and evaluate form? How to work with Evolutionary Solver inside Grasshopper3d? How to evaluate end data and choose the fittest geometry? How to optimize geometry to increase overall energy efficiency of project!?
»»» Rhinoceros 5 + Grasshopper 3D & Sub-Plugins *required grasshopper plugins: Elk, LadyBug + Honeybee, Mesh edit (uto tools), Mesh+, Weaverbird, Human, TT Toolbox, Lunchbox, Horster tools, Exoskeleton & Cytoskeleton
>>>Please download and install Rhino + GH3D & Sub-Plugins before workshop start!<<<
with Igor Mitrić
DIGITAL FABRICATION BASICS - 3D SCANNING AND 3D PRINTING
Workshop would provide overview of current state of technologies for 3D scanning and 3D printing with those affordable and practical devices for research and development new design projects. Attendees would use 3D scanner to generate 3D model in virtual computer space, remodel, and prepare for 3D printer.
with Roberto Vdović
OPTIONAL FIELD TRIP - ON SITE ENERGY MEASUREMENTS (19.6.2015)
with Benedikt Borišič and Veronika Madritsch
Participants will receive CERTIFICATES of knowledge acquired at the workshop for each section. Participation is FREE! The number of places is LIMITED!
MORE INFORMATION AND APPLICATION WWW.LIVECONST.EU
WORKING SCRITPS
Day 1 City.gh
Day 2 Lady Bug.gh
Day 3 Galapagos
Record Galapagos.gh
Day 3_First Half.gh
Day 3 Second Half.gh
Tower from any Curve.gh
…
Illuminants like "A" or "D65" are spectral power distributions that are defined (as per CIE S 014-2/E:2006) for wavelengths ranging from 300nm to 830nm.
For example, CIE Illuminants A,B and C are defined as :
And D65 is defined as :
For illuminance and luminance calculations, the radiation from such illuminants are converted to Lux or Candela/sq.m by weighing them against the Photopic Luminous Efficiency function (also called as V-lambda):
The equation (1) used for this purpose is
Where y corresponds to the V-lambda function and J corresponds to an illuminant like "D65" or "A".
So, why is all this relevant? Honeybee/Radiance also use a similar method for calculation of luminous flux, illuminance and luminance. However, in the case of Honeybee/Radiance the lighting calculations are limited only 3 (R,G,B) channels (and not the 300nm to 830nm). So the equation (1) from above becomes something like:
F = 47.4*R+120*G+11.6*B
Where (R,G,B) refers to the spectral power of the radiation and the numbers (47.4,120,11.6) relate to the V-lambda function. So, the bottom line is that an accurate representation of CIE illuminants is not possible inside Radiance/Honeybee as the spectral information is severely restricted. Some studies have proposed using Radiance with more than 3 channels. For example: http://link.springer.com/article/10.3758%2FBRM.40.1.304 . However, such attempts have been limited. What is possible with Radiance/Honeybee is to create a fairly accurate representation of brightness of the sky. Although, I can explain that too, I would suggest that you try this link first: http://www.bozzograo.net/radiance/index.php?module=FAQ&func=dis...
By the way, which CIE document are you referring to for CIE sky definitions ?…
p others facing similar issues. 1) Letting Grasshopper perform the "implied" loop can be substantially slower than making the loop yourself inside the Python script. This is understandable, however the strangest thing is that it is MUCH slower if the definition has been saved than when it has not (by about a factor of 10)! 2) Setting type hints seems to be slower than inputting data with "No Type Hint". This depends a bit on which type is being input, but this seems to be fairly consistent. In the attached example by about a factor of 3. I suppose this is understandable, but not exactly ideal. 3) Outputtings lists with many items will often take longer than the actual computation performed by the script. I suppose this is more of a Grasshopper thing. My workaround has been to wrap the list in a Python list and pass this along as an item, which will be ALOT faster with large lists (this was crucial to both the Tower and ShapeOP where we pass around large amounts of constraints).
4) Calling certain RhinoCommon methods appear to be randomly much more expensive than using the C# scripting component. For instance, when iterating over a mesh's vertices and calling Mesh.Vertices.GetConnectedVertices() the elapsed time sum of these calls seem to be comprised of only a few vertices which randomly change every time the script is run. The amount of vertices differ on different machines, but the pattern remain consistent. I'm not sure if these bottlenecks are just examples of me being dumb, if so I hope you can enlighten me to the errors of my ways :) Attached some screenshots of an unsaved/saved definition which demonstrates the described issues. Also please find the gh definition attached. Best, Anders Edit: Logged this on Github here. Update: Added point 4), new screenshot and file demonstrating this behaviour.
System: Rhino Version 5 SR11 64-bit (5.11.50226.17195, 02/26/2015) Grasshopper 0.9.0073 GHPython 0.6.0.3 Laptop …
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
essarily architectural. As you can guess from the tone of my previous response, I finished with school and had a hard time finding a job that focused on the technologies I delt with all through undergrad and grad. During grad school I was working with ASGvis (the makers of V-Ray) so I got exposed to the software side of things both on the support/management side and the development side. Now I'm off on my own doing development projects like RhinoHair, a few others, and some custom plugins for clients. Not necessarily what I thought I'd be doing after grad school, but I'm certainly enjoying it more than the "standard" practice of architecture.
I definitely understand "creating" a program. I did both my undergrad and grad at Catholic U here in DC, and although there was some ground work laid in regards to fabrication, I was one of only two or three students spearheading a lot of the scripting/GH/parametric stuff and some of the topics that go along with them (algorithmic design, adaptive systems, advanced geometry). One thing that was incredibly helpful for me was to pair up with the most advanced and forward thinking professor(s) that you can and take their studios, electives, and/or help out with their research. I was lucky enough to pair with a professor who had been at MIT and really encouraged me to explore my interests and sharpen my technicial skills.
It might also be a good idea to stick your head in some other departments, probably the math and engineering ones, or even biology and economics if there are some forward thinking professors. Talk to some people and get a different perspective on things. When I went to the ACADIA conference in 2008 it really opened my eyes to some of the potential influence from those different arenas.
Fabrication wise, I'd really try to focus more on milling (3 axis is fairly standard, 5 axis if you can get access) than 3d printing. Printing is a lot of fun, but ultimately we're not printing buildings (yet), so some of the milling processes will be much more valuble. If your school doesn't have those kind of facilities on campus (either in the Arch dept or engineering or something), then contact a local fabricator and see if you can work together somehow or someway. You'd be surprised and how many fabricators are interested in talking to architects.…
Added by Damien Alomar at 3:13pm on February 8, 2010