Rolf Kalbermatter

It depends on the type of GPS device you are using, but most civil type GPS will only be accurate to about 50m, and that can get less depending on weather conditions such as clouds or rain.

Aside from any encoding issues, it would be enough to change the line: System.out.println(b);[/CODE] [font=arial,helvetica,sans-serif]to[/font] [CODE] System.out.println((char)b);[/CODE] [font=arial,helvetica,sans-serif]The first invokes the println(int number) method, while the second invokes the println(char character) method. This of course will only work for ASCII characters up to decimal code 127 which LabVIEW should be normally generating, unless you use foreign language characters in the format specifiers itself.[/font][font=arial,helvetica,sans-serif]If you need proper character encoding too, you would have to wrap the input stream into an input reader of some sort.[/font]

You will need some ground reference somehow (so two wires at least) and also some biasing of the signal with a resistor to pull it to the passive level. Otherwise you can't measure an open collector signal properly. The cheapest will most likely be one of the USB DAQ boxes.

Well the name of the Windows DLLs has not changed between 32bit and 64bit Windows just because they wanted to avoid to having to change all DLL names everywhere when referencing DLLs dynamically by name. The 32 in the name is a left over artefact since all these DLLs also had the same name without 32 in Windows 3.x. Back then when moving to 32 bit architecture the MS developers chose to use a distinctive name to avoid name collisions. When moving to 64bit, MS decided to use different base directories instead and leave the DLL names alone. So VIs accessing system DLLs can work both on 32bit and 64bit Windows but you need to be aware that some parameters can actually change in size. For instance any HANDLE datatype (almost every WinAPI datatype starting with a H) is a 32 bit entity in 32 bit Windows and a 64 bit entitiy in 64 bit Windows. So the right data type to use for such parameters is the (unsigned) pointer sized integer. If you use a normal 32 bit integer it may still work on resource constrained systems but will sooner or later fail badly when your system has more memory and the value of handles can go above 4GB address range. Same for any pointer that you decide to treat as integer type for whatever reasons and there are also a few other Windows datatypes that can change bitness.

While ActiveX has the feature to also launch the application server there is no reason why you can't use the TCP/IP interface, and I'm pretty sure they do that for multiplatform reasons. You simply have to first launch the executable with System Exec yourself. The entire VIPM stuff is likely a bit involved and complicated, enumerating the installed LabVIEW versions from the registry, finding their install path, reading (and possibly manipulating) the according LabVIEW.ini file to find out the TCP/IP server properties and then trying to connect to it and in case of failure start it with System Exec and try again to connect. But it's all doable although the details about timeouts to use when trying to connect can be a lot of trial and error.

The most likely reason for this is that the concept of Recycle bin is not very consistent across the different platforms LabVIEW runs on (Windows, Linux, MacOSX) and works quite differently. Also technically the Windows Recycle Bin is in fact a tacked on feature to the actual Windows core, residing in the Windows shell component which is a very chaotic collection of interfaces, both COM and procedural oriented and shows that many people have added functionality over time with VERY different ideas of how to do it. There is no central authority making sure those interfaces are consistent nor interoperable, as every product division seems to have added their own gadget with their own preferred architecture into it. Also these interfaces often chance in incompatible ways between OS versions, with APIs being added, depreciated, changed and even removed at will.

You came across the only real problem about re-licensing source code under open source licenses, be it BSD, GPL or whatever. That is that once it has been posted there are typically multiple authors and with that usually also copyright holders (unless it is a trivial patch submission) and in order to change the license or also distribute it under an additional license, you have to get the consent of all copyright holders. Otherwise, unless you have posted the original code under one of the rather artificially crafted licenses as brought up by Shaun, you are always free to grant other licenses under completely different terms, as you are still the copyright holder. A license does typically not relinquish the copyright (in fact the license itself never does but the license document can of course contain verbiage that relinquishes the copyright), that can only be done by a copyright transfer, either by trade such as an employment or "hire for work" contract or by a written statement to release the copyright for instance into the public domain. Also copyright typically expires a certain time after the creator has passed away. But copyright and licenses are totally different things. Copyright (at least in Western countries) automatically is instantiated at the moment when something is created. No registration or whatever has to be done to get it and only an explicit statement can give it away, but that is not what licenses are normally about and certainly not licenses such as BSD or (L)GPL. OpenG allows you to release your code into the public domain but not the OpenG VIs itself, unless you are the original author of them too. And mostly to AQ, although not so much as serious suggestion: Since the attribution clause is such a problem in terms of maintenance, why not getting rid of this altogether and scraping the sentence in the LabVIEW EULA that requires all LabVIEW applications to have an attribution clause to the fact that they are created with LabVIEW? That would save maintenance nightmares for all LabVIEW users too!

It should AFAIK, at least if you as the application developer legally own the LabVIEW for Linux development system.

