Mikrodev/stcoder-qwen25-7b-gguf

stcoder-qwen25-7b

A chat model that writes IEC 61131-3 Structured Text for Mikrodev PLCs, fine-tuned from Qwen/Qwen2.5-Coder-7B-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-7b is a chat-only model fine-tuned from Qwen2.5-Coder-7B-Instruct that writes IEC 61131-3 Structured Text in the Mikrodev LogicStudio dialect. It is the default recommendation of this four-model line, at Q8_0 (7.54 GiB): in the head-to-head study it was the fastest per answer of the four (mean 5.8 s per reply with a short system prompt, 5.1 s with the full rule book) and it had the highest ChrF of the models that delivered all 15 replies (38.5).

This is the default recommendation of the STCoder line — 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).

At a glance
Take this build	Q8_0 — qwen25_coder_7b-tc.q8_0.gguf, 7.54 GiB, wants 9.5 GiB free
Dialect-clean replies	93.3% against 13.3% for the stock base
Speed	5.8s per reply, 340 output tokens (median 269)
Runs on	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_7b-tc.q8_0.gguf, 7.54 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.

Build	File	Size	Free VRAM needed	In repo	Verdict
Q8_0	qwen25_coder_7b-tc.q8_0.gguf	7.54 GiB	9.5 GiB	in this repo	recommended — build used in the study below
Q6_K	qwen25_coder_7b-tc.q6_k.gguf	5.82 GiB	7.8 GiB	in this repo	fine
Q4_K_M	qwen25_coder_7b-tc.q4_k_m.gguf	4.36 GiB	6.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.	~14.20 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.	small	in this repo
article_stcoder-qwen25-7b.html, article_stcoder-qwen25-7b.docx	The full evaluation report for this model.

Quick start with Ollama

Requires Ollama 0.3 or newer.

1. Install Ollama

# Windows
winget install Ollama.Ollama
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh

ollama --version

2. Download the model file and its Modelfile (two files, not the whole repo)

pip install -U huggingface_hub

hf download Mikrodev/stcoder-qwen25-7b-gguf qwen25_coder_7b-tc.q8_0.gguf --local-dir .
hf download Mikrodev/stcoder-qwen25-7b-gguf Modelfile --local-dir .

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-7b-gguf qwen25_coder_7b-tc.q8_0.gguf --local-dir .

3. Register it with Ollama and ask it something

ollama create stcoder-qwen25-7b:q8_0 -f Modelfile

ollama run stcoder-qwen25-7b: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 and a TIME literal — constructs the Mikrodev runtime rejects:

HornTimer(IN := TRUE, PT := T#5s);

This fine-tune, same prompt, no rules in the prompt:

HORN_MS   : INT := 5000;                      (* in VAR CONSTANT *)
tHorn(bHornReq AND NOT 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.

pip install -U torch transformers peft accelerate

import torch
from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-Coder-7B-Instruct", dtype=torch.float16,
                                            device_map="auto")
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-Coder-7B-Instruct")
model = PeftModel.from_pretrained(base, "Mikrodev/stcoder-qwen25-7b-gguf", subfolder="lora_adapter")

merged = model.merge_and_unload()          # f16 merged weights
merged.save_pretrained("stcoder-merged-f16"); tok.save_pretrained("stcoder-merged-f16")

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

• Silo inlet sequence: when the fill request is on and the high-level switch is clear, open the inlet valve. Three seconds after the valve open-confirm is made, start the blower. Any fault stops the blower immediately and closes the valve two seconds later.
• Chiller circulation pump: the pump follows the compressor and keeps running for 45 seconds after the compressor stops so the plate exchanger cannot freeze. E-stop cuts both at once. Give me a post-circulation flag for the HMI.
• Screw feeder motor: NO start pushbutton, NC stop pushbutton, motor overload aux contact. Normal seal-in, and the overload trip latches until the stop button is pressed.
• Level transmitter, 4-20 mA on a 0-8 m tank: 6400 counts = 4 mA and 31900 counts = 20 mA. Convert the raw integer to metres, clamp to 0-8, and raise a wire-break flag below 4 mA.
• Operators enter a drying oven setpoint on the HMI. Clamp it to 55.0-120.0 degC, raise an out-of-range warning the operator can acknowledge, and ramp the setpoint that goes to the loop at 1.5 degC per second.

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 38.5 with a short prompt against 35.3 with the full rule book).

Evaluation

The same 15 plant-engineering requests were sent to the stock base model (qwen2.5-coder:7b) and to this fine-tune (stcoder_qwen25-7b:q8), 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 Q8_0 — note that is not always the build recommended above, and the eval tags used an underscore (stcoder_qwen25-7b:q8) 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	13.3%	93.3%	33.3%	100.0%
Delivered code at all	100.0%	100.0%	100.0%	100.0%
R24 rule compliance	93.34	99.8	97.16	100.0
ChrF vs reference code	32.4	38.5	29.5	35.3
Output tokens (mean · median)	728 · 680	340 · 269	670 · 621	304 · 254
Time per reply	7.2s	5.8s	6.6s	5.1s
Opened with prose, not code	100.0%	6.7%	100.0%	6.7%

• 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.

Model	Clean	Delivered	ChrF	Composite	Out tok	Per reply
Mikrodev/stcoder-qwen25-7b-gguf (this model)	93.3%	15/15	38.5	0.844	340	5.8s
Mikrodev/stcoder-qwen25-14b-gguf	100.0%	15/15	34.9	0.842	288	8.6s
Mikrodev/stcoder-qwen35-9b-gguf	93.3%	14/15	40.9	0.845	1227	17.2s
Mikrodev/stcoder-gemma4-12b-gguf	86.7%	15/15	35.9	0.83	401	8.5s

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:

