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

You mean like this - http://thedailywtf.com/articles/Labview-Spaghetti ?

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 do use build number to link back to source code control.  So this still means manually updating it every time which is a bit of a pain.  I've thought about ways of fixing this but I just live with it.

 

So when I'm making a build I'll set the Major, Minor, and bugfix to what ever is appropriate incrementing from the last version.  I'll then set the build to whatever the source commit number is.  So for SVN I'll right click the project, go to properties, and then use the commit revision number.  I have in the past taken the commit revision number and added one to it, because this would be the revision of the next commit but as long as there is a decent description in the commit I've never had a problem.

 

What this does for me is help isolate an EXE to source.  So years later we get a report saying this step failed.  In the report is says the EXE version was 1.2.3.534.  I then go to source code control, and find commit 534.  Hopefully there is a comment in the commit saying "commit build version 1.2.3.534" and I can roll the source back to that and see what the source was that made the EXE, that was ran when the report was created that failed.

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? 

Prepare to lose productivity: http://thedailywtf.com/

I'm still waiting for the first LabVIEW codesod

What if you use "Get VI Dependencies", with commented diagram disabled, on all VIs.

Put each dependency in a variant lookup, and then you should be able to return all callers for a specific VI from the Variant lookup.

/J

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?

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!

You used 4D arrays.  That alone should be worth some extra credit.

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

This is the approach that I've seen taken for this issue...you have to do all the work you would normally do in the NI.LV.Dialog app instance in the app instance that owns the VI from which you launched the Tools utility:

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.

I've always found that the LabVIEW help didn't explain well enough how the Match Pattern and the Match Regular Expression work. Do you know a good source for learning more about how to use them properly? Thanks

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:

I’m about to release a new version of OpenGDS.

In that version there is a new conversion tool that you got to try :-)

Conversion.png

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?

What happens? Sounds like a bug that needs squashing.

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.

The easiest way to mark everything (including LVClasses) is to load the LVProj file and go to Project -> Properties -> Project -> Mark Existing Items

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.