Showing results for 
Search instead for 
Did you mean: 

Code doesn't run correctly until the block diagram is opened

I have a VI that I am using to generate a variety of signals.  This code has been working fine for a while and all of a sudden it started acting up.  Now, when I start the code, instead of generating a signal at the specified frequency, it generates a deformed sine wave at a low, arbitrary frequency.  However, once I open the block diagram and restart the code, the VI runs correctly.  I am using a NI PCI-6229 DAQmx card for the generation and am running LabVIEW 7.1.  I have attached my code, sorry if it is not the most organized or efficient way to generate a signal, this is my first LabVIEW code.  Thanks for your help.
0 Kudos
Message 1 of 2

Sorry, I no longer have LabVIEW 7.1, and I also don't have your hardware, so I will not be able to reproduce your claimed problem.

Overall, the program is quite nice for a beginner, but I have a few points you might look into at your leisure:

  1. What determines the loop rate?
  2. Many things occur in all cases, so you don't need to localize everything inside the case structures. For example "burst on", "add noise", "boolean" receive data in all cases, meaning you can place their terminal AFTER the big case and feed appropriate values from each case out. This eliminates all the local varaibles.
  3. In the big FALSE case, you read "Generate signal" from a local variable. Why? You can just wire from the inside of the selector terminal! The value is right there!
  4. It is expensive to write all these properties on the left. You should use an event structure and update these only whenever "wave type" changes its value. There is no need to rewrite the same properties at each iteration of the loop.
  5. Same with the plot color. The property node belongs outside to the right of the case and only the color belongs inside the case. Now you only need a single instance of the property node.
  6. To make a plot invisible, you select a black plot color. Better would be transparent so you don't need to change anything if you later would deside on a different plot background color. Transparent is the little [T] box in the upper right of the color selector.
  7. The value of "burst on" belongs in a shift register so you can eliminate the locals.
  8. Try to avoid coercions. For example most of the diagram constants are mismatched. The "2" to multiply the bandwidth should be orange (DBL). The constants you complare with the U32 wave type should be U32 (currently I32). The inputs to the function in the big FALSE case should be DBL. (Right-click on all these constants and selet the proper representation). etc.
  9. The "sample rate" indicator probably belongs outside the case, tapping in the wire right behind the bandwidth multiplication. Right now it won't get updated and thus might contain a stale value if the big case is FALSE.
  10. Uniform white noise is typically unrealistic. I would use Gaussian noise.
  11. You might want to reset everything to visible once the loop stops, using a few property nodes after the loop. This makes editing easier.

As said, most likely none of this is in any way related to the problem you are observing. They are just a few quick ideas to improve dataflow and code readability. Good luck! 🙂

0 Kudos
Message 2 of 2