JKSH

Hi,

************* Exception Text **************

System.InvalidOperationException: DragDrop registration did not succeed. ---> System.Threading.ThreadStateException: Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it.
at System.Windows.Forms.Control.SetAcceptDrops(Boolean accept)

 

 

This error does not show up when I start the application through the SO windows menu directly (as a standalone application).

When you run a standalone application, your Form's constructor and the other methods all run in the same thread.

However, LabVIEW automatically switches between different threads to run your code. You will get a .NET exception if your Form is accessed from the "wrong" thread.

See http://stackoverflow.com/questions/6373645/c-sharp-winforms-how-to-set-main-function-stathreadattribute to get started.

I took up C as an elective while studying Electrical Engineering, and discovered that I really enjoyed programming. So, I learnt C++ as a hobby, which opened doors to an internship to develop a small embedded system. Then, I used my hobby and internship portfolio to land myself a full-time job in a LabVIEW house :-D

Ok, let me check that I've understood you correctly: You want to compress the image and save it to your hard drive, to view the image in the future. Is that correct?

Can you explain what you mean by "real time"?

image that I captured from Basler cam is in .png format ....649*494 size( not exact).

One thing isn't clear to me: How did you produce this .png image?

PNG is one of the many image compression formats out there. So, if you have a PNG image, that means it's already compressed.

i have to compress ghis image without much degradation in the image quality

You will need to strike a balance between image quality and compression size. For example, see the Write JPEG File compression VI: http://zone.ni.com/reference/en-XX/help/371361L-01/lvpict/write_jpeg_file/ It lets you choose image quality. If you choose "high quality", you will get less degradation, but a bigger file size.

Note also that PNG is not optimized for compressing photographs, while JPEG was designed for compressing photographs.

I did chose yet...the sing I picture quality is not so good...which compression techniques would be better...i am new to labview..

Which technique is better? That depends on what you want to do with the image. Can you describe your project in more detail, and tell us how you want to use the image?

Hi,

Have you already chosen the type of compression that you want to apply? How do you plan to use the compressed image(s)?

Here's one possibility: http://www.ni.com/example/30667/en/

Hi,

Hi,

I'm facing this issue with LabVIEW 2014.

I have made a program with LV 2012 that passes some clusters to another application, made with LabVIEW 2012 also.

All clusters are passed as strings between the two programs, using "Flatten to String" and "Unflatten From String" VIs.

Well, everything works smooth when both applications are compiled with the same release of LabVIEW.

I have rebuilt the application that send data with LabVIEW 2014 and the receiver generates an error because cluster version is not recognized

I don't have a solution immediately, but try flattening your cluster with both LabVIEW 2012 and 2014. Save the flattened strings to disk, and then compare them with a hex editor. What differences do you see?

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:

pic.png

I believe that setting  is for compatibility between LabVIEW 7.x and 8.x http://www.ni.com/pdf/manuals/371780e.pdf

Anyway, could you please provide a link to any documentation/discussion about the change in the internal data format between 2012 and 2014? The latest changes I could find are between LabVIEW 2011 and 2012: http://forums.ni.com/t5/LabVIEW/Why-is-a-flattened-variant-different-in-LabVIEW-2012-and-LabVIEW/td-p/2329878

Hi,

1. Please show your code.
2. Did you install NI-Serial on your RT target?
3. What do you mean by "doesn't work"?

Another way to think of it is in terms of deep copy vs. shallow copy. You can think of a branch as a shallow copy -- there are two wire branches representing the same data so it looks like 2 copies, but internally they refer to the same block of memory. However, if 2nd branch needs to modify the data while the 1st branch still needs to access the original data, then the 2nd branch will fully duplicate the data (i.e. make a deep copy) and modify this copy.

For a more technical and in-depth look at the topic, see the VI Memory Usage article.

(P.S. I'f I'm not mistaken, this copy-on-write mechanism only applies to structures like strings, arrays, and clusters. Scalars (Booleans and single numbers) are always copied fully, as the impact is negligible.)

In the final run up to the release no change other than bug fixes should be allowed and even then the developer should be made to walk over blazing hot coals first to see that they really are serious in their commitment to them.

