crelf

Thanks so much for everyone's help - I appreciate it greatly. I've gone for a combination of options that have resulted in a source distribution of all of the dynamic components. The new Project Explorer has certainly helped me here as it offers a layer of abstraction for the developer - I've created the overall system, and I want my developers to be able to define new and change existing dynamic components without the need to touch the main architecure - I've created an application within an application, and the improvements in LabVIEW 8 have certainly helped. Thanks again - I'm a happy little vegemite! :laugh:

I posted you that address to help you understand (in a friendly way) why you hadn't gotten a reply to your question yet. Since you didn't understand what I was getting at: I wanted to point out the it is very bad form to either re-post your original question or post a reply to your question with the intent of just getting everyone to look at it again. Not only is it bad form, it won't help your cause - in fact, it'll probabaly hurt it as you may have offended the person(s) that could very-well help you. Also, you gave us less than 24hrs to answer your question before you resorted to make us look at it again - LAVA users are spread across the globe, so we're in all sorts of timezones, and what you did was just plain rude. In summary: it's a user-based forum - none of us are getting paid to help you, our livelyhood doesn't rest on bowing to your needs, so being pushy will get you nowhere. If someone can and wants to help you, then they will. If not, then you'll just have to get over it.

You might find the answer to that question here.

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