IVI-COM Vi's or property nodes?

I'm fairly new to IVI-COM instrument drivers and have up until now been using the supplied IVI-COM Vi's for the instrument I'm doing a driver for. However I'm finding that more and more it's making sense to just use a property node to set things such as Start Frequency etc so I'm thinking I might just use them for everything from now on.
All I really want to know is are there any major issues with doing this - and is it something is recommended to be done - just really want reassurance that if I take the route of using property nodes I won't get bitten on the arse by something that I don't know about.
Any thoughts happily received,
David Clark
CLA | CTA
CLA Design Ltd
Hampshire, England

Hi David,
I'm guessing that you've got a bunch of LabVIEW vi's from the vendor - that are basically wrappered IVI-COM calls? (If you can tell me where to download the driver from I can look in more detail). The low level IVI-COM calls will just use ActiveX (so property nodes and invoke nodes) to access the COM object.
Whether you use the wrappered vi's or the lower level calls is up to you, it will depend on the level of flexibility that you require. For some configuration settings for the instrument there might not be a ready built vi - so you may have to use the lower level calls to acheive it.   (A bit like the usual plug and play instrument drivers, versus low level calls directly using VISA - which may or may not give you an idea - depending on whether you've used them!).
Take a look at the following tutorial which might give you some more pointers:
http://zone.ni.com/devzone/cda/tut/p/id/4505
I guess one point to bear in mind is that the vendor can at any time change the ActiveX methods and properties with a new release of the driver (a bit like Microsoft have done in the past with things like media player and office) which may leave code you've generated with broken wires, if you are using their wrappered vi's then its possible that they'll keep the wrapper and change whats inside so that its seamless to the end user. - (Its also possible that they could update the automation servers version number which would result in a non working vi - but may not result in broken wires, working with the vendors LabVIEW API should solve these issues - since they will have re-linked them specifically to each version)
Another factor that should help you make up your mind is how well documented each of the options are - they may have put more time into the friendly end user vi's than they have to the API?
But if you're generating your own driver, then it will probably be more useful to you to strip away some of the abstraction to get more efficient results.
I hope this helps - perhaps other members of the NI community can give you their experiences
Hannah
NIUK & Ireland

