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?

.. "Wire diagonally" ..

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

you've just ruined my 2010 april's fool idea...

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

My company deals with a lot of regulated industries and I frequently need to send my LV application documentation to our customers.

Most of the time, along with the Test Specs and Procedures, etc. I send a zipped file with the VI documentation in HTML format. This seems kind of cumbersome, and the "complete" VI documentation does not contain subvi's.

Has anyone thought it would be a good idea for NI to provide a "VI Reader" program? It would be similar to software(s) that allow you to read CAD drawings, PDF files, etc. It would not actually send the code itself, but in Print you could create the entire application in "VI Reader" format. My customer would have VI Reader and would be able to look at it without being able to actually edit it.

Observation: text programmers have the option of sending source code to anyone in a format anyone can read.

This sounds like it might be a lot of work for NI, with limited use, (and I seriously doubt NI would make this available for free ) but before I send this idea over there I would like to get more input.

Thanks in advance.

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?

hi all,

is their any way to know best color combination of your devloped software

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.

I have used smoothing algorithms on data in LabVIEW before but these filters are based on IIR or FIR filters and as such are only applicable to time based signal types, as it is a X-Y graph that needs to be "smoothed" I think the curve fitting algorithms are more applicable. The curve fitting algorithms do work well to keep the shape of the data while removing a lot of the noise.

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.

QUOTE (HeLo @ Mar 3 2008, 08:17 AM)

Hi, thank you for sharing your code. I would like to use it, unfortunately, I'm running on Labview 7.1 and so is unable to open your 8.5 version code. Is there any way you can post a 7.1 version of your TIFF Reader library? Thanks much.

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)

The xml doesn't know anything about the datatype, but the data is typed by the surrounding tags, yes?

*blink* *blink* [*Looks blankly at Jan silently wishing I understood XML better*]

The schema Labview uses is pre-defined and fixed. I assume it would pass (or fail) every time. How would I use the results of that test to figure out the data the xml document has?

Here's my problem in a nutshell. I have a Java app and Labview app communicating via network sockets and using xml fragments to pass the data. Every so often Labview requests a packet of data from Java but it doesn't know exactly what information will be coming. Maybe it will be a cluster of 3 DBL fp numbers, maybe it will be a single U8, maybe it will be a string and boolean. How can I unflatten the xml string without knowing beforehand what the data structure looks like? I could parse the string to figure out the datatypes inside but that defeats the whole purpose of using xml.

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