Yair

I can tell you... but then I'd have to kill you. :ninja:

Yes, that's what I meant. I seem to have forgot that the size asked was for was the size of the structure and not the string. I learned something here. I didn't realize the size allocated for the string was set. Is this a standard thing in windows API functions where you're expected to input a size? I would expect it to be, but I never noticed before a place where you have an additional piece of data which can be found in the header file. Then again, I never looked very hard into this. You have to wonder what's the point of using null terminated strings if you have a predefined size. Is this something required for C compatibilty or is just to make it easier for C programmers?

I have seen something similar, where while talking to the device I would get rubbish and even after disconnecting the device, I still kept getting an answer from the port. What was needed in that case was to go into the windows device manager and properly configure the port number to talk to the "real" virtual serial port and not to the fake one (although I don't remember exactly how at the moment, but it shouldn't be complicated).

You should never have loops inside your program which don't have some sort of delay mechanism (usually a wait primitive or a timeout). Even an empty loop with no wait can cause LV to get your CPU usage very high and there is definitely no telling what LV will do with 2 loops without a wait statement. If you wire 0 into the wait (tells the loop to iterate if no other process needs the CPU), you will probably see more or less identical times as well. Real time systems are systems which run on RTOSs (you got that one right) and the special thing about such systems (if built correctly) is that they are always supposed to respond within a given a time period. Unlike OSs like windows which don't give you control, An RTOS will allow you to set your own priorities and be much more precise.

I believe that the overlapping should be avoided for the entire rectangle. As far as I know, LV does all of its graphics on its own (to support multiple platforms) using MESA and so it is not as efficient and fast as controls displayed in other compilers which presumably use the OS and hardware support for display.

That's nice, but you still need to know the length of the string. You input 34 as default, but this is not enough on my system and some point inputting an arbitrary larger number could return invalid results or crash LV. If there is a function which returns the names of all devices in advance you might want to use that and add the rest of the bytes to the length of the string.

Dynamic VI calls are not supported in the PDA module. I haven't worked with DLLs in the PDA module, but it sound to me like what you might need is to create a specific loop for the DLL call (with a case structure) and transfer the data between the loops. You should be careful when doing this because my experience has shown that the PDA module does not always like multiple parallel loops. Also, you should think about how much non-blocking you want this to be. For example, does the PDA return information which you will use? If so, how long will it take before you will need to receive the information? If you will want to do several calls in parallel that will mean that you will need several loops and synchronizing them could be a problem (not to mention the performance issues and the possible increased memory consumption).

That file will probably prove to be useful in the future, but I doubt it will help the original poster, as it still seems the length of the string needs to be known in advance. Thanks for the file.

Basically yes, but I'm not sure what the problem is. For one thing, you're using I32 for the words, which is wrong. You should use U16 or I16, but I am not sure this would necessarily cause a problem. The other thing is that I'm not sure whether you can use a LV string to represent a null terminated string inside a struct. Also, I think you might need to use Handles by Value. The last thing, and this could be the source of your problem is that your inputs are wrong. You're inputting 1 as the number of the device (if you only have one, that should be 0) and you're wiring 0 as the number of bytes. The number of bytes is probably the trickiest thing to calculate as it seems you will need to know the length of the string. I suggest you try digging up some more in the page I linked to or, if you're lucky, wait until Rolf will explain what went wrong and whether you will need a wrapper DLL.

Sure you have, just look at the last paragraph of my first post. It's a front panel property which tells LV not to update it unless absolutely necessary. You can get it to it by wiring the VI's Panel reference into a property node. Remember that there is no point in updating the display too much. More than 10 times a second is usually something that's too fast for most people. If you tell us what you're actually doing, that might help.

To be honest, clicking the picture does not sound like an intuitive step to me, but then the IE way isn't perfect either. There are 2 context menus which appear if your cursor is over the picture long enough - one allows things like printing, saving and so on (which are also available from the right click context menu) and one which allows you to enlarge (which or some reason does not appear in the RMB menu (they forgot?)). To make it worse, the menus appear on opposite corners of the image and neither of them is particularly easy to see. It seems that once you know how to use the Firefox way, that's a better solution. In any case, I just have the option disabled.

