Grasshopper

algorithmic modeling for Rhino

Hi,

I am unfamiliar with C# but am trying to script a component that uses commands from a non-rhino library. The library is from a analysis program called STRAND7. Until I have linked the library I cannot use the commands I need to activate the program remotely (via its API). The library is a .cs file and I believe I am just suppose to "add" it to the component. This has proven difficult via " manage assemblies" since I keep getting an error code saying it was unable to load it.

Am I missing something? I have tried copying over the file and placing it in the "additional code" area but I end up getting a heap of error messages that way too. 

Thank you so much!

Ken

Views: 5589

Attachments:

Replies to This Discussion

Hi Andre,

We have managed to get the API to work in two similar but different ways:

(1) We created a meshing component using the Strand7 mesher. This is written in the C# component in GH and passes parameters to an exe that we wrote seperately in visual studio.

(2) We created a general API component which was entirely written in visual studio as a custom component (i.e. not using the C# script editor in GH). This accepts text/a string which represents any C# code and compiles the code and runs it on the fly. This way we can write any code we want in GH and ask this component to run it. The code we give it is generated by a number of different clusters etc. so that we can easily create geometry, add loads, restraints etc.

The key to getting it working in 64bit Rhino is that the code does not run in Rhino, the process is run outside. One quick and dirty way of passing information would be to write .txt files in the temp folder and run the exe which will then pick up and read the .txt file.

Kenneth and Sam,

Many thanks for your reply. That sounds like a good workaround to run the API in Rhino 64-bit.

I've been changing my Python code to new C# components coded in Visual Studio. I was hoping that that would improve stability, but Rhino still crashes. I have error handler calls and write a log file to keep track of the process. I've narrowed it down to a few functions. "St7CleanGeometry" seems to be particularly problematic. When I perform the same operations with the same parameters in the Strand7 GUI it runs with no problems, so I'm still pretty clueless of whats causing this.

Anyway, thanks for your help!

Best,

Andre

Looking into the .dmp file I found a lot of "Out of memory" errors. I guess that Rhino 64-bit is the way to go.

How did you pass variables (int, doubles and arrays) to your external process? Writing them in text files?

Hi Andre, 

Regarding the automesher way ie (an exe using the same commands) I sent my variables to the exe as arguments ie an array of strings. See this tutorial (https://www.dotnetperls.com/process).

See attached screenshots of C# code. 

Fig1 - Create single array of strings from other primitive datatypes and converting. (Code in GH)

Fig2 - Running the process.start method to run the external process. note the "myprocess.StartInfo.Arguments = args;" command is where the sting array is sent. (Code in GH) 

Fig3 - Code showing the conversion of the string array back into the original arrays of primitive datatypes. (Code in external process).

As I said previous, the automesher was always the same commands so this process worked for int, double etc, otherwise I believe Sam said that one way was to write/read .txt files. 

Hope this helps.

Ken

Attachments:

Ken and Sam,

Many thanks for your help. Just a (late) update; I got in touch with Strand7 and they recommended the new R3 Preview, which works with a new 64-bit architecture and has now a built-in graphics engine. I've been testing the API in Rhino 64-bit and everything is running smoothly so far.

Again, thanks for your help!

Kind regards,

Andre

Hi Andre,
It seems like you've got the Strand7 API link working but are having problems using the API. I would have to look at a bit of code to offer any help. Alternatively the guys at Strand7 are very helpful.
I remember having problems with memory because a new array was being created each time I created a node, you very quickly run out of memory this way. If this is the issue try to use the same array variables.
Also it's worth noting that the API always runs as 32 bit. So calling the exe from 64 bit rhino won't help memory problems.

Hi All, 

I'm also using the Strand7 API but I am yet to reach your lofty achievements.

I have a C# component example, which was shown to be working on another system, but it doesn't work on mine. It returns the error "An attempt was made to load a program with an incorrect format"

I've attached my file

The st7api.dll is referenced using the managed assemblies method but fails to load - it is unblocked

Any pointers would be great!

Thank you

Attachments:

Two points:

(1) Make sure that you use 32-bit Rhino when using the Strand7 API inside a C# component. The Strand7 API does not work with 64-bit programs, this is true of Excel VBA as well for example.

(2) You do not need to reference the dll. By using the code you copied into the "<costum additional code>" region the dll is loaded via the command "[DllImport("St7API.dll")]". However this means that you will need to reference the path of the dll in your environmental variables. (found in control panel - advanced system settings - environmental variables - path, at least on my computer)

Hope that helps.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service