Yair

I haven't really played with the thread priorities too much either, but you can set a thread and priority for each VI in File>>VI Settings>>Execution. I'm not sure that this would help, because I think what you're seeing comes from Windows itself which takes the CPU from LabVIEW, so maybe increasing the process LabVIEW process priority in Windows will help, but even then you're not guranteed to have your timing. As for the DAQ timing thing, I suggest you search Kevin Price's posts, because I think he was the one who refered to it. Basically, the concept was that you set a task to perform at a known rate (let's say every 50 microsecond) and then you get a trigger in LV every 50 microseconds.

QUOTE(LV Punk @ Jul 27 2007, 04:13 PM) I don't think that can be done. MIME types are relevant if you're handling binary data as an attachment or embedded content. In this case, you're simply asking the server for a file, so there should not be any MIME data.

Yes, while your CPU can perform operations very fast, Windows is a standard OS and as such does not gurantee timing. It can take the CPU from you and cause LV to wait every once in a while for its own purposes. See here and the posts it links to for some more details. Some options: Use a real time OS with LabVIEW RT (see crelf's blog). Increase the priority of your process and thread both in Windows and in LV. If you have a DAQ card with a hardware timer, you can use its triggering to get more accurate timing.

The type input defines the LabVIEW data type (e.g. you might be sent a 1D array of DBL), but the data you download from the web is not a LabVIEW string. You just want it as a LabVIEW string because that's how your file primitives let you save binary data so you have to tell it "don't do any type checking and conversion. Just get me the data".

QUOTE(crelf @ Jul 26 2007, 10:05 PM) I guess I managed to edit that one out of my consciousness.

QUOTE(orko @ Jul 26 2007, 10:18 PM) The way I understand it, the [text] part has nothing to do with MIME types and simply tells the primitive to retrieve whatever is at that URL as binary data represented as a string.

Unless you're constantly building arrays or concatenating strings in a loop, your memory consumption should probably not be a problem. That is assuming you don't have any very large structures (tens or hundreds of MB). The main reason for not using globals is that it's usually fairly easy to create race conditions which will cause bugs in your code. Other options of transferring data and synchronizing include queues and LV2 style globals.

QUOTE(crelf @ Jul 25 2007, 10:19 PM) Is that Jim's sister? QUOTE Does anyone have anything else they'd like to donate to add to the list? Well, I could supply a signed collection of my posts (both from LAVA AND the NI forums!) and I'm expecting to collect a bunch of pens at NIWeek which I could donate. :laugh:

Welcome.

It's fairly easy to roll your own solution. See the attached for a quick example (7.0). Place the LLB in your LabVIEW\Project folder and when you restart LV you will have the Callers Browser... option in your Tools menu which will launch this VI and call it using the VI you opened the tools menu from. Note - this is just a quick example based on another quick example. It was meant as a proof of concept, not as an example of good UI or code. I suggest you fix it up (for example, call it This VI's Callers) and change its UI to look like LV's menu and add an option for refreshing (or auto refreshing) the list and upload an updated version both for this and for a VI which will show the callees.

QUOTE(ragglefrock @ Jul 25 2007, 06:21 AM) That's really nice. :thumbup: I knew that the picture control was a string and I knew that you could concatenate it, but I didn't realize that it overlays the images.

I thought about creating an engine for doing this myself (i.e. each object could be anchored to each corner horizontally or vertically and could have its private resize settings), but when I figured out how much work it would be to handle this for each class I basically gave it up (and that's even before mentioning that there were some things that would have to be worked around). The basic concept was that the resize\anchor settings would be stored in tags and the engine would read them and control the resizing of all the objects.

Two options, off the top of my head: Disable the grid lines for two of the scales. You can do this in the graph properties or using property nodes. Use a picture control to display the graph and add the lines yourself. The picture control palette has a palette for creating graphs. I would go with the first method. You just need to decide which scale will be best.

Cross post. Jason, cross posting without including a link to the other thread is considered impolite. Simply taking the example posted to the other thread and posting it here without any mention of its source is almost downright rude. You're causing people to think that you created something like this and that you just need "a little help" when in fact it seems that you need basic LV training. As said in the other thread, you will need some fairly good understanding of LV before you can do this yourself. It's not super complicated, but it will require a fair amount of work to work properly.

When using a static VI reference, the VI is held in memory just like a regular subVI you would call from the calling VI, so the answer would be yes. You can actually double click the reference to open the subVI. At least, that's the way it worked prior to 8 and I don't suppose the project changed that.

The 3D graph is an ActiveX object, and as such you need to use ActiveX methods. In this case, it's literally a method - you need to use an invoke node and call the Item method, which will return a reference to the cursor, which you can then handle. I'm guessing the way of identifying an Item is by using its index, but I haven't checked it.

Using the locals is definitely better than using the stop primitive and as Dirk mentioned, a state machine architecture would probably help as well. A more elegant option for stopping multiple loops (or even VIs) is to use a USR global, similar to the one shown by mballa here. If you want a simpler version, you can simply have a VI with two boolean inputs like this and place it in the boolean wire. Stopping any of the loop will stop all the other loops. http://forums.lavag.org/index.php?act=attach&type=post&id=6437 P.S. If you're upgrading, go to 8.2 or wait for the next version, which should come out soon. Don't get 8.0.

Actually, I was thinking of Brian Powell and just thought for some reason that Steve Rogers was giving that session. XControls are nice, but ultimately, they are complicated and are still a relatively minor feature which I doubt I will use in the near future. Michael, how would you justify going to that session over a session which talks about how NI works when desigining LV? P.S. Am I the only one who thinks the online scheduling interface for NIWeek mostly sucks?

It seems to work fine in 7.1, even after playing with the size of the while loops. I would guess this was some sort of bug which was fixed. Do you happen to have 6.0.2 which should have some bug fixes? By the way, in general, there are several things I would change about how you do this. For example: You can move the entire password part into a dialog subVI and use a boolean output for the status of the password. The rest of the code is in the True case of a case structure which only runs if the password status is T. Also, I don't think there is any need to inform the user that the password is correct since they will realize that when they see their program is running. You don't have any wait primitives in your while loops. This is very important because if you don't use them, LV will use all the CPU. This might even be the cause of your problem. Using the Stop primitive to stop the VI is bad. Instead, you should do what I mentioned before.

Michael, why did you have to be up against Steve Rogers?

QUOTE(Ben @ Jul 23 2007, 06:53 PM) Now, that's just silly. Where did you get that idea?

Another option is that the tab control is disabled (right click>>Advanced>>Enabled State), but I would agree the indicator option seems more likely.

QUOTE(Dirk J. @ Jul 23 2007, 10:49 AM) I was refering to the one you posted earlier, which was essentially the same thing, just without the uParam cluster. Even if you are confindent that the application will run only on Windows, encapsultaing the functionality is recommended so that you can at least replace\change it easily if the need arises.

http://forums.lavag.org/index.php?act=attach&type=post&id=6423

QUOTE(Dirk J. @ Jul 20 2007, 05:03 PM) How is that one any more pure G than the other version? The problem is that uses OS API functions, which in this case will only be available on Windows. I did all my LV work until now on Windows (some of which included interacting with .NET, which is definitely purely Windows so far), but I prefer to avoid OS calls if they are not necessary. In this case, I consider LV's dialog to be good enough, but if I wanted to use this one, I would probably wrap it in a dynamic call.