Tips and best practices for translating C into LabVIEW? SERIOUS newbie...

[tst]

tbob, telling a C programmer that control references are like pointers or that they point to a "variable" is a great disservice.

Control references point to a *control*, not a variable. As such, when you use the reference, you are going to the actual control and asking it "what's the value that you have now?". The control then gives you your own copy of that value (so it's NOT by-ref).

This is a) slow, b) not at all like using a pointer and c) not like using a variable, so it really isn't the kind of thing you tell someone coming from C if you expect them to do good stuff in LV.

promba, like the others said, you should ignore the whole references and local variable discussion and probably just use wires to transfer your data.

If you want, you can try looking at some of these tutorials, but I don't know if they'll help you.

P.S. One feature you're probably going to love is that LV does not restrict a function to having only one output. Any indicator which you link to in the connector pane becomes an output. This removes one of the use cases you have for pointers.

[promba]

tst, thanks for the insight.

I did about 2 hours of initial layout last night.  I laid out some case blocks and boolean comparison operators to set up the basic structure of the program.  But because of the intermixing of math operations and if-then logic in the original C code, I'm having trouble understanding how to pick when to use wires and when to use references.  It seems like I can either have dozens of references, or a maze of wires coming out of each variable.

It's clear I haven't learned enough yet--I found myself using references in a ton of places... reminds me of the old saying "If your only tool is a hammer, every problem looks like a nail".

I'll post up some screenshots later today to illustrate my questions.

Thanks!

[Ben]

As an ex-C coder I can realte to the challenge before you. While others are giving good suggestions that are direct and to the point, I would like to offer another method for you get an idea of what not to do.

Christian Altenbach started a thread in the BreakPoint devoted to "Rube Goldberg Code" found here.

I sugggest you browse through those posting since many of them were develped by C programmer trying to code in C but using a C frame of mind.

Don't worry about understanding what is wrong with every post, but do try to get an idea of some of the obvious mistakes.

Have fun!

Ben

[tst]

Maybe these tips will help you:

1. Under no circumstances should you use references (which actually means using the Value property). Try to erase that from your mind. It has its uses, which you can learn as you have more experience, but at the moment it will just hurt you.
2. Controls and indicators are NOT named variables. They can be used as such, but that is not their purpose. They should be used either for UI or to allow a function (subVI) to have inputs and outputs.
3. Remember that the basic data flow concept does not have variables at all. It only has values, so that's the term you should think in. When a wire is split, you get two separate values (although in practice, LV optimizes the execution order to avoid creating unnecessary allocations).
4. IMO, math operations are actually something that LV code does not necessarily make easy to read. As you've noticed, if you have a lot of math operations, you might get a mess of wires. Don't be afraid to either use the formula node or break down the mess by creating subVIs.
5. I don't know if the forumla node supports proper control elements. If it does, it might be benefical to use just that, as others have already suggested. You could also potentially create several nodes, each with its own section of the code.
6. Depending on the structure of your C program, you might be able to create a DLL to save time on having to rewrite the C code. This isn't necessarily good, becase then you would have something else to maintain.

[tbob]

---

tst wrote:

Controls and indicators are NOT named variables.

Remember that the basic data flow concept does not have variables at all.

---

We are getting into a semantics discussion here.  What exactly is a variable?  To me a variable is anything that can be varied.  Controls and indicators fall into that category.  They can be varied either by a user in the UI, or by local variables (hmmm, I wonder why they call it a local variable if controls are not named variables?), or by property nodes.  Sounds like a variable to me.  Call it whatever you want, but to say that LV does not have variables is somewhat misleading.  The terms exist in LV, Global Variable, Local Variable.

I do agree that a beginner should learn the basics before tackling pointers and such.  I merely pointed out the similarities to help a C programmer understand that LV can do the most of the same things that C can do.

Sorry to all who disagree, but I am sticking to my guns that pointers are like references in that they both contain an address for a memory location that holds data.  The implementation may be quite different, but the analogy is the same.  If I'm programming in C and I want to pass a variable to a function by reference, I send a pointer.  The function doesn't change a copy of the variable, it changes the original instance of the variable.  In LV, if I want to pass a variable (or control) by reference to a subvi, I send a control reference.  The subvi doesn't change a copy, it changes the original instance of the control value.  Seems pretty straight forward to me.  I don't think anyone can argue this point.  The only disagreement is in defintions.

