To File — Control Systems/Sinks
Control_Systems/Sinks/To_File · 1 input / 0 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
To File
Control Systems / Sinks
Writes what it receives to a file on disk as the run proceeds: one CSV row per retained sample, a leading time column, then one column per scalar channel of the input. A [3,1] input writes three data columns; the file is written incrementally, so a run that is stopped early still leaves every sample it reached.
Ports
- Input – the signal to write, of any size [m,n]. Its m×n entries become that many data columns, in row-major order.
- No outputs – To File is a pure sink.
Columns
The first column is always time. A single-channel input names its one data column with the configured variable name exactly as typed; several channels take name_0, name_1, and so on – the same rule the Signal Recorder uses for the variables it creates.
Parameters
- File Name – where to write. This names something the block
creates, so it is not looked up in the variables space. A relative name
lands in the active project folder, so the default
untitled.csvis findable; an absolute path is used as given. An existing file is overwritten at the start of the run. - Variable Name – the name the data columns carry in the header row. It is what the Simulink counterpart calls the matrix name.
- Decimation – keep every Nth sample. 1 writes every sample.
- Sampling Time (s) – how often a sample is taken. Zero or less inherits the solver's rate; a positive value writes at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text – but only some of them have a filesystem to write into. The six software targets open the configured file and write the same CSV the in-app block writes, with identical column names, column order and decimation. The three HDL targets write the same rows into the simulation transcript instead: a file handle is not synthesizable, and the block is a logging aid there rather than part of the hardware. PLC Structured Text has no portable file I/O at all, so it emits comments naming the exact signal array entries to tap – the same answer the Scope gives there. The file name is inlined into the generated code at export time.
Simulink bridge
Import and export, mapped to simulink/Sinks/To File. "File Name" to
Filename, "Variable Name" to MatrixName, "Decimation"
to Decimation, "Sampling Time (s)" to SampleTime.
SaveFormat is always written as Timeseries: this block only
ever produces time and value series, so there is no other shape to offer.
The file CONTENTS differ – ICore writes CSV and Simulink's To File
writes MAT – and the name crosses verbatim, so a model taken across writes
MAT content under a name that may still end in .csv. Rename it on
the Simulink side, or set a .mat name here and accept that ICore
writes CSV into it.
Notes
- Stateful only in the file handle and the decimation counter; the block computes nothing.
- Two To File blocks pointing at the same name will fight over it, exactly as in Simulink. Give each its own.
- To keep the data inside ICore instead – where the FFT, transfer function estimation and spline tools can read it – use the Signal Recorder, which is the same block with the variables space in place of the disk.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Sinks/To_File |
| family | Control_Systems/Sinks |
| solver environment class | ICoreBlock_0_Control_Systems_1_Sinks_2_To_File |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sinks/To_File/ICoreBlock_0_Control_Systems_1_Sinks_2_To_File.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sinks/To_File/ICoreBlock_0_Control_Systems_1_Sinks_2_To_File.h |
| default size on canvas | 80 × 70 px |
| ports at insert | 1 in, 0 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | — |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
File Name | untitled.csv | — |
Variable Name | ans | — |
Decimation | 1 | — |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | simulink/Sinks/To File |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
CONFIG_FILE_NAME.c_str() | Filename | passes through |
CONFIG_VARIABLE_NAME.c_str() | MatrixName | passes through |
CONFIG_DECIMATION.c_str() | Decimation | passes through |
Caveat (shown to the user): the file name crosses verbatim, but ICore writes CSV where Simulink writes MAT; rename the file on the Simulink side if the extension matters
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0Ports lists 2 entries for 1 port (1 in, 0 out) — grouped, or one undocumented? a reader must sayB03 Simulink params rule(s) this tool cannot resolve
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
To File block -- writes the input to a CSV file on disk, one row per retained sample Row shape: <time>,<c0>,<c1>,... One column per scalar channel of the input, in row-major element order. Written incrementally as the run proceeds, so a run that stops early still leaves everything it got to on disk.
Code export: the six software targets write the same CSV; the three HDLs write the same rows into the simulation transcript (a file handle is not synthesizable); PLC ST names the tap points in comments, as the Scope does.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-In-0 |
|---|---|---|
| 0 | 0 | 0 |
| 0.4 | 0 | 0 |
| 0.8 | 0 | 0 |
| 1.2 | 1 | 1 |
| 1.6 | 1 | 1 |
| 2 | 1 | 1 |
| 2.4 | 1 | 1 |
| 2.8 | 1 | 1 |
| 3.2 | 1 | 1 |
| 3.6 | 1 | 1 |
| 4 | 1 | 1 |
| 4.4 | 1 | 1 |
| 4.8 | 1 | 1 |
| 5.2 | 1 | 1 |
Every 4th of 60 samples, from the step stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 1 |
ramp | Ramp: slope 1 from t = 0 | 0 … 5.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9996 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -2 … 3 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category sink · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Sinks__To_File.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).