ThomasGutzler

You forgot the built-in WiFi! And yes, unless you need the I/O pins it sounds like a fun alternative to play with. Although, running an OS and LabVIEW on 512MB might be a little optimistic

Hmm, must have missed that one. Or ignored it because to the non-LabVIEW user it just doesn't mean anything except "I loooooove those colours. They're awesome!" - and to the LabVIEW user it just means "lucky I'm not maintaining that". It's a little bit like posting a weirdly convoluted 1 page snippet of text-based programming language - nobody's going to read it or find it funny. I prefer the small ones I can look at for a few seconds and actually understand what's going on without having to read the paragraph of explanations. But I guess the world of programming languages has long ago exhausted the pool of simple and original WTFs.

I really like the idea of svn revisions linked to executables like that. I've attempted similar things but I'm not writing customer facing software so I'm not motivated enough to do all that manual stuff every time. Sounds like a good job for a pre-build action though! In fact, I've tried solving it with a pre-build script but I never got it to a state where I liked it. Has anyone?

I'm still waiting for the first LabVIEW codesod

Relative to a right click option, that qualifies as "lots of extra work" I'll keep it in mind for one of those rainy Saturdays...

Is there a way to "Find Callers" or "Find all Instances" that excludes the instances that are currently in a disabled case of a (conditional) disabled structure?

Time to wipe the dust off this one. I found myself in a similar situation as the OP where I want to exclude code using Conditional Disable Structures. In my project, I have multiple Build Specs and I wanted to change the Conditional Symbols based on which Build Spec I'm running. For example, I could have a Debug and Release Spec. I know that the IfDef.llb (LV\resource\plugins\Utility\) provides a SetSymbols.vi, so my first thought was to have a Pre-Build Action which calls SetSymbols.vi to set my key-value pair. That works fine. This could turn messy if there are multiple Symbols that might need setting for different Build Specs and instead of having lots of small vis that each set a single Symbol I want something a bit more manageable. So why not allow setting of the Symbols via the Build specification description? So I made a small vi that you can drop in your Pre-Build Action.vi, which reads this text and sets any of the symbols it finds. LcExtra_IfDefSetSymbols.viLcExtra_IfDefPreBuildDropIn.vi People who don't like this idea may want to replace reading the Build specification description with reading a separate .txt file which they include in the project that contains symbols for all possible build specs. There are many ways ... Of course, if you're in any way interested in this topic, the first thing you should do is support this idea in the LabVIEW Idea Exchange, which would make all of the above obsolete.

I don't have access to the IMAQ library, so I can't run your vi, which I've attached. 6.vi From looking at it, I see that I misunderstood your description about what to do with the red layer. You extract the red layer and average over multiple red layers. In my VI I remove the red layer from an image and average over the modified images. That's easily fixed (see 2nd attachment). Create modify average image.vi I see several problems in your code: 1) You shouldn't have a hard coded 3000x3000 array sitting on your BD. Use "Initialise array" to create that at runtime 2) You have several uninitialised shift registers. That's going to cause weird behaviour 3) You're adding two U8 arrays together. The result is another U8 array. That's going to cause you a LOT of pain, because in U8: 200+240=184. What you want to do is have the array that receives the sum be U16 or SGL. 4) The outer shift register you're using (I don't understand what for) is never reset. So you'll just keep adding images together in a weird way which is probably not what you want. 5) You should look into Event Structures

That's gold!

Thanks I guess I could have put R,G and B in a cluster instead and continued with a 1D array of clusters of 3 elements of 2D arrays. But that would have made it so much more complicated!

Ok, let's do your homework... Create modify average image.vi

I noticed that but I wasn't even sure it was LabVIEW - looked to simple to do anything useful. Guess we'll have to wait for the DVD release.

Assuming you have your 2D arrays (of equal size) in an array, which you use to iterate the loop, why not do this? Or, if your arrays are quite large and you have many cores:

I've bookmarked this one a while back. https://decibel.ni.com/content/servlet/JiveServlet/previewBody/22385-102-3-42676/LabVIEW%20VI%20Dimensional%20Model.pdf Not sure if the same properties also apply to BD

I know nothing about DCT compression, but I would assume that you can calculate the compression ratio: ratio = (size of new image) / (size of old image) It's up to you how to get the sizes. You can use the amount of bytes in a file or the amount of bytes in a data structure containing the images (flatten to string + string length)

I've been trying to solve the same problem. I got it to work, but slightly differently, so I tried out your solution. It works, unless you're trying to start the vi from the project explorer. This is what I came up with. It's a vi, that runs when opened and re-launches itself if it finds itself in the "wrong" instance. (That might be a bit dodgy but it works for me and it was easier than writing a launcher for every tool I want to run in this way.) Once running happily it can search through the paths of all vis on the block diagram. Find VIs on BD by path.vi - If I'm opening it from a Block Diagram or a Front Panel window, it should act on *this* vi (works for BD but not FP) - If I'm opening it from a project explorer it could act on the selected vi (not attempted) - If I'm opening it from the LV launcher the user needs to select a vi with the browse dialog (works) I'm still unsure which application instance I should be using for the different cases - there are just so many to chose from.

Regular expressions can be difficult and every language seems to have them implemented slightly different. The basics are the same and they are explained in the LabVIEW help. For more info you can try the Regular Expressions Cookbook or any of the 20700 Google matches for "perl compatible regular expressions cheat sheet". And when you have finally mastered them, you can achieve anything! There's one thing I'd like to show that possibly not everyone knows. Rather than cascading matches and using the "whole match" terminal, you can extend the Match Regular Expression node to get access to submatches like this:

He, who manually merges conflicted .lvclass, lvlib or .lvproj files - successfully! - shall be my overlord. How many times have I considered changing mime-type of those beasts to binary just to avoid the pain that inevitably comes with a (what svn thinks was a) successful, automatic merge of them.

Really, the Basler API presents you image data in png format? Interesting. PNG is already compressed. You're done! Congratulations If you want lossy compression instead, you need to first convert png back to bmp or some sort of raw format and then pass that into your new compression library - unless that library accepts png format. If this is a final year project, you should be doing more research on that instead of asking what's best. Also, your "." key seems to be broken

They've changed the internal format of flatten to string between 2012 and 2014. This is what you want to do on your 2014 application:

Maybe you should mention that it doesn't actually convert the code - just the class structure. Unless you've added that feature in last weekend

This can't be right. Did you try fixing that file manually or does it actually mix "," and "." as decimal separators in your txt file? 300 1,70367 301 1,7032 302 1.70275 303 1.70229

Maybe you could attach the file you're reading and the actual vi doing the work?

I haven't tried removing compiled code via menu options for a while because I just use my own script now. From memory it just froze or didn't actually process all vis in the list. Also, sometimes I don't want to remove compiled code from the entire project but only from the files in my projects folder (not the ones in user.lib etc). The dialog you get through the menu options doesn't support sorting by file name, which makes that rather painful.

This doesn't always work for me - also, it takes forever for larger projects. Here's my solution, which handles .vi, .ctl, .lvclass and .lvlib files: RemoveCompiledCode.viLcArray_Join_STR.vi I run it every now and then just to make sure I haven't missed anything in my projects.