> Such a stop however cannot be a latch. Since locals are a copy of the data > of the original, it may take more than 1 loop to ensure that all locals are > updated. One way around this which seems to work for me, is to use a > property node instead of the local. Again this cannot be latched. > [However, to have a user latched button, you can use a simple latch button > to drive a hidden 'Stop2' button which has the local or property node > pointing to it. Then your main user Stop can be latched.] > > For the EmStop, OR's of property nodes (you need both loops to have OR's) > may work faster. Property nodes (as I have understood them) are basically > pointers to the data of the main var. Hence, the prop value is immediately > updated as there is no copy required. You will in any case, still need to > wait for every loop to run at least once. This means that you need to ensure > your loops have say less than 250ms delay times (make sure all loops have > some delay, even if =0) to be less than human response times. >
I feel obligated to jump in anytime someone jumps to this conclusion. Property nodes aren't pointers either. They are references to UI objects, not to data. The property value makes a value copy, just like the local, and in fact has even more runtime overhead. If you want to latch a button with locals or property nodes, set it back to its default whenever all of the reads you are interested in have taken place. LV has no way of knowing when you'd like it to be latched, after the first read, after all locals have read, etc. Since you are using locals anyway, just write to it to pop it back out. Greg Mckaskle
