Jump to content

Property Nodes and Local Variables


Recommended Posts

I have often broken the rules about using property nodes for writing values. Typically I will break this rule if there is a need to dynamically change control states of controls in various front panels usually to update a control state that was changed programmatically or in another vi. These are situations where changes may happen every few minutes as opposed to every second. Other situations are for setups where I edit a spreadsheet or INI file. In these cases I rationalized the methods are acceptable because speed is not a major concern with these interfaces and I will typically have a reference number for these controls available from the event structure.

Here is a setup file where I use a standard table control to edit tag names and report status for channels. In this case I wrote to a local variable in the master loop where I would normally have used a property node with reference wired to it.

Question: Is there a great advantage of using the local variable here over the property reference method?

I respect the opinions that many of the users share in this forum. I expect to hear some criticism and see better way's of accomplishing this. Also if there is anything in the vi that you may be able to use feel free to take advantage of it.

For this example these basic rules are utilized.

Col 2-4 can accept only YES or NO

Col 0 cannot be changed.

Col 1 name can be changed but must be unique within that col.

I have used a standard spreadsheet file format. The first row is used as column headers for the table.

Your comments are desired.

Thanks,

Randall

Download File:post-274-1127250963.zip

Link to comment
Thank you for sharing the VI.

Here's some good info' on Property Nodes versus Local Variables:

http://zone.ni.com/public.nsf/websearch/74...47?OpenDocument

Regards,

-Khalid

Thanks for the information. I often wonder why we are given programming tools then warned not to use them. If I understand this article correctly, we can expect better performance with the terminals, then locals as opposed to property nodes by reference.

Yet in some cases where performance is not as critical I see the property nodes as the most practical way of accomplishing a task.

Thanks,

Randall

Link to comment
Thanks for the information. I often wonder why we are given programming tools then warned not to use them.

Thanks,

Randall

I think it helps to know the limitations of the tools you have at hand. The idea of the references etc. is to clean up your top-level diagram, and bury property manipulations in a sub-VI.. a VERY useful function, but it has its cost.

Neville.

Link to comment
I think it helps to know the limitations of the tools you have at hand. The idea of the references etc. is to clean up your top-level diagram, and bury property manipulations in a sub-VI.. a VERY useful function, but it has its cost.

Neville.

I'm going to use references in my next project... could you be more clear about the "cost"?

I know that if you change anything during building your aplication you have to change it in every VI (the same situation with clusters).

What about time? Are they (references, clusters) causing the program works much slower?

Link to comment

Great post and great question.

I started Refactoring your program to see if I could come to a decent answer.

When I was finished I had eliminated the value properties by sending the data through the Queue.

The final program was a little more flexible and easier to change the User interface.

Download File:post-584-1127453851.llb

Link to comment
Great post and great question.

I started Refactoring your program to see if I could come to a decent answer.

When I was finished I had eliminated the value properties by sending the data through the Queue.

The final program was a little more flexible and easier to change the User interface.

Download File:post-584-1127453851.llb

Thanks! :thumbup:

I really liked the idea of moving the table modifications to the lower loop.

You nailed me on the error trapping. I often build quick examples without the error trapping. Later I end up modifying the example for use in an application. I loose as much time editing these programs as would be lost error trapping the examples. Thanks for the prompting here. :oops:

At NI week once, I thought it was taught that without the shift registers the program would need to generate a new copy of the data with each iteration. Also in some earlier versions I had some applications that appeared to loose the value inside a loop after executing several times. These may be figments of my imagination. I checked the buffer allocation and it doesn

Link to comment
Thanks! :thumbup:

I really liked the idea of moving the table modifications to the lower loop.

You nailed me on the error trapping. I often build quick examples without the error trapping. Later I end up modifying the example for use in an application. I loose as much time editing these programs as would be lost error trapping the examples. Thanks for the prompting here. :oops:

The file IO was the only one that concerned me. When I see file IO I think errors.

At NI week once, I thought it was taught that without the shift registers the program would need to generate a new copy of the data with each iteration. Also in some earlier versions I had some applications that appeared to loose the value inside a loop after executing several times. These may be figments of my imagination. I checked the buffer allocation and it doesn
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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