By this reasoning you wouldn't be able to add anything from lavag either including this library. I find that a bogus reason. Strictly speaking even your already existing reuse libraries and even any newly developed VIs for a specific project would have to be considered unapproved under this aspect. Yes you can write unit tests and whatever else to get them stamped as some sort of approved, but so can you with 3rd party libraries. Not saying here you are wrong but trying to point out that the hysteric fear about contaminating something with open source and whatever is leading down a very slippery path for sure.

The latest package was done by Jonathan Green. I guess he missed the platform limitations when porting the package file to VIPM. Personally I would say the LargeFile library doesn't really make sense in post 8.21 at all, and even in 8.20 only very little. I'm not using VIPM for package generation so I can't modify the package configuration myself.

The availability for all platforms is definitely an error. Not sure when that got into the Toolkit. I only wrote the library years ago never really packaged it. As to LabVIEW versions, since LabVIEW 8.0 almost all file functions use 64 bit offsets and since about 8.20 they actually work mostly fine. So it makes no sense to include this library in a Toolkit that is >= LabVIEW 2009 only.

For (L)GPL software (which applies to the DLL portion of the libraries that have them) you do need to mention it both in compiled apps as well as the source code (the second is logical as you can not remove existing copyright notices from the source code). All versions of the BSD license also have one clause for source and one for binary distribution and both of them apply independent of each other. Since the LabVIEW OpenG part is basically BSD the answer to your question would be therefore a clear yes! I would consider it enough to mention in the About box the fact that you use the OpenG libraries and then add a license.txt or similar file to the installation where you print the license text. If your app makes use of the OpenG ZIP, LabPython or other library using a DLL you should strictly speaking also add the relevant LGPL license text and point to the Sourceforge OpenG project where one can download the source code of those libraries.

Actually it's not! You are right that the shared library will refuse to work if your clock is set after June 2010 or so, by simply posting a dialog at runtime. But the reason of the original refnum problem is that this library makes use of so called user refnums. These are defined by resource files that get installed by the package and in order for those refnums to be valid the according resource files have to get loaded by LabVIEW, which it only does at startup (at least I'm not aware of any VI server method to do that at runtime too, like the refresh Palette method the VIPM uses after installation of a new package). I'l be having a look at the library soon and see if I can do anything to resurrect it, but feedback has been very limited, so I was simply assuming that nobody was using it. Please note that the SSL support of that library is really minimal. It allows to get an https: connection up and running but lacks any and all support to modify properties and access methods of the SSL context to change its behavior or for instance add private certificates to it.

In addition to what asbo said, testing with no name adapters is anything but conclusive. Some things can work, with a particular hardware device and depending what driver version you get installed and it then can not work after some seemingly unconnected changes like Windows updates. So even if NI can conclude one thing it may only be valid for that exact HW/SW combination on that computer and behave rather differently on other setups. Sometimes NI HW may seem expensive in comparison to no-name, or semi no-name asian low cost devices, but there is a difference in what you get. One is a hardware device where the people at NI actually sat down and wrote a specific driver for it by people who have some serious device driver development experience, the other is usually a minimalized copy of the reference design from the chip manufacturer with often a completely unaltered device driver from the same chip manufacturer. However reference designs are usually not meant to be end user sell-able items but developer platforms to "develop" a product with. The provided device drivers with those reference designs are at best a starting framework but seldom a fully featured device driver. FTDI drivers are an exception in that respect, as they already are pretty feature complete, although support for things like line breaks, no-data detection are still not something that I would rely upon from the reference design driver. It's the reason why FTDI based adapters are usually fairly functional for standard serial port applications, no matter what no-name producer sells them. Most no-name manufacturers wouldn't know what button to push to compile their own device driver!

Yes hardware exposure on digital logic certainly helps the understanding. If you think of integers as a simple register or counter, the oddball in the mix is rather the signed integer than the unsigned due to its use of one's complements! Think about it. The MSB is the sign! -128 => 0x80 -1 => 0xFF 1 => 0x01 127 => 0x7F A naive approach to this could be instead (offset notation): -128 => 0x00 127 => 0xFF or (separate sign bit): -127 => 0x8F -0 => 0x80 0 => 0x00 127 => 0x7F The reason computer use the one's complement is that all the others are rather difficult to implement efficiently in logic for either addition and especially subtraction. I have seen such code too in the past and simply assumed that the original programmer either didn't think further than his nose, or may have used signed integers before, then in a frenzy to avoid coercion dots, changed them to unsigned without reviewing all the code and noticing the now superfluous positive check. In one or two cases the effective code was in fact in the negative branch of the case which of course never could happen, so that made me scratching my head a bit.

I'm not sure where the claim comes from, about that understanding unsigned numbers is difficult. It supposedly is the reason that Java doesn't have unsigned integers since the original Java inventers claimed, that nobody understands them correctly anyhow so a language better does not provide support for them. I still have the feeling that they did not understand it and assumed that what is true for them must be true for everyone. Now if you need to implement binary protocol parsing that contains unsigned integers you really have to go nilly willy to get the right result in Java.