The blinking rate and color are global properties and can only be set from the LabVIEW options menu, inside the Front Panel and Colors pages. You can do this programmatically by modifying the Colors[] property of the LED, but that would be significantly more complex.

You can usually build such structures by using a cluster (in this case it's simple since the structure only has simple data types). To get the value by pointer you set the parameter to "Adapt to Type" and wire the cluster you built into the input. This will cause the DLL node to allocate the memory for the structure and will feed it into the output cluster. Note that some of the parameters are byte-order sensitive and that to wire in constants you need to know their numeric value (which can be found in the header files). More information about working with DLLs can be found here.

Serial communication in LabVIEW works through the NI-VISA infrastructure. All the VIs you need can be found in the Instument I/O>Serial palette. You don't have to open the port (although you may need to configure it), but to close it you use Visa Close. You can probably find quite a few examples in the example finder (Help>>Find Examples). You should try looking up some tutorials to learn more about LV.

A tab is simply a numeric control which appears as a terminal in your diagram. Create a local variable of it and you can wire any one of the pages into it.

Slides and knobs are only continuous if their type is a float type. If you make them integers they will work fine. Here is a quick example of a customized knob. Download File:post-1431-1137581878.ctl

True benching of a computer can not be done over the space of a few seconds since you have no way of knowing what else the computer is doing at the moment. If I remember correctly, most benching programs (and there are quite a few around) take at least 30 seconds to perform each individual test (I think the common ones test things like 3D display, File I/O, real processor speed and so on). Also, simply running a loop is not a very good measure of how a computer would handle LV applications. It will give you a single number, but you might find out that some computers will be much slower or faster in doing certain types of operations and this will not be reflected in your test. Generally, benching involves running several types of tests to check for different kinds of requirements. Additionally, using a for loop would allow LV to better optimize the execution and refreshing the display inside the loop is what would actually cause most of the overhead, unless you defer the panel updates. You should also consider that different LV versions also affect this, so to get a single meaningful number you will need to compensate for all kinds of factors.

At least in IE, the browser resizes images which are larger than the display to fit the display by default. It seems to use an algorithm optimized for speed and not for quality, which is probably why your image looks weird. To see the image at its real size, you need to enter the picture with the cursor, wait for a couple of seconds and then you will get an option to do this. You can also disable the option completely.

There is no built-in way to do this, but you can write code which will do this. The key to what you want is some Application class properties and methods, namely the Remote Panel>Connection to Clients property and the Remote Panel Client Release Control method. If you drop property and invoke nodes (in the application control palette) they're configured to the app class by default, so you should have a proble finding them. Try reading up on them (right click and select help for...) and looking at their structure to see if you can come up with a way to do this. If you can't, come back with what you came up with and with some more details.

You can also try the NI's forums BreakPoint. More specifically, try finding the funny threads thread. Hours of fun. :thumbup:

Not in that case. Everything was standard LV controls (not even dialog controls). Since I couldn't recreate it and it went away when the real cause for the high CPU usage was detected, I just let it lie, but it did happen - switching to an empty page of the tab and moving the tab control entirely off the screen had 2 different results.

In that case, we can write a personality analyzer similar to NI's VI analyzer - a program which will analyze your VIs and tell you what kind of personality you have. I have a feeling that the people who wrote some of the VI.lib VIs would not rate highly at such an analysis.

Actually, I have seen a case in the past where there was an apparent bug with a tab control where displaying something demanding on a non-visible page of a tab did cause massive CPU usage, but I've never been able to reliably recreate this.

Usually, such problems are caused by overlapping elements, which make it harder for LV to draw the FP. This could definitely be a problem in your FP, since it's very crowded and has a lot of round indicators. Having less elements on the screen would probably also help the user recognize the more important information easily. Try searching the NI website for a presentation called "the good, the bad and the ugly" which discusses LV interface design.

I don't think there is any program which does this with flash. LV has an internal mechanism called "remote front panel" (in the tools menu) which allows you to view your VI from an HTML page. If you want to control the VI as well, you need to install the LV run-time engine on the controlling computer. This is a liscenced technology, so you only get a certain number of simultaneous viewings at the same time. There are also programs called "LabVNC" and "AppletVIEW" which will turn the VI into a Java applet, which means you don't have to install the RTE.