Median.vi Subroutine Priority Requires an Unlocked Copy

In LabVIEW 8.6.1 you cannot change the execution priority of the shipped Median.vi. That copy lives inside a password-protected analysis .lvlib, so it stays locked. To keep a subroutine-priority caller running, call a Median you own. You can bring over the 7.1 copy under a unique name, rebuild the diagram in a new VI, or compute the median with native primitives. You do not need to keep LabVIEW 7.1 installed. Once your copy is saved in 8.6, you edit it in 8.6.

Why the 8.6 Median.vi refuses Save As and priority changes

From LabVIEW 8.x onward, the analysis VIs ship as members of password-protected project libraries (.lvlib). Two consequences follow:

• Save As is greyed out. Saving a member VI under a new name or path changes the library's membership list. The library is locked, so LabVIEW blocks the operation.
• VI Properties are read-only. Execution priority is saved in the VI, and the VI cannot be saved. The same lock stops you from opening the Call Library Function Node configuration inside it, which was possible in 7.1.

This matters because of how subroutine priority works. A VI set to subroutine priority runs start to finish in its caller's thread without yielding. For that reason it may call only other subroutine-priority VIs, primitives, and Call Library Function Nodes. If a subroutine VI calls a normal-priority subVI, its run arrow breaks. When 8.6 relinks your code to the library Median.vi, which is normal priority, every subroutine caller breaks.

The relink happens because the 7.1 project resolves Median.vi by name. On load, 8.6 finds its own library member first and substitutes it for your local copy.

Skip the quick fixes that fail on locked analysis VIs

Dropping the caller to normal priority is a valid temporary restore. Log it as temporary and do the permanent repair below.

Walk the checks: broken arrow, linkage, lock state

1. Check the caller's run arrow. If it is broken, open the Error List.
   • If the error points to a subroutine VI calling a non-subroutine subVI, go to check 2.
   • If it points elsewhere, this is a different migration problem. Stop here.
2. Check which Median is linked. Open View » VI Hierarchy, or right-click the Median subVI and check its path.
   • If the path is in vi.lib, 8.6 relinked to the library copy. Go to check 3.
   • If it is your local copy, open its VI Properties » Execution and confirm it is set to subroutine. If it is not, set it, save, and re-check the caller.
3. Check whether you still have the 7.1 local copy on disk.
   • If yes, use Branch A below.
   • If no, check 4.
4. Check whether the library Median's block diagram opens.
   • If the diagram is visible, even though the VI is locked, use Branch B: copy and paste the code.
   • If the diagram is not visible, or you want no DLL dependency, use Branch C: native primitives.

Build a subroutine-safe Median in LabVIEW 8.6

Branch A: migrate the 7.1 copy.

1. Rename the local copy to a name that cannot collide with vi.lib, for example a project prefix plus Median.
2. Open it in 8.6, set VI Properties » Execution » Priority to subroutine, and save. It is now an 8.6 VI you own.
3. On each caller, right-click the Median subVI » Replace » Select a VI, and pick the renamed copy.
4. Open its Call Library Function Node and review the thread setting. A node configured for the UI thread forces a thread switch, which defeats subroutine priority. Set it to run in any thread only if the library function is thread-safe.

Branch B: rebuild from the locked VI's diagram.

1. Create a new VI with the same connector pane as Median.vi.
2. In the library VI, select all on the block diagram, copy, and paste into the new VI. Wire the terminals.
3. The pasted Call Library Function Node now sits in an unlocked VI. Open its configuration and verify the library path and thread setting.
4. Set subroutine priority, save under a unique name, and relink the callers.

Branch C: compute the median with native primitives. Primitives are always legal inside a subroutine, and this branch has no DLL or library dependency.

n = Array Size(X)
S = Sort 1D Array(X)
q, r = Quotient & Remainder(n, 2)
if r == 1:  median = Index Array(S, q)
else:       median = (Index Array(S, q-1) + Index Array(S, q)) / 2
if n == 0:  return error / NaN per your caller's contract

Sort 1D Array allocates a sorted copy, so this is O(n log n) with one buffer allocation per call. That is acceptable for typical window sizes. If you call it in a tight loop, profile it before you commit.

Confirm the replacement matches the library median

1. Build a test VI that feeds the same arrays to your copy and to the library Median.vi. Use an odd length, an even length, one element, all-equal values, and negative values.
2. Compare the outputs for exact equality. For even lengths, confirm that both average the two middle elements.
3. Feed an empty array to both. Match the error-out behavior your callers depend on.
4. If your data can contain NaN, test that case too. Sort placement of NaN decides what a sort-based median returns.
5. Open VI Hierarchy on the top-level VI. No subroutine caller should link to the vi.lib Median.
6. Confirm every caller has an unbroken run arrow. Then time the loop against the 7.1 baseline.

Keep the copy from being relinked on the next upgrade

• Name collisions. If your copy is still named Median.vi, the next load or mass compile can relink to vi.lib again. A unique name prevents this.
• Old DLL entry points. A 7.1 copy calls the analysis DLL the way 7.1 did. After each LabVIEW upgrade, re-run the comparison test. Branch C avoids this dependency.
• Other locked analysis VIs. Any subroutine VI that calls another analysis function hits the same wall. Search the hierarchy for vi.lib analysis calls under subroutine callers.
• Debugging. Subroutine VIs cannot be probed or single-stepped. Debug at normal priority, then switch back to subroutine.

FAQ