LogMAN

I'm guessing he used his backdoor VI editor (https://lavag.org/topic/19178-low-level-vi-data-editor-warning-not-for-production-use/) to create a mutant subtract node 

That is cheating!

... But I guess you are right.

dcoFiller=0x2 apparently swaps mapping of parameters to instruction, and also prevents the top wire from becoming a stomper. 0/10, would not recommend; stick to dcoFiller=0x3

Hehehe... Found a new toy to trouble our trainees with.

Did you wire up the minus as 2-(shift reg), then move the wires around to make it look like (shift reg)-2?

 

Then the shift reg would go 10, -8, 10, -8,… and never be less than -10.

I guess you are right, however the wires are not wired around, the Subtract function is actually flipped horizontally :

I'm still trying to figgure out how you did that, flarn2006...

Please tell me if it is not possible from within LabVIEW or I die before solving this

If you don't mind .NET try this:

Not sure if there is a build-in solution for that.

Relative. A process which is scheduled to last for 0.9862612 sec runs in ~1 sec, not ~0 sec, if it has to be reported with precision of 1 sec.

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.

Right but, if I asked you to round 3517564740 (what I think is June 19 at 13:19 for you) to the nearest 86400 (24 hours) you would say the value is 3517603200, which ends up being the next day. But I could see how this could cause confusion.

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

What about it? You state the day is wrong, which is true but rounding up to the nearest second could mean the second is wrong, it doesn't invalidate the fact that you only rounded up a fraction of a second. ...

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).

Yes, of course it can easily be worked around this or that other way, still wondering about the design choice. Even if the mere idea of thinking at a date to fractional seconds precision was a perversion (are we vulcanian?), isn't a bit disturbing that 0.999 %.0t gives 0?

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

That's right. My application is like :

1. Adjust camera parameters-> 2. Run Sample OCR-> 3. If not Ok goto step 1 until OCR output is OK.

So I am looking for the possibility of saving MAX settings from LabVIEW. 

 

Thanks,

Sharon

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

Hi LogMAN,

Thank you. It7s embarrassing but I could only find 2010LV for 64bit(2010LV-64bit.exe) . Which one is for 32bit?

 

Sharon

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

It happens to me a lot, when making a message using Actor Framework Message Maker, that Labview is crashing if too many other VIs are opened.

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

Just my opinion, I find SCC much more critical to software development, than OO.

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.

Class-editing is broken in so many major ways in LabVIEW. I know of people not using OO in LabVIEW for this exact reason - one of them is an employee of mine, and I'm actually forcing him to give up his resistance and just suck it up. But that's no fun I tell you 

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.

Generally I can't get manual namespaces to work. The teams I work in aren't structured enough to adhere to one convention, and they are typically those middle-of-the-road programmers that have enough experience to boost their self confidence but not enough to make them put their egos aside and stick to the plan. Something like that. I want namespaces in LabVIEW, and I hate that I have to stick my VIs into a library to get that - or I hate what I must lug around as well when I just want namespaces.

Amen.

Namespacing through the physical file name also has its advantages - one being that you can identify a VI's purpose without the context of its library. But namespacing in file names create long file names, and it creates long paths due to all the duplicate information (the file name being almost the sum of folders leading into the file location). And we have some limitation to maximum path length in characters when we build executables and load VIs dynamically (~230 chars IIRC).

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?

Without LVLIBs, how do I avoid name collisions? I prefer this filenaming convention: Project-Class-Method.vi or Application-Class-Resource-Action.vi ... or generally, LeastSpecificNamespace-...-SpecificThing-...-VerbActingOnASpecificThing.vi

Do you know where this recording can be found? Mark doesn't seem to have the US CLA Summit 2014 videos online currently...

 

/Steen

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:
 

Brainstorming...
 
SendMSG Library  (SendMSG.lvlib is my core library, and sending a message is the core function of the entire package)
Messenger Library
Messaging Library
Messengers
Couriers
Send Message Library
Send Message Toolkit
SendMSG Toolkit

"Messaging Library" is number one on my list, since it is grammatically correct (at least I think it is )

Now I'm a little bit stuck and out of ideas. With the error occurring in "New Data Value Reference" that eliminates all the traps related to array memory allocation in contiguous blocks that could trigger an out of memory error...

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?

I presume you meant that you are running a 64-bit OS. However, note that a 32-bit application running in 64-bit Windows is still limited to 2 GB RAM by default

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.

Uh oh.  Does anyone know what happened to ftp://ftp.ni.com/support/softlib ???

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')

Whats supposed to be there? From the sound of it, it looks its stuff that is supposed to be accessible over at ni.com/downloads. Is something not there?

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!

So blockage #1 is that VITs don't register on the palette

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.

Being sneaky I thought I'd make a VI and embed the VIT in it, calling it from the function palette with the Place VI contents (merge VI to us old hands)

Blockage #2 is that it drops it on the block diagram as a VIT!!!! :angry: :angry:

..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