Mads

Superb, your base64 code did the trick, thanks As for the weakness in the unzip-function I tried downloading the latest version (mine was the previous version) and to my luck the issue seems to have been adressed there, so now absolutely everything works as it should :thumbup: :thumbup: PS. The OpenG base64 decoder still has this problem, that code is not maintained anymore (I think(?))...so replacing it, e.g. with Mark's code, might be useful for others as well. Mads QUOTE (mesmith @ Jan 15 2009, 02:54 PM)

I am using the Open G POP functions to fetch and decode e-mails with attached zip files, and have run into a rather "fun" combination of errors: 1. If the (zip) file has two zero-bytes at the end it will be reflected in the base64-encoded data, however only one of them will come through when the OpenG base64 decoding is applied. 2. If a zip file lacks that final zero-byte the OpenG unzip-functions (i.e. the dll they use) will crash. So - in my case my code receives and writes a zip file, and that zip file is read and decompressed just fine with other zip-software, however because the same software is trying to use the OpenG unzip function it ends up crashing the whole software.... I can probably figure out a way to edit the decoder so that it does not lose any bytes (perhaps this is a known issue that is routinely solved?), however it is still a bit uncomfortable to know that the unzip function is possible to crash by feeding it a file with such an error. Mads

Sure, if the drawing code was made into a general API then I would buy it... For graphs you could have an API where all you needed to do was to feed a reference to the graph to a VI from the tool...and voila - now you can draw figures and write text on the graph. :thumbup:

A sidetrack...but anyway: In the UML Modeller you have a drawing tool that would be great to use for other purposes. In my case I need the ability to add text comments, arrows, boxes etc. to a graph...as part of a report tool. The picture properties of the graph control makes integrating the picture and the graph simple enough...but I still need code to handle all the objects so that they can be moved, resized, deleted etc. I assume you do not have any plans on making that part of the package open source ... ExpressionFlow has a good example that lets you draw multiple figures and delete them sequencially, but are there anyone who has made a more complete drawing package in LV that is available for others?

You communicate with the Hilscher card by calling the Cif32dll.dll. The first step is to call the function DevOpenDriver (stdcall) and input the card device number (you can set up the profibus network in Sycon first). The next step is to call DevInitBoard(), the parameters there is the same device number and a text you can set to N/A. Reading and writing to the bus is done using the DevExchangeIO function: Data transfers are done in blocks of 32 bytes typically so you need to split and write or read and join multiple blocks. You can find details about the dll from Hilscher.

It is a good idea to decide on a minimal resolution you want to support and design everything to work there and scale upwards. Depending on the GUI you may allow the users to scale the window down from there as well, but at least put in a minimum to ensure that none of the objects that are set to scale get too small to be used. It can be frustrating to work on a small control panel when you have so much screen real estate, but the diagrams can still be as large as you like...although personally I think it is a bad habit to allow those to grow too large as well... Generally I never scale buttons and numeric controls...most of the dialog controls are typically kept at a fixed size in other applications so I stick to that standard behaviour. The important thing then is to group the objects and place them so that they do not change their separation or location during window scaling. A graph on the other hand e.g. is a typical object to scale with the window. If I need to scale multiple objects properly it can work to group those objects, however a more robust solution is to use window splitters. Truning on the "Maintain all proportions" or the "Scale all"-option is way to crude. Mads QUOTE (dannyt @ Oct 23 2008, 10:07 AM)

The search could be made binary instead, that would cut the number of Nth line calls dramatically... QUOTE (normandinf @ Sep 20 2008, 02:38 AM)

I second your request. I have several applications where the lack of this feature forces me to use a less than optimal GUI...

I've got LV CDs all the way back to 4.0, however is it really the run-time you want? If you want to see the code and not just a running application you will need to install the development environment.

This is not a bug, it's the established way LV decides the order in which to do things: If you have a property node it will execute the actions on it from top to bottom. All you have to do in the first case is to swap the positions of the properties. QUOTE (Aitor Solar @ Jul 15 2008, 12:06 PM)

It's not just the native configuration file VIs that cause this, the openG code seems to be slow on its own. I especially noticed this now that I'm using them on a RIO controller...just reading in a section containing a cluster of 3 small 1D arrays (10 elements in each) takes 2,5 seconds with the OpenG read section VI. I typically have to read more than 10 of these sections so that takes a whopping 25 seconds or more. Because of compatibility issues with existing software it's not an option go use a different file format so I'm stuck with the configuration files. I've just skimmed the code and I saw that the decoding of the arrays use a recursive call, is that what makes it so slow? I'll have a closer look at it myself when I've got the time, but has anyone looked at this already and found any optimizations?

