README.md

---
license: apache-2.0
base_model: Qwen/Qwen3.5-9B
base_model_relation: finetune
language:
  - en
  - tr
tags:
  - plc
  - iec-61131-3
  - structured-text
  - code-generation
  - gguf
  - ollama
  - mikrodev
  - ALB
  - AdvanceLogicBuilder
  - MikrodevLogicStudio
  - advance-logic-builder
  - mikrodev-logicstudio
  - qwen3.5
pipeline_tag: text-generation
library_name: gguf
---

# stcoder-qwen35-9b

A chat model that writes **IEC 61131-3 Structured Text for Mikrodev PLCs**, fine-tuned from
[`Qwen/Qwen3.5-9B`](https://huggingface.co/Qwen/Qwen3.5-9B) 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-qwen35-9b is a chat-only fine-tune of Qwen3.5-9B that writes Mikrodev LogicStudio Structured Text; it is the only member of the line built on a reasoning base, so it thinks before it answers — which buys clean, reference-shaped code but costs roughly four times the tokens of its siblings and cost it one non-delivery in fifteen.

If you are choosing for the first time, start with [`Mikrodev/stcoder-qwen25-7b-gguf`](https://huggingface.co/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?*.

| At a glance | |
|---|---|
| Take this build | **Q8_0** — `qwen35_9b-tc.q8_0.gguf`, 9.11 GiB, wants 11.1 GiB free |
| Dialect-clean replies | **93.3%** against 6.7% for the stock base |
| Speed | 17.2s per reply, 1227 output tokens (median 793) |
| Runs on | Ollama 0.32.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 (`qwen35_9b-tc.q8_0.gguf`, 9.11 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** | `qwen35_9b-tc.q8_0.gguf` | 9.11 GiB | 11.1 GiB | in this repo | **recommended** — build used in the study below |
| **Q6_K** | `qwen35_9b-tc.q6_k.gguf` | 7.04 GiB | 9.0 GiB | in this repo | fine |
| **Q4_K_M** | `qwen35_9b-tc.q4_k_m.gguf` | 5.38 GiB | 7.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.

**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. | 17.13 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-qwen35-9b.html`, `article_stcoder-qwen35-9b.docx` | The full evaluation report for this model. | |

## Quick start with Ollama

Requires **Ollama 0.32.3 or newer**.

> Ollama 0.32.3+ is required - 0.24 fails to load this architecture (loader, not the GGUF).

**1. Install Ollama**

```bash
# 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)


```bash
pip install -U huggingface_hub

hf download Mikrodev/stcoder-qwen35-9b-gguf qwen35_9b-tc.q8_0.gguf --local-dir .
hf download Mikrodev/stcoder-qwen35-9b-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-qwen35-9b-gguf qwen35_9b-tc.q8_0.gguf --local-dir .`

**3. Register it with Ollama and ask it something**

```bash
ollama create stcoder-qwen35-9b:q8_0 -f Modelfile

ollama run stcoder-qwen35-9b: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).

> **Turning the reasoning off.** This model thinks before it answers, which is where its tokens and
> its one non-delivery in fifteen go. To skip it, send `"think": false` to `/api/chat`, or type
> `/set nothink` inside `ollama run` — both verified against this build. Every number published here
> was measured with reasoning **on**, so that mode is untested territory.

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 a POU wrapper and VAR_GLOBAL (the IDE supplies the wrapper itself) — constructs the Mikrodev runtime rejects:

```iecst
PROGRAM ConveyorControl
VAR_GLOBAL
    StartBtn : BOOL;      // Momentary Start Button
```

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

```iecst
WARNING_MS : INT := 5000;                     (* in VAR CONSTANT *)
tWarning(bStartEdge, WARNING_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.

```bash
pip install -U torch transformers peft accelerate
```

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

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-9B", dtype=torch.float16,
                                            device_map="auto")
tok = AutoTokenizer.from_pretrained("Qwen/Qwen3.5-9B")
model = PeftModel.from_pretrained(base, "Mikrodev/stcoder-qwen35-9b-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

- Car-wash sump pump. Start pushbutton on DI1, NC stop on DI2, pump overload aux on DI3, contactor on RO1. Write me a start/stop seal-in. The start button is bouncy so it has to be held half a second before the pump picks up, and an overload trip has to latch the pump out until someone resets it.
- Chiller circulation pump has to keep running 45 seconds after the compressor stops so the loop clears. E-stop cuts compressor and pump straight away. Give me a purge-in-progress flag for the HMI too.
- Ultrasonic flow meter on a 4-20 mA input. Raw word is an integer, 0 counts = 0 m3/h and 32767 counts = 250 m3/h. Scale it, clamp the result to 0-250, and raise a wire-break flag below 1000 counts. There is an enable bit; when it is off the output reads zero.
- Operators type a brine chiller setpoint on the HMI. Pull anything below -8.0 or above 2.0 degC back to the nearest limit and raise an out-of-range warning. The setpoint going to the controller must not move more than 0.5 degC per scan, so ramp it.
- A photo eye pulses once per carton leaving the label applicator. I need a lifetime total for maintenance records and a shift total the supervisor clears with bShiftReset. Count on the rising edge.

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

## Evaluation

The same 15 plant-engineering requests were sent to the stock base model (`qwen3.5:9b`) and to this
fine-tune (`stcoder_qwen35-9b: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_qwen35-9b: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 | 6.7% | **93.3%** | 26.7% | 100.0% |
| Delivered code at all | 80.0% | 93.3% | 80.0% | 100.0% |
| R24 rule compliance | 93.02 | 100.0 | 96.57 | 100.0 |
| ChrF vs reference code | 28.9 | 40.9 | 34.1 | 37.6 |
| Output tokens (mean · median) | 6345 · 6952 | 1227 · 793 | 2902 · 1521 | 554 · 488 |
| Time per reply | 54.5s | 17.2s | 26.7s | 9.0s |
| Opened with prose, not code | 80.0% | 0.0% | 66.7% | 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.

| Model | Clean | Delivered | ChrF | Composite | Out tok | Per reply |
|---|---|---|---|---|---|---|
| [`Mikrodev/stcoder-qwen25-7b-gguf`](https://huggingface.co/Mikrodev/stcoder-qwen25-7b-gguf) | 93.3% | 15/15 | 38.5 | 0.844 | 340 | 5.8s |
| [`Mikrodev/stcoder-qwen25-14b-gguf`](https://huggingface.co/Mikrodev/stcoder-qwen25-14b-gguf) | 100.0% | 15/15 | 34.9 | 0.842 | 288 | 8.6s |
| [`Mikrodev/stcoder-qwen35-9b-gguf`](https://huggingface.co/Mikrodev/stcoder-qwen35-9b-gguf) **(this model)** | 93.3% | 14/15 | 40.9 | 0.845 | 1227 | 17.2s |
| [`Mikrodev/stcoder-gemma4-12b-gguf`](https://huggingface.co/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`](https://huggingface.co/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-qwen35-9b.docx`](https://huggingface.co/Mikrodev/stcoder-qwen35-9b-gguf/resolve/main/article_stcoder-qwen35-9b.docx) — Word, ~7,000 words
- [`article_stcoder-qwen35-9b.html`](https://huggingface.co/Mikrodev/stcoder-qwen35-9b-gguf/resolve/main/article_stcoder-qwen35-9b.html) — same content, open locally in a browser

## Strengths

- Zero dialect violations across every delivered reply in the study: R24 100.0 in both the minimal and the full-rule condition, with the violation table empty for 14/14 and 15/15 delivered replies. The same figures scored over the fenced code only are identical. The stock base at the same minimal prompt broke rules in 13 categories, led by VAR_GLOBAL (5 replies), FUNCTION_BLOCK (4) and PROGRAM (4).
- Its code shape, variable naming and comment style land close to the hand-written reference: ChrF 40.9 averaged over its 14 delivered replies at the minimal prompt, which is the highest delivered-only figure in the set (7B 38.5, Gemma-12B 35.9, Coder-14B 34.9). Counting the one missing reply as zero it is 38.2, below the 7B's 38.5 over 15 of 15 - so the delivered-only lead is real but conditional, and the denominator belongs with the number.
- The dialect is in the weights, not in the prompt. With a short realistic system prompt and no rules listed it scored 93.3% clean; the base needed the entire rule book in its system prompt to reach 26.7%.
- Reasoning cost cut by roughly five times against its own base: 1227 output tokens versus 6345 at the minimal prompt (median 793 versus 6952), and 17.2 s versus 54.5 s per answer.
- Timers come out right without being asked: positional TON(condition, MS) calls with INT millisecond constants such as START_DELAY_MS : INT := 2000, where the base emitted PT := T#2S and named parameters like StartDelayTimer(IN:=...) - the two constructs the Mikrodev runtime rejects.
- Returns code, not an essay: the prose-opening flag fired on 0% of fine-tune replies against 80% of base replies at the minimal prompt. Output pastes into the IDE with a fence to strip.

## Weaknesses

- It can still return nothing. One of fifteen fine-tuned replies at the minimal prompt (the first-out fault annunciator) spent the whole 8192-token budget on hidden reasoning and delivered no code, giving 93.3% delivery - the only non-delivery by any fine-tune in the study. The base did this three times out of fifteen. Fine-tuning reduced the failure mode; it did not remove it.
- Every reply carries a hidden reasoning block - 100% of replies in all four arms, base and fine-tune alike. Expect a pause before code appears, and never run this model with a short context.
- "Clean" is not "correct". The flashing-beacon reply scored R24 100.0 and violated nothing, but it declared FLASH_OFF_MS : INT := 1500, never used it, and drove the lamp straight from a single TON output - that lamp will not blink. Its ChrF on that row was the lowest of the timer set (30.25).
- Two further logic defects in otherwise clean replies: the pre-start horn block gated the motor on a one-scan rising-edge flag, so the motor never seals in; and the heater-averaging block wrapped its divide in a FOR loop that does not actually average eight samples.
- Doubled comment delimiters - literal (* (* Motor run command *) *) - appeared in 2 of 15 minimal-prompt replies (io_terminal_seal_in, reusable_pump_block) and in 6 of 15 with the full rule book (timer_start_delay, timer_blink_oscillator, reusable_pump_block, retain_counter_power_cycle, shared_project_value, machine_data_grouping). The R24 rule set does not flag this, but the sequence is not valid ST and has to be cleaned before compiling. It is the model's most common compile-stopper, and it is worse in the condition that otherwise scores best.
- In the array-of-machines answer it emitted a TYPE MACHINE : ... END_TYPE declaration of its own. The scorer did not flag it and the row counted as clean, but the Mikrodev dialect has no user-defined types, so that reply needs rework.

## Not the right tool for

- Tool calling or function calling. Tool calling was trained and evaluated for this line and then dropped as a product decision; these builds are published and supported as chat-only models. This family is the one that learned it - tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, 0.642 at Q4_K_M - while stcoder-qwen25-7b and stcoder-qwen25-14b reached 0.02-0.06 and stcoder-gemma4-12b 0.00. Because it was not usable across the line it was withdrawn: not published, not supported, and not to be relied on here even though the weights retain some of the ability. If you need an agent that drives IDE tools, do not build it on these releases.
- Deployment without compiling. R24 is reference-free and checks dialect compliance only; three of the clean replies in this study contained real logic defects, and doubled comment delimiters slip past the scorer entirely. Compile in LogicStudio and test before commissioning.
- Any dialect other than Mikrodev LogicStudio. The fine-tune actively suppresses POU wrappers, TIME literals and named function-block parameters that other IEC 61131-3 environments expect.
- Machines where the context window has to be cut short. This is a reasoning model; a small budget is exactly how you get a reply with no code in it.
- Latency-sensitive interactive use. This model answered in 9.0-17.2 s per reply depending on condition; the line default, stcoder-qwen25-7b, answered in 5.8 s at the minimal prompt with 100% delivery.

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 `qwen3.5:9b`, 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 Q8 0.836 / Q6 0.832 / Q4 0.828; ChrF 47.4 / 46.0 / 44.5) 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.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/Qwen3.5-9B`](https://huggingface.co/Qwen/Qwen3.5-9B); the base
model's attribution and NOTICE are preserved. You may use, modify and redistribute under the same
terms.

## Citation

```bibtex
@software{stcoder_qwen35_9b,
  title  = {stcoder-qwen35-9b: Structured Text for Mikrodev Advance Logic Builder},
  author = {Mikrodev},
  year   = {2026},
  note   = {Fine-tuned from Qwen/Qwen3.5-9B}
}
```