unicorn

It would be a rather complex knob which would some explanation for the user. I think you have your reasons but nevertheless I would ask is it really necessary? The output of the knob will be two DBLs and may be a boolean which indicates whether the knob is pressed or not. So I would suggest to make an XCóntrol. An alternative could be a slide with two sliders. It is build in. Here it is more obvious that the user can enter two values. Regards

192.168.1.1 is a local network address which might change. If you have assigned a drive letter for a network drive, why not using this?

You can do this already. While wiring E. g. one pixel right, left klick, one pixel down, klick ,... no programming right click framework, just a calm hand

Perhaps you can come out with a working tool. No one would believe you. There is some time left...

In my opinion the only use of giving code to the (non programming) customer is that the customer gets psychologically satisfied because he can hold something in his hands for what he has paid. For regulated things (I am thinking of IEC 62304) it would be of more help to have the requirement docs, risk assessment docs and so on in a nice and understandable form. Will your customer ever look into the provided code? In some point the customer must rely on you and your company that you fulfill the requirements for the regulations. Perhaps a point for your marketing. Another point for giving the full code to the customer is that you have a remote location where the code is stored for back up reasons. As far as I know you can include all SubVI in the documentation. If you start Print... select multiple VIs > press Add VI Hierachy ... and you have on, two, many VIs selected for printing the VI documentation. Isn't that what you could/need to print into HTML-Documentation? On the other hand one has to admit that LV-code is quite similar to certain UML diagrams if the SubVI are carefully choosen. So for regulation purposes I would always try to argue that a print of an upper level VI replaces e. g. an UML-activity diagram. Of course some explanation is needed but UML diagrams are not selfexplaining as well. So LV-code-prints can be part of the software documentation even on a more abstract level.

Since ages I am missing the context menu entry "Finish this VI". It should simply finish programming the code for the selected VI according to my ideas and the requirements. Does anyone has such a function?. Any idea how to make it?

Here some of my thoughts and findings to color: You should avoid pale colors on pale color -> no contrast also dark colors on black background gives almost no contrast. Red and green cannot distinguished by red-green color blind people as already said but there are also other forms of colorblindness. The user gets very easily confused if you use too many colors. And acceptable number of colors is low. I haven't got reference by hand but I think it is about three! So less color is better. To indicate differnt things it is better done with differnt icons than with color. One can differentiate more icons than colors. But don't forget that most icons are not self explaining. If you need to distinguish of combine different things/controls/indicators on the front panel it is better done by borders or by aligning in columns and or rows than with color. The basic/main color could be that of a cooperate design. There is some common meaning of certain colors. Red with white colored text is danger. Orange is warning. Yellow is caution. Green is all right. using them in a different meaning on indicator will be confusing and missleading. Using color in subVI Icons is up to your taste as long as you are working on your own. If you are working in a team you should talk about it. But if you use a basic color for a group of VIs they are easily found in the block diagram. Regards

Hi, I would like to give some thoughts: I am working on two programs which handels a set of 600 images with approximately VGA resolution. The images will be loaded and processed according to user commands from the run-time menu as well as by pressing buttons. This amount of data cannot be handled by a queue. So the image data need to be stored once in a data repository or using IMAQ Vision Images. The whole dataset cannot be passed as data flow from VI to VI. While working with that I found that it is not really necessary to pass data using a queue. Nevertheless I use a queue in one of the programs. The program is based on a producer consumer loop. The producer is the GUI-Handler which start e.g. the aquisition of the image set by queuing a respective element. The consumer loop detects it and start aquisition. The aquisition process can be stopped from the GUI whereby another element is queued. The aquisition VI will look at the queue and stops if requested. While aquisitions runs the GUI-Handler can perfom other things. GUI-Handler contains a event structure, so that it is not polling for user commands all the time. In conclusion the queue transmits information i.e. certain user events which control the aquisition process. The other programm is using only a while loop with eventstructure. Here I register own user events. No data is passed. the event just carry information. Using user event and having only one event structure (otherwise you run into problems) the user events are handled sequentially with all the other event. there is no parallel processing like with the producer-consumer loop. The event are something like update a plot and produce the right legend. Using user events is only suitable for code with short duration because the user interface is not reacting while the user events are processed. In general I don't see the design pattern as a strict dogma and vary them as needed. Regards

Here is something similar: http://forums.ni.com/ni/board/message?board.id=170&message.id=423230#M423230

A few ideas: A) If you have many bits of Data why don't you store them in a repository made of a loop with an array of cluster of the data chunks and just pass the index of the data chunk with the queue. Thus the queue won't grow that fast. In the repository you can release the memory once the data is written to disk. B) Perhaps it helps if you cluster the data (e. g. cluster of an 2D-array of DBL instead of an 2D-array of DBL) before writing to the queue. I could imagine that the cluster is saved as a pointer in the queue. So memory for the data can be released while the space for the pointers in the queue could remain. The pointer would use less space. C) Buy another Hard disk ;-)

What's about this: Take any data point and contruct a cone. Now throw away all data points which are outside the cone. Repeat until one data point remains. It gives the largest cone inside the data. But the requirement is that you know the axis and its direction. Or do you need to find the direction as well?

Yes, I think so. But I didn't get what you exactly mean. But may be one of the following helps: - Make a control as a type def or a strict type def. It will be the same control/indicator in all VIs - Build a XControl. It can have different appearence depending on a internal variable. You could set the variable from VI B and the behavior of the XControl in VI A will change. But not all instances of the XControl will change Perhaps you could describe your aim in more detail.

Curve fitting needs often the knowledge of a mathematical description of the observed/measured values or at least on parts of the data set. Sometimes you can guess the behavior, e. g. if something decays (but do you see whether there are one or two decay rates?). Smoothing on the other hand just suppresses fast changing components by averaging consecutive data points using different weights.

I thinks it's no good idea to have many tabs. The user (as I always do) gets easily confused because the tabs are organized in rows above the main panel area and the order of the rows always changes if one clicks a tab in another row. I think using a listbox is the better style. And for three tabs its not worth while to make some scripting.

Where is the code anyway?

Smoothing is somehow different from curve fitting. Smoothing tries to remove noise and fast changes on the data to show the slow changes more clearly. Curve fitting tries to get as close as possible to the data with some mathematical description. To make your data look more smooth look out in the net for "data smoothing". You will find descriptions of several algorithms. I haven't found a running mean in LV yet, but there are several filters which can be applied to your data. See palette Signal Processing > Windows

QUOTE(Daklu @ Aug 23 2007, 04:00 PM) An XML element has got the data type string (with some restrictions). So if you are exchanging data between application, you need to specify the datatype of the information in your packets. As far as I remember, there exist some documents describing common data types for data exchange (written in XML of course). Unfortunatly I don't remember any URLs. For getting into it, try out http://www.w3schools.com' target="_blank">www.w3schools.com and search the web. If you exchange data your could simply give your XML-elements in your packets an additional attribute naming the appropriate LabView data type. In LabView you need to evaluate this attribute before reading the data of the XML-element. Within LabView "Flatten To String.VI" and "Unflatten from String.VI" or alternatively the variant data type to transport your bits of information from VI to VI in a general manner. Writing a general application understanding any packets will be very difficult. But I guess that you have only a limited number of possible data packets. Then you just define adequate attributes. You are free to name XML elements and its attributes as you like. If you want to define the legal building blocks of an XML document you could to write a Document Type Definition (DTD). It defines the structure with a list of legal elements and attributes.

Try the LabXML Toolkit (http://labxml.sourceforge.net/). It is based on Microsofts XML parser