To make the GUI ignorant of the cluster container for tab navigation should be doable without causing any huge problems. That would solve the most annoying problem. The ideal solution however would be to have clusters that the control panel is unaware of alltogether - so that the controls/indicators could be placed independent of eachother even if they were in a cluster. To keep things simple for beginners they could keep the old type of clusters, but add a "diagram-only cluster" for advanced users. If you want you should e.g. be able to include a control/indicator in a cluster by right-clicking on it and "cluster" it. You define a cluster much like a type definition, and then you can add or remove things from that cluster by right-clicking the control and select a defined cluster to add it to. Yes, you can always drop the use of clusters to not get the GUI problem, but on the diagram it's very neat to work with clusters instead. QUOTE (rolfk @ Apr 25 2008, 06:12 AM) To reply to my own thoughts here...perhaps the right-click to cluster should not be used since that ties into the control panel...instead you could create a cluster container on the diagram and drag the terminals into it instead...Isolating the clustering to the diagram. QUOTE (Mads @ Apr 25 2008, 08:59 AM) To make the GUI ignorant of the cluster container for tab navigation should be doable without causing any huge problems. That would solve the most annoying problem. The ideal solution however would be to have clusters that the control panel is unaware of alltogether - so that the controls/indicators could be placed independent of eachother even if they were in a cluster. To keep things simple for beginners they could keep the old type of clusters, but add a "diagram-only cluster" for advanced users. If you want you should e.g. be able to include a control/indicator in a cluster by right-clicking on it and "cluster" it. You define a cluster much like a type definition, and then you can add or remove things from that cluster by right-clicking the control and select a defined cluster to add it to. Yes, you can always drop the use of clusters to not get the GUI problem, but on the diagram it's very neat to work with clusters instead.

Not an answer - but this is something I've flagged to NI a couple of times: There is no reason whatsoever for the user interface to care about cluster containers. Tabbing should ignore the fact that the controls or indicators are part of a cluster, that is only relevant for the program code, not the GUI. QUOTE (cmay @ Apr 24 2008, 01:21 AM)

Well, how large arrays are you using and what is the write wait time? You can generate up to 3MB/s and the file IO will handle that, the data formatting will not run any faster. Unrelated to the problem at hand, but a tip for the future: The code can be written much more compact (both in logic and display size)..attached is a picture of basically the same approach(no optimization of the logic though, that is still the same as in your speed test). Not the optimal code that either, but much easier to read. QUOTE (alexadmin @ Apr 10 2008, 12:31 PM)

Like you say, File IO is not the problem - it is faster than the data generation. Formatting the data takes 0,94 us per byte on my machine (generating 3 bytes of formatted data), that means that the maximum rate of data to write to the file that can be generated is: 3 bytes/0,94 us = 3191489 bytes/s = 3,04 MB/s That is the same file write speed I achieved yesterday...in other words, it's not a problem to write the data, however you cannot format it any faster than 3 MB/s. I'm not sure why you only get a few hundred KB/s, but it could be bacuse you actually use a wait in the write loop and have a very small array...with e.g. an array of 50 and a wait of 10 ms that loop will only generate 14,6 KB/s. If the sampling device is outputting data faster than this I would skip the formatting and just write the data directly to disk. You could then generate the formatted file at a different time - or in a parallell loop. Ironically this would swap the whole approach - put the file IO in the same loop as the data sampling...but separate the formatting loop - it's too slow:-) Mads QUOTE (alexadmin @ Apr 10 2008, 08:14 AM)

As others have commented here buffering the data makes the file IO much faster, and it could be an idea to spearate the logging from the sampling. If I assume the USB returns about 1000 bytes on each read, doing the formatting and writing the data to a file the way you do it runs at about 2,2 MB/sec on my machine. One trick you can apply to bump that up a bit is to not build the string the way you do it (feedback node etc.) - instead you just output the string and let it be autoindexed by the for loop. You then use a single input concatinate on the output array to get the string. The speed you gain by this relates to the length of the arrays, however with a 1000 byte input the logging went up to 3,1 MB/sec just by doing this. The fact that things slow down that much when you do the sampling in the same loop might point to a problem with that part rather than the file IO...How fast does that part run if you skip the file IO? On a side note I would suggest that you try to keep the diagrams more compact - it was barely readable on a 1280*1024 display, and there was not really any reason for it, the code could easily have fitted vertically. If you need space on your diagram later on just hold down the Ctrl-key while you click and drag the area you want on the spot you need it on the diagram...When programming in LabVIEW it's also a good thing to trust (and/or make) the data flow to drive the execution. Most of the sequence structures you have are either unnecessary or could easily be replaced by pure data flow. QUOTE (alexadmin @ Apr 7 2008, 01:50 PM)

