s para acercarse al diseño paramétrico.
El curso esta dirigido a arquitectos diseñadores e ingenieros de diseño que pretendan implementar las técnicas del modelado por parámetros dentro de sus herramientas de proyectación.
La duración de dicho curso es de 20 horas, repartidas en 6 sesiones los días lunes y miércoles de 5pm a 8:20pm, en el espacio cultural calle nueve (calle 9 # 43b-75 abajo del parque del Poblado. https://www.facebook.com/calle.nueve). El curso dará inicio el día lunes 22 de Agosto de 2011. El máximo de inscritos por curso es de 15 personas para garantizar la calidad de la enseñanza.
Este curso estará dictado por los arquitectos Ana Maria Bustamante Y David Vanegas arquitectos de la oficina de arquitectura interior137 (www.interior137.blogspot.com) que cuentan con más de dos años de experiencia en el manejo de GRASSHOPPER, y tienen una trayectoria reconocida como docentes en la Facultad de Arquitectura de la U.P.B.
Para participar en el taller los estudiantes deberán tener un computador portátil para su uso personal, durante todo el curso, además deben tener instalado el software Rhino versión 4.0 con la actualización SR9, y un conocimiento mínimo del modelado y la interfaz de este software.
Contenidos:
Sesión 1: * Introducción al modelado por parámetros y al diseño mediante algoritmos.
* Grasshopper: datos + acciones. Interface.
Sesión 2: * Datos fijos, datos variables: Parámetros.
* Puntos, Curvas parametrizables.
* Transformaciones: Mover, Rotar.
Sesión 3: * Datos múltiples (listas): Series. Rangos.
* Funciones de 1 y 2 variables.
Sesión 4: * Gestiones de datos en listas: seleccionar items, ordenarlos, desordenarlos, eliminarlos.
Sesión 5: * Atractores.
Sesión 6: * Superficies: creación de superficies, panelizaciones.
Informes e inscripciones:
Para inscribirse en el curso deberá reservar su cupo abonando el costo total del curso al menos hasta el miércoles 17 de Agosto. Este valor se devolverá totalmente únicamente en caso de cancelación del curso.
Para mayor información, póngase en contacto a través del correo electrónico interior137@gmail.com asunto: CURSO GH…
r-tools/
the hack is found here: http://fancywires.com/?p=499
it doesn't function the same as it used to, and i wonder if somethings have changed in the functions underlying the VB script or maybe some other updates to GH that are relevant.
furthurmore, i ask if anyone has made advancements on labeling techniques for cnc/laser cutting?
is there anything more built into GH to do this task?
Permalink Reply by Giulio Piacentino on Thursday
Yesterday I was asked a modified version of the script. Now it supports planes, so it should be easier to use.
- Giulio
Permalink Reply by gotjosh on Thursday
Delete
cool! I also recently adapted the old version to use an input plane instead of a point... i'll have to look at your script to see if we made the same solution.
thanks for your reply... is there anyway that your script could take care of the hack that fancywires has made afterwards? it would be great to have each letter returned cleaned and joined, so there were exactly the same number of curves in the output as characters in the input...
i am basically clueless with VB and .net scripting so far, but i can code in AS3 and php, so a small push in the right direction might get me far...
How can one return one single curve in a letter like "O"? Do you mean using single-stroke fonts? Or maybe returning a brep (polysurface) as output?
- Giulio
…
r interface to gsa, you'll find technical help/descriptions in it's help system. Certainly changing the type to Bar overrides any user defined releases.
The gsa solver must make special allowance for node "stability" when the elements connected are all bars (for rotation). If you're circumstance when you change type to Beams, your end releases are applied to axial and shear at all ends (note you can change the "close model" input on the solver component to false so you can see the analysis error). I think I previously discussed with Oasys about the COM interface sending back the "log" so I could display it in Grasshopper. Elements with axial and shear releases both ends are unrestrained, so it's causing the solver error. If you say released Fx and Fy at both ends it might work (I didn't test), certainly at one end only it should.
There's a hidden component (I can't remember if it's completed or not, i think so but not extensively tested) that can generate "tied interfaces" along edges of meshes to link nodes. Try dragging and dropping this string below onto the gh canvas.
{4661c381-1c36-4099-90f2-0d5cf0d30db3}
The trouble with rhino meshing is that polysurface edges can only have two adjacent faces, so getting coincident nodes along shared "edges" of surfaces is near impossible.
I do have some routines for "meshing" surfaces with simple geometry (ie 3 or 4 edged faces). This takes a distance setting and forces vertex spacing to respect this along edges, so tied interfaces wouldn't be necessary. If this is of interest, I'll see if I can provide it (or have done so) for the plugin. Let me know deadline/time frames you have for using this.
Look forward to hearing from you,
Jon…
he installation folder, Drag & drop SYNTACTIC(green one) over your grasshopper canvas.3. Close your rhino and reopen it. 4. Type GrasshopperDeveloperSettings5. Tick the Memory load *.GHA assemblies using COFF byte arrays option6. Run grasshopper and enjoy plugin…
ns. but first allow me to explain what i'm trying to do: i have a serial device i want to talk to, but i have to do it using some sort of handshaking. for instance, when i send a command/data, i need to wait for an appropriate response before sending another. i have used andy payne's general serial components from firefly, but i don't think they'll work for what i want to do, and in general, i want to know how to do this from scratch. i'm using the pyserial library to do the comm, and i can get it to work within one script. here's an example of a working (mostly) port open/close script (x=input param for baud, y=input param for port name, z=boolean input param for open/close):
import serialmyPort=serial.Serial()myPort.baudrate = xmyPort.port = yif z == True: try: myPort.open() except: print "Something went wrong. Cannot open port." if myPort.isOpen() == True: print myPort.name + " is open" if z != True: try: myPort.close() except: print "Something went wrong. Cannot close port." if myPort.isOpen != True: print myPort.name + " is closed"
this all works well and good. here are my questions:
1) I can open the port and then close it. however, if i try to re-open it, i get an access denied error. it seems rhino is holding the port open, as i have to re-start rhino to get it working again. i read through the discussions and didn't see any definitive answers to this problem. any advice?
2) I'd like to share this port with other components (or at least break up the functions of opening/closing the port and read/write, not unlike how the firefly components are organized), but i have no idea how to share an object instance between components. i did see that there is a sticky dict and tried to add myPort to it, but i kept getting errors in the other component when i try to use the object's methods. for instance:
Component 1 Script:
import serial
import scriptcontext
myPort=serial.Serial("COM4", 9600)
scriptcontext.sticky['myPort']=myPort
Component 2 Script:
import serial
import scriptcontext
myPort=scriptcontext.sticky['myPort']
print myPort.read()
but i get messages like:
Runtime error (MissingMemberException): 'Serial' object has no attribute '_port_handle'
any assistance would be greatly appreciated!!
best,
~BB~…
.
Today we have gone live, and the plugin is available on Food4Rhino. You will find an installer package, sample files, and a demo video on getting started:
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo and poke around in the code:
https://bitbucket.org/andheum/humanui
Check out today's coverage in Architect Magazine:
http://www.architectmagazine.com/technology/nbbj-releases-human-ui-to-bring-parametric-modeling-to-the-masses_o
Finally join our group and ask any questions or post any comments here:
http://www.grasshopper3d.com/group/human-ui
See below for detailed description!
----------------------------------
Human UI
Primary Development by:
Lead Developer: Andrew Heumann / andheum / @andrewheumann
Product Manager: Marc Syp / marcsyp / @mpsyp
Contributing Developer: Nate Holland / nateholland / @_NateHolland
Gone are the days of faking a user interface by laying out sliders and text panels and hiding wires on the Grasshopper canvas. Human UI interfaces are entirely separate from the Grasshopper canvas and leverage the power of Windows Presentation Foundation (WPF), a graphical subsystem for rendering user interfaces in the Windows environment.
OLD NEW
In other words: Human UI makes your GH definition feel like a Windows app. Create tabbed views, dynamic sliders, pulldown menus, checkboxes, and even 3D viewports and web browsers that look great and make sense to anyone--including designers and clients with no understanding of Grasshopper.
Human UI has been in development at NBBJ for over a year, as part of a larger NBBJ Design Computation initiative to deliver our tools internally as Products -- with fully automated installation, managed dependencies, analytics, documentation, and “magical” user experience. Human UI has been a huge component of the user experience part of this puzzle, and we are excited to share it with the larger Grasshopper community so that others can benefit from it and contribute to its development.
The initial release of Human UI is accompanied by a few simple examples to get you started, but we have developed sophisticated user interfaces with these tools at NBBJ and will slowly be rolling out more advanced examples. We also look forward to opening up the development to the community and seeing what new features and paradigms we can add.
Download the plugin at Food4Rhino and get started building Custom UIs for Grasshopper right away! We are happy to answer any questions or field discussion in the dedicated Grasshopper Group. Please join us!
Join the Grasshopper Group
http://www.grasshopper3d.com/group/human-ui
Download the plugin + sample files
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo
https://bitbucket.org/andheum/humanui
We look forward to seeing where this project takes you, please share your projects made with Human UI!
Sincerely,
Design Computation Leadership Team, NBBJ
…
evel] are required. No specific Processing skills are required (although an introductory knowledge of programming logic is welcome). Participants should bring their own laptop with pre-installed software (software download links will be given after subscription).
[.]Tutors:
Alessio Erioli + Andrea Graziano + Alessandro Zomparelli – Co-de-iT.
[.] Brief
The workshop explores the manifold relations of creativity and control in computational design. The availability of increasingly complex and sophisticated tools shifts how control and sensibility are exerted and deployed within the design process. A new computational craft is required, one that allows the embedding in computational simulation of matter and agency so that ideas propagate in a deeper ecology with degrees of autonomy that provide complex feedbacks. Objects and systems are not anymore simple assemblages of static parts but are generated from the interrelations of other complex objects within ecologies. The designer is not just merely using tools rather establishing a loop dialogue with their creative and autonomous possibilities: questioning their capacity and extension, evaluating and empathizing with the result that in turn allow configuring and being configured by them continuously.
We will explore matter and agency behaviors through Grasshopper (with Millipede plugin) and Processing, interrogating the aesthetic potential of Topology Optimization and Multi-Agent Systems.
more info here:
http://www.co-de-it.com/wordpress/ctrl-shift-grasshopper-processing-workshop-vienna.html…
picture:
... and on a PC without anything attached to the serial port. When you open the port, start the read component and its timer, do you then get a stream of <empty> values in the log output? (hmmm... I suppose that's only reasonable - but still, you are also seeing this?)
I suppose that, because of the mutually exclusive behavior of both the spider and grasshopper (i.e. only one at a time can access the COM port), we can deduce that we are listening on the correct port.
Am I listening on the correct pin (if such a notion makes sense at all)? If I look back to the spider software, I see that 9 channels are listed and that it's only the measured value on channel 0 that changes when I press the load cell. Channels 1, 2, and 3 report OVERFLOW; 4, 5, 6, and 7 are pretty much constant at 0.000 to 0.005 V; and channel 8 says FFFF. I do not know how things like that work so I do not know if they reflect reading from the 9 pins on the D-sub 9 connector.
As for your BTW question: no, I don't need to record all of the sensor values. I suppose that the Out value on the Read component will always reflect the most current value and that's all that I need to get on with life. In the end, the idea is that we have 4 load cells in the 4 corners of a plate onto which a vertical pipe is fixed. Loads are then put on the top end of the pipe and we'll have to visualize both direction and magnitude of the bending moment that is calculated from the compression - tension readings from the load cells... We've done this on a scaled model and streamed load cell information into MatLab. Now we'll have to use a different datalogger and I was hoping to be able to do the post processing in Rhino.
wim…
new components, and the Firefly Firmata has changed since the 1.003 version. However, the problem still exists in that there is not a super smooth workflow for integrating Steppers with Firefly (yet)... but it's not impossible. There is a post on the Firefly website that has some instructions on how to drive a stepper motor using the Generic Serial Write component and the Easy Stepper Driver. You can find a link here for more information: http://www.fireflyexperiments.com/discussions/post/1438445
It's quite possible that if you already have a sketch that is working using a set Arduino variable (say 100, which makes the servo move to 180 degrees) that you're very close to getting it to work with Firefly. You'll want to use the Generic Serial Write component (instead of the Uno Write component... as the Uno Write component has been setup specifically for use with the Firefly Firmata... and you'll be using you're custom script). You'll likely need to modify your Arduino script in some small way to read in the serial information being sent over from Grasshopper. Basically, in Grasshopper, you'll first need to open the port (using the Open/Close Port component). Make sure the baud rate matches the speed that you use in your Arduino sketch (and that the port number matches your board number). Then, on the Generic Write component, you'll set the port number (same as the COM number in the Open/Close Port component) and set the start input to True. Then, all you need to do is connect some data to send over the serial port... If you wanted to send a numeric value (like 100), then just connect an integer slider. As I said, you need to modify your Arduino code so that it knows how to read in the data from Grasshopper and then what to do with that data. Without seeing you're code, it's hard to tell you exactly how to do this... But, perhaps if you upload a file (or send us a file at info[at]fireflyexperiments.com) then we can help you get your file modified so it will work. Once that's done, it should be really straight forward to drive a stepper through Firefly.
HTH,
Andy
PS, integrating steppers into the Firefly firmata is on my wishlist of things to implement into Firefly very soon. Thank you again for bringing it up.…