Similar Messages

  • Changing the property node from an control in an cluster raises an error in LV2011

    Hi, all
    when I run the code in LV2010 SP1 no problems.
    But in LV2011 it gives an error.
    Is this an BUG
    Attachments:
    test.vi ‏18 KB

    Franzo,
    It certainly is strange.  The error comes from the Width property node, but it occurs when ReadoutMode is clicked.  It does not need to be changed.
    Wrapping it in an event structure (ReadoutMode: Value Change) seems to eliminate the error.
    Questions for someone at NI who knows how these things work internally: It is also interesting that the data type of the Maximum property is always DBL, regardless of the datatype of the control.  Should not a U16 control have a U16 Maximum? And what about the Extended datatype? How can a value larger than the maximum for a DBL be set via a property node of type DBL?
    Lynn

  • Why is IMAQdx property node not sending/receiving? Please take a look!

    Hi!
    Im trying to control FPS but with no result. Whats wrong with this code?
    thanks!
    Attachments:
    pic.JPG ‏95 KB

    Please see this related thread http://forums.ni.com/t5/LabVIEW/IMAQdr-Property-Node/m-p/1642950/highlight/false#M590168
    Matt
    Product Owner - NI Community
    National Instruments

  • I am using the NI application note "Calling IVI-COM drivers from LabVIEW" I created an Automation Open and an Invoke Node, after wiring

    the 2, the AN asked to right click the Invoke Node(this is step9) and choose initialize. However there is no intialize option on the pop up menu. Anything am I doing wrong? I am using Labview6 and I did add the "enableCustomInterface=True" in the INI-fileThank you for your help.
    T Tall

    the 2, the AN asked to right click the Invoke Node(this is step9) and choose initialize. However there is no intialize option on the pop up menu. Anything am I doing wrong? I am using Labview6 and I did add the "enableCustomInterface=True" in the INI-fileT Tall,
    What's the number of the application note "Calling IVI-COM drivers from LabVIEW"? I'm unable to find what you're looking at.
    Thanks,
    --Bankim

  • Property Node in VI throws Error 7 in LV 7.1 but runs OK in LV80 and LV86

    Hi everybody
    I build a custom IVI instrument driver and using the LV tool <Generate VI Interface from Instrumnet CVI Driver> I was able to get a LV wrapper for each driver method. From LV86 I saved first in LV80 and from LV80 I saved as LV71. I have all these LV versions on installed on my PC.
    I have no trouble in using these LV wrappers in any of these LV versions as they work OK.
    Now my IVI driver has also Properties that the Import Driver Tool does not convert as a wrapper and for that reason I had to create a Property Node Warpper myself and saved in the same LLB under LV/instr.lib folder.
    Once I have all these method wrappers and the property node wrappers I made a small VI
    1. Initialize IVI With Options on a TCPIP instrument
    2. Set-Get an IVI Timeout property
    3 Close IVI driver on TCPIP instrument.
    Good part is that in LV 86 and in LV 80 the VI is running fine when I use these LV version wrappers from their coresponding instr.lib folder.
    As soon as I am going to use the LV 71 wrappers in LV 71 I could create the same small VI to Set/Get Timeout and the VI look OK nothing is broken but when I run it the Initialization is OK but as soon as is reaching the Timeout Set Property Node gets out an Error Code 7.
    To run this VI the user need to install the jdCMR IVI driver then add the LV71 jdCMR wrappers inside LV71/instr.lib and then he may build any VI using these LV warppers.
    The only problem is that the Property Node get out an Error Code 7 and the same error code get out from Property Node if I am picking the Property Node from VISA Advanced Pallette, connect this node to jdCMR driver, set Timeout property inside the node and after connecting the input and output references  plus the input and output error to Initialize and Close LV wrappers I still get this error at running time.
    The same LV 71 VI if I open in LV80 or in LV 86 runs without any problem?
    Does anybody knows why LV 71 is not working the same way as LV80 and LV86 with respect to Property Node?
    Btw When I save my VI from LV 80 to LV 71 I get this warning...
    IVI Error Message Builder.vi
        Cannot save VI from VI.LIB to previous version.
    Merge Errors.vi
        Cannot save VI from VI.LIB to previous version.
    Thanks
    Sorin

    Hi
    For further testing of the IVI driver Property Node bug with LabVIEW 7.1 IVI drivers I download and installed two different IVI drivers from two very known instrument companies, Rodhe-Schwarz and Agilent Technologies.  
    I have to mention that both these companies releasead their IVI NI LabVIEW 7.1 drivers under NI Instrument Driver Network and ready to be installed and used by any customer of these two instruments.
    The bug is present only in LabVIEW 7.1 version as if I take the same VI that breaks in LabVIEW 7.1 I could run it without any problem in LabVIEW 8.0 or LabVIEW 8.6 versions.
    Anybody could test this bug for these two NI released IVI drivers in simulation in LabVIEW 7.1 by following these links below.
      Agilent ag81150ni IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
    http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=55798957B1A633BDE0440003BA7CCD...
       Rodhe Schwarz rsngpt IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
    http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E91D6659CE034080020E748...
      After installation complete close LabVIEW 7.1 if was open, then restart LabVIEW 7.1  and now you may see under the LabVIEW Instrument Driver Palette  two new IVI drivers ready to be used as LabVIEW 7.1 wrappers.
    Open a new blank VI and from Instrument Driver Palette use two well known Vis that are Initialize With Options.vi and Close.vi add them on your blank VI block diagram and connect thm together. Accept all default parameters except Simulate that must be Simulate=1.
    Both Vis run OK in simulation mode without errors. Now pick a Property Node from VISA Advanced Panel and squeeze this between the Initialize With Options VI and Close VI and make the instrument reference in-out and error in-out connections.
     Now run these two simple Vis in simulation
    I run Rodhe Schwarz IVI driver and Property Node passes OK until the end
    I run Agilent IVI driver but Property Node is getting out Error Code 7 that is the same as my own driver error.
    Both these IVI drivers are under NI Instrument Driver Networks and have been built and integrated as native NI IVI instrument drivers.
    Question is why they behave so different with respect to Property Node from the VISA Advanced Panel?
    I attached the screen shots as PNG files that show clearly the difference of VISA Property Node behaviour when used under the same circumstances.
     Thanks  Sorin  
    Attachments:
    ScreenTestShots.zip ‏152 KB

  • What is difference between local variable and property node ?

    What is difference between local variable and property node ?
    " 一天到晚游泳的鱼"
    [email protected]
    我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
    欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview

    To make things clear, here are two small examples that show how nasty locals and value properties can be to the naive programmer.
    - Open the diagram of the race condition.vi before running it and try to predict what will be the values of the two counters after the third run.
    - Use the Compare Locals Properties and Wires.vi to find out how slow locals and value properties can be (times 1000+).
    This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient
    Chilly Charly    (aka CC)
             E-List Master - Kudos glutton - Press the yellow button on the left...        
    Attachments:
    Race condition.vi ‏9 KB
    Compare Locals Properties and Wires.vi ‏18 KB

  • NI 845x USB: Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi

    Hello,
    I am currently working  with digital accelerometer LIS35DE from ST Microelectronics. I want to start with tests of this device. For that purpose I used NI 845x USB to connect with accelerometer via I2C. Unfortunately, when I made electrical connections and set up parameters of communication and run the program (I found it in examples) the following error occured:
    Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi
    Possible reason(s):
    NI-845x:  An input parameter, or combination of parameters, is invalid. An example of this error may be setting an invalid baud rate or enabling I2C ACK polling while using 10-bit addressing.
    The code can be found in attachements. I couldn't find any extended description of this problem. What could be a problem: incorrect device address, register address, configuration parameters?
    Any help is appreciated!
    Best regards,
    Michael
    Attachments:
    General I2C Read.vi ‏24 KB

    Hi MicMac89!
    First of all could you please post which version of LabView are you using?
    Could you please tell me which version of 845X hw are you using? (8451 or 8452)
    I opened the example you attached. As you wrote the error occurs at the second argument of the property node. (I guess this is the first property node where the error occurs.)
    This argument of the property node enables the onboard pull-up resistors. But not all NI-845x hardware support pull-up resistors. (Because of this is important to know which hw version are you using.)
    Did you try the example with disabling the pull-up resistors?
    I suggest you to go through the Manual of this product, (if you did this not yet) This could make it clear where and when to use what kind of pull-up resistors.
    For example: If you are using 8452, you must enable pull-up resistors, for Vref ≤ 1.8 V for the FPGA to properly detect a low-to-high transition
    Manual: http://www.ni.com/pdf/manuals/371746d.pdf
    HW specification: http://www.ni.com/pdf/manuals/290598a.pdf
    Please post if my suggestions helped. Of course if you have any questions, don't hesitate to post them.
    Best regards, 
    Balazs Nagy

  • How to show/hide sliders on a slider control using property nodes?

    If I have a slider with multiple sliders on it how do I change which sliders are visible using property nodes? The only property I have found is making the entire control to be visible or not.  This is a possible solution to have two different controls, one slider with only one slider and another slider with two sliders overlapped, but not desirable.
    I found on a thread in the forum that it is possible but the user did not provide any specifics about which property it was. (http://forums.ni.com/ni/board/message?board.id=170&message.id=181279&query.id=34404#M181279)
    I would appreciate an example VI if possible (Preferred version is 8.5 but versios 8.2, 8.0, and 8.6 are available to me).
    Thank you in advance for the help,
    Aaron

    Just make them transparent! Here's a quick draft.
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    HideSliders.vi ‏20 KB

  • Disabled property node hangs loop

    I've got a parser loop, operating on streamed data from a CRIO via UDP.  The loop operates at about 90Hz.  In response to the user opening a file, the code will use a property node to enable (or disable and gray) a couple of boolean front-panel objects.  When these property nodes execute, I see the CPU usage (in Windows task manager) go to close to 100% and coincidentally, the parser loop hangs.  Other loops within the same VI continue to run.  CPU usage stays at 100% until I force a VI abort.
    With a small test-VI, I've noted that these property nodes require roughly 10ms to execute.  This seems quite sluggish, but nonetheless, my thoughts are that my code, running at 90Hz, would be able to tolerate a single slip of the loop execution time, particularly because the UDP data is queued.
    Any thoughts regarding this property node execution time or suggestions on how to improve the code?  Thanks in advance.

    Mark, thank you for offering to look at a stripped-down version of the code.  I just couldn't spare the time required to simplify our complex code.  However, I've been working on this problem in the past couple of weeks since I originally posted the question, and have made some progress toward a solution.  Although I still do not have a conclusive explanation for the Labview's behavior, I thought I'd follow up with a list of what appears to have made improvements to the code.  I'll concede that these suggestions are not definitive, but the problems are not repeatable and without any transparency into Labview's internal behavior, my analysis of the problems and my attempts to find a fix are admittedly speculative in nature.  Software development shouldn't be magic, but damn it seems like Labview requires we dance around a black candle.  Frustrating.  OK, exiting rant mode, here is a list of what NOT to do if you want Labview to be more stable:
    --  Do not use frames around your front panel objects.  Our main panel has approximately 100 front-panel indicators.  In an attempt to make the interface more intuitive, in a recent code revision we grouped the objects using frames.  The effect was a sluggish UI and a processor loading that went to close to 85%.  I'm aware from posts on this forum that overlapping indicators forces Labview to update all when any is updated.  This is an understandable coding contraint.  OK, fine, we weren't overlapping any idicators.  But for pete's sake, why should the same constraint apply to a purely decorative object like a frame?  This strikes me as a fundamental philosophical flaw in LV's coding.  Group N objects with a nice frame -- update the objects N-squared times.  If this is the result of using a frame, I would have preferred that NI not even offer the option.  Bad choice on the part of the Labview coders and bad choice on our part for assuming zero frame impact on performance.
    -- Do not use property nodes.  We occasionally gray-out front panel objects when appropriate for the state of the software.  This appeared to be contributing to Labview's instability.  I built a diagnostic routine that measures execution time for the "gray-out and disable" property node.  Generally around 8ms, but occasionally as high as 16ms.  Good grief.  I've got a code loop running at 90Hz.  A 16ms hit isn't easy to tolerate or frankly to understand.  Particularly when slow execution is the BEST of the consequences -- the worst is that the property node seemed on occasion to precipitate a hung loop.
    -- Do not use Labview's built-in queue structure.  Our code was originally using queues to hand off packets of data from a UDP-listener loop to a packet-parser.  The UDP-listener blocks on UDP reception, shoves the packets into the queue.  The packet parser blocks on data available in the queue and subsequently writes the data to file.  NI would have you believe, and I did believe for a while, that this is an elegant producer/consumer approach to this problem.  When our problem would occur, the UDP-listener continued to put data into the queue, but the packet parser would never retrieve it.  Just went off into nowhere, consumed and forgotten by the Great Labview Scheduler in the Sky.  The loop would hang, wouldn't respond to the stop button, would require a forced-abort.  Subsequently, if we simply restarted the code, we couldn't be assured that the packets retrieved from the queue would be in chronological order.  Seemed to be just randomly retrieved.  Clearly the failures had corrupted some of the Labview internal data structures that govern the queue operation.  We couldn't assure proper behavior unless we shut down and restarted Labview each time the error occurred.  The solution was to abandon code elegance in favor of sequential operation -- get rid of the queue, listen for the UDP packet then parse it immediately.  No queue handoff.  No further parser lock-ups.
    I'm not sure what other bombs might be lurking in our code.  Our listener and parser code hasn't lately hung, but the problem is starting to move on to other loops.  They'll run for hours and then just stop.  Dead.  Frozen.  In the most recent cases, even the abort button won't shut them down.  We have to use Windows Task Manager to kill them.  I'll admit to harboring some deepening skepticism for any of the more clever and powerful "features" that NI has added to LV.  From my perspective, these more powerful features cannot come free of cost -- they must impose some unavoidable computational burden on LV itself, a burden that LV seems unable to handle, with unpleasant consequences.  Must we impose a moratorium on Timed Loops?  Event structures?  To what level of simplicity must I drive our code to ensure stability?
    Thanks, everyone, for tolerating my frustration, and for your comments, if you've got any guidance you can offer.
    -dave sprinkle

  • Can I use the 'Export Signal Property Node' on a quadrature encoder?

    Hi,
    So I don't know which counter board I'd be using yet for this (it's used in conjunction with a PCI-6280--the PCI-6280's counter inputs are all taken and so I need another board), but assuming this is possible at all in DAQmx I wouldn't mind knowing whether, say, the PCI-6601 (or any other timer board for that matter) could do this. I'm programming this in LabVIEW 2010 by the way. 
    I want to have a counter which counts the number of pulses on one channel (I'll call this the 'clock' channel) between when another channel goes from low to high (which I'll call the trigger). It's basically a pulse width measurement, but I only care if there are more than n clock pulses between triggers. I need to have a hardware-timed digital signal which goes from low to high if there are ever more than n pulses between trigger changing state from low to high. 
    What I am planning to do is this: 
    Wire 'trigger' to the z-input of the quadrature encoder, and set the z-input value to some arbitrary large value such that, at the quadrature encoder counter task's settings, the counter reaches terminal count in n pulses.
    Configure the quadrature encoder counter using DAQmx Export Signal Property Node (tutorial I was looking at is here: http://zone.ni.com/devzone/cda/tut/p/id/5387 ) to toggle a digital channel ('counter event output') from low to high if the counter reaches terminal count (ie, if the encoder reads n pulses).
    If the encoder ever reads n pulses on 'clock' between two rising pulses on 'trigger', it sets counter event output high.
    Is this possible? Reading through the manual of M series PCI-62xx devices, the index pulse loads the counter with a particular value so it seems like you could conceivably set the counter to the terminal count if you wanted. My only real problem is whether DAQmx Export Signal Property Node works on all counter tasks or just on edge counting tasks. 
    Thanks in advance for your help. If this isn't possible, I can reply with more details on the problem this is supposed to solve so that you can help me figure out an alternate method.
    Solved!
    Go to Solution.

    There is probably a way to do it, but it it may be easier to use an X-series board for the job.   They support a new counter capability for count reset on a digital edge without needing to be configured in encoder position mode.  I am not sure exactly how that feature's been implemented however, so maybe it won't make things easier after all.
    The plan based on the hoped-for behavior: 
    1. Configure an X-series counter for pulse generation based on "ticks" of your clock channel.
    2. Set both initial delay and low time to the critical # of ticks.
    3. Configure for count reset on a digital edge (if possible in pulse generation mode)
    4. Configure the count reset value to be the critical # (or possibly 1 less, if possible in pulse generation mode)
    5. If you want the output to remain high indefinitely, configure the counter task to use its own output as a
    pause trigger, and pause while high.
    The way pulse generation works is to preload a # of "low time" ticks into the count register.  Then every source edge will decrement the count.  When the count reaches terminal count (0), the counter's output is toggled (or can be configured to pulse).  The register is then loaded with the # of "high time" ticks and the process continues.
    You would be perpetually interrupting the count-down process as long as you got your triggers in time.  The count would keep getting reset to the # of low counts, keep decrementing toward 0 without reaching it, and so on.  If ever you did reach 0, the output state would toggle high, then the high state would prevent subsequent clock signals from decrementing the count.
    You can conceivably do a similar thing with a 6601, but I'm pretty sure you'd need 2 counters working together to get it working.
    -Kevin P

  • Waveform Names to Menu Ring String Property Node

    Hi,
    I am extracting waveform data (names) to go into a menu ring as string data.
    It seems to work, apart from when you actually click on the menu there is no text (though you can successfully change it).  I am wondering if it is to do with the odd symbol in front of the name but not sure how to get rid of it.
    Hoping it is something simple but it is just knowing where to look with all the options available to you.
    Please see attached.
    Best Regards,
    James
    Solved!
    Go to Solution.
    Attachments:
    MenuRing.jpg ‏23 KB

    Hi James,
    You were 99% of the way there all you needed to do was to pull that weird character from the string, I used the “match pattern” function to allow me to isolate that character and pass the resultant string into the text ring property node. A good bit of advice if you find a character in LabVIEW that you do not recognise or if you are unsure about spacing, right click the output string and select “ ‘\’ codes display “ this will show what the code representation of the string is and you can just feed that directly into the “match  pattern” function. I have attached my code (LabVIEW 2010 if you need in previous version please just ask) for you to have a look at. I have used a producer consumer template and selected multiple input channels from a simulated PCI 6220.
    P.S. I’m not sure where that character comes from??
    Regards
    Andrew George @ NI UK
    Attachments:
    Forum James AC.vi ‏26 KB

  • Property nodes to items in cluster are FRAGILE

    This issue has bugged me for a long time .  I just got bit again and I wonder if anyone else has a workaround.
    I just checked and LV 2009 has it too.
    Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
    Make it a TYPE DEF (non-strict) and save it.
    Put an instance of it on a new VI panel.
    Create a PROPERTY NODE for item B and set it to DISABLED property.
    Wire a constant to that property node.
    Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant.  Fine.
    Now go to the TYPEDEF, and add another item, called A2 to the cluster.
    Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
    Look at your diagram.  The property node is no longer linked to B, it's now linked to A2.
    Apparently, LV uses the cluster order internally to keep track of the links.  So now I'm linked to A2, not B.
    If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
    But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
    I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label.  So if I see a discrepancy between the true label and the free label, I can recognize such a case.
    But that's only if I remember that this crap happens.
    Anybody got any better ideas?  How can I prevent, or at least recognize, such an unwanted change?
    Bonus question: the same thing happens with events, for the same reason (I suppose).  If I tied an event to item B, that event switches to item A2 behind my back.
    Steve Bird
    Culverson Software - Elegant software that is a pleasure to use.
    Culverson.com
    Blog for (mostly LabVIEW) programmers: Tips And Tricks

    CoastalMaineBird wrote:
    This issue has bugged me for a long time .  I just got bit again and I wonder if anyone else has a workaround.
    I just checked and LV 2009 has it too.
    Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
    Make it a TYPE DEF (non-strict) and save it.
    Put an instance of it on a new VI panel.
    Create a PROPERTY NODE for item B and set it to DISABLED property.
    Wire a constant to that property node.
    Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant.  Fine.
    Now go to the TYPEDEF, and add another item, called A2 to the cluster.
    Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
    Look at your diagram.  The property node is no longer linked to B, it's now linked to A2.
    Apparently, LV uses the cluster order internally to keep track of the links.  So now I'm linked to A2, not B.
    If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
    But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
    I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label.  So if I see a discrepancy between the true label and the free label, I can recognize such a case.
    But that's only if I remember that this crap happens.
    Anybody got any better ideas?  How can I prevent, or at least recognize, such an unwanted change?
    Bonus question: the same thing happens with events, for the same reason (I suppose).  If I tied an event to item B, that event switches to item A2 behind my back.
    For the disabled property inside of cluster whos definition hcanges... we are screuued.
    For the events your idea to include the text name, is the same technique that Jim Kring shared with us when he discovered the same thing can happen with dynamic event references. I belive that was CAR'd.
    No solutions so no bonus points.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Tab Page visible property node not working correctly

    I am making a vi in which we have a tab control with 6 pages and to move from one page to another there is ring control with option for every page on page 1( page 1 is the default page), at a time only one page is visible so we can move only through that ring control present on page 1 and to come back to page 1 from all other pages there is button "go back" on all other 5 pages, everything is working fine for 5 pages but when after going on page 6 and then if i press go back button instead of going back to page 1 program hangs and one more thing that i noticed is after stopping the program the page 6 becomes the default page( which otherwise is page1) i dont know why this is happening.
    I am attaching the snippet of the code which executes when i press go back button.
    one more thing that i am not getting here is when i checked the program through step execution, the last property node( page6 ) that is executing first after that it goes to first property node and then it goes in sequence, this also i want to how is this happening.
    Solved!
    Go to Solution.
    Attachments:
    tab page property node.png ‏43 KB

    I think you would be better off just to use your array and turn on/off the necessary tabs instead of explicity setting each property every iteration.
    Attached is one example.
    "There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
    Attachments:
    set visible tabs.png ‏56 KB

  • Setting DAQ channel by property node does not display the value

    I am writing a configuration VI to set channel selection and calibration parameters for an SCXI chassis. I store a default setup in a configuration (ini) file and read that file automatically when the VI is called. The value from the file are set by property nodes using the "Value" property. The values from the file do not display in the DAQ channel selection rings, but the numerical calibration values do display correctly. When I click the down arrow in the channel rings, the correct value displays.
    This behavior exists both in LabView and app-builder EXEs. Also, if I change the property nodes for the DAQ channels to local variables, it works. The Value (signaling) property doesn't cause them to display
    properly either. Why can't I use the property node?

    I don't understand exactly what you are trying to do.
    Please upload a simple VI to demonstrate the behavior you are describing. Remember also to attach the .ini file.
    Best regards,
    Philip C.
    Applications Engineer
    National Instruments
    www.ni.com/ask
    - Philip Courtois, Thinkbot Solutions

  • Use of multiple property nodes for GUI manipulation

    I have a LabVIEW 6.0.2 application where I'm using 14 different property nodes in the main loop. All of these have to do with GUI - hiding buttons when "X" isn't pressed, disabling and greying out controls if <0, popping one button on top of another depending on the mode of operation, etc, etc. While this works fine, the program is getting slow. I've noticed that using the old 2-D buttons works faster - things update faster and redraw quicker. However, more to the point, I once read that if you have to use a lot of Property Nodes like this, that you should bundle them into a sub-vi, thus replacing what would be Property Nodes with references. How does that make it faster?
    Richard

    Not sure if bundling them into a sub-vi by itself would make it faster. The nodes in the sub-vi would still have to access the user interface thread, and that's where the slow down comes from.
    When I use any property node, I put it in a case structure and only write to it when needed. You just need to be able to detect when the value being written is changed from last loop iteration. It's useless to constantly rewrite the same value (doesn't have to be the "value" property) to the node.
    Bundle them into a sub-vi and put the change detector, case structure and nodes in the sub-vi, this should help speed things up a bit. Assuming of course that the nodes are the slowdown. It may also help clean up the diagram a bit.
    Ed
    Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
    Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Maybe you are looking for