Point each target at a subsystem, pick its language, and press Deploy All. Each target is generated at its own subsystem's rate, checked against the simulation at the level you chose, and written into its own folder: the fast loop to the microcontroller or the FPGA, the slow one to the PLC.
One model with two rates, deployed as three targets. The inner loop goes out twice, as a C core and a VHDL entity. The supervisor, at a quarter of that rate, goes out as Structured Text. Each target is verified at its own level before its folder is written. The fields, file names and status line are the panel's own. The model and the target names are an example.
Create targets on the Deploy To Hardware panel, or under Code Engine →
Export → Deploy Targets. Targets are saved beside the project in
exportTargets.ini, so they come back when you reopen it.
icore fire finds it.None,
Output Gates Only, Output Gates and Sink Blocks or
Strict - All Signals.Home, the whole model.inner = target(C) inner.setConfig(Name, inner_c) inner.setConfig(Source, Home/InnerLoop) inner.setConfig(Folder, code/inner_c) inner.setConfig(Verification, Strict - All Signals) sup = target(PLC - ST) sup.setConfig(Name, supervisor_plc) sup.setConfig(Source, Home/Supervisor) sup.setConfig(Folder, code/supervisor_plc) inner.fire() sup.fire()
inner_c exported Home/InnerLoop as C into <project>/code/inner_c: CMakeLists.txt InnerLoop_deployableCore.c InnerLoop_deployableCore.h InnerLoop_testbench.c
fire() exports now and lists the files it wrote. It never
opens a dialog. If verification fails, the export stops and prints the reason. From outside
the application, icore fire inner_c does the same.A generated core advances at one rate: one call is one sample. So a model whose parts run at different rates is deployed as several targets. Each one points at a subsystem that is uniform in rate, and each is generated at that subsystem's rate. A slow supervisory loop and a fast inner loop become two deployables, each in the language its destination needs.
Most blocks carry a Sampling Time (s) parameter set to -1. Zero or less
inherits the rate, and a positive value runs the block at that period. Inheritance runs
downwards through the levels. Home takes the global sampling time. A
subsystem takes its own rate if it sets one, and its parent's otherwise. So a whole subsystem is
set to its rate in one place.
If a target's subtree is not uniform in rate, the export says so and stops. It does not
pick a rate for you. The same check runs whether you press Deploy, verify, or call
fire().
The subsystem is multi-rate; code export verification needs a uniform sampling time.
Two targets don't have to share a language. The same diagram can produce a C core for a microcontroller, a VHDL entity for the FPGA beside it, and Structured Text for the PLC, all from one source of truth and all verified the same way.
Fixed-size storage, nothing allocated at run time. DeployableCore_init(&core),
then execute_blocks(&core) once per sample. It comes with a
CMakeLists.txt.
Every signal in Q16.16 fixed point. One rising clk edge is one sample, and there is a
testbench and a Makefile for GHDL or Icarus.
IEC 61131-3 Structured Text: a FUNCTION_BLOCK FB_<name> where one call is one
scan.
The same core and the same one-call-one-sample contract, for a bench, a simulator or a CI job.
| Scripting | Written by Deploy |
|---|---|
| C | _deployableCore.h/.c, _testbench.c, CMakeLists.txt |
| C++ | _deployableCore.hpp, _testbench.cpp, CMakeLists.txt |
| Rust | _deployableCore.rs, _testbench.rs, Cargo.toml |
| VHDL | icore_pkg.vhd, .vhd, _tb.vhd, Makefile |
| Verilog · SV | icore_defs.vh/.svh, .v/.sv, _tb, Makefile |
| PLC - ST | _deployableCore.st, _testbench.st |
| Python · MATLAB · Java | _deployableCore and _testbench in that language |
Each file is prefixed with the source subsystem's name, and the core's parameters can be tuned after export without generating it again. See each target →
A target whose verification level is not None is compared against the
simulation before a single file is written. Deploy All runs the targets one at a time, and you can see
each one finish.
The generated code is built with a real toolchain and compared with the simulation, sample by sample, against a residual tolerance. Software targets typically report 0 or about 1e-14 %. The HDL targets report about 1e-3 %, which is the Q16.16 quantum.
If a check fails, the app asks whether to keep exporting, and No aborts the whole run, not just that target. With no window to ask in, the answer is No.
Targets export in turn behind a progress bar, with a Cancel button. A target whose language can't carry one of its signal types stops alone, and the rest of the queue still runs.
While an export or verification runs, the model can't be edited. The code always matches the diagram it was generated from. You can still scroll, zoom and save.
The same targets are what Code Engine → Code Export Verifier checks without deploying, with Verify This Target or Verify All. Its residual tolerance defaults to 1 %, and it can auto-scan for a compiler or use one you pick.
Every refusal names its reason. None of them silently changes your model.
target(Language) ·
t.setConfig(Key, Value) · t.fire() · getTarget(name) ·
targetsicore targets ·
icore fire <name>, from an agent, a script or a build serverSee also: Code export · Verification
Download the application from the customer portal, or read the documentation first - the manual, a page for every block, and the full command reference are public.