QUOTE (Michael_Aivaliotis @ Mar 13 2008, 08:58 AM) Cool idea, having a GUI gallery. It's often difficult to figure out good designs so inspiration - or stealing some good ideas - is great:-) LabVIEW GUIs have a tendency to look...well - like LabVIEW GUIs, non-standard colors, 3D buttons etc. The examples so far avoid most of that, but there is a big no no in the upper left corner of the windows - a window name that ends with .vi. Aligning and making all of the controls in a group the same size would be another tip, makes it look a bit cleaner. It's always easier to criticize than to make things yourself though:-)

Try logging into the 2003 server by setting remote desktop in consolre mode: You start remote desktop in this mode by running: MSTSC /CONSOLE This will allow you to log into the existing active session. QUOTE(Donald @ Feb 29 2008, 01:12 PM)

I've solved this kind of problem by creating a server application that administrates the access to the port and devices on the port. This "Port Share"-application allows multiple applications to share the same ports (the middleware is the only application that actually use the ports), and it has commands that enables the apps to reserve a port and/or a spesific device (on a multidrop link) if they are in an operation that requires exclusive access for a while (ports are reserved during heavy data transfers, devices are reserved when they are used for tasks that cannot be interrupted by commands from others). In my apps the serial communication is handles by a comhandler-plugin with a que-based interface so all I had to do to switch to the port share system was to replace that comhanler.vi with one that acts as a port-share client instead...(off course to fully use the port/device reserve functions you typically need to implement that at a higher level though). I've thought about releasing this software to the public, however there are some rights-issues to solve for that to happen....The idea is free though:-) QUOTE(Khodarev @ Feb 6 2008, 08:55 PM)

I do not think the reference is closed automagically, there must be some bug somewhere that closes or looses the reference. Is it able to write once and then never again, or? Does the file exist? The shown code never creates it (open, not open or create as action into the open/create/replace file function)...If it is a preexisting file, have you tried generating a new one? If you feed the que twice and probe the reference and error outputs in this logging VI, does the reference ever change and where is the first error? Mads

That's perfect, thanks for the help I had overlooked the add button on the destinations tab. Regards, Mads PS for NI: It would have been great to be able to add it directly in the set destination input on the source tab as well (then I would have found it), but that's a minor issue.

In the app builder of LV8.5 you can add a folder to the source list. I have several folders where I store plug-in VIs and tools (VIs or libraries) so it would be nice if I could add those to the source list and specify that their diagrams should be removed...however even though you actually add a folder it will not add a folder - it will just take the content of that folder and place it in a directory which is limited to be either the support folder, the exe folder or the folder of the caller.... It seems very strange that they could not add a user specified folder option there. So - this seems to mean that I have to do what I used to do - namely to create folders manually, save all the VIs and libs without diagrams manually (although I did make a VI that does this automatically) and then include those folders in the installer. To sum up - is there a more streamlined way to achieve this or should this be a feature request for the next LV? Perhaps the OpenG app builder can help with this? I've not used it yet... Mads

The path does not refer to the correct VI in the sample, however I'm not sure why you insist on using a call by reference node :question: I've updated your sample to a working one. As you will notice I've also added a wait in the subVI loop, you should always have something that prevents the loop from running as fast as possible, otherwise it will use up all the CPU time. On a side note I would also recommend sticking to dialog controls and colors, that will give the users a familiar and professional looking interface, the advantage of using a OS-standard interface should not be underestimated. I also noticed that you are using the place as icon feature for the diagrams...that is the default and it's probably easier to read for beginners, however it takes a lot of space so in the long run it's a good idea to not use that, just a tip The example can easily be expanded to show cool ways to use the run method...you could e.g. make the subVI a template and have as many of them running in parallell as you want. You can also use e.g. a notifier or read the front panel properties in the subVIs to close all windows when the main app window is stopped.

+ If you want the subVI to run in parallell with the main VI you need to run it using the run method like I showed in the previous reply, not a call by reference node.

You have two options - either have a separate loop in the main VI and (statically) call the subVI from there (then only that loop will wait for the SubVI to return, the rest of the main VI will continue to run), OR call the subVI dynamically by opening a reference to it and then use the run method on that reference with the wait until done set to false. To set the inputs of the subVI you use the Set Control Value method: The latter method is great in many situations - I use it to call VI templates (.vit files), then you automatically get a unique instance for each call. A typical use of this is to allow the users to open as many graph windows as he wants... Regards, Mads