JKSH

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

Hi, 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 This is a historical relic of LabVIEW. The same error code was used to represent two different errors in different modules (Code 2 could mean LabVIEW-out-of-memory, OR GPIB-has-no-listeners). Unfortunately, that means LabVIEW now can't differentiate between the two errors. So, both error messages are displayed: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/More-sensible-error-messages/idi-p/2244422

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

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

No source control for individual VIs either.

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.

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.

Hi, You can manually search for tabs yourself to split the text into separate strings. If you install OpenG, you'll get the "String to 1D Array" VI that is designed for your use case.

As ak_nz and drjdpowell have both said, it is perfectly fine to implement concrete code in an abstract class. This lets you make full use of inheritance to keep your project tidy and organized. "Rules" and "best practices" are established to guide you down a tried-and-true path, to maximize your chances of succeeding the first time you try. However, a set of rules will never cover all possibilities so simply following rules will not guarantee you success. As the software designer/architect, it is your job to decide whether or not it makes sense to follow a rule in a particular part of your project. Referring to the two quotes above, I'd say: "It's ok to inhibit parent behaviour if 2 out of 20 children need to do it, but not if 18 out of 20 need to do it. If 10 out of 20 need to do it, well... make a judgement call." I'll answer your question in multiple levels. Level 1: The definition of "Abstract" In OOP, an abstract method is defined as a method which has no implementation. Its purpose is to define an interface for children to follow, and it is the children's job to provide the implementation. An abstract class is a class that contains one or more abstract methods. An abstract class can contain concrete methods too. So yes, if you put code in your parent method, then the parent method is concrete, not abstract. However, this in itself doesn't make the parent class non-abstract. Level 2: The (lack of) necessity of "Abstract" From your original question, I gather that you're wondering if you need to keep your parent "abstract" in order to abide by some set of best practices, and your latest post suggests that you're no longer worried about this. To reaffirm: Many examples of inheritance show you an abstract common ancestor implemented by multiple children. However, there are no rules that say you must have an abstract common ancestor. You are free to have a fully concrete (and usable) class as your common ancestor if it makes sense to do so. Level 3: The (lack of the) concept of "Abstract" in LabVIEW Since you're interested in formal definitions and terminologies, I'll throw this in: LabVIEW does not support abstract methods in the traditional sense (yet?). As I said in Level 1, an abstract method has no implementation by definition. However, what people commonly refer to as "abstract VI"s do in fact have an implementation: This implementation simply does nothing. "Having no implementation" is not the same as "Having an implementation that does nothing". LabVIEW doesn't let you create a VI with no implementation. In other languages, your program cannot be compiled if you inherit from an abstract class but don't provide implementations for all of its abstract methods. This can be a useful way to remind developers to implement them. LabVIEW doesn't do this -- a LabVIEW program will happily run even if you call an "abstract VI". To work around this, what I did in a recent project was to implement pop-up dialogs in my "abstract VIs". This way, I'll get a message at runtime if I forget to implement something in a new child class a few months down the track. EDIT: LabVIEW programmers fulfil the purpose of abstract functions by doing 2 things: (i) Have a VI that does nothing, and/or (ii) select the "Require descendent classes to override this dynamic dispatch VI" option in the class properties dialog. See this post for more: http://stackoverflow.com/questions/391483/what-is-the-difference-between-an-abstract-function-and-a-virtual-function (Note that NI explicitly rejected the term "virtual" because it's confusing to talk about non-virtual-Virtual-Instruments, so they picked "dynamic dispatch" instead) At the end of the day, knowing terminologies is useful (and important!) when discussing concepts, but it shouldn't affect how you design your project. All the best!

The documentation explains more: Event Structure: http://zone.ni.com/reference/en-XX/help/371361L-01/glang/event_structure/ Elapsed Time Express VI: http://zone.ni.com/reference/en-XX/help/371361L-01/lvexpress/elapsed_time/

