LogMAN

Let's care about anyone Alternatively don't care about anyone... but that's no fun

If you don't mind .NET try this: Not sure if there is a build-in solution for that.

True but, if you use a stop watch with a precision of 1 sec, it would (should) show 0 sec and not 1 sec, assuming it has perfect accuracy. The question now is: What did we actually measure? Relatively spoken one second did not pass and also we are no longer at 0 seconds. Meaning that our process to measure the time is not precise enough to give a conclusive answer. Perfect example, this brings us to the question what we actually ask LabVIEW to do for us. So if we request %#.1T we expect it to coerce right? So assuming we have 01.01.1904 23:59:59,999 we expect it to coerce to 02.01.1904 00:00:00,0 Now I want to write information into files, where the file name is build upon the actual date (%<%d-%m-%Y>T), however the entries within the file should be prefixed using the actual time with a precision of %#.1T. In accordance with the coercion, I now expect my file name to be something like '01.01.1904' (we didn't specify any precision, so we expect the highest precision possible, right?). The entry however would be prefixed with 02.01.1904 00:00:00,0! Only a fraction of a second changed, but the entry is (seemingly) in the wrong file. Is this really a problem? I can't tell if such a small 'mistake' is actually a huge problem on the large scale of projects that are done with LabVIEW. To me it would just be an annoyance (I like my files to be as accurate as possible ), so I would most likely write a wrapper to deal with it (which is the reversed role to the solution for coercion ThomasGutzler posted before).

What would happen if you coerce this: The Timestamp would have to coerce up which means the day would be wrong (01.01.1904 23:59:59,999 becomes 02.01.1904 00:00:00,000). Now try that on the 31.12.1904 23:59:59,999... I think this might be part of the reason why the Timestamp is not coerced by design. Time is absolute (or was it relative?)... so yes it is a perversion and we are all vulcanian

Are you by chance searching for this: http://digital.ni.com/public.nsf/allkb/BBB5B94C038267DF8625723E00030559

The 32bit version has the language code attached to it: http://download.ni.com/evaluation/labview/ekit/other/downloader/2010sp1LV-WinEng.exe

Hi Sharon, Please try following url: http://download.ni.com/evaluation/labview/ekit/other/downloader/ You'll find all kind of programs there. The link says evaluation, but you can activate full versions after installation. Greetings, LogMAN

I've seen that many times in LabVIEW 2013, hope that it gets better in the newer version. Anyways, there are a couple of things you could try: Load the project on another computer Clear the compiled object cache and recompile all sources Load the library without the project, disconnect the library from its owner, disconnect all VIs from the library, delete the *.lvlib and rebuild it manually.(Maybe it is not possible to disconnect the library, in which case you can only try to disconnect its members and basically rebuild the entire hierarchy...) The safest way is to revert your codebase, but I assume you don't use SCC right?

Okay, I finally found a solution: A second project had no issues, even though it is basically a copy with a few alterations. After a stroke of genius clearing the compiled object cache for the application builder solved the problem. Now everything is fine again. I hope this helps anyone who stumbles over the same issue.

Hello everyone, I've got a situation with source distributions: I want to export the sources of a project, but some of the VIs should not include their block diagrams. (But they do ) This is what I tried: Create a new Source Distribution and under Source Files add all top-level VIs to Always Included. Next in the Source File Settings select certain folders and check the 'Remove block diagram' option (under Additional Exclusions the checkbox for 'Remove compiled code' must not be checked). When I build the distribution and open one of the VIs, which are marked as to remove the block diagram btw, it still has it! I already found out that this is related to all my VIs having their compiled code separated (to keep source control clean, you know...). So in order to archive what I want, I would have to disable that option, let all VIs recompile, build the distribution, enable it again, and let all VIs recompile again to keep my commits clean... What am I doing wrong here? Does anybody know a cleaner way to do this? I'm still stuck with LV2011 btw Thanks for the support. LogMAN

I totally agree. I was actually trying to understand the logic behind the decision, but I guess my text is quite misleading (even for me as I read it again now ). Maybe I don't understand the initial post correctly, but if I have a problem with the SCC, than I would try to fix it. If I cannot fix the problem, I would rather finish the product and live with a complete SCC history that has certain complications (like renames that are tracked as delete/add commits for example), than overthinking my entire software architecture. Or maybe the initial post is absolutely not related to the SCC discussion but rather to the topic at hand that is "The nightmare that is renaming a class and its folder". In that case the employee might want to rename folders from within the project and fix the SCC in manual labor.

Could you go more into details? What are the reasons? Abandoning classes just because they don't integrate with the SCC sounds like bad reasoning. Rather consider abandoning the SCC and go with ZIP backups instead.

Amen. My arguments follow the same line, however I recently "discovered" that having namespaced files in namespace folders over-determines the namespace and therefore makes no sense. Thus all files can be put into a single folder without loosing information, or rather putting all files into a single folder would increase readability. At the same time you don't increase the path length: 'Library/Function.vi' vs. 'Library-Function.vi'. However the initial problem remains: Programmers stick to their own plan. @JackDunaway: I would like to see how you organize the files on disk. VIs are one thing, but classes and especially dispatch VIs are a whole different story. So how do you prevent the name-conflict and path-length issues?

Haven't seen them anywhere and the friendly search engine has no clue too. However the presentation material is available: https://decibel.ni.com/content/docs/DOC-36232

How about Register? You can read and write an register, but you could never add another element to it.

