Hi Mike, thanks for the reply.
I know how to communicate with the DLL method using the array of floats. The problem for which I created this topic is another, like I mentioned before: in 3D rad I have a script that calls a method from a DLL. Everything works till this point. Yet, if inside the DLL method I do only a small calculation and then pass the array of floats, it works, but, if, and this is my case, I do some complex calls, like opening a COM port, reading data from that port, closing the port, parsing the message and putting it in the array of floats, the call from 3D rad doesn't return any value.
This is why I am asking if 3D rad is built with some kind of timeouts when calling a DLL method or it waits until the method finishes and the returns the values? From what I have experimented, it seems that the first statement is true...that 3D rad has some timeouts. What I need to know is that, if these timeout exist, is there any way to find out their value? Or if they can be modified?

I am asking if 3D rad is built with some kind of timeouts when calling a DLL method or it waits until the method finishes and the returns the values?

sorry i didn't understand the question...

i cannot say for certain whether 3DRAD's dll interface logic has a built in timeout...  i don't have access to the code nor have i looked into disassembling the core code...

i would though, tend to think that there would be no logic reason for a timeout to be part of the  dll data transfer logic... i mean, why would such why it would be necessary to implement  a timeout...

i could be wrong though...

also... from what i remember (it's been a verrrrrry looooooooooooong time), data transfer through COM ports does have asynchronous timing considerations that must be dealt with...  but i would imagine that would be on the dll side logic...

anyway, as to your problem...

first... does your dll logic work as a standalone... if so, then it would tend to lend credence (though not absolutely), to your assumption... at least it would validate the dll... 

--Mike

I think that it may exist some kind of timeouts inside 3D Rad, for not blocking the script until a response from a DLL method that takes a lot time to complete.

another suggestion...
if 3DRAD isn't waiting for the data to be ready, why not have the dll return something like -9999 when the data is not ready...  and on the 3DRAD side, have the results ignored whenever it is -9999... 

you are going to have to set up a simple handshake logic between the dll and 3DRAD so that the dll is notified when 3DRAD is sending up a request for data, so that once there is valid data, it will be sent on the next request and then replaced with the not ready flag value...

if 3DRAD is "not blocking the script until a response from a DLL", then something like this should work...


--Mike