DAQFactory Virtual Channel Shows No Data: Fix the V. Prefix

Virtual1 and Virtual2 stay blank because the sequence never writes to them. In DAQFactory, V channels live on the V connection, so script must address them as V.Virtual1 and V.Virtual2. A bare Virtual1 = Eingang0 does not bind to the V channel. The V channel table stays empty, and a logging set pointed at those channels has nothing to write. The setup here is a LabJack digital output switching an analog multiplexer ahead of AI0 (Eingang0), with one sequence splitting the two mux states into two channels.

What does an empty V channel table actually mean?

An empty table means no value ever landed in that channel's history. This is a binding fault: the script's name does not resolve to the object you created. It is not a data fault, where the channel receives values but they are wrong. Sort out which one you have before touching the acquisition side.

Check 1: Does every V channel reference carry the V. prefix?

Search the sequence for every assignment to a V channel.

• Prefix missing: this is the root cause here. Change Virtual1 = ... to V.Virtual1 = ..., and do the same for Virtual2. Clearing history needs the prefix too: V.Virtual1.ClearHistory(). Go to Check 2.
• Prefix present, table still empty: confirm the sequence is running and passes the assignment line. Open the Command/Alert window and watch for a runtime error stopping the loop before it reaches the write.

Check 2: Is the source channel subset to one value?

In DAQFactory expressions, a channel name with no subscript refers to the channel's whole history array. Only Eingang0[0] is the most recent reading. With a plain = assignment to a V channel, the engine usually keeps just the latest value. Don't rely on that. Write exactly what you mean:

V.Virtual1 = Eingang0[0]

The same rule applies to AddValue() in the Test channel approach below. Passing the unsubscripted array pushes more than one point into the target.

Check 3: Is Eingang0 read only when the mux is in a known state?

Two things let one mux state's reading end up in the other state's channel.

1. Look at the Timing column for Eingang0. If it is non-zero, DAQFactory polls AI0 on its own schedule, whatever the state of DigitalOut. Eingang0[0] may then be a polled sample taken mid-switch or in the wrong state. Set Timing to 0 so the only samples come from the sequence's read(Eingang0) calls.
2. Look at the gap between the output write and the read. The original loop calls read(Eingang0) right after changing DigitalOut. The mux output and the ADC input need time to settle after the switch. Add a delay taken from the multiplexer datasheet's switching and settling specification. Do not rely on the command latency alone.

delay() in DAQFactory sequences takes seconds. The existing delay(10)Plan your logging and display refresh around that rate.

Check 4: V channel or Test channel, which should hold the mux data?

Both work once the prefix is fixed. Use Test channels for this job. V channels are an older mechanism, and they cannot be logged directly. Getting their data to disk means building an export set. A Test channel is a regular channel that happens to have no hardware behind it. It supports every normal channel feature.

If real-time saving is not needed, an export set on V channels will work. Test channels still leave you a logging path, persist-to-disk history, and averaging with no extra objects.

How do you rebuild the mux logging on Test channels?

1. Create two channels, for example Mux0 and Mux1. Set Device Type to Test, I/O Type to A/D, and Timing to 0. With Timing at 0, the Test device generates no data of its own. Only AddValue() fills the channels.
2. Set Timing on Eingang0 to 0, as in Check 3.
3. Replace the sequence with the version below. Assign settle the mux settling time in seconds from the datasheet before you run it.
4. Add Mux0 and Mux1 to a logging set, or to an export set if you only need on-demand files.
5. Delete the old V channels, or leave them unused, so nothing references Virtual1 or Virtual2 any more.

private settle   // assign mux settling time in seconds before running
while (1)
   DigitalOut = 0
   delay(settle)
   read(Eingang0)
   Mux0.AddValue(Eingang0[0])
   delay(10)
   DigitalOut = 1
   delay(settle)
   read(Eingang0)
   Mux1.AddValue(Eingang0[0])
   delay(10)
endwhile

To reset between runs, call Mux0.ClearHistory() and Mux1.ClearHistory() from a button or at the top of the sequence.

Verify it in this order:

1. Start the sequence and watch the Command/Alert window for one full cycle. There should be no errors.
2. Apply a known, different signal to each mux input. Mux0 should track only the input selected when DigitalOut is 0, and Mux1 only the input selected when it is 1. If both channels move together, recheck the Timing setting on Eingang0 and the settle delay.
3. Start the logging set, let it run for several cycles, then open the log file. Confirm both columns are populated with matching time stamps.

FAQ