ShaunR

I'm exactly the same. You end up trying so many different things to get it to work you don't really know what parts were crucial. Rabbit hole after rabbit hole. Mine isn't Ubuntu but Centos which is supported but even that wasn't trivial. When they say "supported" they mean you can phone up to get support and not get stone-walled I had to install LV2012 on Centos 7.2 (64bit with Gnome) this time around. Previously I stuck religiously to OpenSuse 32bit with KDE because that just worked out of the box. The main things I remember this time round are that I had to [first find then] install the relevant 32 bit libraries piece-by-piece (2012 is only 32 bit on Linux) as the installer complained about them. Then I had to symlink them because it still couldn't find them. Then MESA (whatever that is) and finally the kernel source to get VISA. This was over the period of about 2 days trying different things and I'm sure some of the stuff I tried, but can't remember, contributed to the final success.

But we have internet nowadays so you can do stuff like this-it's not rocket science. As for LabVIEW. Since I use polymorphic VIs for APIs and always make the menu visible, I use the instance menu and add (deprecated) after the instance (and menu) name. From that release it will be available for a minimum of 2 years to allow migration but generally it will not be removed at all from the library, only removed from the polymorphic list after that.

I think I actually heard an audible sigh at the end of that. Nice. And learning the meaning of "deprecate" wouldn't hurt either.

OK. So how does it differentiate between an NI or non-NI client?

It's a call to setsocketoptions like the NAGLE. There are some VIs in Transport.lvlib.

What's wrong with flooding the buffer? (they are allocated for each connection) TCPIP connections block when the buffer is full (that's why there is a timeout on the write). If you set the buffer to, say, 10 x message size then it will fill up with 10 messages and wait until at least one has been received (nak'd) and then write another.

It says on the diagram password is "12345" although I'm so familiar with the syntax I didn't really give much thought that it wasn't obvious for those that haven't seen the "Speed Example". If you want to see it in other packages then just make a backup (there's a button for it in the toolbar). The backup will be unencrypted. It still has to go through formal testing for inclusion so thanks for the debug (re: path wire). Not sure why you got "not-a-path" since it is supposed to return the filename appended to either the project directory or the directory from which the top level VI exists in. I expect that will disappear when it is included in the main package but I will error guess to see if I can smell the reason and make it more robust. With regards to types. SQLite is [almost] typeless - It is one of the reasons I love SQLite . It uses what are called affinities which, for the most part, affect how data is stored rather than imposing type constraints. I use this to remove the strict typing in LabVIEW (you'll notice everything is a string). If you move to another DB then you will of course have to consider the types and your code will become more complex as you convert backwards and forwards for the specific types. You will also notice that each parameter has a "type" field, which is nothing more than a text label so that when required in LabVIEW, the strict typing can be reintroduced for the things that matter, if desired. (the VI I used to "guess" your types from the INI files needs some more work ). That isn't required for this configuration example (everything's a string...lol), But it is based on a real configuration editor I have written many times over for different people. You have a number of choices from this point on for "Steps". You could make another table just like the "parameters/Limits" or you could just use labels (groups). The problem with the former is that it is not very generic and you usually run into problems further down the line with instruments "in use" when they are used for multiple test steps in parallel. The labels approach enables you to just use a filter on the parameters (works for both limits and configuration) but I can see good arguments for either. You will note that the schema is hinged on Instrument configuration and steps don't really factor into that very much - just like the tests. So the schema isn't hierarchical from Test>Steps>Parameters as you show in you second ER diagram. Calculations are anyone's' guess. I don't know what they are for or what they do. Off the top of my head, I would probably consider them just another parameter with a "calc" label or group.

No requirements specification; no solution. If you don't have one, then write one. It will force you to consider the details of the system, the components and how they will interact. If you are in the position to dictate component/device choices then choose a multi-drop interface and ensure all devices/components use that interface (TCPIP/RS485/Profibus whatever-find the common denominator). Then try and normalise the protocols (SCPI for example). A judicious choice of device interface options means the difference between juggling RS232, TCPIP, GPIB, RS485 et. al when they all may have TCPIP options when purchased. It will decrease the code complexity by orders of magnitude when you come to write it. Once you have all that defined and documented, then you can start thinking about software.

