Yair

Looking at it now, it's actually not working at the moment, so either I was mistaken last time or something's going on.

The problem was not with getting to the first post (although there were times in the past where there was such a problem too). The problem was with the next page being marked as read even if you didn't go into it. As said, it currently seems to work correctly.

Check out this long thread which referred to this issue with probes (which I'm assuming is what you're looking at) - http://forums.ni.com/t5/LabVIEW/What-does-quot-refnum-not-valid-in-this-context-quot-mean/m-p/1048044#M465846

This seems to have gone back to working correctly.

This would also be the right place to mention Altenbach's flat controls idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Flat-controls-indicators-and-containers/idi-p/919361

Mikael, this is about the UI itself.

You can use a classic array with a classic simple numeric control, which gets you fairly close.

Another alternative is using a table or list box and overlaying the actual control over it on a mouse move event.

Other than that, I believe it's down to directly editing LV resource files.

I once blindly implemented this algorithm which is supposed to find the optimal setup for a grid (although I didn't bother to clean it up or optimize it, since I never found any actual use for it) and running your VI through the test cases shows a couple where your results are different. You can see the attached code which includes the test cases.

Max squared.zip

There's a utility which does this here, but it requires installing the JKI RCF for accessing the right click functionality. You can either install it or try adapting the tool to something you can use, like a QD shortcut.

Another option is to set your accessors to be available through property nodes and then you can easily select them just like any other property. This doesn't apply to all the VIs in the class, but if many of them do have a single parameter, it can save you enough time to be worth it. I think it's worth it anyway because it makes the code much cleaner and easier to read.

Bjarne, I would also suggest voting for this idea, so that NI fixes the problem if it still exists:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Get-rid-of-the-second-LabVIEW-window/idi-p/1444130

If you do make XControls, you could probably have the it initiate a separate process when it's dropped which will receive the references to the dropped controls. The process will then delete the XCtls (or it could possibly be a single XCtrl and it will replace it with two clusters), replace them with error clusters, wire them and then terminate. I don't know if this has any potential pitfalls, but it seems like it should be doable.

Incidentally, I hate the no error text on the error cluster. If you're already making a template, you might as well remove it (and of course get people to vote for the relevant ideas:

Get rid of the "(no error)" part of the error cluster

Show the default value of controls in subVIs which aren't required in the tip strip

).

I ran into another similar concept, but one which looks more practical - littleBits.

There's a nice TED talk where the creator demonstrates how it works - http://www.ted.com/t..._and_teach.html

Even if it would, creation of an new object should be fairly cheap, as it's just 3 pointers, since objects share the same copy of the default data of a class.

Was it really “half-valid”, or just invalid but non-zero?

Like I said, I think it worked for some of the things and not for others, but it was long enough ago and unimportant enough (it wasn't my code) that I don't remember for sure. It's quite possible that it was just a number.

The main thing that annoyed me then was that the AEH was disabled, but the error out terminal was not wired, which was what caused the error to be effectively invisible.

And then the VI's that do work (like enqueue, TCP write, Start Async Call, Generate User Event) return errors, does that mean that they failed completely? Is it possible the function was actually successful, but still returned some kind of error?

A long time ago, in a version far, far, away I was asked to debug an issue where a property or invoke node wasn't working properly. I think it was returning error 1, which I couldn't understand, since the only relevant input was a VI ref and it was getting that directly from the open VI ref primitive and the probe showed a value (and I think it worked for other things). It took me a while to get to the answer - the OVR prim was returning both an error and a reference and I didn't see the error because auto-error-handling was turned off and I was expecting it to be on. Once I saw the OVR error I figured out what the problem was with the OVR prim.

I really don't remember the details of what caused this, and I'm assuming that a situation where OVR returns both an error and a half-valid ref is a bug, but it looks like it still can (or at least could) happen.

P.S. It's also possible that the issue was with the open app ref primitive, but the concept is the same.

Check the size of the files compared to the size the FTP client says they should be. My guess is that the files weren't downloaded fully (something which can happen with FTP) and AVI files are built in such a way that the file can be played even if you only have part of it. I can say that I watched quite a few of them fully.

If this is really the issue, you could try another FTP client (such as FileZilla).

And I don't really see the need for that.

These days, no, but back in 2004 Scan From String didn't know how to parse a time string into a time stamp. I believe that was added in 8.0.

And just to clarify Ton's point - you can input the same format string into a Scan From String function and get out a time stamp.

Middle Class Rapper

Is it sad that I knew exactly what that link would point to?

"which moon are we talking about?"...

Well, I'm certainly no expert on P2P architectures, but my understanding is that some of them (at least those that work over the web) do rely on some nodes functioning as temporary servers (at least for facilitating connections). The Wikipedia article seems to suggest you need an overlay network, which is used to connect any two nodes which know each other. This is basically the direct TCP connection I suggested in my first reply (which applies to all nodes, in your case).

I don't think I would personally use SVs for this, mainly because they're designed for passing data, not commands.

UDP may not be reliable, but I don't think you have any other choice. Without a server, your choices for discovery are either cycling through all available addresses (probably impossible, since they're not all on the same subnet) and broadcast, which I believe only UDP can do. The fact that UDP is not guaranteed to get your message across shouldn't necessarily matter, because you keep transmitting it regularly and once you form TCP connections, your communication path is guaranteed and you can also use the TCP connections to pass along messages such as "I found this new guy". The only thing you have to make sure of is that the UDP messages can get to all nodes.

