[02/03] Program Size Complications Question

Guys,

I've been working on a program for a while that uses a DLL to communicate with a controller of actuators. One section of the program commands a number of them to move based on some calculations. I initially built a test program containing nothing but the required function and then added it into what will eventually be my complete program. The small test program works fine, but the larger program doesn't work at all. I've had a lot of luck asking people on this board questions and was wondering if anyone has had issues like this concerning the size of their programs, or if there are any other suggestions as to what it could be.

To give a little more detail. There are 3 functions in this section. The first pulls data from a form, two input angles. These are both then sent into a model which uses them to calculate how much the motors will move and then sends those calculations back to the first function. The first function then redirects the calculations to a third function which actually contains the movement method. The test program contains only this information and works.

I checked the values in the larger program when they come back from the model and once they are sent into the function which contains the movement method. I checked them in both places and they are fine and this is why I'm concerned that it is a size issue as the actual method is getting the correct values. Any information or experiences would be greatly appreciated. Thanks in advance.

Take care,
Pat

There is also this line in the manual about the dll that might help. This is talking about the lengths that are passed in to move the actuators. They're objects for what it's worth. "As a convenience to the caller, the safearray passed into this method will be destroyed before it returns. To keep this from happening, use safearraylock() on the passed in data before calling this method." Could it be destroying the information before it actually uses it?

Frankly, I think size is unlikely to be an issue, unless you have a specific reason to suspect it. Size in VB.NET is kind of a nebulous issue, as a search of this forum will show you. It isn't even all that easy to figure out the memory footprint of a .NET program, much less figure out reliable ways to reduce that footprint. It appears that MS simply ignored size as an issue, and I would say that you can, too, unless you are on a system that is VERY short on memory space.

The thing that is really puzzling is that this worked in a smaller version, and according to your debugging, you have determined that correct values are being sent to the movement function. This suggests that size and the larger program are not the issues.

Is there any OTHER difference between the smaller version that works, and the larger version that doesn't? I can imagine how calling conventions, or difference in variable size between different language versions could alter the behavior from one to the next, but either of those would require that there was some greater change rather than just taking working code and adding it to a larger project.

By the way, that sounds like an interesting project. I'm getting into robotics at the moment with the intent of testing some AI concepts I've been kicking around for the last few years.

Shaggy Hiker,

Thanks for the response. I'm puzzled too, I've put in my daily phone call to the hardware manufacturer, but they're going to call me back, not that they will have any sort of solution.

I'm going to play around with that safearraylock stuff and see if that somehow helps. The only difference between the code in the small one and the code in the larger one is where I connnect to the actual card. In the larger one I have seperate functions to do this while in the smaller I have it done in the main function. I'm going to be unhappy if this is the problem as I'm trying to keep everything as encapsulated as possible because I know my advisor will want changes to be made, and I'd like them to be as isolated as possible.

I also initially had trouble with it being an object. I want to do more research on that class and see if that is somehow getting mixed up when I send it through the different functions. I don't see how it could be the problem as I check the values on the line before and they are correct.

Robotics are an interesting field and seem to unify a number of very interesting topics (control, dynamics, programming, etc) and the sky is the limit, well if you're well funded it's the limit. Compared to other projects I have worked on this is very interesting. Although it's technically cadaveric and not robotic, it's along those lines I guess. Take care and thanks for the responses, today and yesterday.

Pat