Jump to content

LAVA 1.0 Content

Members
  • Posts

    2,739
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by LAVA 1.0 Content

  1. QUOTE(crelf @ Feb 29 2008, 02:39 PM) Some of us have obviously watched too many diagrams run in execution highlighting mode. Another pattern I noticed is that if more than one "flow" has their inputs available, the thread that was dropped on the diagram first will be executed first. Ben
  2. QUOTE(crelf @ Feb 29 2008, 11:51 AM) Congratulations Ton! Ben
  3. "Some of us seem to have forgotten the (unwritten) First Rule of NI Tests and Certifications: The "correct" answer is not necessarily the answer you think is right, but the answer NI wants to hear." QUOTE(crelf @ Feb 29 2008, 11:49 AM) True, true. That phrase is the text version of "finger-nail on the chalkboard" for me. Manitaining my certifications under those rules is probably one of my prime reasons for counting down the days until I retire (2862 days). Ben
  4. Yes I have experience with DSC. If you are using LV 8+ wheer DSC is based on shared variables, I suggest you punch those "Champion Buttons" ASAP! What I know. With the pre-LV 8 datasocket reads CPU demands scaled linearly with the tag count so after about 100 performance started to suffer. Still with pre LV 8 DSC... The Tag engine for DSC was quite efficient and I have deployed apps with 3000+ tags with good performance. With LV 8+ DSC.... I have avoided going to LV8+ DSC since some of my smaller apps (<100 tags) started showing hits on performance. Generally speaking... Depending on your OPC server your performance can vary depending on the how the OPC server is impelemtned. All of the 3rd party OPC servers I have touched have shipping utilities that allow me to monitor tags apart from DSC. If you poke around enough, there should be configuration screens that let you specifiy update rates, dead-bands etc. Very often we have solved our performance issue by setting the OPC server settings. There are also settings in LV DSC and the shared variables that also let you set update rates. So while your app is running, try monitoring tags using the 3rd party Tag monitor to help narrow down were the issue lies. If you see quick updates in the OPC server but they don't show up in the Shared Variable engine... then start pulling strings! You are trying something that NI has never attempted. I hope this helps! Ben PS sorry about all of the CR's. Sometimes I just can't help myself.
  5. QUOTE(Aristos Queue @ Feb 28 2008, 04:59 PM) Also, isn't it true that if a subvi is not reantrent, and it is being called by other callers, the subvi will have to wait untill it is not busy running somewhere else, before it can execute for another caller. That was a ugly sentence. If the top VI takes a long time to execute, and it is already running somwhere else in the code (if this chunk was a small part of a larger application), it will not execute for this caller untill the other caller has finished executing it. In addition, there could be other callers of this VI already waiting in line, in that case it would have all its inputs but may have to wait awhile before it can execute for this caller.
  6. QUOTE(richlega @ Feb 28 2008, 02:18 PM) There is no way to determine which one will finish first (assuming execute means finish first), with the information provided. The only thing that can be stated for certain is that the bottom tone will not start execution until the filter vi is completed. There is no dependency between the top tone and the bottom tone so it is simply a mater of which process takes longer to execute the top one or the sum of the bottom two. If by execute they mean which one starts first, the answer is the same the reason is different. Since there is no data flow between the top tone and the bottom tone it is up to Labview to decide the execution order. Many factors are considered by Labview when deciding execution order (in parellel processes) , a look at the block diagrams would enable a better guess, but it would still be a guess.
  7. WOW ! That's really cool ! I've beeen dreaming of this and you made it. Even if I use it everyday, the IMAQ function palette is a maze for me, and the palette search tool doesn't really help me. I love this tool ! Nice coding style by the way Dziękuję bardzo !
  8. QUOTE(halohase @ May 25 2005, 04:06 AM) why dont you hold the 'Control' key and double click on the subvi. (Control+double click) that will open up the subvi blockdiagram
  9. QUOTE(Kevin P @ Feb 19 2008, 10:23 AM) Thanks a lot guys.... Let me ask the testers to test it...... if the problem persists lets c what could be done....
  10. QUOTE(dthomson @ Feb 16 2008, 12:50 PM) Also why dont you lock your functional global with a semaphore to avoid unnecessar access from other toplevel vi's?
  11. QUOTE(guruthilak@yahoo.com @ Feb 18 2008, 12:02 AM) OK.... Now i ma able to "Abort" a vi by calling it on a seperate thread as toplevel (or something similar) see the attachement I have 2 quesstions to ask 1) Which is better? "Abort vi" method or the "stop" function under "Function palette->application control"? (I ma using ABort vi method currently) 2) when the vi is aborting, i can see a small pop up window (looks like the window property of this vi is "Model") which says "Resetting "vi name" " .. Now how can i remove this.. Somettime this pop stays and does not go at all making me to kill Labiew from the "windows task manager" Any suggestions???????
  12. QUOTE(Aristos Queue @ Feb 15 2008, 02:14 PM) This looks to be a better idea... Let me try it out. I have couple of spare H/W so i can take a risk....
  13. QUOTE(Aristos Queue @ Feb 15 2008, 02:14 PM) That is true right up till you get to doing an I/O. THe VI will be aborted BUT it may hang the LV session (at least that is what happened the last time I tried it, about a month ago under LV 8.2.1) Ben
  14. Back to the topic of challenges... Daklu, The lack of LV Challenges has been mainly due to the lack of a sponsor. If you are willing to sponsor the challenge (write rules, evaluate results, etc) we* can get you incontact with someone inside NI that can make it official. PM us if you are interested in sponsoring a challenge! Ben * "we" = Any of the LabVIEW Champions
  15. QUOTE(Daklu @ Feb 15 2008, 12:18 PM) Judging by the fact that someone got their PHD for studying the ergonomics of toilet seats, I supect the answer to your question is "Yes!". Ben
  16. QUOTE(tcplomp @ Feb 15 2008, 04:26 PM) Very very nice it's probably caled "FlashVIEW"?? I can't say more...
  17. Thanks to all who replied! Ben PS: Those stars are for all of you, so share.
  18. QUOTE(guruthilak@yahoo.com @ Feb 15 2008, 08:28 AM) Ditto Gavins comments. Have you tried specifying a time out value for the ping? Generally the "abort VI" is not elegent since if the VI you are aborting is waiting on an I/O, the resource associated with that I/O must be cleaned-up. In Windows this could mandate killing the task. So... Does the timeout help? Ben
  19. QUOTE(Gavin Burnell @ Feb 15 2008, 08:15 AM) I dont have to do any operation with the H/W....Its absolutly fine...I just need to a way to perform a self kill.
  20. Hello there...I have a question to ask........ Looks silly but i dont know whats happening here....I have an application which pings to a linux based hardware and it is supposed to get some response when its pinged. If the response is not recived within some 10 seconds i am killing this vi (which is attached ) so that the main application will call this vi once again.I have used the method "ABORT VI" to kill the vi itself.(The reason why i am killing it because the "System exec" hangs or enters to "dead lock" most of the time) But when this method executes it throws an error as "Error 1000 occurred at Invoke Node in test.vi->xxxx.vi->ZZZZZZ.viPossible reason(s):LabVIEW: The VI is not in a state compatible with this operation.Method Name: Abort VI"Now i dont understand why it isnt state compatible.....? Can someone analise the same and let me know whats happening in this vi.PS: The reason why i am killing it because the "System Exec" hangs or enters to "dead lock" most of the timeOne more thing.. If u run this vi alone it will run without any problem. call this vi as subvi and then u can see the problem..May be even you can remove the "system exec: vi and rplace with a "Wait (ms)" with the "milliseconds to wait" value as anything more tha 11000 (11 seconds)
  21. Just my five cents remark : As long as you don't use any DAQ - and I assume you won't at home - there can be a Linux version that will do the job. Using DAQmx on Linux is really dodgy.
  22. Shane and Laurent, I suggest you post your questions about this on the machine vision board on NI forum, guys there will tell you which IMAQ VI can be set re-entrant or not and why. Many IMAQ VIs just call a thread-safe dll, such VIs can be set re-entrant, but as pointed Neville D : QUOTE Hope this helps
  23. QUOTE(tcplomp @ Feb 13 2008, 01:38 PM) Thanks Ton! So you use Ubuntu ? Re: "The wife" She had her MIS degree at age 23. She was managing a PDP-11/70 runnings RSX-11M+ when I met her. She focuses in computers from an IS view-point. I come at them from a hardware approach. We argue over who is responcible for E-mail. She wants to pad her resume, I want to ease my pain of an up-coming project were I will have to develop a hardware for both Windows and Linux. Since I have not touched Unix since AT&T's version 4 of Unix, I figure I should start exercising a part of my brain that has been gather cobwebs. Ben
  24. Hi all, My wife and were planning on setting up a Linux machine at home. She found the following " Debian Linux 4.0 CD Set - $19.99 " I plan on using it for LV development.Any comments or suggestions on this project would be greatly appreciated. Thank you, Ben
  25. Hi Thang, I'm not sure if I fully understand what you are trying to do, but from what I understand it is possible to do so. I've done something similar to that recently myself. Where you may hit a problem is if the referenced item is not of the same type. It will cause 2 problems: 1. you can't put them into an array 2. you can't call the exact same Callback. How to solve this? Well, for item 1, you may not be able to create an array of controls of different types, but you CAN create an array of clusters. The cluster can contain the different control types. For item 2, you can obtain the control reference property and determine it's type. So in your Loop, you can have a case structure that contains the Callbacks for the different types you'll encounter (plus a default - catch all & error msg). That way you'll call the appropriate one, all within 1 VI that can be re-used. Hopefully this gives you some ideas.. As I said, I am not sure if this is what you were looking for. Have fun! RayR
×
×
  • Create New...

Important Information

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