jmvrd wrote:
let me ask you again regarding the sequence, when it is more advantageous to use the stacked sequence compare to a flat sequence? in my case, with the program that i have, is it still more advisable to stick to flat sequence rather than shifting to flat sequence? thanks
You're actually asking the wrong question. Sequence frames in LabVIEW are used to enforce execution order, so they should be looked at from the perspective of which is the best method for enforcing execution order, rather than which one is better for your program. You need to use sequence frames when you cannot use a wire to enforce execution order. Remember that LabVIEW is a dataflow language, which means a function or VI will not execute until all data on all its wired inputs is present, and that data must be generated from somewhere, whether it's a control, a constant, or a VI (including global variables). Thus, wires can be used to enforce execution order instead of sequence frames, and are the preferred method for doing so.
ok ok..will try to look at it and study it
further. so far ive just focused on the basic read and write sample on
labview and didnt think i will be able to use the advance serial sample
their since i find it complicated and cannot understand the block
diagram at all. anyway, thanks again for the help!
Well if the Basic Serial Write and Read was clear, then the Advanced one isn't that much different. The only additional things it does is:
- Configure VISA to automatically append a specific character on the strings you send out with VISA Write. With some devices you need to end a command with a specific character so it knows that it has received the end of the command string. If you stick with single-character commands then you do not need this. Otherwise, your device needs to know when it has seen the end of the command.
- Set XON/XOFF: This, again, is device-specific. The example is there to show you how to do it if your device requires it.
- Loop around the write and read - this is really trivial. All it does is sit there so you can continuously send commands and receive responses, like you do in HyperTerminal.
Just out of curiosity: you said that your microcontroller will be controlling some LEDs and some motors. Is there a reason you're using a microcontroller as opposed to a simple USB DAQ device?