In an attempt to be extremely exact, you guys are complicating things beyond what is necessary.  The poor C programmer must be confused.  A programming language without variables???  Oh, the items can change values like a variable, they are just called wires or controls or indicators.  And remember, a local variable is not really a variable.

I know someone or several will answer back.  I'll let you have the last word.  I'm done and I'm sticking to my beliefs.  I understand it well enough that I can translate any C program into LV.  Been there, done that.

[tst]

I agree with you that controls can be used as variables and I said as much. Global and shared variables are also specifically designed as a data holding/transfer mechanism.

My point was that this style does not mesh well with the data flow paradigm (and remember that all parallel data transfers in LabVIEW break data flow, although that can't be avoided if you expect to have parallel execution). You can use all of them (and I do), but if you're a C programmer transitioning to LV, those are not the tools you should use, because your code will probably look bad.

This is even more pronounced with control references. Yes, you can use a reference to update the value of a control in another VI (although if you're doing that to trasnfer data, you might as well use a global which is simpler to use), but references are not equivalent to pointers. Pointers are an essential part of programming in C. Using control references to pass data around is a kludge (and that's before getting into the functional differences between the two).

[Ben]

---

tbob wrote:

...

Sorry to all who disagree, but I am sticking to my guns that pointers are like references in that they both contain an address for a memory location that holds data.  The implementation may be quite different, but the analogy is the same.  If I'm programming in C and I want to pass a variable to a function by reference, I send a pointer.  The function doesn't change a copy of the variable, it changes the original instance of the variable.  In LV, if I want to pass a variable (or control) by reference to a subvi, I send a control reference.  The subvi doesn't change a copy, it changes the original instance of the control value.  Seems pretty straight forward to me.  I don't think anyone can argue this point.  The only disagreement is in defintions.

In an attempt to be extremely exact, you guys are complicating things beyond what is necessary.  The poor C programmer must be confused.  A programming language without variables???  Oh, the items can change values like a variable, they are just called wires or controls or indicators.  And remember, a local variable is not really a variable.

I know someone or several will answer back.  I'll let you have the last word.  I'm done and I'm sticking to my beliefs.  I understand it well enough that I can translate any C program into LV.  Been there, done that.

---

That is OK, appology accepted.

See here to see the performance hit from control refs and here to see Rolf confirming Christians assertion "bad, bad bad".

Ben

[tbob]

Well, I said I wasn't going to reply.  I lied.  I think I was taken completely out of context.

I never intended to convey the idea that references and property nodes should be used instead of wires or more practical methods.  I would never recommend doing this, and I don't think I even said anything like that.  I know property nodes are slow, I use them only when I have to.  I'm not arguing the performance differences.  I'm simply saying pointers hold an address, and so do control references.  I use these when I need to control a subvi from the main, or if I need to show a value from a subvi in the main while the subvi is running.  This is the analogy I'm refering to.  So they perform similar functions although the execution speed may be different.  It is up to the user to use them wisely and not needlessly.

[Ben]

---

tbob wrote:

Well, I said I wasn't going to reply.  I lied.  I think I was taken completely out of context.

I never intended to convey the idea that references and property nodes should be used instead of wires or more practical methods.  I would never recommend doing this, and I don't think I even said anything like that.  I know property nodes are slow, I use them only when I have to.  I'm not arguing the performance differences.  I'm simply saying pointers hold an address, and so do control references.  I use these when I need to control a subvi from the main, or if I need to show a value from a subvi in the main while the subvi is running.  This is the analogy I'm refering to.  So they perform similar functions although the execution speed may be different.  It is up to the user to use them wisely and not needlessly.

---

So all we have to do is take you out of context ...?

WE got by by very well back in LV 5.1 and prior when property nodes were attribute nodes and all we had to work with was controls and indicators, and our target noob should focus on just using those until ready to move to sub-VIs.

TO the orignal poster...

You benefit by putting free labels on your wires to ID what you would have called them in your C code.

Now i wonder if I can find that thread where I did the C to LV translation...

Ben

[Ben]

I replied to an earlier thread here with suggestions for C-to-G converts.

Ben