• article_stcoder-qwen25-7b.docx — Word, ~7,000 words
• article_stcoder-qwen25-7b.html — same content, open locally in a browser

Strengths

• Dialect compliance is in the weights, not the prompt. With a short realistic system prompt that lists no rules ('minimal'), the fine-tune scored R24 99.80 and produced rule-clean code on 14 of 15 prompts (93.3%). The stock base weights under the same prompt scored R24 93.34 with 13.3% clean (2 of 15). All R24 and clean figures in this card are the whole-reply variant; see the methodology note under weaknesses.
• Prompting cannot close the gap. Pasting the entire rule book into the base model's system prompt lifted it from 93.34 to 97.16 R24 and from 13.3% to 33.3% clean - better, but still two thirds of replies broke at least one rule. The fine-tune reached 100.0 R24 and 15 of 15 clean in the same condition, with zero recorded violations.
• The two habits that break Mikrodev compilation are gone. Across the base model's 30 delivered replies, named function-block parameters were the most persistent violation (7 replies in each condition) and TIME literals appeared in 7 minimal-condition replies. The fine-tune emitted neither, in either condition.
• It stops wrapping code in POU shells. The base produced POU headers in the minimal condition (no_pou_program in 5 replies, no_pou_fb in 2); the fine-tune produced none, delivering the body-only form the IDE expects.
• Terse and fast. Mean 340 output tokens against the base's 728 (median 269 against 680) and 5.8 s per reply against 7.2 s, falling to 5.1 s in the full condition. At 5.8 s it is the fastest per answer of the four models in this line; stcoder-qwen25-14b emitted fewer tokens per answer (288) but took 8.6 s to do it.
• It answers with code, not a lesson. The prose flag fired on 100% of this model's base replies and on 6.7% (1 of 15) of fine-tune replies. There are no thinking tokens to strip: the think metric is 0.0 in all four arms.

Weaknesses

• Hex literals survive when the prompt supplies them. On the VFD status-word prompt, where the drive manual's masks were quoted as 16#0001, 16#0002, 16#0008, 16#0080 and 16#0F00, the fine-tune reproduced them verbatim - R24 97.06, no_based_literal, and the only violation in this model's minimal arm. It occurred in the minimal condition only: with the full rule book in the system prompt the model's full arm recorded zero violations on all 15 prompts. Give it decimal masks or bit indices instead.
• Rule-clean is not compile-clean. On the drilling station prompt the fine-tune scored R24 100 but declared TYPE E_Station : (IDLE, CLAMPING, DRILLING, RETRACTING) and then branched to a DWELLING state that is not a member of that enumeration. It will not compile as written.
• Logic errors occur in rule-clean code. The bottle counter block (R24 100) incremented the shift counter inside IF bResetActive THEN instead of clearing it. The blink oscillator (R24 100) called the same TON instance twice in one scan with two different presets, tBlink(..., BLINK_MS) then tBlink(..., DARK_MS), which will not produce a 500 ms / 1500 ms flash. R24 is reference-free and scores dialect compliance only.
• Declarations can drift from the body. The seal-in block declared HOLD_MS : INT := 500 and never used it, while a comment claimed the button 'must be held for 500 ms before pump runs' - behaviour the code does not implement.
• Trailing prose can be wrong. On the pump-block prompt under the full system prompt, the fine-tune appended an explanation stating 'The fault latch is shared across all instances, so a single overload trip on any pump will trip the latch for all three' - untrue of the code it had just written, which is per-instance. Read the code, not the summary.
• Closer to the reference is not universal. ChrF fell below the base on 3 of the 15 minimal-condition prompts: the reusable scaling helper (25.94 against 27.76), the first-out fault annunciator (32.23 against 35.92) and the machine data grouping prompt (29.54 against 29.83). On the scaling helper it also invented raw endpoints the prompt did not specify (RAW_MIN : INT := 3200).

Not the right tool for

• Tool calling or function calling of any kind. The capability was trained and measured across this line, but only the Qwen3.5-9B family learned it usefully (tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, 0.642 at Q4_K_M); this model's family 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.
• Agent frameworks that expect structured JSON actions, MCP tool schemas, or a ReAct-style action loop.
• IEC 61131-3 dialects other than Mikrodev LogicStudio. The fine-tune was trained to suppress TIME literals, named FB parameters, POU wrappers, STRUCT and based literals - all of which other runtimes legitimately require. Output will need rewriting.
• Safety-instrumented functions, emergency-stop chains or any SIL-rated logic without full engineering review. Nothing in this evaluation measures functional safety.
• Whole-project architecture. The study covers single blocks up to about 970 tokens; multi-block projects, device configuration and signal maps are outside what was measured.

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 Q8_0; the stock base ran at the Ollama library default for qwen2.5-coder:7b, 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.844-0.846 and ChrF ~50 across Q4/Q6/Q8 (spread under 0.002)) 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	16 / 16 (dropout 0.0)
Epochs	3
Learning rate	0.0002
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-7B-Instruct; the base model's attribution and NOTICE are preserved. You may use, modify and redistribute under the same terms.

Citation

@software{stcoder_qwen25_7b,
  title  = {stcoder-qwen25-7b: Structured Text for Mikrodev Advance Logic Builder},
  author = {Mikrodev},
  year   = {2026},
  note   = {Fine-tuned from Qwen/Qwen2.5-Coder-7B-Instruct}
}