A chat model that writes IEC 61131-3 Structured Text for Mikrodev PLCs, fine-tuned from
Qwen/Qwen2.5-Coder-14B-Instruct and published as GGUF (Ollama, llama.cpp),
plus the LoRA adapter it was trained with.
This is a fine-tune for the Structured Text coding rules of Advance Logic Builder (ALB), the IEC 61131-3 engineering environment developed by Mikrodev and shipped as Mikrodev LogicStudio. It follows Mikrodev's ST dialect, not generic IEC 61131-3 and not another vendor's conventions.
stcoder-qwen25-14b is the rule-compliance member of the line: a chat-only fine-tune of Qwen2.5-Coder-14B-Instruct that writes body-only Mikrodev LogicStudio Structured Text, and the only one of the four fine-tunes that was 100% rule-clean with zero prose in both prompt conditions. The line default is stcoder-qwen25-7b at Q8_0; choose this one on 12 GB of VRAM or more when clean dialect output is what you are buying.
If you are choosing for the first time, start with Mikrodev/stcoder-qwen25-7b-gguf at Q8_0 instead (the fastest per answer of the four (5.8 s), 15/15 delivery, and the highest ChrF among the models that answered every prompt (38.5)). Come to this model for the reasons listed under Is this the right model for you?.
Ollama 0.3+ (tested on 0.32.5), llama.cpp — CPU, GPU or Apple unified memory
Trained for
Mikrodev / ALB Structured Text only — body-only, no POU wrappers, INT milliseconds
Tool calling is not supported on this release. These are chat models: you describe a plant
requirement, they reply with Structured Text. It was trained, measured and then dropped as a
product decision — the numbers and the reasoning are under Not the right tool for. Do not build
an agent on them.
Always compile generated code in ALB / LogicStudio before deployment. The model produces
dialect-correct code, which is not the same as correct control logic.
Which build should I download?
Take Q8_0 (qwen25_coder_14b-tc.q8_0.gguf, 14.62 GiB) if it fits. Q8_0 is the smallest build with no practically measurable loss against the trained weights - it is the precision we recommend for real work.
Before you download Q8_0: it needs a 24 GB-class card. A 16 GiB card cannot fit it - including the RTX 5080 this model's own evaluation ran on, which is why the measured numbers below are Q6_K. On 16 GiB or less take Q6_K.
Build
File
Size
Free VRAM needed
In repo
Verdict
Q8_0
qwen25_coder_14b-tc.q8_0.gguf
14.62 GiB
16.6 GiB
in this repo
recommended. Needs a 24 GB-class card. A 16 GiB card cannot fit it - including the RTX 5080 this model's own evaluation ran on, which is why the measured numbers below are Q6_K. On 16 GiB or less take Q6_K
Q6_K
qwen25_coder_14b-tc.q6_k.gguf
11.29 GiB
13.3 GiB
in this repo
fine — build used in the study below
Q4_K_M
qwen25_coder_14b-tc.q4_k_m.gguf
8.37 GiB
10.4 GiB
in this repo
not recommended
Free VRAM is the file plus roughly 2 GiB for the 8192-token context and runtime. Less than that
and the runtime spills layers to system RAM: it still answers, but the speed figures below no
longer apply. CPU-only and Apple unified memory work too — same arithmetic against system RAM,
slower generation.
Why we do not recommend Q4_K_M. Q4_K_M halves the bits per weight again. The only capability we measured across quantisations degraded sharply - tool-call composite 0.816 at Q8_0 against 0.642 at Q4_K_M, measured on the Qwen3.5-9B family, the only one of the four where tool-calling worked at all - and low-bit quantisation is a known source of drift and hallucination on long or unusual requests. Our 15-prompt code study never ran at Q4, so we have no measured code-quality figure for it: treat this as a precaution, not a measured code-quality gap. That measurement is from the Qwen3.5-9B family; this model's own tool-call score was near zero at every quantisation, so there is no quantisation comparison to make for it.
Also published
Artefact
What it is
Size
In repo
lora_adapter/
The LoRA adapter this model was trained as — PEFT adapter on the base model above. Merge it yourself, stack it, or continue training from it.
small
in this repo
f16 merged weights
f16 is the merged fine-tune at full precision: the reference build, for evaluation or for producing your own quantisations.
~27.50 GiB
not shipped - rebuild from the adapter (snippet below)
Modelfile
One ready-to-run Ollama definition: the system prompt, the sampling defaults and num_ctx 8192 (the sequence length this model was trained at). It deliberately carries no chat template — Ollama uses the chat template stored inside the GGUF, so the chat format is the trained one and cannot drift out of sync with this file. Its FROM points at the Q8_0 file; edit that one line if you downloaded a different quant.
2. Download the model file and its Modelfile (two files, not the whole repo)
Note before you pull several GiB: Q8_0 needs a 24 GB-class card. A 16 GiB card cannot fit it - including the RTX 5080 this model's own evaluation ran on, which is why the measured numbers below are Q6_K. On 16 GiB or less take Q6_K.
If hf is not found after installing (common on Windows, where the Python scripts directory is
often not on PATH), call it as a module instead — same arguments:
python -m huggingface_hub.cli.hf download Mikrodev/stcoder-qwen25-14b-gguf qwen25_coder_14b-tc.q8_0.gguf --local-dir .
3. Register it with Ollama and ask it something
bash
1ollama create stcoder-qwen25-14b:q8_0 -f Modelfile
23ollama run stcoder-qwen25-14b:q8_0 "Silo inlet: on a fill request with the high-level switch clear, open the inlet valve; 3 seconds after the valve open-confirm, start the blower. Any fault stops the blower at once and closes the valve 2 seconds later."
You get a body-only iecst block: VAR declarations plus logic, millisecond INT presets,
positional function-block calls, no PROGRAM wrapper. Paste it into ALB / LogicStudio and compile.
For a different build, download that GGUF instead and change the Modelfile's FROM line to its
filename (the Modelfile lists the alternatives at the top).
With llama.cpp instead of Ollama, run llama-cli -m <file>.gguf --jinja and pass the same system
prompt. --jinja matters: it makes llama.cpp use the chat template stored inside the GGUF — the
one this model was trained with — instead of guessing a format.
What the fine-tune actually changes
One prompt from the study below, sent to the stock base and to this fine-tune under the same short
system prompt that lists no dialect rules:
We've got a conveyor with a pre-start warning horn. When the operator hits the start button I need the horn to sound for 5 seconds first, then the motor kicks in and the horn goes quiet.
The stock base answered with named function-block parameters, a TIME literal and a PROGRAM wrapper — constructs the Mikrodev runtime rejects:
Timer5Sec(IN := FALSE, PT := T#5s);
This fine-tune, same prompt, no rules in the prompt:
iecst
1HORN_MS :INT:=5000;(* in VAR CONSTANT *)2tHorn(bStartBtn ANDNOT bFault ANDNOT bStopBtn, HORN_MS);
Positional function-block call, delay as an INT in milliseconds, no wrapper — the dialect came out
of the weights, not out of the prompt. Both snippets are verbatim from the recorded run.
These lines show dialect, not correctness. R24 certifies that no forbidden construct appears;
it does not check that the logic works. Read Weaknesses before you trust an answer.
Use the LoRA adapter directly
The adapter is published so you can merge it at whatever precision you want, or keep training.
From there llama.cpp/convert_hf_to_gguf.py plus llama-quantize produces any quantisation you
prefer — that is exactly how the GGUF files in this repo were built.
What to ask it
Surface grinder start sequence: when the operator presses start, sound the warning siren for 4 seconds, then energise the spindle contactor. The stop button and a coolant-low fault both drop the spindle immediately.
Dust extractor run-on: the extraction fan runs whenever the panel saw runs and keeps running for 45 seconds after the saw stops. E-stop cuts it immediately.
Flash the tower lamp while the line is in manual mode: lit for 300 ms, dark for 1200 ms.
Scale a pressure transmitter from the analog card: 6000 raw counts is 0 barg, 30000 raw counts is 25 barg. Clamp the result to the range and raise a wire-break flag below 5400 counts. There is an enable bit from the scan logic.
Unpack a 16-bit soft-starter status word from Modbus into ready, running, tripped and bypass-closed flags. The manual gives the masks in hex: 16#0004 ready, 16#0010 running, 16#0040 tripped, 16#0100 bypass closed.
Keep the system prompt short: the dialect is in the weights. In our evaluation pasting the full
rule book into the system prompt did not improve this model
(ChrF 34.9 with a short prompt against 36.8 with the full rule book).
Evaluation
The same 15 plant-engineering requests were sent to the stock base model (qwen2.5-coder:14b) and to this
fine-tune (stcoder_qwen25-14b:q6), twice: once with a short realistic system prompt listing no dialect rules,
and once with the entire rule book in the prompt. Greedy decoding (temperature 0,
seed 42), num_ctx 16384 / num_predict 8192, local Ollama on
an RTX 5080 (16 GB). This model ran at Q6_K — note that is not always the build
recommended above, and the eval tags used an underscore (stcoder_qwen25-14b:q6) where the walkthrough above
creates a hyphenated tag; the name is arbitrary and does not affect the weights.
The shipped Modelfile is not the study configuration. It defaults to
temperature 0.2 and num_ctx 8192 (the sequence length this
model was trained at) because that is the better interactive default. The numbers below were
measured greedily at num_ctx 16384 / num_predict 8192. Match those
three values if you want to reproduce them; expect run-to-run variation otherwise.
Measure
Base
This fine-tune
Base + full rules
Fine-tune + full rules
Dialect-clean replies
0.0%
100.0%
40.0%
100.0%
Delivered code at all
100.0%
100.0%
100.0%
100.0%
R24 rule compliance
92.36
100.0
97.16
100.0
ChrF vs reference code
32.6
34.9
32.5
36.8
Output tokens (mean · median)
713 · 674
288 · 262
664 · 606
313 · 292
Time per reply
11.1s
8.6s
10.2s
8.7s
Opened with prose, not code
80.0%
0.0%
100.0%
0.0%
R24 — dialect rule compliance: 33 weighted forbidden patterns, 0–100. Comments, prose and
string contents are stripped before matching. Figures here are computed over the whole reply.
ChrF — character n-gram F-score of the generated code against a hand-written reference.
Clean — the reply delivered code and broke no rule. A reply with no code scores R24 = 100
trivially, so delivery is checked first.
Composite — a single 0–1 roll-up: 0.5 × R24/100 + 0.3 × ChrF/100 + 0.2 × (1 − 6-gram
repetition). Useful for ranking, but always read it next to Clean and ChrF.
Which R24 variant — the figures here score the whole reply. Scoring only the fenced code
instead lifts the pooled base clean rate across the four models from 6.7% to 10.0%; the
base-versus-fine-tune gap survives either choice, but the variant is named so the numbers can be
reproduced exactly.
The four models, identical conditions
ChrF is averaged over delivered replies so the denominator is the same for every model.
Which one should you take?Mikrodev/stcoder-qwen25-7b-gguf
at Q8_0 — the fastest per answer of the four (5.8 s), 15/15 delivery, and the highest ChrF among the models that answered every prompt (38.5). The other three are for specific reasons: the 14B if
you want the only model that was 100% rule-clean in both prompt conditions, the 9B if you want the
reasoning family, the Gemma if you want a non-Qwen lineage as a second opinion.
Detailed report
The full evaluation for this model — VRAM guidance, step-by-step setup, every one of the 15 test
prompts with its result, side-by-side base-versus-fine-tune code, the violation breakdown, method
and limitations — ships in this repo:
Highest clean rate in the head-to-head: R24 100.0 and 100% clean across all 30 fine-tune replies, in both the minimal and the full-prompt condition. It is the only one of the four fine-tunes that reached 100% clean in both (stcoder-qwen25-7b 93.3/100, stcoder-qwen35-9b 93.3/100, stcoder-gemma4-12b 86.7/80).
The dialect lives in the weights, not the prompt. Under the minimal prompt - a short realistic system message that lists no rules at all - the fine-tune was 100% clean while the same base weights were 0.0% clean. Pasting the entire rule book into the base model's prompt only lifted it to 40%.
No prose leakage in either condition (0%, against 80% for the base at the minimal prompt and 100% at the full prompt). Replies are a code fence, not an essay wrapped around a code fence, so the output can be pasted straight into a block.
Fewest output tokens in the head-to-head at the minimal prompt: 288 mean and 262 median, against 340 for stcoder-qwen25-7b, 401 for stcoder-gemma4-12b and 1227 for stcoder-qwen35-9b - and 2.5x more economical than its own base on the same 15 requests (713 mean / 674 median). Mean wall clock was 8.6 s against 11.1 s for the base.
100% delivery in both conditions and both arms - no empty or non-delivered replies. Of the four fine-tunes only stcoder-qwen35-9b missed one (14 of 15 at the minimal prompt), which is why its higher ChrF carries a smaller denominator.
The only fine-tune in the set whose ChrF improved when the rule book was added to the prompt (34.9 to 36.8); the other three all dropped. Extra context does not destabilise this model.
Weaknesses
Lowest ChrF of the four at the minimal prompt: 34.9 over 15 delivered replies, against stcoder-qwen25-7b 38.5 (15/15), stcoder-qwen35-9b 40.9 (14/15) and stcoder-gemma4-12b 35.9 (15/15). Rule-clean output is not the same as output that resembles hand-written reference code, and on this metric this model is last in the set.
Fine-tuning made reference similarity worse on 5 of the 15 minimal prompts, where the fine-tune's ChrF fell below its own base: analog_scale_helper 24.46 against 30.97, io_terminal_seal_in 25.82 against 37.01, first_out_fault_annunciator 26.18 against 32.56, machine_data_grouping 28.76 against 31.91, setpoint_clamp_and_ramp 36.11 against 37.79. The training buys dialect compliance and brevity, not uniformly closer structure.
Clean does not mean correct. R24 is reference-free and has no compiler behind it. In the heater_power_avg_squared row the model scored R24 100 while reusing the ring-buffer index nIdx as the FOR loop counter (FOR nIdx := 0 TO 7), which destroys the index every scan. The metric cannot see that.
Undeclared symbols occur. The machine_cycle_full_program reply is dialect-clean at R24 100 but branches on bDownLimit and bUpLimit, neither of which appears in any VAR block. That code does not build. Compile before you trust it.
It can hand back a stub instead of admitting a limit. Asked to show how a reusable pump block is called for three pumps, it produced a second block that instantiates nothing - bP1Motor := bP1RunReq; and similar - with all three fault codes set to 0. Under the full prompt condition it dropped the call-site block entirely.
It can answer the dialect while missing the engineering question. The retain_counter_power_cycle prompt was explicitly about totals surviving a nightly power-down; retention is forbidden in code in this dialect and must be set on the symbol in the IDE, but the reply just counts and never mentions it. ChrF 25.7 on that row reflects the gap.
Not the right tool for
Tool calling or function calling of any kind. Tool calling was trained and evaluated for this line; only the Qwen3.5-9B family learned it (0.816 at Q8_0, 0.805 at Q6_K, 0.642 at Q4_K_M) while the code-focused families scored 0.02-0.06 and the Gemma family 0.00. Because it was not usable across the line it was dropped as a product decision, and these builds are published and supported as chat-only models. If you are building an agent that drives IDE tools, do not use them.
Agent frameworks that expect structured JSON actions, MCP calls or an OpenAI tools schema. This is a chat model that returns Structured Text in a code fence.
Machines with 8 GB of VRAM or less - the smallest published file is 8.37 GiB of weights. Use stcoder-qwen25-7b there (Q4_K_M, 4.36 GiB).
Readers who want the line default. That is stcoder-qwen25-7b at Q6_K: faster per answer, smaller, and higher ChrF at full delivery. Come to the 14B for the clean rate, not as a general upgrade.
Any dialect other than Mikrodev LogicStudio. It was trained to violate conventions that other IEC 61131-3 environments require, so its output is deliberately wrong for them: no POU wrappers, no TIME literals, no named parameters, no output arrows.
Those tool-call figures come from a separate internal evaluation that is not part of this release —
not from the code study reported above, whose own data and method ship with this model as the
detailed report.
Limitations of the evaluation
Quantisation was not matched. This fine-tune ran at Q6_K; the stock base ran at the
Ollama library default for qwen2.5-coder:14b, which was not recorded in the run data. Where the
comparison implies the base was around Q4 that is an inference, not a measurement. Extra precision
plausibly helps the fine-tune on quality and demonstrably penalises it on raw throughput.
"Clean" is not "correct". R24 is reference-free: it certifies that no forbidden construct
appears, not that the logic works. Correctness was checked by reading the code, not by compiling it.
Per-quant figures come from a separate evaluation (code composite 0.851-0.852 and ChrF 52.0 across Q4/Q6/Q8 (spread under 0.001)) whose code holdout overlapped
the training distribution by roughly 84%. Those absolute scores are inflated and weakly
discriminative; use them for the within-model quantisation comparison only, never to rank models
against each other.
Scope. 15 prompts, one dialect, English only, no tool calling, and the prompt set was
deliberately built on the categories where this dialect diverges from standard IEC. Treat
single-prompt differences as anecdote and the aggregate as the signal.
Training data
A curated in-house multi-task PLC corpus (approximately 2,930 training and 550 validation examples)
focused on Structured Text generation, written against the ALB / Mikrodev LogicStudio rule set. The
dataset is not publicly released.
Prompts are mostly English with a Turkish minority (10.8% of training prompts contain Turkish). Code, identifiers and code comments are always English; the model's conversational prose follows the language you write in.
Training setting
Value
Method
LoRA (PEFT) supervised fine-tune
LoRA rank / alpha
32 / 32 (dropout 0.0)
Epochs
2
Learning rate
0.0001
Sequence length
8192 tokens
Effective batch
8 (batch 1 x grad-accum 8)
The published LoRA adapter is exactly this run's output, so anything above can be reproduced or
continued from it.
Licence and attribution
apache-2.0. Fine-tuned from Qwen/Qwen2.5-Coder-14B-Instruct; the base
model's attribution and NOTICE are preserved. You may use, modify and redistribute under the same
terms.
Citation
bibtex
1@software{stcoder_qwen25_14b,
2 title = {stcoder-qwen25-14b: Structured Text for Mikrodev Advance Logic Builder},
3 author = {Mikrodev},
4 year = {2026},
5 note = {Fine-tuned from Qwen/Qwen2.5-Coder-14B-Instruct}
6}