Oops. A bit embarrassing. Seems LabVIEW linking insists that VIs are in the VI.lib instead of user.lib when opening the project. and causes linking hell! Attached is a new version that fixes that. However. If it asks for "picktime.vi", it is a part of the LV distribution and located in "<labview version>\resource\dialog" which isn't on the LabVIEW search path by default, it seems. I'll delete the other file in the previous post to avoid confusion. Test Manager0101.zip

Sequence the wait and time functions using a sequence to ensure they are executed the in the same order, each time, on each iteration. A better approach is to use the "Timed Loop" instead of the wait.

Sorry it's a bit later than expected - I was called out of country for a week or so. Here it is, though. You'll need the SQlite API for LabVIEW but once you have that you should be good to go. There's still a couple of bits and pieces before it's production ready and I'm still "umming" and "ahing" about some things, but most of it's there.

You will design your own schema-it's an example. Email support@lvs-tools.co.uk and we'll get your error looked at. At a glance, it looks like it can't extract the files to the vi.lib directory.

You can download the API here. (You will need to wait for the example) It's not that important to have real files - it's just useful context for you. But to demonstrate the power of using a DB means that you can have multiple configurations of devices and tests so what I have so far is this: This is just showing some device info which is the beginnings oft of asset management. This is showing you a filtered list (CVT Tags showing) of the configuration parameters (your old ini files) for Test1 that you can edit. ....and the Test1 limit list You can go on to add UUTs which is just a variation on the devices from a programmers point if view but I don't think I'll go that far, for now. The hard part is getting the LabVIEW UI to function properly...lol.

Well They are all config files so I'll have to make up some tests and test limits. I think I might add it to the examples in the API-without your data of course. I'll have a play tomorrow.

Depends how much of a match the example will be to your real system. I could just copy and paste the same INI file and pretend that they are different devices But it wouldn't be much of am example as opposed to, say, a DVM and a spectrum analyser and a Power Supply - you'd be letting me off lightly .

You have more? One isn't really enough to demonstrate how multiple devices/configs can work. What I mean by "Import" is the SQLite API that use has an Import from INI file function.

From the SQLite API for LabVIEW readme: Why would you need to reload DB tables? (and from where?) .

Do you have any INI files you can post? We can do an import to a DB and I'll knock up a quick example to get you started..You can then figure out a better schema to match your use case once you are more familiar with DBs.

You really need to migrate to a database so that you can maintain different configurations and calibration data by just viewing the database information in certain ways (usually a single SQL query). The benefits far outweigh not being able to use a text editor and you can easily manage multiple configurations and calibrations on-the-fly.

Ah. the ol' "digital" problem. Try something like this (maybe hunt for an isolated version) and use your super duper cRIO FPGA to do 100kHz . Of course. I'm ignoring your accuracy requirements etc but you should get the idea.

Someone is working on cold fusion If you insist on long distance, then you should be looking at 4-20mA current loops and I highly recommend not doing CJC yourself - it's a black art. However. I personally convert close into digital then transmit via ethernet, rs485, profibus, smoke signals, whatever) since you can string many off of one link. Your FPGA should be plenty for the high speed bit.

No-one has stated categorically, so... The first image is a raw, unadulterated image of the part under inspection with a rake overlaid. Whilst you can take measurements that way, it is very lighting and part specular dependant. To make more repeatable measurements you post process (threshold in this case) to remove noise and make features more defined. The result is a binary image. You then apply the rake to the post-processed image (second of your images). None of this is camera dependant so changing camera properties does not yield the second image unless it is a smart camera with post-processing (threshold) on board. So how would you create the first image? Two ways: 1. Acquire an image and use the Horizontal Clamp to to make your measurement (it will add the rake overlay). 2. Acquire an image. Make a copy (using the IMAQ Copy Image primitive) then apply a threshold to the copy (there are a couple, one of which I gave earlier) . Next, use the Horizontal Clamp on the copy then copy the Overlay (IMAQ Copy Overlay) onto the original image. This will give you the measurement repeatability of the second image with an output of the first. Note that operations on IMAQ images are destructive so if you want to keep an image after processing you must make a copy of it before the processing.

I cannot replicate your problem. (Untitled 1 Folder.zip)

Looks like the second one has a clustering threshold (AutoBTThreshold)

If you use a "Wait" (or Wait until next millisecond) with a value of zero, it will yield when other tasks want the processor but run full-pelt if not.