LabVIEW
Error 200303 - Coordinating DAQ devices
Solved!
My friend, if you were looking at a program whose wires were scanning through several screen widths, you were looking at a VERY badly written piece of code. I am sorry that was your first exposure. There are much better ways to do things. You might consider starting with the online tutorials, if you are interested in learning to program properly in LabVIEW. As a good rule, your code should never sprawl off the screen in both directions.
Ok, I am telling you that you have to get rid of all those locals. 
For instance..."Encoder 1 count". You have no way of knowing whether that local represents the previous value of the indicator, or the current value of the indicator, because you have no control over whether the local gets read before the indicator is written. So your current scanning angle may or may not be correct at any given time. You have the calculated value sitting right there...you can get rid of the local, and then you will always be certain that you are using the correct scanning angle.
You also have lots of places where you repeat identical calculations...you might consider putting those equations into a subVI and then making the subVI reentrant if you need separate instances of it. That way, if you ever need to change the calculation, you only have to change it in one place.
For grouping related data, I suggest a type-defined cluster. The type definition is nice because, in order to make changes to your cluster, all you have to do is open it, make your change, and select "Apply changes". Then, everywhere that cluster is used, the changes will automatically propagate. You don't have to find each instance and change them individually. HUGE advantage. Look them up. You'll like them.
Depending upon what you are actually trying to do (you mentioned that your program will grow a lot), you should look into what would be the most effective way to architect your code BEFORE you really get into it, so that it doesn't become a horrific nightmare of spaghetti, impossible to read and worse to debug (let alone maintain). Look at LabVIEW's shipping examples for things like queued state machines, producer-consumer loops, etc.
ScottC. wrote:Haha,
Some of this I new was going to be a problem.
From what I read so far, it's going to get much worse. But it does not need to be. It's time to learn proper coding techniques and proper architecture with LabVIEW.
The local variables I started doing because I had trouble keeping track of what wire was carrying what data.
Local Variables are already your worst enemy. You just don't know it yet. I ban people I recruit from ever using Locals (yes, even with opposition from peers)
I learned how to put dataflow programs together using a program that was MUCH more complicated than I was ready for and just had to dissect it little by little. With the more complicated program the wires can span several screen widths and I was trying to clean it up when I was checking my math so that I didn't get lost.
LabVIEW programs should never be larger than a single screen. That can be achieved by the appropriate architecture. Actually, now days, with larger screens, the programs should be smaller than a single screen.
I will work on getting that cleaned up, but to be honest I was just waiting on someone to tell me I had to
.
Okay.. I'm telling you it is time to clean up the code and to remove ALL Local Variables. 🙂
As far as the front panel configuration, a lot of the confusion is because I tried to simplify the code to post on here. The working version I have is labeled a lot more effectively, but I'm still struggling to group things so that they are related but the decorations aren't overdone.
Start by cleaning up the block diagram first. You may even notice that the Front Panel becomes cleaner. Aim for simplified code, remove unnecessary functions. Use the power of Polymorphism.
This program is going to grow aggressively in the next few months so I need to come up with a more efficient way of adding on to it both in the front panel and the block diagram.
That's why you have to clean the code now. Otherwise it will be unmanagable, and you'll go nuts.
