Trying to Add library to C# component

Replies to This Discussion

Permalink Reply by Sam Gregson on June 29, 2017 at 3:42am

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.

Permalink Reply by Andre on July 4, 2017 at 6:17pm

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

Permalink Reply by Andre on July 4, 2017 at 7:39pm

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?

Permalink Reply by Kenneth Allan on July 5, 2017 at 4:24am

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:

• Fig1_Create String Array.JPG, 56 KB
• Fig2_RunExernalAutomesher.JPG, 69 KB
• Fig3_ReconvertToArraysOfOriginalDatatypes.JPG, 106 KB

Permalink Reply by Andre on July 23, 2017 at 10:31pm

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

Permalink Reply by Sam Gregson on July 5, 2017 at 12:01pm

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.

Permalink Reply by Sam Gregson on July 5, 2017 at 12:04pm

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.

Permalink Reply by Jack Hawker on December 14, 2017 at 2:59am

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:

• panostest.gh, 43 KB

Permalink Reply by Sam Gregson on December 14, 2017 at 3:31am

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.

• ‹ Previous
• 1
• 2
• Next ›
• Page