Jordan Kuehn

To clarify, that was a quick fix (well not really), and is no longer in the dialog. Yes, prior to this it was stopped by two boolean controls OR'd into the stop condition. Sorry for the confusion.

Well, the second dialog (a while loop with simply two boolean controls to stop it) was definitely blown through with no input from the user. I was able to compare time stamps from the end of the action and the confirmation of that dialog, which were nearly identical. Verified that key focus is on neither of the buttons, nor are they bound to any keys. Then moved to an alternate approach that involved using F-keys to trigger an event structure (key up) in the dialog rather than the controls. We were able to queue up multiple events with this approach which led to the screen being dismissed on subsequent sequences. In a last minute solution, I ditched the event structure in the dialog and simply opened a reference to the keyboard and used the keys from that. No time to test much beyond basic functionality. This is all very strange.

As I mentioned, in the past we have had hints of this behavior when one of the dialogs would get immediately dismissed or the event would fire right away after the completion of the first event. I was able to witness that while remotely logged into the machine. Never did it make it past more than one window, and I don't think it ever skipped the two button dialog, but I could be wrong. To counter that we updated windows, there was a .net fix, and disabled tap-to-click on the touchpad. Also, while this machine was exhibiting this behavior we plugged in an external mouse and it stopped. Yup, that's a big can of worms and if it's related to the touchpad I'm not overly optimistic about being able to find something on the internet. As far as this incident goes, it only happened once, but that was nearly catastrophic for us (there's a reason we have two confirmation screens ). We have two people heading to the location of this laptop (Canada) and we can try to reproduce the issue soon. If by "human interface issue" you mean an operator covering his... then we have considered it and have not ruled it out completely. However, the timestamps between the logged events differ by 25s and the action takes approximately 22s which helps validate the operator's story. It could be possible that we have a combination of the past behavior and an operator reluctant to admit he hit a button twice. Either way the problem still exists. I'll have some more information in a few hours once we get our hands on the machine.

I cannot reproduce this behavior on my machines and just have logs and the description from the operator to go off of.

Well, the button is latch when released so there should only be one firing. I know that both dialogs were confirmed because the desired action did occur, and on the confirmation (2nd) dialog the response is logged as either a pass or fail based upon the user's input. It was logged as pass. Also, that action only exists in that specific event. See my second edit. The only event handled by that case is the value change event from that boolean.

A simplified mock-up. I can add some more functionality if needed. Basically something triggered the event twice and dismissed both prompts with an 'OK' click. Edit// Sorry, I left out the "Do Something" VI that should be in after the two button dialog and before the display result subvi. Edit again// There appears to be a bug in the VI snippet thing. It dropped the definition of the event. It's the "Do Action" boolean value change event.

In that case, I can understand a second event getting queued up. What about the two dialogs though?

Well here's a problem that I'm having trouble with and I was wondering if you guys had any insight. Essentially a front panel event is being triggered twice. Ok, so you say it's probably just queued up a second one. However, there is immediately a primitive 2-button dialog that must be confirmed and a subvi that has a confirm/deny boolean pair that are 'latch when released'. These buttons don't have any key binding that I'm aware of and key focus is elsewhere. Both of these prompts must be confirmed for it to execute and record the action contained in the event as successful. (first one is a confirmation to execute, second one displays data and prompts for confirmation that it occurred.) Now we've had one of these screens get confirmed before and we though it had been traced down to a MS update. Updated the machines and didn't see the problem. Today, it appears as if it executed a second event and confirmed both screens without the action of the user. Also, cursor is set busy in the event case which should prevent another click. I will point out that this case is not set to lock the front panel. I don't think that should be an issue and cannot imagine how that would trigger both confirm buttons on the dialogs, but there are certainly much smarter people than myself who are hopefully reading this I'll probably be on the phone with NI first thing Monday morning, but any insight you guys have would be tremendously helpful. I doubt that I can post the actual code due to NDA, but if needed I can mock something up. I tried to describe things fairly thoroughly though. Darkside crosspost: http://forums.ni.com/t5/LabVIEW/Interesting-intermittent-problem/td-p/1797572

Cool. Thanks for the insight guys. It's nice to hear from people who actually use the thing rather than the local NI guy.

Please come back and report either way. This could be useful info down the road.

^ if so, is it worth the expense to a customer? How is the overhead on the target machine? How accessible and functional is the citadel DB? The features sound great, but nothing that I can't/haven't coded myself.

One suggestion (if it's purely UI related) would be to move to LV2011 and display the visibility checkboxes.

Without trying to state the obvious, why don't you simply get an external GPS receiver with a serial interface or equivalent?

The advice you are getting is non-specific for two reasons. Your questions are very broad, and it feels as if you are asking for us to do the work for you. If you can present targeted questions as you work through the problem, then you will get much more relevant information than to read the manuals.

I don't know if you counted me. If not, make that 24.5

What is the processor usage while it is running? Could it be maxing out one of the cores and thus killing one of those timed loops that's tied to that core?

Over wi-fi, yes there are apps that have free texting and the new iMessage is free. You do actually have a separate bill for your netbook to have internet, your cable/dsl/whatever bill. The data plan is for use on the 3G network, which isn't usually an issue from the living room couch. Skype charges for text messages, but there are skype apps for phones that would be free to message skype-skype.

The iOS will never have as much functionality as a computer. That being said, when it comes to tablets more weight is given to ease of use. The purpose of a tablet is consuming information/media or entertainment. The iPad is successful because it does that out of the box and you aren't burdened with any of the minute details. If you want to be bothered by those details and spend more time customizing your experience you can go in that direction. I think at one end you start with an iPad that holds your hand for you and makes sure you have fun and at the other end you find yourself building a linux kernel for your netbook and customizing your display drivers weekly because the manufacturer doesn't support linux. I have an iPhone and an iPad1. I will never have a mac computer. The difference is that these things serve separate purposes. I use the iPad to surf the internet while watching tv or keep up with football scores. I use my computer to do real things.

Small terminals are almost required when using an FPGA read/write control node with several controls. It could be useful to have RT code default to non-icons.

Ah. Thanks AQ.

I would recommend this approach as it lends itself to manual editing of the file more than the xml file, a.k.a. the resultant file is far more readable. It can take a few more steps in the actual code, but you only have five channels and it appears as if the file is going to change more frequently than the software

This was the disconnect between my understanding and your implementation I was expecting. With the assumption that all messages are atomic, and momentary, then of course there is no need to do anything but wait for a new message to execute. Also, I may have unintentionally limited the original question to 'state' machines. I've found that it can be useful with unreliable network communications and the information being transmitted is simple control signals that can be lossy. Things time out every once in awhile, just ignore it and continue with the previous commands. RT targets and such. This may open the door to a myriad of ways to handle such situations. I suppose the point of this thread is that this approach seems almost obvious to me, but I don't see it in other places. So is that because it's obvious to everyone else, or there is something wrong with it?

Not sure if this is the same thing under a different name (I don't have the material you mention), but "Advanced Architectures in LabVIEW" is from 2009. Even if it's not the same, I'm sure a lot overlaps.

I mentioned your slave loop architecture because from what I saw when getting into it, the execution loop waits to dequeue a 'message' and then act upon it. Is this not quite similar to a QSM? It's entirely possible that I've missed something important about the architecture as I've only had time to give the thread and the code a cursory look. I also brought up the Actor framework because while even more abstracted from a traditional LV architecture, it seems to me that the actors are simply waiting for messages as well. Objects/text/enums/variants/whatever, it seems to me that you don't necessarily want the other code to simply wait for a new message all the time. Now I'm probably beating a dead horse, but I did want to explore how this affects the other architectures that are more complex than just a QSM. Edit// Oh! Thanks for the stars

See snippet below. I have used this approach a few times to dequeue elements while they exist and to simply maintain the previous state when they don't. However, I cannot remember seeing this in any high level asynchronous communication approaches. Most everything I see only reacts to additional messages being sent to the 'slave' process (Daklu's slave loops, actor framework, even QMH). Correct me if I'm mistaken of course. Perhaps I'm over thinking this, but is there anything fundamentally wrong with an approach like this? Like I said, I've used this basic idea a few times before and it has served me well. The use case is when you want the other loop to continue it's previous command when nothing is left in the queue rather than pausing. A simple example could be a DAQ loop that is restartable/reconfigurable. You can send it all the configuration commands which will be transferred without loss, but then when you start the acquisition it simply continues acquiring without any help from the other loop.