LabVIEW
Help avoiding sequences (possibly causing serial write bug)
First of all, no, the sequence file isn't causing the issue. You didn't include the critical subVI that needs to be loaded, so I'm making a (probably correct) guess that the ? code inside the FOR loop contains the code to grab the data, and that it ignores any attempts to do another grab while one is already in progress, returning no data.
Now, while the sequence structure isn't causing the issue itself, it's the issue of not understanding why it isn't necessary that IS (partly) causing your issue! Read up on Dataflow Basics. The main takeaway from that tutorial is: Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution. Your issue is very well described in figure 2 of that tutorial. The way you have it set up, you cannot know whether the serial write or the data grab will happen first. If you can grasp that one italicized sentence above and be able to apply it ruthlessly to your code, you will see why you shouldn't need any sequence structures ever. (Technically, if the only way to enforce dataflow is by using a sequence structure, you can always stick that code in a subVI instead, although most LV developers would not frown upon you if you were "lazy" and didn't do that.)
So, what you should have learned from the tutorial is that you have to wire your data grabber subVI such that, by applying that sentence above, it is forced to execute AFTER the serial write.
The other issues, not related to dataflow, is that you have to figure out how to a) stop the grabber from grabbing before the motor has had a chance to complete its mission (bet you didn't even know you could have that issue, but whatever it is that the motor is supposed to do, it's not going to happen instantaneously), and b) make the grabber subVI wait until the grab is complete before exiting.
Hope that helps.
@ljh48332 wrote:
Thanks for your response! This makes sense and I think I can see how to wire things up differently so that I can do away with the sequence structures just by more strategically placing my wires.
One more follow up: Will the for-loop move on to the next iteration before the spectrum grabber finishes? I was under the impression that the for-loop shouldn't advance until everything inside it has finished. If that is the case, then there should never be a situation where the grabber would need to ignore another grab because it should already have finished.
Your impression is correct - that's dataflow! I did so well explaining dataflow, then didn't follow it. So now you know how to make the grab happen after the motor command. Now you have to figure out how to make it happen after the motor COMPLETES its command. It could mean a hard-coded wait in between the two, but that is inelegant, not very robust, and usually implies an incomplete understanding of how to communicate with the thing on the other end. See if there is some kind of feedback from the motor that tells you when it has completed its task, or if you can somehow query the motor to see whether it has completed its task or not. If there isn't, you may have to go with the hard-coded wait.
Oh and I gave you kudos for showing that you have taken seriously the task to understand dataflow!
The Flat Sequence structure itself is not the sin you committed here.
No, your sin is not using a proper program architecture. I understand you are new to this and National Instruments has done you a disservice by making it look like your programs should all be OBL (One Big Loop) architectures.
OBL works for the tiny little demo and tutorials but in the real world it rarely works, and when it does if left unchecked, you end up with something like this.
(I could not even see the whole thing when spread across two monitors)
I suggest you look closely at the simple state machine architecture for this project.