I've followed this thread closely to learn more about libraries, classes and dependency injection. Thanks for sharing all your thoughts so far. Now, I don't just want to lurk in the shadows, but participate to this discussion. So, let me reply to the initial question: Should I abandon LVLIB libraries? First of all, I don't consider the correctness of the dependency tree as a problem. If you only want your hierarchy in the dependency tree, than you cannot use any type of library. So the only thing I'm concerned about is loading time and responsiveness of the IDE. This is what I think: You should not abandon libraries, if you have a collection of VIs, like utility VIs, that do not call any subsequent libraries. An example would be a library that wrapps functions to call an external DLL. Such a library is completed as one entity. There is a slight loading overhead, but it is acceptable in my opinion. You should consider to abandon libraries if they contain optional functions that call to other libraries (other lvlibs or classes to be precise). Then again, if all of the VIs in the library call to the same external library, there is nothing gained by abandoning it. You should abandon libraries, if they heavily depend on other libraries and the dependencies are different on a VI basis. Calling one VI will load the entire hierarchy into memory which cannot be desireable, unless all sublibraries are in private scope. In the latter case you try to namespace items, which adds dependencies that are undesirable for other functions. --- In the end you'll have to choose by yourself which way is the best. As for me, I'll stick with libraries, but refactor some of my code to a more 'flat' layout (if possible no sub-libraries). For someone like me who loves namespaces, the namespacing JackDunaway recommends (namespace in filename) is somewhat undesirable (no offence, I just preffer namespaces even if they try to slow me down ). I would rather see something like a "Namespace" type of object in LabVIEW.

As someone who's always thinking about naming everything "correct" (and continuously failing to get the perfect name ), I think the name should describe what it does and 'is' in few words possible. ShaunRs suggestion to suffix the current name with "Framework/Library/Toolkit" feels more correct in my opinion. And that's because it just is a Framework/Library/Toolkit for Messenging... (You could go as far to say it is a Framework/Library/Toolkit for Messaging between parallel processes, so a Parallel Messaging Framework/Library/Toolkit...) I would even say it like "I'm using the Messenging library". However if you choose to stick with the current name it will be fine too (a little bit awkward though). Here my votes to your brainstorming: "Messaging Library" is number one on my list, since it is grammatically correct (at least I think it is )

I'm not sure of that one. You stated that you add items to a dynamically growing array. Now in your RAM you need a contiguous chunk of memory that is large enough to hold the entire array. Even if you have 16GB RAM in your computer, if the largest chunk is 500MB, than that is the maximum amount of memory your array can allocate. Otherwise you get an "out of memory" exception. Also be aware, that with dynamically allocated arrays, if the chunk is to small to harbor the next element, the entire array will be moved in memory to a location that is large enough to harbor it. This will double the amount of required memory for some time, as a copy is made in the process. Could you initialize your array with a decent amount of elements and try again? That's not entirely true. LabVIEW 32-bit running on a 64-bit OS can allocate up to 4GB of memory as stated in this document: http://digital.ni.com/public.nsf/allkb/AC9AD7E5FD3769C086256B41007685FA On a 64-bit Windows operating system, LabVIEW 32-bit can access up to 4 GB of virtual memory without modification.

Yeah, it seems that the server has been reorganized. Might take a while to figure out the new places. However most files should be in similar locations under '/support' instead of '/support/softlib'. (example: '/support/softlib/labview/labview_runtime' is now '/support/labview/runtime') No, everything should be alright on ni.com/downloads, however it is easier to directly access the FTP server and fetch files, than clicking through a couple of pages.

Some time ago I tried to launch the On-Screen keyboard that ships with Windows on a 64bit system from 32bit LabVIEW (starting "osk.exe" via shell command or console in LabVIEW). That didn't work even though I explicitly pointed to %windir%\SysWOW64. The issue is Windows redirecting calls to the system32 and SysWOW64 folder depending on your application bitness. This is called File System Redirection. Disabling File System Redirection allows you to call files in the SysWOW64 folder instead of being redirected to the system32 folder. Call this function and try it again: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365743(v=vs.85).aspx Don't forget to revert redirection once your call is finished: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365745(v=vs.85).aspx Read more here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx Oh yeah, be sure to execute your VI as well as the DLL calls in one specific thread, or else these functions will have no effect!

A VI template is not intended to be placed inside a VI, therefore you cannot put it on the palette. If you try to put a template into a VI it is like trying to call the template from the VI if that makes sense. ..And that's exactly what happened here This is how you can create a VI from the template: If you try to create a project template with more than one *.vit, there is a solution for LabVIEW 2012+ well described over here: http://ekerry.wordpress.com/2012/11/09/creating-and-distributing-custom-templates-with-the-new-create-project-dialog/ There might be other options though. Other than that you can put VIs on the palette and check the "Place VI Contents" option (as you did before). Now if you create an VI and place the content from the palette it is similar to a template function. However this lacks the ability of template hierarchies.

In one of my recent projects I used an actor (based on NI's actor model) to update UI elements. It basically consists of a class with all necessary control references in the private data (accessible only before launching the actor by using property nodes). Messages were implemented to update each specific control. Due to that it was possible to update the UI without blocking tasks, since the UI thread was handled by the actor core.

There is no premium anymore an thus the limits no longer apply. See also: http://lavag.org/topic/18317-adverts/?p=109842

Check in your application build script if the 8.x file layout is activated: http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/referencing_files_in_applications/

Browsing for updates just revealed this: See you guys in a couple of month