ShaunR

The issue is not much to do with LabVIEW and very much depends on the distro and versions already present. Your next issue may be that Linux will load another DLL with the same name if it is present in the general locations and everything will crash. The DLL should also be compiled with "-soname" so that ld and ld_config are aware of what it should do with it-dlls need to be installed, as such The easiest way is to just put it in the appropriate lib/lib64, for that distro run ld_config. Then use a symlink to point to it and hope it works. LabVIEW sees through symlinks so as long as you name the symlink the same as the library, in the CLN path, it will work on all platforms - you can just have the DLL itself in the app directory on Windows so it's business as usual. It's then demonstrably the users distro/configuration that is the problem if things don't work. If it doesn't work then you have conflicts with other, already loaded version and since the LabVIEW CLN function cannot be set to " RTLD_DEEPBIND "; you are stuck This is what -soname is supposed to alleviate but I've had mixed success. If this is the case, you can point the symlink to the version already loaded (if you can figure it out) which will work as long as the binary interface (ABI) is the same - they don't think twice about breaking it between versions, though (yes I'm looking at you Python!).You will end up spending most of your time answering Linux support with a myriad of configurations as everyone has all sorts of favourite crud installed. My advice is to get it all production ready and installation proof on windows and think about Linux for version 2. Linux devs can still try the symlink method if they are aching to use it, but you can avoid all the Linux rabbit holes while you concentrate on the library itself.

Is this on LV 64?

About 600-800us if memory serves. For Linux I opted for a symlink to the *so if it's not on the search path. If you try to load a *so from the local directory and there is another elsewhere on the search path; you normally end up with crashes. Linux handles dynamic loading poorly which I suspect is why most people statically link.

The LabVIEW help has the answer ( Intensity Graphs and Charts ). There are also examples shipped with LabVIEW, one of which includes a VI with which you can create your own colour tables for them. Once you understand how #1 works you will [hopefully] see how to emulate the behaviour with an image indicator by reproducing the colour table behaviour of the intensity chart. If you get into difficulty; post what you have tried (the VI rather than an image).

Did you save your 1.png as an 8bit greyscale image? Try with mine.

I have a LabVIEW RTL SDR wrapper around the rtlsdr.dll that I've been using and want to release it into the wild. Since I only have one device, I would appreciate it if others could try it with theirs. The state of the driver is final beta testing before release (RC1). Once I'm happy with it and proved it doesn't just work for me, it will be packaged and released (under BSD licence) so I'm looking for test pedants Since it isn't packaged, I'm looking for people that are comfortable with using it from the project file and the IDE rather than from palettes and already have the rtlsdr and usb binaries. There is an example (shown above) so you should be up and running quickly. If you have a RTL2838 based SDR and some time to run the example and report issues;. let me know and I'll see you get a copy.

Here you go. load lut.vi Rainbow RGB.lut

I think you misunderstood my objection.

I'm not sure I'm understanding correctly. But could you not put all the data into a sqlite database and query using "group by" for display?

I'm not familiar with that Rohde and Schwarz product but I did previously work at Anritsu with their equivalent products as well as evaluating competitors products. Most devices are SCPI compliant across manufacturers and if you truly want to take advantage of different manufacturers' equipment I would suggest forgoing the specific LabVIEW drivers and cherry picking the SCPI commands to produce configuration and script recipes that work on common command sets. Most devices of this type already have inbuilt functions for most measurements and a quick look at the datasheet seems to show that they are present for CISPR 16, at least. That said. They are pretty standard kinds of measurement for RF equipment generally and the standards will mainly dictate setup and measurement tolerances. Creating recipes for tests with the raw SCPI commands will greatly simplify your code and performance will be dictated by the hardware. Many times a test boils down to a configuration that you can store in the device itself and just select a program number or name.

Hardly. It's like pitching your tent inside your house because you don't have a hammer for tent pegs. Sure, the tent is up. But now you have to move your entire house when you want to go camping! I get really annoyed with the Linux community who's only answer for any Windows issues is to install Linux (or Cygwin)..

I have a partition (F:\) that contains all my code (my whole disk, USB drives and SD card are Vera-crypted, so I'm even more paranoid than Rolph ). The top level of F:\ looks like this: F:\CB F:\CT F:\LV F:\MingW F:\PHP F:\ RUST F:\WEB F:\VS (CB=Codeblocks, CT:=Codetyphon, LV=LabVIEW, VS=Visual Studio) Under F:\LV I have the different LV versions: 2009 2010 2011 2012 2013 2014 2015 2016 2017 And each has the following structure Components Products Projects. Each project has an entry under "Projects" (duh! ) and all have the following structure API Bin Build Core Docs Examples Menus Test The project file and any dynamic libraries directly loaded sit at this level (F:\LV\<LabVIEW Version>\<Project Name>). The Bin directory will contain both 32 and 64 bit,libraries but the bitness that is worked with (usually 64 bit) will be here. From that point it gets more flexible and project specific. However. SVN plays an important role here since copies across versions are never copied from directory to directory. Instead they are checked out from SVN.

Does the R&S driver not do what you need?

I can also undo screws with a knife but I would prefer to use a screwdriver

PCI = 33MHz x 4 bytes = 132 MB/s

It's a good job that LabVIEW is a dataflow programming language then!

Make sure your hard disk is up to the speeds you require. You can use these VIs to benchmark your disk.

Confirmed. Thanks.

Yup. No ideal solutions for a fast, searchable time series database. The best I have used so far is SQLite. It can have 32k columns so does for most things I have to deal with. Inserting 32k into a row at a time isn't all that quick, though. 10k points is usually an acceptable trade-off for dumping graphs.

Locally, SQLite. Remotely, MySQL/MariaDB.

The problem is back again. Sorry, there is a problem Something went wrong. Please try again. Error code: EX145

Yes. that works. I've checked through the SVN log and nothing has changed in the code from the last time it was run (over a year ago) so I'm not sure why this happened unless the default project refnum no longer returns the root. Thanks for looking into it

I have a test harness that I haven't run for a while that uses the CCSymbols tag to lookup the conditional symbols of a project. It seems this no longer works and returns an empty variant. There is also a GetSymbols.vi located in "<LabVIEW Version>\resource\plugins\Utility\IfDef.llb" which also no longer functions and returns an empty array. I've executed GetSymbols.vi on LabVIEW versions 2009 through to 2017 and none of them work. (I'm pretty sure it uses the same property node). Investigating further, I have retrieved a list of tags and the only tags that seem to be available are these. I'm sure there were more than this and CCSymbols was among them. Can anyone confirm or deny this? Does anyone have an alternative way of getting the symbols?