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…
bounding box wont work because it will seldom be square shaped. this square bounding surface should always be larger than the open or closed curve
2. dividing the curve into then testing its closest point to the center of the bounding sqaure plane.
3. creating rectangles with the same size as the divisions of the bounding plane.
this works perfectly, but there is one last problem that needs attention.
it generates the same amount of closest points than what is specified for the curve divide. e.g. the curve can be closed for instance with 35 squares , but the curve was divided into let say 50 points. the curve will be closed with the 35 squares but there are an additional 15 squares ontop of the 35 squares.
SO if someone can tell us how to remove duplicate data from a list of points(the points with the same coordinates), then the final solution will have no duplicate data.
the duplicate data can be seen in the second image
Gordon
…
and demonstration of the component
3. Example
This way if people just want a description of the component they can stop watching before the example section.
For this video I explained the example I made at the end. So maybe that is a waste of time? Maybe it is better if I show an example and then post pictures of the components. That might be easier for people to build it themselves and get a deeper understanding.
I agree that it is best if there is only one idea covered per video and I will try to do that in the future.
I think that the winform with a fragmented video tutorial is a good idea but for me right now would be too hard to setup.
I think my videos will have to be within the 6-8 minute range, but I will try and we can see what will happen. (I originally had another example in the video above but it made the video 15 min and I thought that was way too long).
Thanks.
Shout out to NARUTO. Its been awhile. Hello.…
Added by Jake Hebbert at 8:06pm on November 19, 2015
nderstand each other quite well.
I will pick one piece of the PVsurface at the bottom row:
So the label "1" represents the PVsurface for which the shading diagram will be created.
Label "2" is the back facade (made of glass or opaque elements, does not matter).Label "3" represents the row of PVsurfaces above.
Now take a look at how the shading diagram would look like for the mentioned PVsurface. I made some of its parts a bit incorrect on purpose, so that I could clearly the differences a bit easier:
Label "1" would be first type of self-shading. It's the shading which prevents the PVsurface to "see" anything behind its back.Label "2" would be shading from the facade wall to which the PV surfaces are attached to. I deliberately colored it blue, to distinguish it from other two types of the shading. Otherwise it would look black.Label "3" is the second type of self-shading: the shading from the above row of PV surfaces.In literature, you won't find the terms: first and second type of self-shading. I invented them.To my knowledge, when self-shading is mention, this will probably be related with label "3" (second type of self-shading). It's the shading from the adjacent rows of PV modules in front, or like in this case above.So when I said:
You do not have to supply the surfaces additionally to the context_ input. The component will "under the hood" add them to the context_ input to account for self shading. Last year this hasn't been the case, but after the suggestion by Chris Mackey, I changed this feature.
This was related to the first type of self shading (label "1").
And when I said:
However, as we are using the PV SWH System size component, there will be no self-shading. The PV SWH System size component positions the PV rows in such a way, that no self shading will appear for the given minimalSpacingPeriod_ criteria.
This was related to the second type of self shading (label "3").
I should also mention that I made the upper photo a bit incorrect. If you would do the shading analysis, the label "3" would be almost non-existent. Here is how the shading diagram would actually look like:
As mentioned this is because PV SWH System size component will position each PVsurface row in such a way, so that there would be no second type of self shading for the chosen minimalSpacingPeriod_ criteria. In our case, as the minimalSpacingPeriod_ criteria we chose the summer solstice in the Northern Hemisphere from 10 to 14 hours. We should have taken from 9 to 15, but we took from 10 to 14 to as on option of lowering the distance between the PV rows.This means that there will be no second type self-shading all year round from 10 to 14 hours.
Let me know if all of this helps in any way.…
ld work.
For example there's a grid shell and I've got a number of control points (for example 3) that can move up and down.
Depending on the control points I get forms that are structurally good and some that are bad.
In my office we've got a GH-Component, which leads the geometry in structural members and solves the structural forces and so on through an external Software called Sofistik and afterwards gives back to GH some Values, for example maximum bending moments. (Like Karamba)
Now I want to create this optimization component or something like that to minimize e.g. the bending moments in the given geometry.
Let's start with the work of the component.
So when I've three control points that can only move in z-direction.
P1(0,0,Z1), P2(10,0,Z2), P3(5,5,Z3)
They only depend on Z, so everything depends on Z1 to Z3 which have a range between 0 and 10 f.e.
First I want to get some (between 9 and 15) random Particles, one particle consists of this 3 different Z's.
So for example the first particle Part1 is [Z1=10, Z2=5, Z3=7]
and the second particle Part2 is [Z1=7, Z2=1, Z3=9]
and so on.
I created these Start Particles in a Cluster. See attached file.
I also tried this in C#, but thought it is easier in GH.
After I've got the Start Particles I want to give out the first particle and evaluate with its including Z's the target value in GH. Therefore I had to take the first branch and graft this branch (Discussion before)
Afterwards I want to save this Target Value that depends on the first starting Particle. Then I want to give out the second starting Particle to evaluate its target Value and store it. And so on till the last target Value of the last Starting Particle got assigned.
Then I want to assign the particles with its target values. E.g. part1: t=0.9, part2: t=1.8...
Then I want to define neighborhoods or the count of the expected local minima.
These neighborhoods can look like: Each neighborhood has to include not less than 3 particles. And the particles have to be next to each other.
E.g. if there are 12 particles and I want to have a look for 3 local minima, I need 3 or 4 neighborhoods. Then I would take 3 neighborhoods, because the more particles in one neighborhood, the better.
So the Count of the neighborhoods would be N=min{(Count of Part/3)& N_min}
How to define these neighborhoods I don't know at the moment. I think it has to be searched for the distance between the particles. E.g. part1 with (9,9,9) and part2 with (9,9,8) are next to each other but part 3 with(1,1,2) is far away.
Then each StartParticle is set to Partx_localbest.
And in each Neighbourhood the best of these localbeststs is Part_NyBest. (The best ist the one with the smallest target Value)
Loop:
Now I want to create new Particles. These Particles don't change their Z-values randomly. They change their Z-Values depending on Part_NxBest and Part_localBest. Therefore it has to be evaluated a new velocityfactor with v_Partx_new=0,792*v_PartxOld+1,5*random(0,1)*(partx_localbest-partx)+1,5*random(0,1)*(part_NyBest-partx)
The new particles will then be partx_new=partx+v_Partx_new.
The new Particle partx_new will be set to partx and then set in the output.
then there has to be caught the targetValue of part1 afterwards part2 can be put out and its target value caught and so on.
Then it has to be looked for the Partx_localbest through comparing the partx_localbest and its target value with the new part_x and its target value. If the target value of the new partx is smaller than partx_localbest,
then partx_localbest is the new partx.
This has to be done for each partx. Afterwards the same for neighborhoods best (best of all partx_localbest in one neighborhood)
Endloop if velocity gets small.
Output all part_NxBest
Output all targetvalues of the part_NxBests.
So in the Input there have to be:
StartParticles if they are given through the cluster attached.
Device on the target Value like in the attached gh.file from David Rutten I found in the discussions
Count of neighborhoods
And in the output
Output particle for evaluation
Output all part_NxBest
Output all targetvalues of the part_NxBests
Hope didn’t forget anything. And hope it isn’t crushed to badly. Sorry for my bad English by the way ;-)
For more explanation, how the PSO works in other programs. There’s attached a workflow script (is it called like that?) I think for GH it should be a little bit changed like I tried in my explanations.
So if you can help me a in some parts or you have any advices would be great, otherwise thank you nevertheless!!!!
Thankfully there’s no limit for the words in the discussions :-D
Best, Heiko
…
te one of the boxes (kind of). Now I'm trying to set up the pattern, but I would like it to be random. I'm having trouble coming up with the actual algorithm, though.
I'm able to generate a list of items, randomly select some of them, and rotate them. I can also select the item after a rotated one and move it to the right.
However, I'm having trouble selecting all of the items after an item that's been rotated, and moving all of them.
Let's say I have a list of 15 elements and numbers 3, 6, and 7 are rotated. I would need to move numbers 4 through 14 (since it starts at 0) to the right by an x amount; numbers 7 through 14 to the right by a 2x amount; and numbers 8 through 14 by a 3x amount.
How should I go about doing this?
I'll add my current non-working setup. I should note that since I'm new, it probably looks horribly disorganized. Sorry about that.
Thanks!…
ison, construct a 15' long plywood bench for Mark Weston's Digital Fabrication Studio, Spring 2013.
Rhino and Grasshopper were used to design the bench parametrically in 3D. The model was then contoured in the computer to generate 129 sections. Each section was cut out using a 3 Axis CNC Router. 520 spacers separate each contour by 3/4" to make the bench's total length. 3/8" all-thread rod runs through each segment of the bench. When tightened, the rods put the plywood pieces in compression, holding each section together without glue.
We estimate apprx. 200 man-hours went into this project over the course of less than a week. The project contains 129 contour pieces, 520 spacers, roughly 120 feet of threaded rod, 40 nuts, 40 flat washers, 40 lock washers, and 2.5 gallons of waterproof sealer.…
geode. The faceting system also references the original use of triangulation for mapping three dimensional landscapes.
My question responds to the need to control the edges lengths and angles within the triangles to make the process of construction possible. We are hoping to keep the edges under 28 inches and the minimum angle more than 15 degrees. What would be your suggestion in grasshopper?
Our process for getting the facet was also... the long way.
1. draw curves based on three dimension measurements of interior
2. networks surface the four curves
3. mesh surface
4. triangulate mesh
5. reduce polygons
6. splitmeshedge where necessary to make quadrilaterals triangles once more
Any suggestions?…
Added by Amanda Gann at 8:57pm on December 4, 2013
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
main attention is set on easy to handle interface , which should be used at a early stage of conceptual design to respond to external and internal influences in a intelligent and sustainable way.
Participants will use the software Grasshopper as a parametric modeling plug-in for Rhino. The usage of this graphical algorithm editor tightly integrated with Rhino’s 3-D modeling tools open up the possibility to construct highly parametrical complex models. To generate this complexity we will use live linkages to several programs listed below:
• Autodesk Ecotect Analysis and Radiance via GECO
• Processing, Excel or Open Office via gHowl
• FEA software GSA via SSI
In this 3 intense days, the participants should learn the workflow of the plug-ins with the help of examples and get an overview of the different software’s, there possibilities for evaluating the performance of a design or the usage of additional tools to be not chained to a single system .
(e.g. parametrical accentuation, parametrical formation, parametrical reaction)
TIME AND LOCATION
27th – 29th September 2010Leopold-Franzens university innsbruck/austria
Technik Campus | ICT - building
Technikerstraße 21a
A - 6020 Innsbruck | Austria
47°15’50.71”N 11°20’43.45”E
detailed program as pdf-version
FOR WHOM
All levels are welcome (students & professionals)
The only requirement is knowledge of Rhino and Basic Grasshopper.
You will need a level which corresponds to the Grasshopper Primer course outline.
FEES
21 hours
professionals: 395€
students (bachelor/master): 250€.
REGISTRATION
please send a email to to.from.uto@gmail.com attached with following information :
Last Name
First Name
Date of Birth
Nationality
Email Address
Current Address
Profession or proof of student status
After submitting you will receive an email with a PayPal link to complete registration.…