Hi, What version of LabVIEW are you using? There was a bug in LV 2010 that causes LVOOP property nodes to output wrong data. See issue #255982 http://www.ni.com/white-paper/11869/en/ It was supposedly fixed in LV 2010 SP1.

I prefer to post bug reports to http://forums.ni.com/ -- I seem to get better responses and CARs that way :-D Also, in the event that it's a PEBCAK (http://en.wiktionary.org/wiki/PEBCAK ) instead of a bug, there will be lots more people who can see my issue and point me in the right direction.

I converted C:\ProgramData\National Instruments\MDF (and other large folders that don't need to be on an SSD) into a symbolic link that points to a folder on a HDD. That way, the files don't take up space on my SSD, but programs can still find the files if necessary. No configuration required. http://technet.microsoft.com/en-au/library/cc753194.aspx

Hi Sharon, How do you read the text from Excel into LabVIEW? I'm guessing that the text that you read from Excel text is encoded in SHIFT-JIS. SHIFT-JIS can encode Japanese and English text, but it cannot encode text from Turkish or Russian languages. That's why Unicode was invented. Unicode can encode text from many many different languages at the same time. To display the text in LabVIEW Unicode mode, you must convert the text into a Unicode encoding first. As a starting point, read the link I posted earlier (https://decibel.ni.com/content/docs/DOC-10153 ). I haven't tried it yet, but the example under "Converting ASCII Strings to Unicode" should let you display your Japanese text in LabVIEW's Unicode mode. (I don't think it will correctly convert your Turkish and Russian text, though. But anyway, try it first, and let's do this one step at a time. Text encoding is a moderately complex topic, and you'll probably need a few days to fully understand your problem).

Hi, What encoding does your OCR software use? Is it UTF-8 or UTF-16 or SHIFT-JIS or something else? To display Unicode text in LabVIEW, you must give it Unicode data. If you provide SHIFT-JIS text but LabVIEW tries to interpret it as Unicode text, then the interpretation will be wrong. This page might provide more insight: https://decibel.ni.com/content/docs/DOC-10153

I agree with drdjpowell. The JSON standard says (emphasis added), "An object is an unordered set of name/value pairs." This library is standards-compliant and does not need to be changed. The problem lies in the API you're communicating with. Send its developers a bug report and get them to fix it. The world will thank you for it

@jdsommer: Thank you for your detailed and open explanations. Our current project (which doesn't need a wide range of data types) has been implemented using h5labview, so it looks like I won't be able to try out your toolkit for now. I do agree that high-level convenience APIs make a noticeable difference to a programmer's job.

Congratulations on your milestone! Could you tell us more about your toolkit? Your website says, "Several attempts at LabVIEW interfaces to HDF5 have been produced over the years. LVHDF5 is the most complete and flexible interface available". What advantages does it offer over the other attempts, like h5labview? (I notice also that LVHDF5 cannot be co-installed with h5labview) I work for a systems integrator, so we often need to interface with the non-NI world. HDF5 is a popular format in the scientific community. In our current project, we had to interface with the client's data logger, which provided us with HDF5 files. Our job was made much easier thanks to 3rd-party LabVIEW bindings.

A game: https://github.com/mrhappyasthma/Snake A measurement system: https://github.com/Naviss/Oto A LabVIEW IDE plugin: http://sourceforge.net/p/lv-cct-tool/code/ci/default/tree/ A library: http://sourceforge.net/p/h5labview/code/ci/default/tree/ (I haven't used any of them except h5labview, so I can't give you an assessment on their quality) If you want a good resource on LabVIEW tricks and designs, I recommend The LabVIEW Style Book by Peter A. Blume. He walks you through sample projects, points out their strengths/weaknesses, and provides lots of useful guidelines.

Good question; I've been wondering about this too. A nice application would be adaptive and type-safe variant-attribute dictionaries.

This isn't code review per se, but LAVA does have a Code Repository for people to share their work: http://lavag.org/files/ You can also search open-source hosts (e.g. GitHub, SourceForge) for projects written in LabVIEW.

I concede, it has never crossed my mind to try this.. :-D