A LabVIEW install with no DAQ hardware, no instruments, and no assigned project is enough to build a portfolio, but not by hunting for finished VIs. Build a small set of projects that show acquisition, state-machine control, data logging, and a usable front panel, and swap simulated I/O in for hardware you do not own.
Stop hunting for finished projects to copy
These are the usual moves when there is nothing to work from. Each one leaves you with nothing to defend in an interview.
- Download someone's finished VI and re-save it. You get a working block diagram you did not design. A reviewer who asks why a state exists or why a queue sits between two loops gets no answer from you. Asking for the file of a Pac-Man build gets the same reply it deserves: build your own; it is doable.
- Wait until you own a DAQ device. This blocks you for no reason. Simulated devices run the same acquisition code, and pure-software projects need no I/O at all.
- Watch tutorials without producing an artifact. Nothing exists to put on a resume or in a repository.
- Drop controls and indicators on a panel and wire one big loop. It runs, but it shows no architecture. Reviewers read the block diagram before they read the front panel.
Temporary restore for tonight: a random-number generator VI standing in for a sensor. Permanent repair: an acquisition layer you can swap between simulated and real I/O without touching the rest of the code.
Build to show architecture, not screens
A project earns its place on a resume when it demonstrates design decisions you can explain: an explicit state machine, separation of acquire/process/log, error handling, and clean data types (clusters instead of loose wires). Choose projects by the skill they exercise.
| Project | Skill it exercises | Hardware needed |
|---|---|---|
| Simulated DAQ to timestamped file to SQL | Acquisition, clusters, file I/O, database writes, a common industry workflow | None (simulated device or random numbers) |
| Tic-tac-toe, snake, memory, Pac-Man | State machines, event-driven UI, logic in code | None |
| CLD-style exercise: ATM, coffee machine, automated car wash | Requirements-to-architecture, state machines, timed practice | None |
| Web-service widget UI (weather, atomic clock, RSS) | Web calls, parsing, .NET controls and APIs | None |
| Webcam computer vision (OpenCV or NI Vision module) | Image acquisition and processing | Low-cost webcam |
| Pi Pico or Arduino I/O exercises | Real hardware interfacing | Microcontroller board |
Simulate the DAQ device in MAX
MAX (Measurement & Automation Explorer) creates simulated devices, and the acquisition code you write against them is the same code you would run against a physical device.
- Install the NI-DAQmx driver alongside LabVIEW. Simulated DAQ devices depend on the driver being present.
- Open MAX, expand My System, right-click Devices and Interfaces, and choose Create New. Select the NI-DAQmx simulated device option and pick a device from the list.
- Note the device name MAX assigns. Use it in the DAQ Assistant or in the DAQmx VIs (create channel, timing, start, read, stop, clear).
- Run the VI. The simulated device returns simulated signal data, so the diagram, channel configuration, and downstream processing behave the same as they would with hardware.
Limits: a simulated device does not exercise wiring, sensor scaling against a real transducer, noise, or calibration. State on the resume that the I/O was simulated. If DAQmx will not install, or MAX does not offer the simulated-device option after install, use a random-number generator VI as the data source and keep moving; the logging and UI work is identical.
Log simulated data to a file and into SQL
This project maps to a common industry workflow: acquire data, timestamp it, store it, and put it in a database. It works with only SQL access and no DAQ device.
- Generate values from a simulated DAQ channel or a random-number function. Add math (scaling, averaging, a threshold check) so the data is not raw noise.
- Bundle each sample into a cluster: timestamp, channel name, value, and any status flag.
- Write the samples to a CSV or other file with the date and time on every row.
- Insert the same records into a database table using LabVIEW's database connectivity tools.
- Query the table back and plot it to prove the round trip.
Structure it as a producer/consumer pair so the acquisition rate is not tied to database latency:
Producer loop (sim DAQ read, timestamp) --queue--> Consumer loop (cluster -> CSV, cluster -> DB)
|
Error / stop state
Keep the producer behind a single subVI. That subVI is the swap point: simulated today, a real device later.
Drill state machines with pure-software projects
Games and exam-style problems force you to make state, transition, and event decisions without any instrument getting in the way.
| Source of practice | What you get | Note |
|---|---|---|
| Recreate a basic game (tic-tac-toe, snake, memory, Pac-Man) | State machines, event-driven UIs, game logic | Build your own; do not import someone else's VI |
| CLD-type project (ATM, coffee machine, automated car wash) | Requirement-driven architecture under a time limit | Practice exams are available online |
| Project Euler | Math-heavy algorithm problems | Good for data-flow and array handling |
| Old Advent of Code problems | Archives go back many years; early days are simple | Difficulty climbs sharply around day 12-14 |
Write each one with an explicit state enum, a case structure inside a loop, and a defined error and shutdown state. The same pattern carries directly into machine and test-sequence code.
Get real I/O cheaply, or use the network as your I/O
If you can get a bit of hardware or a network connection, add these to the mix.
- Arduino or Pi Pico. Community LabVIEW exercise repositories on GitHub (search for the LabVIEW CTI) include Pi Pico exercises. A microcontroller board gives you real digital and analog I/O without a DAQ chassis.
- Web-service widget UI. Pull data from weather services, atomic clocks, or RSS feeds and display it. Windows .NET controls and APIs can be pulled into the same VI.
- Webcam vision. A cheap webcam plus OpenCV or the NI Vision module gives you an image-acquisition and processing project.
Use university or lab bench gear and instrument drivers
If you have access to a university lab, power supplies and multimeters often have LabVIEW instrument drivers you can download from the instrument manufacturer. Place the driver in the folder LabVIEW searches for instrument drivers (the instr.lib location in the LabVIEW install), then drop the driver VIs into your code. This gives you a real device with a well-defined command set and a clean acquisition example.
You can also practice by reproducing other people's posted LabVIEW problems and working out the fix. Being first with the answer does not matter. The learning is in analyzing the problem and why the fix works.
Check each project before it goes on the resume
- Open the VI from a clean start. It must run without hunting for missing files, hard-coded paths, or a device that only exists on your machine.
- Confirm the state machine has a defined start, error, and stop state, and that stopping the program leaves no open file, DAQmx task, queue, or database connection.
- Query the database and compare row count and timestamps against the CSV.
- Confirm the acquisition source is swappable by changing only one subVI or one device name.
- Give every subVI an icon and connector pane, label loops and cases, and write a short README covering what the project does, how to run it, and what is simulated.
- Walk through each design choice out loud. If you cannot explain a queue, a shift register, or a case, rewrite it until you can.
FAQ
Can I build LabVIEW projects without any DAQ hardware?
Yes. Use a simulated device created in MAX, or a random-number generator VI, as the data source, then build timestamped logging, SQL storage, and a UI around it. Pure-software projects such as games and CLD-style exercises need no I/O at all.
Does a simulated device in MAX run the same code as a real DAQ?
Yes, the DAQmx acquisition code is the same; you address the simulated device by the name MAX gives it. It does not test real wiring, sensor scaling, noise, or calibration, so label the project as simulated.
Can I copy a Pac-Man VI and modify it for my portfolio?
Do not. Copying leaves you unable to explain the state machine or event handling. Build it yourself from an empty diagram; it is a doable project and teaches state machines and event-driven UI.
Can I use Project Euler or Advent of Code as LabVIEW practice?
Yes. Project Euler is math-heavy, and Advent of Code archives go back many years, with early days simple and difficulty rising around day 12-14. Use them to build logic and array skills, and lead the resume with I/O, state-machine, and logging projects.
When should I stop and contact NI support?
Stop when the NI-DAQmx driver fails to install, MAX does not offer a simulated device after a clean install, or license activation fails. Those are install and licensing faults, not code faults. Contact NI through its official support channels with your LabVIEW version, the installed driver list, and the exact error text.