11-10-2014 02:30 PM
Dennis is objecting to the use of long waits because the vi becomes unresponsive during the wait. If you try to abort it you may have to wait the full 30 minutes or whatever before it responds, which is generally unacceptable. I was only trying to show you how to use the DAQ functions without cluttering up the block diagram, and it wasn't meant as a model of good LabVIEW programming. If you want an architecture that is more responsive to a stop button, see the attached snippet.
11-10-2014 03:19 PM
Richard,
I don't see in your new program where the callout is to the DAQ equipment.
Dennis and Lynn,
I don't appreciate the sarcasm. I'm here asking for help, not to be mocked. I need a program that will run for 15 days and 15 hours. I understand this is a long time. We have equipment in our lab that runs for 21 days without a problem, so I know it can be done.
11-10-2014 03:55 PM
I left that out for simplicity. You need to combine the two as shown in the attached snippet. Don't worry too much about the other comments. There are some people on this forum who provide help, and that is what matters.
Rich
11-10-2014 04:17 PM
11-11-2014 12:34 PM
Matt, you're confusing two ideas and you really shouldn't. You've discussed that it CAN be done. That's an entirely different discussion from WILL ALWAYS be done. When setting up your system, you're assuming a perfect system for every run. That's a bad assumption to make. You need to re-evaluate your design and look for a design that CAN run for 15 days and 15 hours rather than one that WILL. Look at it from the viewpoint that it will run that long only if you allow it to continue. If it is designed to last that long when you allow it to do so, it fits the CAN model. What you're doing now is dangerous design. Really, it should be mocked.
Richard, there are people here that are helping. You're not one of them. It's not "generally unacceptable." It's entirely asinine. It's terrible design. Matt is clearly new to the environment and you're starting him with bad habits. This is like teaching a child it's ok to strip in public. Sure, people will probably laugh because the "kid doesn't know any better." But, it's not helping the child. Your guidance is detrimental to the child. Similarly, offering bad practices is detrimental to a new programmer. Here's what's more disturbing. In order to show that you understand the problem being pointed out, you post code that still can't be expected to respond within less than 3 seconds. While that is more responsive than your original terrible code, this is STILL bad practice. The design you put forth is shortsighted and shouldn't be considered a viable solution for a first program, let alone one that you're suggesting shows expertise.
Rather than give Matt a broken example to feed your ego, why don't you point him towards a design that will actually benefit his application? When you're called on your ego stroking, own it. There's no point pretending you were doing something beneficial. Anyone with a basic understanding of your code realizes it was bad advice.
Matt, there are dozens of examples available to show you how to use timing appropriately. The Elapsed Time Express VI makes this very easy to manage. Put yourself on a better path and learn to use the tools designed for the task you want to perform. Stop using Richard's hammer to work with your screw.
11-11-2014 12:58 PM
Nat, so far Richard is the only one to provide any concrete examples. All you said was, to paraphrase, "there are better examples out there."
11-11-2014 02:18 PM
Matt, if your version of LabVIEW has the Elapsed Time vi, there is no question that it is the best choice. If you don't have it, you can make your own using "Get Date/Time in seconds". I have attached a snippet that shows how to use the Elapsed Time vi for the delays. I am not a professional programmer, and I freely admit thay my code is not the most elegant or efficient. If you find something better, use it.
Rich
11-11-2014 02:19 PM
This time with attachment.
11-11-2014 02:29 PM
11-11-2014 06:06 PM
Matt,
In addition to the examples Dennis pointed you towards:
http://zone.ni.com/reference/en-XX/help/371361J-01/lvexpress/elapsed_time/
http://digital.ni.com/public.nsf/allkb/05A9C3B0A4D5A7638625712B006FB30F
https://decibel.ni.com/content/docs/DOC-8175
http://www.labviewing.com/timer-measuring-elapsed-time/
You're right, we haven't provided "concrete" code for you. We've provided you with resources to help you understand the concepts. You've rejected those because you'd prefer we write the code for you. Here's the problem you're running into: the people that CAN write the code for you know the benefit in teaching you how to understand the code for you, us, and the rest of the community. Handing you the code doesn't benefit anyone, including you. The people that can't understand the task write code for you.
This leads back to you Richard. You don't understand dataflow. You NEED to start with the basics before starting to mentor others. Nodes in LabVIEW start when they receive all required inputs. In the latest code you've given, you read the stop button in the first loop. If he wants a program that responds only in that single STATE, swell. It'll respond within 50 ms. What if the user tries to interact when the program is in any other STATE? That's right, it only reads the value at the start of the loop. You've written new code that has the same problem. If you're going to use the nested While Loops, why in the world would you opt to use two? The outer loop is already going to run until it reaches the maximum number of loops required or until it receives a stop. Why not just use a shift register to pass values between the iterations to perform the same functionality without some big mess of loops? That's assuming we want to use this architecture in the first place.
No, you didn't claim to be a professional programmer. However, you did post an incredibly snarky comment about others that were providing something useful to the original poster. Posting bad code to get the new programmer starting with bad habits is not helpful. You shouldn't suggest you're providing more value than the other posters that at least took the time to look at the problem rather than pretending it didn't exist.