A quick query about LV functionality

[Corelab]

Given this vi that controls a motor based on some sensor data, I have some logic that determines the next motor state (based on the previous state & some sensor input). Furthermore, I need to test/evaluate different logical methods to determine the best motor/sensor approach for our application. This currently leads me to the practice using nodes/wires to encapsulate the state logic into a subVi, then trying the sub in the larger test vi.

My question is, can I compose the logic in C and make this usable (by some means) to the test vi, instead of wiring the logic into subVIs? Since the logic can be distilled to primitive data types, it seems like it would be much faster to type the transition function into C than it would be to encode it into a subVi w/wires & nodes.

Am I making any sense here? I've been using LV for about four weeks now. I'm wondering if there is a method of "compiling" a function written in C into a node that can be placed into a vi. Thanks in advance for you help.

[johntrich1971]

You could certainly compile a dll in C that you could call from LabVIEW. There may be other approaches of which I am not aware. However, that seems like a lot of trouble to me. You're still going to have to connect the inputs and outputs of the dll in LabVIEW. Perhaps if you shared your code there might be a better way to do what you want to do.

[billko]

Hmmm, I don't think performance is going to be an issue here.  The bottleneck in your code is not likely to be the logic that determines the next state.

[Yamaeda]

Yes, you can compile a C program as a DLL and use the Call Library node to use it, though i would assume the overhead of calling a DLL is a lot higher than simply using the basic datatypes in LV (LV is quite efficient). It can be a good experience to do and compare both, though.

This looks like a case of "When all you have is a hammer, everything looks like a nail." 🙂

/Y

[rolfk]

The DLL calling overhead is not the problem but the development and maintenance of such a devided solution certainly will be. Putting code into an external DLL just for the sake of it is ALWAYS going to give you a more complex and much harder to debug solution. => Absolutely not worth the trouble.

Learn to use LabVIEW correctly and do it all in LabVIEW or do it all in C but do not mix such things just because of a presumed performance gain.

There isn't, LabVIEW code is not fundamentally slower than C code but you can make in LabVIEW much easier software that works but is programmed awfully than in C. In C if you program awfully you are very likely that the software simply crashes and never will produce anything, in LabVIEW it's surprisingly easy to program bad code and still get a somewhat working solution. Applying the same level of good software knowledge in a LabVIEW program will however lead to a just as performant solution as when doing the same in LabVIEW. The only problem for some people is to understand the difference of data flow programming in LabVIEW and sequential programming in C.

[johntrich1971]

Maybe I misunderstood the OP. I thought that he had several options for algorithms that he wanted to test to determine which approach gives the best results. To do this he has encapsulated this piece of code into a subvi which he is recreating each time. He finds this creation of a new subvi to be tedious and feels that he could more efficiently write these pieces of code in C and call it in LabVIEW. I think that this is a bad idea and suspect that with a little more information he could receive guidance to make his process less tedious. I did not get that he thought he would get a performance gain by using C.

[Corelab]

jophntrich1971,

Yes, your comments reflect the matter of the question I was originally asking. We're attempting to apply certain sensor/actuator devices in a somewhat novel way. We need to try several algorithms, through numerous variations, to decide what's actually possible and what's the actual achievable performance.

I've don't have any significant problems implementing state machines or parallel loop interoperation in LV (at this time). My original interest was in whether or not I could write the state transition functions (the things we're testing) in C and have them available as nodes in the LV pallet. From the comments, it looks like I can, but with no gain in productivity. If it was productive to encode some things in C, somebody would have mentioned it by now. Also, the many comments about poor performance in doing such was helpful in the deciding, but not technically the answer to the question (my error in the wording).

[cbutcher]

I hate myself for mentioning this, but have you considered the MathScript node? Does that give you what you need?

I really don't suggest it in general, but it might be relevant here.