crelf

now that sounds spooky...

I understand and fully appreciate your concerns, and I think that you've touched on a very real idea, but I prefer to look at it from another angle - with power comes responsibility :ninja: , and I see this as an extremely powerful technique. Like any file that you download from the net - if you don't trust it, then don't use it. At least with LabVIEW VIs you can open the file without fear, so you can check the BD for rougue scripting nodes. But look on the upside! For example (hypothetically speaking of course ), wouldn't it be great if there was a tool out there that could automatically paste a code snippet in all of the structures on all of your diagrams within a project to register wether every portion of the code in a project ran? Sort of like a statement converage tool? PS: Commercial: Oh, and if you'd prefer to stay out of the theoretical world and could use such a tool, it's part of our VISTA toolkit - contact Wyatt Meek at V I Engineering

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

Well put!

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

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?

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

Looks like LabVIEW uses implaceness with the common node.

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

Well summarised!

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

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

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

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:

Yes - yes you were

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:

Awww man - you answered too quickly!

run the attached VI - what's the difference between the two arrays? Download File:post-181-1146771059.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

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

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 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. Very droll Irene (or, at least, I think you're being droll - you forgot to add a smiley to the end of that sentance ) 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!

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?