jgcode

Me too, but I rename the library in the distribution process as to avoid a clash with the source - e.g. after it has been distributed to <vi.lib>. This way I can control the member scopes I only generate a new library if I want to wrap up support VIs so the release does not have those dependencies (e.g. from OpenG, my reuse library etc..). This is a great way to do it for toolkits. Is this your application code or reusable code? I have been using .lvlibs a lot lately in my application code, and it has been working out very nicely. I now what to see where these fit with respect to reuse. I was of the same opinion as you - that .lvlib items get loaded into memory as a group - but AQ has pointed out that this only relates to classes, which I did not know and thats why I shied away from them in the past for reuse. However, I use VIPM and its namespacing for my general reuse library (string, boolean etc..), but at the moment I handle toolkits and classes myself (as there is no need to rename the member VIs). I have been renaming the .lvclass file during the build, but in order to make my namespacing more unique and am looking at the best way to distribute those - rename .lvclass or use a .lvlib wrapper instead. But then, if you did expand the source release in the far future by adding another class (for functionality or to release an inherited class), the original class would name be namespaced differently and your calling code would break? Therefore, I am considering doing it for even single class released. Plus I don't have to rename the class then - so it is no more or less work for me. Add multiple classes in a library is great, as I only have to rename the library during the build, not each .lvclass file - so in that case its less work. So how does your application code get updated automatically when you release a new version of your reuseable class? If the reuse library name changes between releases, then your application code would break? Cheers JG

Thx Daklu All the VIs in the palette are public VIs of a class that is wrapped inside a library and the class is public to the library. Therefore any VI I choose should be able to access them, and when I drop them on the BD, they all work fine! Weird!?!

Howdy! As a developer distributing classes, what type of namespacing do you do/use? I have been renaming the class during the source distribution (NI app builder). But I have been thinking about using libraries (.lvlib's) a bit lately Somewhere after 8.2, and definitely in 2009 you can add the source to a lvlib during a build This seems a handy way of renaming the entire class hierarchy all in one go. Any which way better? Cheers JG

No, 8.5+ methinks.

Hi Mike You have a bunch of options to create by reference (ByRef) objects all with their pros and cons, here are some... Use LVOOP with Data Value References and the In Place Element (IPE) (new in 2009) Create a Single Element Queue (SEQ) and create your own ByRef API Use a third party tool such as Endevo GOOP, Sciware etc...

Does anyone know why my icons have crosses in the bottom left hand corner? They seem to function ok, and I can drag and drop them on the BD? I made the palette manually. Cheers JG

A quick note: this is only supported in the more later versions of LabVIEW.

Looks like this version supports the Select and Coerce primitives too! And (from the pic) it looks like you can swap a terminal if no other terminal is yet connected. Cool, nice job

What kind of LabVIEW enthusiasts would we be if we didn't upgrade to the latest and greatest!

FWIW, I think 2009 SP1 is the equivalent of 8.2 -> 8.2.1 This is something that doesn't sit well with me as well, dealing with customers who require source and having to support their LV update schedule. And it gets worse with hardware's software (cFP, cRIO etc...) that needs to be updated too. Using MS to compare against, Office 2007 superseded Office 2003 so thats ~4yrs between versions. I like the idea that 2009 is interchangeable with 2009 SP1 code (as is e.g. 8.6 and 8.6.1). Maybe it would better if this was the case for longer i.e. all releases for 4 years will be guaranteed to be compatible? However, given the new yearly schedule I think not.

Well thats what I thought/assumed too but I just had the time of my life finding this out! T? But I was using Scan Engine (SE) on LabVIEW Real Time (RT) and until I compiled the Variable nodes returned either an error or the wrong value, source ran fine tho! Don't know if its an issue with SE/RT, or if I should be forcing a recompile before each build. But it raised alot of questions Yes, I wanted to know if I could avoid this. Cheers, much appreciated

Thanks guys, Do you have a rule/protocol to always recompile before each build? And if you do, have you automated this process (e.g. for a nightly build?) Cheers JG

Glad someone else has seen this, I thought I was going insane when this was happening!

I would like to be able to have hooks into the Dynamic Dispatch and Static Dispatch templates, just like we got for data member access http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LVOOP-Custom-User-Dynamic-Dispatch-and-Static-Dispatch-Hooks/idi-p/1029957

I ran into a nasty issue where a build for Real_Time was returning incorrect data! The solution was to recompile the top level VI and save all callers (have to save as its RT). The problem arose as most VIs were read-only as they were in SCM. What is the standard protocol for this from SCC point-of-view? Should I check out the VIs, compile/build/archive-build, then check them back in and tag them as "recompiled" or similar? Or should I check out the VIs, compile/build/archive-build, then get last revision to overwrite the new local copies? What do you guys do? Cheers JG

jgcode (LAVA) \ jg-code (NI)

Thanks, I did try google before I posted, now if I try "pb + french" I get it!

Hi PJM, what is pb?

I have complained before about Error 6 but am still of the opinion that it is better than having files outside of the build. I would be nice if NI could do the build in a temp directory (as close to the root as possible) to avoid this, then copy it back to the dist location - all transparently (I currently have to use a script to do this manually). I have also had the annoying problem of Vague Errors in builds. The fastest way I have found to identify the issue is to Build after integration - so I can keep track of what the problem may be down to Disabling/removing modules of code and rebuilding until it works - when it works, the last thing I removed may be the culprit and I can build a test VI to confirm. Does anyone has any other/better ways? In the past, for me, these issues have been caused by e.g. Dot Net calls, the client PC did not have the framework installed, but all I got was a Vague Error Dirty class (once), I have no idea why but it would work in source but not in the build, I had to delete it and start again The first one can be avoided by prechecking registry etc... but a descriptive message would be appreciated I do not know why LabVIEW cannot return better diagnostic information when this happens?

For me, its to do with classes because: I build classes into LLBs for distribution of reusable code But I use VIPM for almost all other LLB distributions So I can't say exclusively classes, but my use cases predominately includes them. I started noticing it happening with controls, in particular DVRs, which is what I played around with a lot since LabVIEW 2009 came out. But I have seen controls and VIs (as per my example) excluded too.

Has anyone else had the problem of?: When building an llb (from a class in this case), (random) build items move outside of the llb even though their destination should be inherited from the caller. In the video here: http://www.screencast.com/t/NmQ1MWVm, you will see I have to manually set the destination for these "sub-items" to fix the problem. I get this problem quite a bit. This is annoying and error prone. Cheers JG

Sorry, to clarify: IE8 works, Google Chrome doesn't (and still doesn't) I was wondering if Google Chrome is not supported for NI FTP? Or is it just me? Anyways, I have my software, that's all that matter

This module sounds cool I have been checking it out as NI just announced Machine Vision on CompactRIO. The article mentions your module as well as support for IP cameras on cRIO We've used the CVS before for the sole reason of VGA output support. If the cRIO had this feature we could just use it instead.

Hi Robert The only (windows) software I can download is the Platform DVD2. Platform DVD1 gives an error and 32bit and 64bit are empty? Is there any reason for this? - I will try again later tho. Cheers JG <edit> Seems my Google Chrome can't see the downloads? IE8 is working tho so I am happy Cheers </edit>

Great post - classic!