To be fair, he did say it was a comment made in jest (see post #7)

This doesn't always work for me - also, it takes forever for larger projects.

What happens? Sounds like a bug that needs squashing.

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.

NI would do well to accept contributions from the community!

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

1. Have you made sure you pass the arrays as Array Data Pointers, and not any other format? http://zone.ni.com/reference/en-XX/help/371361L-01/lvexcodeconcepts/array_and_string_options/
2. What happens if you call this DLL from another C++ program?

double rms = calibrateCamera(objectPoints, imagePoints, imageSize, cameraMatrix, distCoeffs, rvecs, tvecs);

from compiled code, functions works. Non of from LabVIEW data is used to call this function.

objectPoints is a vector created from Apoints  by arr2vect() while Asize is used to properly place elements in mentioned vector.

Well, you are using LabVIEW data to create objectPoints.

Crashes caused by memory errors don't always happen immediately. For example, the error could have happened in arr2vect(), but program only crashes when you call calibrateCamera(). Or, by removing calibrateCamera(), you changed the memory layout of your program in a way such that the error doesn't cause a crash anymore.

I've seen this issue extremely frequently over the past few weeks (sometimes, LavaG.org is one-day-up, two-days-down for me). Is anyone else seeing this?

Hi,

Have a look at the FPGA Math & Analysis VIs and Functions. There are ready-made Butterworth and Notch filters.

By the way, if you want to post any code in the future, open your LabVIEW Block Diagram, select the code, and click "Edit" -> "Create VI Snippet from Selection". That produces a high-quality PNG file that other users can import directly into LabVIEW to test your code.

I might want to run the analysis on "any" computer without having to trouble the user to have a DB server installed.

An SQLite database consists of a single standalone file, which your application can place anywhere it wants. No need to install a server. (That's why it's called "Lite")

There's even the option of an in-memory SQLite database (which exists in RAM only, not on disk -- the user will never know that SQLite was involved)

 

LabVIEW 32-bit running on a 64-bit OS can allocate up to 4GB of memory as stated in this document: http://digital.ni.com/public.nsf/allkb/AC9AD7E5FD3769C086256B41007685FA

On a 64-bit Windows operating system, LabVIEW 32-bit can access up to 4 GB of virtual memory without modification.

Ah, I didn't realize that LabVIEW had LAA support. Thanks for sharing!

Hi,

I know it's not actually running out of memory because the PC has several GB free when it happens and the application is using less than 2GB and running on 64bit.

I presume you meant that you are running a 64-bit OS. However, note that a 32-bit application running in 64-bit Windows is still limited to 2 GB RAM by default: http://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system

Hi,

There are a few ways you can do this.

First way

Make the program in A write "true" to the NSV when it starts, and make it write "false" before it quits.

This is simple, but there is one disadvantage: If the program in A doesn't quit properly, then the value will stay "true". For example, if computer A loses power, the program stops running but it can't write "false".

Second way

Make the program in A write a value to the NSV every second. The program in B doesn't check the value, but it checks the timestamp. If the timestamp doesn't change for 5 seconds, then B sets a local flag to "false".

You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations.

Isn't that upside-down? LVClasses are specializations of LVLibs, so they inherit the strengths and weaknesses of LVLibs, not the other way round.

If LVLibs are improved, then LVClasses will automatically gain those improvements too.

2. A function per VI is a purely semantic imposition for dynamic dispatch.

If I've understood Jack's point correctly, the issue is that the one-function-per-VI system significantly increases the number of files in a project. This increases the effort required to write and refactor code (all LabVIEW code, not just LVClass code). This also amplifies the lags caused by widespread static linking.

Great work! How long did this take you to make?

I had to click "Undo" 3 times to beat it... 

LLBs don’t seem to be equivalent (though I never really used them).  No namespacing, no Private scope.

No source control for individual VIs either.

My (probably very unrealistic) initial goal is actually to recreate SC2 melee in LabVIEW. A secondary goal for later is to get OpenGL working nicely with LabVIEW and SDL. I have started this bit several times and never really got enough momentum to keep development up.

A worthy initial goal 

Does that include "standalone" OpenGL? OpenGL support would be great for advanced data visualization in LabVIEW.

As for momentum, I have a large stop-start project myself. I found it very useful to document my thought processes and experimental findings. I'd get back into the project after a ~2-week hiatus and would've forgotten much of what I was planning. The documents helped me get back into it quickly without having to restart.

• I don't receive a valid response from ping between the two computers

That means the computers aren't connected properly. You must get pinging to work first. Without this basic step, UDP definitely won't work.

What are the IP addresses and subnet masks of your two computers?

Nice!

Extra points for demo-ing with Star Control 2 

I saw this on Google+ last month: https://plus.google.com/107942026210962154106/posts/9cZoas7UgLy Are you guys working together?

See http://floating-point-gui.de/ -- it explains why floating point numbers lose precision.