PIEZO-5: 1024 = NV200D arbitrary-waveform-generator max buffer size (default n=256 at 2-BM); current operational mode is `--random`; FPGA-output-to-axis cable mapping still needs operator confirmation

[decarlof]

PIEZO-5: Two parts to the question, two-part answer.

Part 1: The 1024-position triggered-step mode (mechanism + purpose)

Mechanism: The NV200D's onboard arbitrary-waveform generator can hold up to 1024 setpoints in a buffer (gparb,i,pos Telnet commands load them at indices 0..N-1). The trigger function trgfkt,2 (= TriggerInFunction.WAVEFORM_STEP in the official nv200 Python library) makes each rising edge on the TRG
IN connector (pin 3 of the I/O D-Sub, TTL 0/3.3-5 V) advance the waveform index by exactly one step.

So the 1024 is the device's hardware buffer maximum, not a fixed list length used at 2-BM. The operational script defaults to n = 256 positions per axis (chosen for tomography acquisition cadence); the --n flag can be increased up to 1024 for finer sampling, or decreased.

Purpose at 2-BM: Compressive-sensing dithered tomographic sampling. The operational script supports two list-generation modes:

• --linspace (default in the library): N evenly-spaced positions spanning the full 0…100 µm closed-loop stroke. Equivalent to a deterministic raster of the coded-aperture position.
• --random: N positions uniformly sampled from the stroke. Produces a random walk of the coded-aperture position during the scan, which feeds compressive-sensing image reconstruction algorithms (better dose efficiency, sub-pixel resolution, etc.).

Current operational state (inspected 2026-06-19): the positions_x.txt / positions_y.txt files saved alongside the script contain 256 random-looking values per axis (e.g., X starts 82.24, 85.89, 66.46, 36.63 …) — confirming --random is what 2-BM is running today for compressive-sensing imaging.

Part 2: FPGA output → piezo-axis cable mapping (still needs operator confirmation)

This part remains open. CORA's question observed an apparent contradiction in item_028:

• The cable map says FPGA out2 → JenaX cable, FPGA out3 → JenaY cable.
• The softGlue GateDelay PV labels are inverted: GateDly-3_DLY is labelled "X axis delay" and GateDly-2_DLY is labelled "Y axis delay".

So out2 and out3 are wired to (X, Y) per the cables, but the PV labels suggest (Y, X). One of these is wrong; only an operator with access to the physical wiring can settle which.

The triggered-step scripts themselves don't address this: they connect to each NV200D over Ethernet (via IPs, not FPGA channel), so the cable-to-axis question is entirely upstream of the scripts. Knowing which FPGA output is wired to which axis matters when configuring the softGlue trigger generation in a tomosc
an recipe — if the labels are swapped, the wrong axis advances on each frame.

What the operator needs to verify:

• Physically trace the cables from the softGlueZynq box (2bmbMZ1) FPGA outputs out2 and out3 to the NV200D TRG IN connectors at the controllers (IPs 10.54.113.126 and 10.54.113.125).
• For each FPGA output, note which NV200D IP (and therefore which axis) it terminates at.
• One of these will agree with the cable-map note in item_028, and one will agree with the GateDly PV labels. Fix the documentation that is wrong.

Once that's resolved, this row can be closed.

CORA-side application

For the triggered-step scope (Part 1):

• The CodedApertureFineDrive_X and CodedApertureFineDrive_Y MotionController Assets (per PIEZO-4) should carry an operational note that per-frame fine-positioning is via external trigger, not direct PV setpoints during a Run. The Run's per-frame coded-aperture position
  comes from the pre-loaded waveform buffer + the FPGA-triggered advance, not from a CORA-side setpoint.
• The position list (the actual sequence of (X, Y) coded-aperture positions used by a given Run) is per-Run provenance worth recording — the positions_x.txt / positions_y.txt snapshots are the artefact, and CORA may want to pin them as part of the Run's logbook so the reconstruction algorithm later knows which r
  andom sequence was used.

For the FPGA-mapping scope (Part 2):

• The CORA-side softGlueZynq Asset (the Timing Pending entry in 2-BM assets.md) will eventually carry per-output bindings. The bindings need to match the resolved cable-map answer once the operator clarifies (otherwise CORA will encode the same axis
  -swap ambiguity).

Downstream alignment

The coded-aperture sub-block in item_020.rst (latest commit pending) carries the new operational detail and now points at the formal procedure page [item_013](https://docs2bm.readthedocs.io/en/latest/source/proce
dures/item_013.html) (slug nv200_trigger_step); the implementation is in the 2bm-procedures repo (nv200-library / asyncio variant). A raw-Telnet reference variant is preserved at /home/beams/2BMB/conda/sandbox/nv200/nv200 _trigger_step.py. Both default to n=256, max 1024, support --linspace / --random (current operational --random), and share the one-Telnet-connection constraint and EEPROM-persistence option.

The FPGA-mapping question (Part 2) is intentionally NOT settled in the docs — item_028 still carries both pieces of evidence (the cable map AND the GateDly PV labels), and the resolution waits on the operator's physical-cable check.

Cross-references

• PIEZO-1 / cora#241 — physical role: NV200D drives the coded aperture upstream of the sample.
• PIEZO-2 / cora#242 — actuator model and 100-µm closed-loop stroke.
• PIEZO-3 / cora#243 — vendor + controller part numbers.
• [PIEZO-4 / cora#TBD] — IPs (X = 10.54.113.126, Y = 10.54.113.125) and two-controllers-not-one architecture.

Net

PIEZO-5 answer: 1024 = NV200D arbitrary-waveform max buffer; 256 = the operational default at 2-BM; --random is the current operational mode (compressive-sensing dithered sampling for tomography). The FPGA-output-to-axis cable mapping remains an open operator-confirmation item because the cable map in ite m_028 and the GateDly PV labels point at opposite pairings; physical-cable tracing settles it.