Jump to content

ShaunR

Members
 View Profile  See their activity

  • Posts

    4,882

  • Joined

  • Days Won

    296

 Content Type 

Everything posted by ShaunR

  1. ShaunR
    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.
  2. ShaunR
    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
  3. ShaunR
    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.
  4. ShaunR
    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.
  5. ShaunR
    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.
  6. ShaunR
    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.
  7. ShaunR
    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.
  8. ShaunR
    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 .
  9. ShaunR
    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.
  10. ShaunR
    From the SQLite API for LabVIEW readme: Why would you need to reload DB tables? (and from where?) .
  11. ShaunR
    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.
  12. ShaunR
    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.
  13. ShaunR
    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.
  14. ShaunR
    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.
  15. ShaunR
    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.
  16. ShaunR
    I cannot replicate your problem. (Untitled 1 Folder.zip)
  17. ShaunR
    Looks like the second one has a clustering threshold (AutoBTThreshold)
  18. ShaunR
    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.
  19. ShaunR
    No. It will wait until you have closed the dialogue. If you want it to run independently you will need to dynamically load it.
  20. ShaunR
    I wouldn't use Python for this just like I wouldn't use PHP - right tool for the right job and with NI support, which is second to none.
  21. ShaunR
    HMI_PopUp_KB has one (HMI Pop Up Num KP.vi). You just need to place it in the Mouse Up event.
  22. ShaunR
    Plotly is a rest API (V1, V2). You don't need (nor should want) Python. Just use the HTTP VIs in LabVIEW.
  23. ShaunR
    The DVR is a container that enables you to access data via a refnum (so you can pass around the reference rather than make copies of the data). It is not a pointer but has some analogies. You will notice that there is a "data value" output of the delete primitive which returns the contained data when the container is destroyed and, if you inspect this data, you will find the incremented value. .
  24. ShaunR
    Well. The Celeron is probably a quad core and the Atom you describe is a dual core but you might also look at the Ethernet port since most budget boards use 10/100 rather than Gb ethernet.
  25. ShaunR
    As do browsers. But perhaps it helps to think of it another way. Once you have completely separated the UI from the working code with a cross platform, standardised communications scheme (like websockets, WebRTP, TCPIP or UDP) you are not just limited to browsers or even LabVIEW - you can create interfaces in any language rather than patching LabVIEW. However. If you intend to support cross platform for the UI then doing as you suggest means you will end up with [a minimum of] 3 different and distinct code bases along with all their test harnesses and build tools (probably in different languages). You are also a bit stuck if you want to see the pseudo interfaces of embedded applications that LabVIEW provides natively. It is a maintenance nightmare that browsers solve quite nicely and, if you are as incompetant with an ebrush as I am or almost at the deadline, you can outsource the UI to web developers while you do the interesting stuff. There's always a few web-devs hanging around IT departments and they can argue about layouts, corporate colour schemes and logos. Maybe we should move all this to another thread if we are not finished?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept