03-18-2019 09:28 AM
@crossrulz wrote:
@mcduff wrote:1 recommendation though, you probably do it already, but when sending string commands I like Case Insensitive Match, so STOP, Stop, StOp, ... will work.
Absolutely. I abuse that functionality. Do note you will have a slight performance hit. But the protection from miscapitalizations is worth it.
Sending an (type def) enum will solve that more elegantly, IMHO.
Of course, just to mention the option, not to recommend it, the main VI could also use VI Server to simply abort the VI... No way to build an application, but still a valid answer to the OP.
03-18-2019 09:31 AM
@crossrulz wrote:
As an aside...I often run into people who use the Producer/Consumer and stop the consumer when the queue is empty. This is BAD because you might be stopping prematurely. You should have some type of message in your queue to tell the consumer when to stop. Of course, Bob doesn't have that issue because it is built into Channel Wires.
You could however stop any loop when the queue is destroyed. Then it will return an error... Not the prettiest practice, but not really any harm in that. You won't get any elements over the queue anyway.
03-18-2019 10:06 AM
I wanted to thank everyone who has commented suggestions. You all have been a great help.
The program that I am writing is supposed to be a practice example for me to test the waters of data Acquisition. The requirements for this program was that 1) I needed to have a daq Engine sub VI that I can spawn using the Asynchronous start and wait functions. The DAQ engine will read in analog and digital voltages and will display them to a chart. as well as display the analog out.
2) I need to be able to control this Sub VI from the main front panel application.
Some things to note is that my boss would prefer me to not use global variables, and not use a queue to drive the sub vi.
I have decided on using custom events to drive my DAQ engine as someone has recommended.
I have run into a couple of new problems. The main one being that I am able to start my DAQ engine from my front panel, but for some reason my DAQ engine doesnt recognize my Stop user event.
Any examples or insightful help would be awesome.
I appreciate it a lot guys
03-18-2019 10:44 AM
@Gaffinator wrote:
The program that I am writing is supposed to be a practice example for me to test the waters of data Acquisition. The requirements for this program was that 1) I needed to have a daq Engine sub VI that I can spawn using the Asynchronous start and wait functions. The DAQ engine will read in analog and digital voltages and will display them to a chart. as well as display the analog out.
That are silly requirements. Who would require that and why?
@Gaffinator wrote:
2) I need to be able to control this Sub VI from the main front panel application.
Now that is a sound requirement...
@Gaffinator wrote:Some things to note is that my boss would prefer me to not use global variables,
He seems like a smart guy...
@Gaffinator wrote:and not use a queue to drive the sub vi.
And now it's gone...
@Gaffinator wrote:
I have decided on using custom events to drive my DAQ engine as someone has recommended.
I have run into a couple of new problems. The main one being that I am able to start my DAQ engine from my front panel, but for some reason my DAQ engine doesnt recognize my Stop user event.
Any examples or insightful help would be awesome.
I appreciate it a lot guys
It would be more productive if you'd show some code. Pretty sure there are User Event examples shipped with LabVIEW.
03-18-2019 10:49 AM
The reason these requirements are odd is because my boss knows the issues that come up often and he wants me to be able to figure out how to work around certain constraints. I'm an intern learning labview for the company I work for, and have no formal experience with labview other than the couple small projects i have done.
Attached should be my code ( Don't laugh too hard).
Regards,
-Jon
03-18-2019 10:52 AM
Another thing to note, I did configure a simulated analog voltage in ( Dev1/ai0) to do the testing
03-18-2019 11:20 AM
Look in the NI Example finder. Look for Voltage (with Events) - Continuous Input.vi example. (It is attached here.)
It may simplify your loops; then you can use just user events to communicate between modules, and if you open the DAQ engine everything is self contained within one event structure.
mcduff
03-18-2019 11:27 AM
Another one of the requirements was that I use the company template. That's why I'm kind of developing around that kind of structure. My original DAQ engineV1 was very similar in format to the example you have attached. My boss told me that I should be using the company template
03-19-2019 04:10 AM
@Gaffinator wrote:
My boss told me that I should be using the company template
My sincere condolences.
Knowing you can't change the situation (or don't\shouldn't want to try)...
03-19-2019 06:23 AM
wiebe@CARYA wrote:
@crossrulz wrote:
As an aside...I often run into people who use the Producer/Consumer and stop the consumer when the queue is empty. This is BAD because you might be stopping prematurely. You should have some type of message in your queue to tell the consumer when to stop. Of course, Bob doesn't have that issue because it is built into Channel Wires.
You could however stop any loop when the queue is destroyed. Then it will return an error... Not the prettiest practice, but not really any harm in that. You won't get any elements over the queue anyway.
That is how NI has always taught the Producer/Consumer. Yes, it does work. However, you will lose any data that has not been processed at the time of the queue being destroyed. That is a MAJOR issue in 95% of the projects I have done where P/C fit the need. So over the years I have learned that you almost always want your consumer to maintain the queue (create, read, destroy) while everybody else can only write to it. I do this via a library for the consumer with an Action Engine that is private and a public method for allowing other loops to write to the queue.