LabVIEW
Event Logging
Solved!
@_natalie_ wrote:.... I would still love some feedback though if you don't mind! 🙂
I think you will find that the contributors here are a lot like Superman. Once the emergency is taken care of they are off to another adventure.
Ben
No problem! It's why I answered in the first place 🙂
So there's a few components at work here, but the two that are most important are Queue Error.vi and Consume Queued Errors.vi. I'll place pictures to guide you along and hopefully help your understanding.
Consume Queued Errors is started before your other code, so it sits in the background:
The red arrow points to the User Event wire (I'll get into that later) that's used to stop the loop. Because this User Event goes into your main loop, this ensures that the Consume Queued Errors VI starts before everything else, but because it runs in the background, it's indicators must not be connected to anything. If they were, or it it was in some sort of sequence structure, the rest of your code wouldn't start.
Every "Consumption Period" milliseconds,
it flushes (empties) the queue,
and if there's anything in the queue, (eg the autoindexing has more than one element) it logs it to ERRORLOG.csv,
which is located in the same directory as your MAIN.vi:
So what fills up this queue? The Queue Error vi:
To answer your original questions about the call chain and the reference error, this code was meant to be run strictly AFTER "Consume Queued Errors.vi" has been started, which is why, originally, the "Obtain Queue" vi has a False wired to it. You can change that very first boolean to a TRUE (as in the diagram above) to get rid of this error.
In regards to the call chain, have you ever noticed that when LabVIEW automatically handles errors, it pops up with a window saying something like "Error -2147463647 Occured at SubVI1.vi", and the message has a long list of VIs that it took to dive down to the VI where that error occured? Something like "Main.vi -> Sub1.vi -> Sub2.vi -> LowLevelFunction.vi". That's the call chain. It lets you trace back where the error came from, and the order in which the VI was called, so you can better debug your VI.
It's like an itinerary, of sorts. If a loved one is travelling to your city from across the world, you'd probably want to know what flights they are going to take and when, so you can keep track of their progress. For simplicity, I'm going to keep everything in the same time zone. Let's say that their flights go: 12PM departure for New York, 1PM departure for Philadelphia, 4PM departure for Atlanta. If they sent you a message at 3:00PM saying their flight was delayed, you wouldn't need to know where they were, you would just look at their itinerary and know that the Atlanta flight was the delayed one, so they must be in Philadelphia.
Call Chain VIs will always work, so there's no reason to remove it. It's only better information for you!
-----
Finally, let's talk about that User Event. Remember how the Consume Queued Errors is started in the background and just keeps going? As good LabVIEW programmers, we need a better way to stop that than simply pushing the "Abort" button. But how do we communicate with something that we started way back and don't have any wires to? My preferred way is via a User Event.
Event structures, as you may know, allow you to handle events in your user focused application without resorting to a dreaded polling scheme. But they also can handle events from far flung regions of your application via User events. In our case, we simply want to tell it to stop. Here's how it works:
First, we need to create a User Event. See "Create User Event.vi":
As you can see, it's really simple. Just tell it the type of data the User Event contains, and wire it into the "Create User Event" vi. The wire you get out will allow you to "Register" an event structure to listen for that event, as well as "Generate" a user event to be sent out to all listening event structures.
In Red, the User Event we created. In Blue, we "Register" for that specific event. Then, in black, we wire that Registration into the Dynamic Event terminals of our event structure, effectively "subscribing" it to any User Events that get generated.
Finally, we look for where this User Event gets used:
So whenever we enter your "STOP" state, we generate a User Event to everyone who's listening. Back in "Consume Queued Errors.vi", we can see what happens:
As you can see, nothing super interesting! All we do is wire a "TRUE" to the stop terminal of the while loop, which effectively halts this VI, as well as cleans up all of its Queues and Events, as desired.
Anyways, hope that helps!