I think the main issue you would have with a no-server system is making sure that you don't have conflicts in the network. In classic P2P systems you don't have this issue because each node has to work with N other nodes, but it doesn't have to do any coordination. If you look at file sharing, for instance, a node might say "I want this part" to one node and "I want that part" to another node and the receiving node will make sure that it got all the part and put it together correctly, but that has nothing to do with the other nodes.

I think this would require you to be able to change at least the number of nodes you're waiting on dynamically (e.g. if more nodes were added to the system while you're waiting) or coordinate and lock it in place when you start waiting, otherwise, you will have the option for race condition. That means that when the first node wants to start waiting, it has to send a message saying "these are the nodes I'm waiting on" and it has to receive a confirmation on that from all connected nodes before proceeding, and all those nodes then have to agree to not add anyone to that list until they're done waiting. They can agree to take someone off, but not to add.

Well, I think it's mainly a matter of taste. I remember trying The League (and AHS) and not liking it and I had to start The Big Bang Theory three times because each time I stopped after a few episodes and even then I stopped again after a while. Personally, I was never that kind of involved gamer (and MMO's are not my thing), so for me it's mainly the writing and the details (like the "5 6 7 8 9 hours a day" limit post-it which you see about a minute into the first episode).

Keep in mind also that this was designed for the web. An episode is generally less than 10 minutes and they can be very condensed, so taking too much in at once can be hard (or borderline painful, as you found out).

What I understood from your original post is that you're working on a completely ad-hoc system. If you have a closed network which you can control, I would suggest using a server for this, which then makes the issue much simpler - every program talks to the server and it decides what to do. Then, all you have to worry about is various race conditions and what happens if the server is inaccessible (basically the system is dead).

Is having a server a viable design?

The question becomes: can I create and destroy these variable at runtime? Can others find them at runtime?

I'm pretty sure you can create, destroy and access SVs dynamically, but the key point is finding them - that's where the UDP broadcasts I suggested come in, as they allow others to find you.

All machines would be on the same local private network, but not necessarily the same sub-net.

This may also be an issue with UDP. UDP broadcasts have a limited life-span to avoid bouncing all over the internet. They won't necessarily reach every node.

There are a number of considerations here to be aware of:

1. Once you're working across machines, things are not instantaneous. Unlike a RV, where everyone is guaranteed to get it "at the same time".
   
2. That also means that you have potential for race conditions. For a RV, you have a single arbitrator. Here, you have multiple entities with no arbitrator.
   
3. Firewall issues. You need to know that everyone is accessible.
   
4. What's the logic? Are you saying "once I get to this point in the program, I need to see that everyone else has also reached that point before I can proceed"?
   

Assuming the answer to 4 is yes, here's a basic design. It's probably full of holes.

1. Each program needs to continuously advertise itself (its IP address) with UDP and listen for all the others.
   
2. Once a program hears another program, it needs to open a TCP connection to it (so you have N squared connections. This will be an issue if N is large).
   
3. This TCP connection is basically what you use to tell each of the other programs "I reached the RV".
   
4. Since each program holds a connection to every one of the other programs, you need to see that all of them have sent the OK signal and then you can proceed and reset the RV.
   

Some issues with this:

1. What happens if only some programs hear the UDP call and not others? You will have a big bug where some of them proceed and others don't.
   
2. What happens if someone disconnects in the middle?
   
3. What happens if someone connects in the middle?
   

Another option is to try to negotiate between the different programs to decide who's the master. This master will be the one who decides when to proceed and will regularly inform the others of the current status, so that if it's taken down, someone else can take over. I have no good reference for a master selection algorithm (I have done one in the past, but it relied on having a fixed point in the system), but I'm assuming there is some material on this. I'm guessing that mostly in involves the various programs shouting "I'm here" and waiting until enough other programs agree on which one is the master with a certain algorithm to make certain programs more likely (e.g. the lower the IP address, the better).

I like the idea behind the movie. Looks cool.

Wasn't this a Doctor Who episode a couple of seasons ago?

There were a couple of somewhat similar DW episodes. I'm assuming you're thinking of this one.

There was also a movie - http://www.imdb.com/title/tt0298814/

Can you give a teaser on why it's so good?

Well, looks like you're willing to check it out already, so no reason for that, but for those who do need a reason - it's funny. Just check it out.

Spam?

No, that's Monty Python. Come on!*

I didn't make it through the first season.

Well, be aware that the first season was made by inexperienced producers with such a low budget that it had to be shot in two separate blocks. But the humor and style are basically the same.

* No, that's Arrested Development. I fear I may be going into a cycle here.