LabVIEW
dynamic string array
I at least see a bunch of smilies and the icon with the smily sticking its tongue out. I'll try not to take it personally. 
It seems to me that you should look at the "Format Into String" function. This will allow you to create your string based on any number of parameters. You can even, if you wanted to, have it create the entire list of commands at once with the proper format string. For example, your "PULSE1: STATE 1" command would have a format string of "PULSE%d: STATE %d".
It seems to me that you should look at the "Format Into String" function. This will allow you to create your string based on any number of parameters. You can even, if you wanted to, have it create the entire list of commands at once with the proper format string. For example, your "PULSE1: STATE 1" command would have a format string of "PULSE%d: STATE %d".
Message Edited by smercurio_fc on 07-16-2007 02:07 PM
smercurio_fc:
Thanks, I had thought about taking this approach. I chose not to (right or wrong, I do not know, I am not a Comp Sci/Engr, just a lowly EE) use this method because I'm sending so many command string (4*5 + 4*7) and the only thing common to them all is ":PULSE". HEre's how I have sort-of solved the problem thus far.
I am about to tackle the issue of choosing which channel is duty cycle and which is normal
Thanks, I had thought about taking this approach. I chose not to (right or wrong, I do not know, I am not a Comp Sci/Engr, just a lowly EE) use this method because I'm sending so many command string (4*5 + 4*7) and the only thing common to them all is ":PULSE". HEre's how I have sort-of solved the problem thus far.
I am about to tackle the issue of choosing which channel is duty cycle and which is normal
Well, in my experience I have found that dealing with errors early on is the best course of action as it leads to less headaches down the road...
Auto-indexing is one of the more powerful features of LabVIEW. If you're familiar with text-based languages it's equivalent to the "foreach" statement. Basically it allows you to wire an array into a for-loop and the size of the array tells LabVIEW how many times the loop needs to execute. Inside the loop LabVIEW peels of each element of the array in order for each iteration of the loop. Looks like this:
My comment regarding not needing the sequence frame was related to using the error cluster since that wire would allow you enforce data dependency like so:
Note that the VISA resource wire does the same thing.
"I got a little aggravated at how NI seemed to handle the loops in those two frames concurrently". That's because LabVIEW is a data-flow language, and not a sequenced language like C or VB. In fact, that's one of the things that makes LabVIEW so powerful.
Auto-indexing is one of the more powerful features of LabVIEW. If you're familiar with text-based languages it's equivalent to the "foreach" statement. Basically it allows you to wire an array into a for-loop and the size of the array tells LabVIEW how many times the loop needs to execute. Inside the loop LabVIEW peels of each element of the array in order for each iteration of the loop. Looks like this:
My comment regarding not needing the sequence frame was related to using the error cluster since that wire would allow you enforce data dependency like so:
Note that the VISA resource wire does the same thing.
"I got a little aggravated at how NI seemed to handle the loops in those two frames concurrently". That's because LabVIEW is a data-flow language, and not a sequenced language like C or VB. In fact, that's one of the things that makes LabVIEW so powerful.
Message Edited by smercurio_fc on 07-16-2007 04:48 PM
@smercurio_fc wrote:
Well, in my experience I have found that dealing with errors early on is the best course of action as it leads to less headaches down the road...
Auto-indexing is one of the more powerful features of LabVIEW. If you're familiar with text-based languages it's equivalent to the "foreach" statement. Basically it allows you to wire an array into a for-loop and the size of the array tells LabVIEW how many times the loop needs to execute. Inside the loop LabVIEW peels of each element of the array in order for each iteration of the loop. Looks like this:
My comment regarding not needing the sequence frame was related to using the error cluster since that wire would allow you enforce data dependency like so:
Note that the VISA resource wire does the same thing.
"I got a little aggravated at how NI seemed to handle the loops in those two frames concurrently". That's because LabVIEW is a data-flow language, and not a sequenced language like C or VB. In fact, that's one of the things that makes LabVIEW so powerful.Message Edited by smercurio_fc on 07-16-2007 04:48 PM
MAN! I KNEW that!!!! GGRRRRR!!! That makes sense. Actually that's WHY I connected the error lines in the first place was to aide in flow control. OH!!! Still getting used to LabVIEW.
But I still have a question related to flow control. Check out the pic below. LabVIEW runs everything in a seemingly random order... well at least where it STARTS each chain of data. It obviously starts with the static constants or the earliest data in each chain, but I can't figure out how in the world it's deciding WHICH chain to start first. It kind of seems to go with the lower right and work it's way to top-left, but it doesn't exactly do that either. I dunno if it's worth you answering this concern or not, but if you got one for me I'd be much obliged.
I should take a LabVIEW class! Yeah right, as if they'd let me... R&D means I won't need it tomorrow ;( which stinks cause I'm liking LabVIEW the more I learn it. (I was not fond of it in the beginning, but that was my stubborness).
thanks again so much for all your help!!!!
Also, I am using all those strings to make my display appear as I want it to... I wonder if there is another way? I am aware of system labels, but I like the look of the recessed, grayed control boxes better.
Message Edited by Radiance_Jon on 07-16-2007 05:06 PM
It may seem random, but it's not. It's all based on dataflow, which means that a function will execute as soon as data for it is available. Take this simple example:
In the top example, the left Add function will execute first since its input terminal have the required data from the "x" and "y" inputs. The right Add function cannot execute until the left one is done since one of its inputs requires data that is generated by the left Add function.
In the bottom example both Add functions can execute at any time since for both their input terminals have the required data with no dependency between them. As for which one LabVIEW chooses to execute, it doesn't really matter.
You can head over the NI Developer Zone Learning Center. There are tutorial available there, as well as on external sites. Links for them can be found in the Learning Center. Also, there's a tutorial that comes with LabVIEW.
In the top example, the left Add function will execute first since its input terminal have the required data from the "x" and "y" inputs. The right Add function cannot execute until the left one is done since one of its inputs requires data that is generated by the left Add function.
In the bottom example both Add functions can execute at any time since for both their input terminals have the required data with no dependency between them. As for which one LabVIEW chooses to execute, it doesn't really matter.
You can head over the NI Developer Zone Learning Center. There are tutorial available there, as well as on external sites. Links for them can be found in the Learning Center. Also, there's a tutorial that comes with LabVIEW.
Message Edited by smercurio_fc on 07-16-2007 05:47 PM
