Output
This reference collection includes Vector documentation reproduced with permission. Snippets may require configuration-specific symbols and are not all standalone programs. Sources and validation limits.
Syntax and result
void output(message msg);
void output(errorFrame);
The message form outputs a message object from the CAPL program block. Its return type is void: there is no success code to assign to a variable or compare with zero. The error-frame form is a separate operation; it is not a way to report an application error. Channel-qualified error-frame output and hardware support must be checked in the installed help before fault-injection work.
Make the transmission request unambiguous
This illustrative source is for a simulation node in a controlled classical CAN configuration, with CAN1 mapped to the intended bus. It has not been compiled or run here.
variables
{
message CAN1.0x200 request;
}
on key 's'
{
request.RTR = 0;
request.DLC = 2;
request.byte(0) = 0xAA;
request.byte(1) = 0x01;
output(request);
write("Submitted CAN1 0x200; verify Trace and receiver separately");
}
The explicit channel avoids an accidental default-channel test. The hexadecimal prefix matters: 0x200 and decimal 200 are different identifiers. The example defines a standard identifier; an extended identifier with the same numeric value is a different frame format. Both bytes inside the declared length are assigned on every trigger, so a previous use of the message object cannot silently supply a stale command byte. These two example bytes have no application meaning until a receiver contract defines one.
What each observation establishes
| Observation | Supported conclusion | Additional evidence needed |
|---|---|---|
| The Write line appears after output | The program reached the call and continued | Inspect channel, direction and ID in Trace |
| A matching transmission is recorded | That observation point recorded a matching transmission | Confirm a receiving observation point and the expected payload |
| A receiver observes the data frame | The frame reached that observer | Verify application decoding, validity conditions and state change |
| An expected status changes after the request | Evidence consistent with the requested behavior | Rule out stale status or another trigger; correlate the response with this request |
A repeated background status can arrive immediately after output even when the receiver ignored the new command. If the protocol defines a transaction counter, correlate it; otherwise design a controlled initial state and an observable transition with a bounded deadline. Do not label the Write line “command succeeded.” The test-module tutorial separates arrival checks from stronger application claims.
Avoid turning an observer into a transmitter
Node placement changes what output means in the data path. A CAPL node in a measurement evaluation branch may need explicit forwarding to preserve downstream traffic. A simulation node that calls output(this) for every incoming message can resend traffic and create a loop. Adding that line to “make Trace work” can therefore change the system being observed.
Before adding forwarding, draw the source channel, destination channel and observation point, and decide which direction and IDs are allowed through. Validate one frame at a time with other automatic senders disabled. The on message reference explains the placement distinction; the stream-filtering guide provides a check matrix for mixed traffic.
Source and validation
Signatures and node-placement behavior were checked against the authorized Vector output and on message references; message declaration details follow the authorized CAPL introduction. The evidence ladder, counterexamples and inspection procedure are this site's analysis. No CANoe execution or hardware result is claimed. See sources and validation limits.