Yair

That's incredible. I wonder how long it takes before these allow better control than the existing limbs. There are already experiments with exo-skeletons which allow soldiers to carry great weights and I seem to remember that professional runners are already complaining that runners with artificial legs have a fair advantage. Before long, we might be seeing basketball players or weight lifters complain about these guys.

Chris, how did you know? Incidentally, in my previous line of work part of what I did was very similar to tagging and was required. I think I did enough tagging to last a lifetime.

If you really want to do this using the formula node, you can try declaring the output as a U8 array and using that as the string. To easily convert the string, you can use the String to Byte Array primitive and either use that as an input or as a constant inside the formula node. You can then use Byte Array to String on the output to convert it. Of course, I don't think the formula node is able to do something like printf anyway, so you will be doing a considerable part of the code outside the formula node.

QUOTE (crelf @ Jun 1 2008, 10:44 PM) My thought exactly! QUOTE (Michael_Aivaliotis @ Jun 1 2008, 10:57 PM) I don't get it. Grog is an important part of the MI games.

I just realized that with my newfound embedding abilities this thread is perfect for hijacking and turning into all things Monkey Island . Note: this video is supposed to have the text "Deep in the Carribean Monkey Island " appear at the beginning, but it doesn't. It makes it more funny, so just imagine it there. And the inevitable mashup:

In case anyone runs into this in the future, here's how to do it.

Note: This feature is limited to Premium Members only Turn off the rich editing mode (you want your html tags to be preserved, and rich text editing will try to make hyperlinks active): Paste the embed code: Select one of the HTML On modes (HTML Code - Auto Linebreak Mode will allow you to include other non-HTML text in your post too, as it will convert CR+LF characters to HTML linebreak tags, whereas HTML Code - Raw Linebreak Mode will interpret everything in the text field as raw HTML): Post and be merry (or, if you want to make sure that everything is formatted correctly, click Preview Post) I would like to thank crelf for providing the images and showing me the elusive step 1.

That's a great idea. I really can't comment on the code (other than that it looks good) because I didn't look deeply into it. Stupid question - wouldn't the implementation be simpler if you used wrappers for the queue functions and then used remote CBR calls to call those wrappers like shown in the other thread?

Still can't embed, so: http://www.youtube.com/watch?v=Ni_rAamVP2s

Thanks, it already looks better. QUOTE (Michael_Aivaliotis @ May 30 2008, 08:12 PM) To be frank, it's too much of a pain. Tags are only really useful if you use a limited subset and that requires discipline and some automated tools. Ben has his auto tagger, but I don't always have LabVIEW open and I can't say I really feel like coming up with\learning\using the relevant set of tags.

Is there any option of hiding the tag section of each post (it's visually distracting)? I didn't see any obvious options in the control panel.

I still don't know if this is a bug or not (there may be a reason behind the design), but when you enable the TCP connection of the VI server it takes the default values rather than the ones you just set. If you enable the TCP connection first than the code should work fine. In any case, I reported it to NI.

QUOTE (Michael_Aivaliotis @ May 30 2008, 08:25 PM) I'm sure "they" are hard at work...

Clicking on PMs in the inbox also produces a blank screen.

I believe the terms "context" and "instance" are interchangable in this case. I personally prefer "application instance". An app instance determines all kinds of things. Here are some examples of things that have to be unique within an instance: Queues, notifiers, etc. VI names (CTLs, standard VIs, global VIs...) To open a reference to an instance, you use the Open App Ref primitive and give it the machine address and port number. The port number is what determines which application instance you connect to. Another key point is that if you want to connect to another instance in the local machine you HAVE to connect something (e.g. "localhost") to the machine name input, or it will open a reference to the current instance. This is most likely the source of your problem. Once you have the application reference, you can operate on the VIs within that application (at least the ones you have permission for). As for using the VI name - as I mentioned, the VI has to be already loaded in the application instance you're using. In this case, because you didn't actually connect to the other instance, you got the 1004 error because the VI was not loaded in your instance.

Thanks. :thumbup:

As far as I can tell, the issue here is with the programmatic setting of the VI server properties. It looks like the settings are only applied after the VIs in project A go idle. I'm not sure, but I think this is a bug. In any case, if you run the VI from project A, stop it and then run it again, the FGV should work in project B. For me it worked earlier because I set the settings manually (by right clicking the My Computer icon). As a minor point, if a VI is in memory, you can use its name to open a reference to it instead of its path. Makes you less dependent on its exact location.

I made no modifications to the FGV. I just placed the VIs in different projects, enabled the VI server access on the "cFP" project (make sure your firewall allows that traffic and that you use a unique port for that project) and pointed the "PC" VI to that port. QUOTE (Antoine @ May 30 2008, 01:08 PM) It shouldn't be any more difficult. As mentioned in the other thread, the key is using a unique port number for each application instance. When you work with another target it's simpler, because all instances default to port 3363, so you don't have to change it.

I'm guessing that the front panel needs to be at least loaded for the set control value method to work. You can test this by adding a property node for one of the controls to the code. The better solution is to use the call by reference node. You're already opening the reference with the VI refnum type, so this should make it much cleaner and easier. A simple modification and testing of this example on two projects seems to work fine when the FP of the FGV is closed.

QUOTE (PaulG. @ May 30 2008, 12:14 AM) I figured as much, but didn't feel like searching to make sure this isn't something that does exist and which I don't know about. For example, http://en.wikipedia.org/wiki/User:Kieff/Square_sine_and_cosine_functions' rel='nofollow' target="_blank">here's someone who thinks such a thing should exist. Anyway, from looking at the code it's clear, as Ton said, that it's a selection between a sine wave and a square wave.

And what's nice is that the sequence structure is actually designed to look like film.

QUOTE (orko @ May 29 2008, 10:55 PM) I don't speak French either, but I know that sinus is a sine and Google says that carré is square, so I assume it means "square sine wave". I'm not sure whether your wife will appreciate that or not...

Thanks, I added it to the list.

QUOTE (neB @ May 28 2008, 08:03 PM) Just look at the picture. It clearly is an older version. My guess would be 6.0 or earlier. As for the Project menu item, that's easy - it has nothing to do with the current project concept. Ever wonder why you have to put VIs in the "Project" folder to make them appear in the Tools menu? That is why - backward compatibility. As for different wires crossing each other, that was my initial guess, but it doesn't fly - when wires cross in newer versions they always have a boundary.