ur setup. Can you say what sensor you are using? Are you using an Arduino to write this ascii information to the serial port? If so, there may be some formatting code for the string that you'll need to do to get the Read component to function properly. I see that you were able to open the port and Start reading... so my first thought is that the data is formatted correctly....
All of the read components look for a specific character (in this case two characters) to indicate when it has reached the end of the line being read and should spit out the data. In this case, Firefly uses the Carriage Return (\r) and Line Feed (\n) to know when it has reached the end of the line. In arduino, these are automatically added to any line if you use the Serial.println("blah, blah, blah"); command. Notice, this is different from the Serial.print("nothing to see here"); command. This doesn't mean that you can't still use the regular print command... it's just you need to use the println command to indicate when you've reached the end of the line. Let's take a look at a simple example.
void setup() { Serial.begin(9600);}void loop() { int sensorValue = analogRead(A0); Serial.print("The value of the sensor is: "); Serial.println(sensorValue);
delay(20); // important to wait some small time so you aren't sending just a ton of info over to GH which will cause it to crash :(
}
The first print statement prints a string to the serial port... and the next one adds the current sensor value... and THEN adds the carriage return and line feed to start a new line. The nice thing about using these together is that you can concatenate any type of data you want. If you were to upload this sketch, you should see a sentence being printed to the serial port that says "The value of the sensor is: 512". I made up the number, but you get the idea. Notice, I also had to include a delay function. You don't always need this (there are other ways to go about this) but the important thing to note is that the loop cycle on the Arduino can run really fast. I mean... really fast. So, you wont want to send so much data over to GH, because this could flood the string buffer in the Read component and cause it to crash (eventually). It's a good idea to add some small time interval just to slow it down a bit. I should say that I've optimized the refresh rate in the next release so it's significantly faster... so hopefully this wont be as big of a problem... but hopefully that helps some.
Now... Why are you writing data to a sensor? Sensors by default are considered inputs... so I'm quite confused as to why you would want to send data back (if you are... then you need some way to handle the string data being sent from GH... this is the whole reason we built the Firefly firmata... it sets up the two-way protocol so you don't have to deal with all of that mess... If you're going to read and write, you're better off just uploading the firmata and using the Uno Read and Write components). Also, I'm not very familiar with the Hyperterm or Advanced Serial Port Terminal... but I will say that could get COM conflicts if you're trying to open the port with different tools. Anyway, I hope some of this helps you get up and running.
Cheers,
Andy
…
phere with the maximum number of triangles but not much than a defined threshold.
I scaled that mesh just to fit Rhino grid, but it is not mandatory. What is useful, is to scale not uniformly the mesh (Scale NU). It could be done after cellular modifier applied or before or before and after. The 3 options are possible in the script. If you don’t need them just put 1 in scale sliders.
Ellipsoid mesh is the populated with points, I put 2 independents populations to randomize a bit further. For each vertices of the mesh the closest distance from the populated points is calculated.
Here is an illustration in color of this distance.
This distance is then used to calculate a bump. If domain for bump is beginning with negatives values to 0, it carves the mesh. Instead it bumps/inflates it.
Some images to illustrate the difference with populating 100 points with one or two populations.
Here some images to illustrate the application of scale before carving or after.
Next phase apply noise. At the moment I don't find it good.…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
uired information, a poor representation of data evolve misreading messages and by turn ambiguous responses especially with complex data. Inforgraphics are graphic visual representations of information, data or knowledge intended to present complex information quickly and clearly. In the nowadays flow of complex information, Infographics is the key for optimized visual communication. The use of infographics is an important step towards developing a pedagogical approach that draws on visuals where 90% of Information is transmitted to the brain so it is crucial to tickle the optic nerves to get people excited about data. The workshop investigates how computational tools can aid in designing and controlling complex information to be easily understood in addition to improve cognition by utilizing graphics to enhance the human visual system’s ability to see patterns and trends and much more likely to be remembered in today’s fast – paced environment. This workshop investigates multiple computational tools and techniques of developing coefficient visualization of data types including; network, statistical and hierarchal data. The workshop objective is to reconsider visual representation a promising design tool for architects, artists and designers. /// Application To apply, please follow this link to fill the application form https://docs.google.com/forms/d/1HOv6c1_LzhHNJU5n_FLvuhC-Yg75HDfbEcq6TN6mulI/viewform /// Fees 1200 EGP for students / 1500 EGP for graduates and young professionals more info on the workshop webpage: http://www.encodestudio.net/#!infographics/cqvl
POSTS
…
ike using something like the Z vector, but technically you can use any vector you want. This vector will actually determine the static rotatation of all the planes, so you can control that here if you like. One important thing that I've noticed is that the closer the vector is to the plane of the curve or if its too similar to one of the tangent vectors, the more likely you'll have "flipping"
2) Take the cross product between the tangent and the static vector. This will be your first perpendicular vector, which you can use for the X component of the plane.
3) Take the cross product between the tangent and the result of the previous cross product. Use this result as the Y component of the plane. All three components (X, Y, and Z (which is the tangent vector)) are all perpendicular to each other now.
After you've done that you should have planes that decrease twisting. If your curve is not planar, then there will always be some twisting in the frames, but it will be minimal enough to use them effectively.
There also may be "flipping" within the frames, which means one (or both) of two things. First, you could have planes that have reversed their vectors, so the X vector is properly oriented, but pointing down when it should be pointing up. Second, the X and Y vectors could have potentially swapped, so that Y "should" be X and X "should" be Y. In order to check these things, you'll need to do a few tests. The first one is find out whether the vector (X or Y) of the plane your testing is pointing in the opposite direction of previous vector. The second test is to find out whether the vector (X or Y) of the plane your testing is perpendicular to the previous vector. In both cases, an angle test between the two vectors will be able to tell you what you need to know, but you will likely NEVER get exactly 180 for an opposite test or 90 for a perpendicular test. That means that you have to choose a range with which to determine that a given vector is opposite or perpendicular.
You should start testing the X vector to see if anything is wrong. If you find that the X vector is fine, then just move on because Rhino will only allow you to create right handed planes, and the Z vector (the tangent) will always be the same.
I don't believe that there's a native function within the old dotNET SDK for calculating angles, so use the example at the link below. It basically takes the arcCosine of the Dot Product of the two vectors your testing to return the angle in Radians. I'm not sure if this function is included in RhinoCommon or not....
http://wiki.mcneel.com/developer/sdksamples/anglebetweenvectors…
ed when membrane cones are invited to the party (then mesh (via Starling is the best way) the brep and send data to Kangaroo : the easiest thing to do). But patch doesn't trim the inner Loops and ... well initially I thought to find this in SDK and do the job:
Well... I confess that I can't get the gist of the Brep.Trim (as explained in SDK).
Thus go to plan B: having already the closed breps (the "cones") as cutters ... attempt a Boolean difference
but this does that (this looks to me a bit paranoid, but some reason must exist):
What I want is this:
the code that mess things is (open the script inside definition attached):
BTW: where in SDK is that DeBrep thing?
BTW: Delaunay GH syntax is still cryptic to me (but this is not an issue anymore)
I would greatly appreciate any help on that final step (to greatness).
The full working definition soon (v5: with 90% of components replaced by C# stuff).
best, Peter
…
bout angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.
Rotating the entire pair in space has no effect.
Rescaling the lines from their joint point has no effect.
Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."
Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.
Running the "line-like curves" through a Line component to give "lines" doesn't fix it.
Re-creating the lines by extracting endpoints fails to fix it.
Each line, if separated from each other works fine.
Grafting makes each line into its own little cylinder minus a hub.
The error is the boilerplate "Object reference not set to an instance of an object."
Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.
CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.
Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton
Source code is here but it's for compiling, not something I can just test in a C# component out of the box:
https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...
…
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…