JamesMc86

That is what I am unsure about. I don't see what stops you posting it under a BSD license publically but effectively giving NI the license in the ToCs. As the copyright holders I think you may be within your rights to do this although I am not certain. I think you could even post your code to ni.com with a license for the public such as BSD. That is my interpretation of what I see and it doesn't mention that works are under a particular license for those who download them, it does mention that people have to maintain attribution and can't modify them but presumably as the copyright holder you can license the downloader to do this by giving them a license with the software but I suspect NI cannot do that for you.

The EULA does not require it to be public domain. It requires that you own the copyright or it is in the public domain I.e. you are not breaching copyright by posting it.

Does the RTE include BSD components though? If this is free of BSD components then any exe you create can be used by someone who is not allowed to use BSD components, however if you then have libraries that have BSD components you must then add this attribution and consider the restrictions for some companies. The RTE does not contain source code, only the dependencies for the EXE you create. Yes but BSD is not public domain. BSD means you have given someone rights to use the work (as long as it is attributed) but you still own the copyright. Public domain means there is no copyright owner and everyone can do with it what they please. I did find a good site that talked through the differences here but sod's law I cannot find it again now. Your last point is certainly something that you would need to consider. There is another section which states there are no warranties for anything on the website so I think that would cover it but this is again where a lawyer would help! EDIT: I would like to point out I have no objection to BSD licensing or feel they should not be used in LabVIEW, I am just explaining things as I see them

I think the difference is the nature of what is included. If LabVIEW contains BSD software as part of the LabVIEW environment then we include the attribution in the readme and I guess all is well, this is what many of the third party licenses that distribute with LabVIEW appear to be for. What I suspect causes the issue here is that if we include libraries under a BSD license as source then that means that everyone that builds an application in LabVIEW using that must: Ensure they also have the required legal information distributed with the EXE. Ensure they are allowed to use software licensed under the BSD (this is probably NI's biggest concern, I can't talk for the decision makers but it is highly likely we have customers who cannot include BSD source code in their own applications). It will certainly be interesting to see what the law centre say. To me it appears the difference to the developer is that putting it on ni.com does not guarantee attribution from NI in the read me. Other than that it appears the generic rights given are the same under either license, in the current state if the developer would rather see something that can be integrated into LabVIEW and lose the attribution from NI, or keep it under BSD only but be slightly more restrictive over who can use it. We can argue over whether LabVIEW should be able to distribute BSD software all day but it is a decision that has been taken by someone at NI, not anyone on this forum and so cannot be changed down this route.

Ah yeah must have been skim reading! Pleased you found something to work.

This maybe a non functioning brain on a saturday, but is that filter going to do anything? Sampling only gives you frequency content at Fs/2 so you can't have frequency content at that level, if it is there in the analog domain it will already have aliased to a lower frequency in the digital domain. You would need to over sample then filter at the desired point if you are trying to avoid aliasing.

Wow licensing is a PITA. I have been trying to learn some of the subtleties of this all and one seems to be the difference between owning the copyright of a piece of code and owning a license to a piece of code. I believe with the NI.com agreement you are giving NI a lot of freedom with what you post (a lot of this is standard across the web and must be the same for lava otherwise if you upload some code and then someone downloads it then they have distributed it and without the license that would be illegal.). The difference is nowhere in there does it say you transfer ownership of the copyright of the code to NI so I don't think you are giving that up, you are just giving NI an unrestricted license which would allow them to use the code in LabVIEW. I realise this still maybe undesirable but my understanding (I am not a lawyer as with everyone!) is different to the idea of transferring ownership as many suggest, but please correct me if I'm wrong.

Hi Daklu, I would aim to get something like this on the FPGA, I don't understand what would need to change that often once you have it down. Do you mean changing the sample rate of the module or the filter? Don't have the filter VI in front of me but you can change the sample rate of the module without a recompile by using an IO property node on the module. In terms of relative requirements I haven't tried to many. I would expect some form of FIR filter to be pretty efficient. I think anything that requires an FFT and back is going to be pretty resource hungry.

Sounds like an express vi but it may be built on that library still. If you can post some code it will help us understand what your doing.

Something I have done for rt targets is combine the serial number and mac address into a string and encrypt with a specific key to produce a licence key which could be checked on boot. You could probably do a similar thing with the serial numbers of the 9191s.

I don't have the code in front of me now but in response to your final point: A) (and possibly B) would typically be specific error handling. At the piece of code that operates you code responses to specific errors, e.g. Attempt to reconnect to a network connection. B to D would often be handled centrally (not exclusively but often). Typical practice would be to have a central process which receives the errors. At the source the error is given a classification based on the source. This tells the error handler what to do such as log, notify user and/or shutdown the system. For the specific instances you describe: Case #1: depends on what you consider to be an error for this piece of code. Typical examples might be looking for invalid inputs and outputs General advice would be identify errors you expect manually, if there is nothing you can do at that level don't bother (e.g. The issue probably isn't with an add but whatever is feeding the add function, you don't want one issue to throw a huge number of errors). Case #2: if there's nothing you can do at the source then you can't add specific error handling. I would typically string the errors together and at the end of the section of code send it to the central error handler to log. Case #3: the classic issue of human vs machine! For this it is going to depend on the mechanism you are using. For the specific example you describe you would want to be preventative I.e. have outputs limited so the controller doesn't overdrive the system. Then have some alarming in place so if this is hit, or the system takes to long to reach the desired state. This could alert an operator or shutdown the system. Hope this helps!

