Jump to content

Jordan Kuehn

Members
  • Posts

    688
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by Jordan Kuehn

  1. 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.
  2. 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.
  3. In that case, I can understand a second event getting queued up. What about the two dialogs though?
  4. 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
  5. Cool. Thanks for the insight guys. It's nice to hear from people who actually use the thing rather than the local NI guy.
  6. Please come back and report either way. This could be useful info down the road.
  7. ^ 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.
  8. One suggestion (if it's purely UI related) would be to move to LV2011 and display the visibility checkboxes.
  9. Without trying to state the obvious, why don't you simply get an external GPS receiver with a serial interface or equivalent?
  10. 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.
  11. I don't know if you counted me. If not, make that 24.5
  12. 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?
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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?
  18. 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.
  19. 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
  20. 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.
  21. LV 2011 has added the ability to place check boxes on the legend to en/disable the display of different plots. IMO should have been done long time ago, but it's the simplest way to do what you want.
  22. I would also again emphasize the point I was making that when they wire error wires out and they autoindex a broken wire appears when running it into another vi. Of course you could argue that n00bs don't use error wires...
  23. My SSD and large monitors have also done this. To counteract, I'll code on my laptop occasionally. The worst is having to code on a touch pad in the field. For an on topic response, no I don't use any of the extra buttons, though I do like having a wireless mouse. Logitech makes good products.
  24. Well references and error wires could default to shift register terminals when wired into the loop? Much like arrays default to auto-indexing. This would also be useful for counteracting the auto-indexing of references and errors when exiting the loop.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.