PID being a certain algorithme, indeed has a high chance to come up with similar code. But to be safe it is definitely a good idea to go from the text book description of the algorithme and not from looking at another implementation of it. Open Source development for instance usually allows for so called clean room development. It means it is considered permissible for someone to use reverse engineering practices to produce a textbook description of the interface and its requirements and someone else using that description to implement the code. But the reverse engineer has to be careful to not describe the internal algorithm in more details than absolutely necessary to allow for a compatible implementation. The implementation of an algorithme can be copyrighted, the workings of it not, that is possibly a case for patent protection, another can of worms. But much of the confusion about copyright also comes from a confusion between copyright and patent right. One protects the form, or specific implementation of an idea, the other more the content of the idea itself.

I consider it in fact one of the more successful ones. I'm no Apple fanboy by a long stretch but not everything Apple does is bad. But I have not seen any speech recognition solution yet that had not various troubles in one way or the other, and some simply did not work at all. Designing algorithms to recognize perfectly recorded voice isn't that complicated, but we usually do not want to go into a multi million dollar recording studio to dictate our little smart phone some commands.

Well ask OpenSource programmers! Many think that looking at non-free code is already more than enough to endanger an Open Source project. Wine for instance has a clear policy there. Anyone having had access to Windows source code is not welcome to provide any code patches. They can do testing, documentation and such things but source code patches are refused if project leaders have any suspicion that the person sending in the patch might have been exposed to that code either through the Microsoft shared source initiative or the illegally leaked source code a few years ago. Also they state explicitly that someone having looked at the (incomplete) source code of the C runtime or MFC library, that comes with every Visual Studio installation for many years, should not attempt to provide any patches to code related to these areas. If the submitted code raises suspicions of such influence, it is refused. They even have for many years refused code patches from people involved in the ReactOS project, another Open Source project trying to create a Windows compatible kernel but not building on Linux but directly sitting on top of the BIOS interface, meaning it is a fully featured OS in itself, because some of the contributors to that project have more or less openly admitted to the use of disassembling Windows for reverse engineering purposes. So not just exposure to source code is a serious risk to creating copyright challenged source code but also looking at the compiled product of such source code to closely. Some Open Source programmers even refuse to look at GPL source code since they believe that it poses a risk if you do not plan to release your own source code under (L)GPL yourself, but under a different possibly more permissive open source license like BSD. Copying GPL source code in anything non-GPL is anyhow a sure way of copyright violation. Memorizing source code and recreating it is more complicated but could be in many jurisdictions a serious legal risk already. And very often the question is not who is more right, but who has a longer financial breath to go through all the legal procedures. So be careful offering to recreate copyrighted code. NI may not be interested to go after you in general, or where you currently live or for whatever other reason, but many little things like this could build up to something undesirable in the future. Also you have to think about such things anyhow. Just doing it has always the danger of the so called sliding perception. If this hasn't caused problems today I should be fine going a little further tomorrow and even further next week and before you are aware of it you operate in truly dangerous areas.

It may not be very much if the purpose of that project is to actually do some work on the speech recognition algorithmes themselves and not just create an application that can do speech recognition. However there have been many companies trying to get a well working speech recognition software designed and more than one of them failed. So it is definitely not trivial and an area of expertise with only very few people knowing the in depth details. Most of them probably aren't here on lava but on more special interest boards into that area.

Yes you do!

I think you might still end up with interlinking problems at least in some versions of LabVIEW. I know that LabVIEW will revisit ALL CLNs loaded into memory linking to a specific DLL name if you change one CLN to load this DLL name from a different location. It should of course completely ignore anything inside a conditional disable structure, but I'm sure it didn't in some versions. Also with simply installing the right DLL for the platform you can avoid the conditional disable structure AND also develop on only one platform without the need to load the VIs on both platforms and make edits. Of course you have to test it on the other platform too, but you don't have to load each VI in every different platform everytime you change something on the CLN.

That's what he seems to point at here: And it indeed adds an extra hassle to building an application with such a library. But I don't think the solution is in allowing even more wild card options to also specify relative path patterns. A 64 Bit DLL simply shouldn't be installed on a 32 Bit app installation and vice versa. If VIPM would support specifying platform settings for individual files or file groups, that would be quite a moot point, I think. I solved it for me by creating my own improved version of the OpenG Package Builder, which supports that option. (The improvements were not to support this, it already does! But its user interface and some other options are a bit limited. Also note that VIPM does provide quite a different UI for defining a package. More user friendly but harder to add the feature to specify platforms and versions for individual files)

The proper solution is to use some kind of installation tool like VIPM and install either DLL, depending on the bitsize of the installation target into the same directory. Ohh wait VIPM doesn't support file specific version settings, when building a package! Well the good old OpenG Package Builder does! And its opg file format is still used and recognized by VIPM too. If you want to stay with VIPM you have to use the PostInstall step to make those modifications after the installation. Your proposed solution has at most some hackish merits. It will cause many problems further down the road as you will edit the VIs and forget sometimes to follow the very strict VI open protocol to avoid it. And even if you won't others using your library for sure will.

Well for simplicity I consider variable sized messages with prepended size information similar enough to fixed size messages, as in both cases the size is known before you start the read operation. And the link to the VISA Abort VI can be found here!