Manufacturing a satellite or a simple pen require to test the quality of the product before delivery to the customer.
LabVIEW is widely used for that purpose. Since 20 years of LabVIEW development I saw numerous test framework. I was wondering if people where interested to work in a collective and open source test framework.
Per example the following feature can be included:
HAL (hardware abstraction layer)
Database to record test results with the data viewer (PostgreSQL)
Image analysis (open CV) + bar code reader
User access level
Jig identification to prevent user error (testing the wrong product with the wrong jig/test sequence)
and so on....
By Audi Dec
Senior Engineer Cupertino, CA 95014 1 year and extendable Domain: Consumer Electronics Must have : Python, C/C++ (preferably Python), LabView • Work closely with the design team to analyze the requirements and help with defining the test criteria • Work with the team to develop the automated functional and regression tests using apple’s testing framework. • Actively participate in code reviews conducted by the developers • Evaluate existing testing methodologies and suggest new techniques that will help us deliver high-quality features faster. • Improve, maintain, and execute automated functional, regression, testing codebase • Maintain a solid understanding of Test workflows, automation best practices, and agile methodologies • Maintain proficiency in application and use of systems, tools, and processes within the Technology department. • Take a lead role in QA Roadmap initiatives Basic Qualifications: • BS/MS in Computer Science, Computer Engineering, electrical engineering or similar technical field • 3+ years of experience as a Software Development, Test Automation. • Experience in embedded hardware, software test automation. • Demonstrated experience in test framework design and development • Excellent communication, collaboration, reporting, analytical and problem-solving skills • Proficient with Agile testing methodologies and best practices Mandatory Skills: • Strong programming skills with Python, C/C++ (preferably Python), LabView Expert • Excellent fundamental knowledge of data structures, algorithms, and object-oriented design • Experience with embedded system hardware/software test automation. • Experience with Functional, factory line, diagnostic, reliability testing • Experience defining test plans and designing/developing the automation. • Experience with Linux, real time operating systems (bonus) • Passion for testing and quality engineering • Experience with bash scripting Reach me at firstname.lastname@example.org for more information
By Gary Armstrong
I have inherited a LabVIEW Interface that talks thru a USB2 Interface to a micro-Controller at 921,600 baud.
This opens a new world of possibilities as USB2 can handle data at much higher rates than a typical RS232 interface.
I have been tasked with rewriting the LabVIEW code as it is difficult to maintain. I have an application that will talk to the uC at 230 kbaud but can't attain the 921,600 baud. I have tried copying the pertinent VIs from the supplied code into my app but still can not attain 921,600 baud. Plus I don't have a serial line analyzer capable of handling USB2, so I can only trial and error with the uC. Is there a setting I have to do in LabVIEW to allow serial communications at the higher rates? At the moment, I am trying to get the Find Controllr VI to work. I have included the support VIs for the Find Controllr.vi. The Find Controllr VI attempts to find the correct port and baud rate and then obviously communicate with the uC.
Get Available Ports.vi
Check For Packet.vi
Extract Packet ID.vi
I have a small problem with SPI communication. I'm using NI USB 8452 module and LabView 2013 with driver NI USB 845x 14.0. As a first step I ran the example from attached library called "Atmel AT25080A Write.vi". The problem manifests as logic "0" all the time on MOSI and MISO lines. No Data transferred. CS and CLK works properly. I never use pull ups when using SPI but maybe I should? The question is did anybody meet the same problem while using this usb 8452 module? All 4 SPI lines connected directly to oscilloscope. Waiting for any reply. Thanks in advance.
I have several USB instruments (Agilent/Keysight optical power meters) which I can talk to via USB.
To minimise the time "wasted" by transferring data between the instruments and the PC I would like to query them in parallel. Unfortunately, LabVIEW doesn't agree with that strategy and reliably crashes when doing so. It doesn't matter which command I send, so here's a sample snippet, where I just query the instrument ID repeatedly. I don't even have to read the answer back (doing so won't make a difference):
This will kill LabVIEW 2012 and 2014, both 64bit without even popping up the "We apologize for the inconvenience" crash reporter dialog.
Has anyone had similar experiences?
I've seen LabVIEW crash while communicating over RS232 (VISA) but it's much harder to reproduce.
Is it outrageous to assume that communication to separate instruments via different VISA references should work in parallel?
All my instrument drivers are separate objects. I can ensure that communication to a single type of instrument is done in series by making the vi that does the communication non-reentrant. But I have to communicate with multiple instruments of different types, most of which use some flavour of VISA (RS232, USB, GPIB).
Am I just lucky that I haven't had more crashes when I'm talking to a lot of instruments?
Could it be a bug specific to the USB part of VISA? I've only recently changed from GPIB to USB on those power meters to get faster data transfer rates. In the past everything went via GPIB, which isn't a parallel communication protocol anyway afaik.