crelf

Looks like you should post to this thread to show that being a CLA does not automatically mean you get a job.

I think that that thread already makes the point pretty clearly.

Just follow the link in Chris's signature.

Well put!

Here, let LAVA have all this traffic, not my site.

If you don't want the traffic, you might want to edit your original post and remove the link there.

I would like to further note that anything involving eating and recursion is just sick.

So this is the question: Is it possible to determine for NI Vision whether there are dark characters on a light background or light characters on a dark background for any selected ROI?

You could try a histogram across the whole ROI which should give you two distinct peaks (one for the background colour and one for the text colour), and then look at the intensity just inside the border of the ROI - if it's the same as the darker peak then you've got light text on a dark background, and if it's the same as the lighter peak then you've got dark text on a light background (this assumes that the area just inside the border is the background - depending on your image, that's a fairly safe assumption). Do you have any example images that you can post for us to look at?

Well this works but may not result in the most realistic image. Psychophysically the eye responds more to the green content than to red or blue.

terminator's right - there is no real emperical method to convert from RGB to grayscale - unfortunately it's in the eye of the beholder: it depends on the sensitivity response of your specific detector to the irradiating light (with respect to wavelength). That said, try a googling convert+RGB+grayscale and you'll get a few formulae to choose from...

using just one string constant - and everything works fine!

Looks like LabVIEW uses implaceness with the common node.

I have found and fix two small bugs:

Hey - thanks for the fixes - I appreciate it :thumbup:

I am much more positive about the whole matter but here is what it breaks down for me:

Well summarised!

Here is a bug that I've noticed in LabVIEW 8.0.1.

Oooooooo - that one's a ######!

i did read through all the basics already. but i did not see any that could run in sequence.

:!: Show us what you've already done and we'll try to point you in the right direction.

As long as your plugin VIs and all of their subVIs are in the same flat location (irrespective of whether it's one big folder or an llb) then it works!

After some more research, it seems that you *can* have multiple levels of folders with subVIs all over the place - the problem is that the links between VIs and their subVIs is absolute, not relative. So what's the problem you ask? This screws everything up if you create an installer and bundle your plugins and their subVIs with it (thus moving the VIs from their original locations) - even if you preserve the relative struture, any dynamically called VIs will not be able to find any of it's subVIs unless they are in the same directory as the caller. Please please please - does anyone know how to force the links between a VI and its' subVI to be relative (am I going to need to hack the VI's binary here? :ninja: )

Well, what's so big deal getting certification? Anyone... can get it in a couple of months.

Really?!? Even with no LabVIEW experience, anyone can get their CLA in a couple of months?!? I don't think so, and unless you've sat the CLA than I don't think you know either.

:!: Disclaimer: I mean no malice in my comments below - please take them at purley face value.

I re-iterate my previous comment: unless you've been through the certification process (and what you need to learn to do it) then you have no basis to comment on its' true educational worth. All you're doing is trashing it based on what you think it's like - if you want to talk about the impact of having certification might have on whether you'll win a job or not, that's fine, but trashing the content of the certification exams without even knowing what's in them is purely ignorant speculation. :2cents:

Sorry, was I supposed to wait a while for people to be shocked and amazed before answering?

Yes - yes you were

I think its great that we have several (3-4 at my last count) who have contributed to this topic and are active members in this board.

The NI CLA Listing shows 70 (although in my experience, these pages tend to be updated less that regularily).

Hey - here's an added bonus to being a CLA: no resit required! (for the moment anyway ) My CLA expired this month, and I just got a new certificate in the mail - the accompanying letter said that nothing significant had changed since I took the exam, so voila! New certificate that expires in another 2 years! :thumbup:

It is possible to have a 0xn or an nx0 array in LabVIEW, where n is a non-zero number.

Awww man - you answered too quickly!

run the attached VI - what's the difference between the two arrays?

Download File:post-181-1146771059.vi

Just found something possibly better.

http://sine.ni.com/apps/we/niepd_web_displ...source=external

The page includes a 7.1 example VI

So it looks like you need to send a TCP/IP string to the PC you want to wake of the following:

6 bytes of 0xFF

16 x the 6 bytes representing the PC's MAC address

ie:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF AA BB CC DD EE FF

where AA = MSB HEX of the PC's MAC address ... FF = LSB HEX of the PC's MAC address

Ok,

Thankyou

it looks like the VIs loose their link to their subVIs, resulting in the error message. I'll try a few more experiments tomorrow to confirm that having a VI in the same folder/llb as its' subVIs works - like a flat structure - stay tuned

Well, I've finished doing some tests, and sure enough - it's all about location location location! As long as your plugin VIs and all of their subVIs are in the same flat location (irrespective of whether it's one big folder or an llb) then it works! As soon as you have a plugin VIs or one of its' subVIs refer to a VI that's outside of that location (even if it's in a subdirectory), then the plugin is toast: "Error 1003 occurred at Open VI Reference - The VI is not executable."

I think what JP Drolet is saying is that you have to make sure you have all the support libraries (whatever they may be) for your plugging VIs.

Ahhh - I see: thanks for the clarification. The reason I was confused was that I did have all of my support libraries available - opening a plug-in VI with subVIs worked fine under LabVIEW, and after a couple of experiements, it looks like the very talented (and lovely I might add) Irene looks to be on to something - it looks like the VIs loose their link to their subVIs, resulting in the error message. I'll try a few more experiments tomorrow to confirm that having a VI in the same folder/llb as its' subVIs works - like a flat structure - stay tuned

I use the plug-in architecture with executables and it works as expected. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly... I usually do that by Save with option>Application distribution.

I specifically don't want to include my plug-in VIs in the distribution with the executable - I want to call them by name and path only.

Hmm... too bad that CLA courses do not teach how to solve problem.

Very droll Irene (or, at least, I think you're being droll - you forgot to add a smiley to the end of that sentance )

I guess (I am not NI, so guessing) you got error message because your dynamic called vis are broken because couldn't find some subvis. LabVIEW runtime engine does not know where to search for subvis, unlike development environment.

Hmmm - that's just crazy enough to work! My VIs do have subVIs, and I thought that the implicit internal location that is saved within the VIs that I call would be enough to load in the subVIs too... Thanks - I'll give it a shot!

It seemed like you were ok if you had the LV development environment on your computer, but if not it became a real hassle.

Good point - my test machine has the LabVIEW dev environment on it, but I still can't get it to work - and the final install probably won't have LabVIEW on it

Are you suggesting that building a VI in with a generic exe and then copying it out of it again works? you're right - that's nuts! I wonder if that means that there's some sort of flag in the VI that determines if it's been "built" or not...

Anyone from NI care to chime in on this one? (pleeeeeeeeease?)

I thought this had been fixed before LabVIEW 8, but up until now I'd never had a need to check:

I've got an executable that I've created, and in the spirit of modularity, I'd like to call a VI that is completely external to the exe - it wasn't included anywhere in the build. I use a strict-type call to trawl through a folder with a bunch of VIs in it until I find one with the correct connector pane (an old trick I got from the AAD course a few years ago), and then try to load it. Sure enough, I get a "Error 1003 occurred at Open VI Reference - The VI is not executable." - only VIs that I include in the build (even if they aren't referenced by any other VI) will load properly.

Again, I thought I saw a way around this a while ago - can anyone please enlighten me?

...but <VI list> are missing.

Oops - sorry - they should be there now.

Well I'll take the beer...

I would have stopped there

I'm more than happy to bring up my 250th post by offering you a beer at NI-Week 2006 - add your name to the steadily growing list of people for me to shout...