Ah probably should have started there. I realised what the files were but wondered who was to blame for them being left there. I would expect a system to clean this for me rather than me having to manually remove them. It appears the purge extension may do this for you so I will investigate that further. Cheers, James

Hi, I'm looking for some advice from anyone who has been using mercurial with LabVIEW. Firstly I have just been trying some branching and merging. After a merge, having been configured for merge using https://bitbucket.or...iew-integration I see some .orig files getting left in the repository. Is this a failing on LabVIEWmerge.exe to clean it up or is it the way mercurial works? I am interested in the DVCS camps because of merging. I currently use SVN, primarily as a lone developer. I like not having to maintain a separate central repo and the improved merging, primarily from the point of having sandbox branches. I like that in Git, if I have an experimental branch that doesn't work out I can delete it. Is there a similar workflow with bookmarks that can be achieved or am I going to end up with a load of bookmarks littered around the place? I liked that Mercurial integrates better with Windows and is a simpler way to learn DVCS than Git, but I do also like the look of branching in Git and think the extra flexibility may be a killer feature. That said my general opinion when you get these 'holy wars' is that there is probably no real difference between them, else people wouldn't be arguing so much over minor details! Cheers, James

Check out https://decibel.ni.c...docs/DOC-15560. It's quite a nice little utility built on scripting. It will pull anything with a colon in the first 10 characters in the diagrams.

Hi Brenton, There is another format just called TDM. It has a different internal layout to TDMS so if this is a question because you have seen this that could be it (you also have to keep the index with a TDM file). If you just want a custom extension there is no issue, just no other application other than yours will know it is a TDMS file so you will limit what will open it directly (there are ways around this with LabVIEW and DIAdem, not sure about excel). As for v2 I am not sure on the internals but there is an FAQ at http://www.ni.com/white-paper/9995/en. In short 1.0 is deprecated (but still an option if required), I would use 2.0 for new designs.

I have been having a play with mixing web services with JavaScript. If you don't mind getting your hands dirty with some JavaScript and maybe some HTML. Check out: Getting started with google charts and JavaScript: https://decibel.ni.com/content/docs/DOC-23174 AmCharts (an offline alternative to google charts): https://decibel.ni.com/content/docs/DOC-24017 It is very compatible across devices but you do have to get into JavaScript a little although I had no prior experience before this. Of course it is very hard to comment on compatibility for quite a niche platform. It claims a fully featured browser but it may be worth heading over to the Samsung dev forums to confirm websocket and/or RESTful web service support.

Once you have the driver installed it should install some api examples. The location is in http://digital.ni.com/public.nsf/allkb/BEA8C88ED8B09AF286256ED0004544F7 There maybe some hardware limitations on what you want to do though. May DAQ cards would use a counter to generate a digital pulse but the 6009 an only use the counters as inputs judging by the spec. This means you will have to use the analog output lines instead but this can only be done ith software timing which is going to limit the timing accuracy you can achieve. The lines are capable of the current though. In terms of software examples therefore check any analog output for the API calls you need.

You need to download DAQmx Base to use it on a Mac. I think it is a slightly different configuration program than MAX though I don't have any personal experience. I can't see a getting started guide from a quick search but one may install with the driver.

I would be surprised if this was used a huge amount as this would make the libraries performance far more dependent on system architecture. They would need to run on embedded targets such as smart cameras that don't have this sort of hardware available and it would have to begin maintaining very different (internal) code across platforms. If so I can only imagine it would have to use OpenCL for hardware independence. I can't get at the documentation right now but it would be worth looking at to see if that dependency is made.

I think you can do this with VISA. Drop a property node and use Serial Settings>Modem Line Settings>DTR State. It appears to be writable to the assert state. Looks like the only requirement is that they are not used for flow control (Hopefully that can be assumed!)

Not sure about direct Ethernet control but ther is certainly some switching products on PXI that could do this. Alternatively could you modify your physical hardware so you could just put a relay or similar on the power line, this should be all you need to do this to a single dut.

The risk with a system like this is that it is very easy to end up with the queue communications embedded within your code modules. This can reduce the reusability and scalability of your application so I prefer wiring the reference, especially as 3 of your functions just wrap queue primitives anyway.

I agree, the comparison between LabVIEW and C++ is moot. You can write bad code in either. It really depends on the implementation of the algorithms and that is likely to vary between algorithm. I know a lot of effort is put into the performance of our Vision libraries (it is one of the few modules support in 64 bit to deal with large data better). If you have specific algorithms to use or benchmarks your interested in it is best to compare these directly.