I am just starting on trying to be able to use Python code from a LabVIEW application (mostly for some image analysis stuff). This is for a large project where some programmers are more comfortable developing in Python than LabVIEW. I have not done any Python before, and their seem to be a bewildering array of options; many IDE's, Libraries, and Python-LabVIEW connectors.
So I was wondering if people who have been using Python with LabVIEW can give their experiences and describe what set of technologies they use.
By Yaw Mensah
I have installed Labview 2020 on Dedian Buster using the rpm to deb conversion method via alien. Due to Architecture mismatch i deleted the *i386.rpm files before conversion.
My Problem is that after creating a project at "Build Specification"-> "rigth click" i am only able to select "Source Distribution". Application does not show up as an option.
I will be grateful for any suggestions.
Thank you in advance.
VIPM.io now allows you to post LabVIEW Resources, Ideas, and Tools. For example, you could post a link to a video tutorial or blog article about a package. You can also post ideas, like feature requests or new tools. Best of all, package developers are notified when you post your ideas and resources, and you can comment and discuss posts with the community. Take a look at this video to learn more: https://www.vipm.io/posts/664960df-f111-4e13-989a-24be8207182d/
By Shuvankar Das
I want to connect My ccd camera with labview. The details of my system is given bellow. I cannot connect it please help OS: WINDOWS 7, 64bit LabView Run-Time 2013(64-bit) NI-IMAQ 4.8 NI-IMAQdx 4.3 Camera: QICAM Monochrome Cooled (QIC-F-M-12-C) Model QICAM Resolution 1392 x 1040 Sensor 1/2" Sony ICX205 progressive-scan interline CCD Pixel Size 4.65 x 4.65µm Cooling Type Peltier thermoelectric cooling to 25˚C below ambient Digital Output 12 bit Video Output FireWire (IEEE 1394b) Max. Frame Rate 10 fps full resolution @ 12 bits Pixel Scan 20, 10, 5, 2.5MHz Mount Type C-mount optical format
Re-establishing TestStand Database Connections: Does anyone know exactly how TestStand maintains its database connnection?By Bryan
TestStand Version(s) Used: 2010 thru 2016
Windows (7 & 10)
Database: MS SQL Server (v?)
Note: The database connection I'm referring to is what's configured in "Configure > Result Processing", (or equivalent location in older versions).
Based on some issues we've been having with nearly all of our TestStand-based production testers, I'm assuming that TestStand opens the configured database connection when the sequence is run, and maintains that same connection for all subsequent UUTs tested until the sequence is stopped/terminated/aborted. However, I'm not sure of this and would like someone to either confirm or correct this assumption.
The problem we're having is that: Nearly all of our TestStand-based production testers have intermittently been losing their database connections - returning an error (usually after the PASS/FAIL banner). I'm not sure if it's a TestStand issue or an issue with the database itself. The operator - Seeing and only caring about whether it passed or failed, often ignores the error message and soldiers on, mostly ignoring every error message that pops up. Testers at the next higher assembly that look for a passed record of the sub assemblies' serial number in the database will now fail their test because they can't find a passed record of the serial number.
We've tried communicating with the operators to either let us know when the error occurs, re-test the UUT, or restart TestStand (usually the option that works), but it's often forgotten or ignored.
The operators do not stop the test sequence when they go home for the evening/weekend/etc. so, TestStand is normally left waiting for them to enter the next serial number of the device to test. I'm assuming that their connection to the database is still opened during this time. If so, it's almost as though MS SQL has been configured to terminate idle connections to it, or if something happens with the SQL Server - the connection hasn't been properly closed or re-established, etc.
Our LabVIEW based testers don't appear to have this problem unless there really is an issue with the database server. The majority of these testers I believe open > write > close their database connections at the completion of a unit test.
I'm currently looking into writing my own routine to be called in the "Log to Database" callback which will open > write > close the database connection. But, I wanted to check if anyone more knowledgeable had any insight before I spend time doing something that may have an easy fix.