stcoder-qwen35-9b

Start from the graphics memory you have. Every build below is the same fine-tune; they differ only in how heavily the weights are compressed.

Also published for this model. The LoRA adapter it was trained as (lora_adapter/ in the same repository) so you can merge it at any precision or continue training from it, and the f16 merged weights (f16 is the merged fine-tune at full precision: the reference build, for evaluation or for producing your own quantisations.). Ready-to-run Ollama Modelfiles ship next to every build: correct chat template, stop tokens, num_ctx 8192 — the sequence length this model was fine-tuned at — and the system prompt.

Read this first: tool calling was trained and evaluated for this line and then dropped as a product decision. This build is published and supported as a chat-only model. This family is in fact the one that did learn the skill (tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, collapsing to 0.642 at Q4_K_M) while stcoder-qwen25-7b and stcoder-qwen25-14b scored 0.02-0.06 and stcoder-gemma4-12b scored 0.00. Because it was not usable across the line it is not part of this release and is not supported here. If you have not already decided, take stcoder-qwen25-7b at Q6_K (5.82 GiB). That is the line default: 5.8 s per answer, the smallest files, 100% delivery, and the best ChrF at full delivery in this study (38.5 over 15 of 15), with composite within noise of everything else. Pick stcoder-qwen35-9b instead only if you specifically want the reasoning family and can pay for it in latency. On the minimal-prompt condition it scored R24 100.0 with an empty violation table on every delivered reply, 93.3% clean, and composite 0.845 over its 14 delivered replies (0.835 if the missing reply is counted as zero, which puts it behind the 7B's 0.844 and the 14B's 0.842). Its ChrF is 40.9 over those 14 delivered replies — the highest delivered-only figure in the set — but 38.2 over all 15, below the 7B's 38.5; the lead exists only after excluding its own empty reply, so quote the denominator whenever you quote the number. Every reply carries a hidden thinking block (100% of replies in all four arms), averaging 1227 output tokens and 17.2 s per answer at the minimal prompt against 340 tokens and 5.8 s for the 7B. It is the slowest of the four per answer; the 14B is the slowest per token (about 50 tok/s). Accept also that it was the only fine-tune in the study that ever returned no code at all (14 of 15 at the minimal prompt, 15 of 15 with the full rule book).

1. Install Ollama

   Any recent release. Verify it responds before continuing.

   ollama --version

2. Download one GGUF file

   Q6_K is the recommendation for 12 GB and up; Q4_K_M for 8 GB; Q8_0 is the quant the published study numbers were measured on. You need one file only. The "-tc" in the filename is a build-pipeline tag, not a tool-calling build - these are chat-only.

   hf download Mikrodev/stcoder-qwen35-9b-gguf qwen35_9b-tc.q6_k.gguf --local-dir .

3. Write a Modelfile next to the GGUF

   Context window matters more for this model than for its siblings because it reasons before it answers. 8192 is the budget used in the study; 16384 removes the empty-reply risk. Greedy decoding (temperature 0) is what was measured.

   cat > Modelfile <<'EOF'
   FROM ./qwen35_9b-tc.q6_k.gguf
   PARAMETER num_ctx 8192
   # the published numbers were measured with num_ctx 16384 / num_predict 8192
   # this family reasons before answering and the thinking is drawn from the same budget, so do not set num_predict lower
   PARAMETER num_predict 8192
   PARAMETER temperature 0
   PARAMETER top_p 1
   SYSTEM """You are a PLC programming assistant for the Mikrodev LogicStudio IDE. You write IEC 61131-3 Structured Text in the Mikrodev dialect: no POU wrappers, no TIME literals (use INT milliseconds), positional function-block calls only, no OOP, no pointers, no global or retained variables, no STRING types, no hex literals, no cast or selection functions. Declare variables in VAR / VAR_INPUT / VAR_OUTPUT / VAR CONSTANT blocks and use (* *) or // comments."""
   EOF

4. Create the model in Ollama

   Takes a few seconds; the GGUF is copied into the Ollama store.

   ollama create stcoder-qwen35-9b:q6 -f Modelfile

5. Ask it for something small

   The first reply includes a hidden reasoning pass, so expect a pause of several seconds before code appears. That is normal for this model and is why it averaged 17.2 s per answer in the study.

   ollama run stcoder-qwen35-9b:q6 "Chiller circulation pump has to keep running 45 seconds after the compressor stops. E-stop drops both at once. Give me the ST."

6. Reproduce the published numbers, if you want to

   The 240-generation head-to-head used these exact tags. The base arms ran at the Ollama library default, whose quantisation was not recorded in the run data.

   # fine-tunes: stcoder_qwen35-9b:q8  stcoder_qwen25-7b:q8  stcoder_qwen25-14b:q6  stcoder_gemma4-12b:q6
   # bases:      qwen3.5:9b            qwen2.5-coder:7b      qwen2.5-coder:14b      gemma4:12b

7. Paste into LogicStudio and compile

   Always compile before deployment. The scoring behind this release checks dialect compliance, not whether the logic is correct - and this model's replies also need a check for doubled comment delimiters, which the scorer does not catch.

These are ordinary single-purpose requests, the kind this model handles well. Type them as they are.

The same 15 requests were sent to the stock base model (qwen3.5:9b) and to this fine-tune, twice: once with a short realistic system prompt that lists no dialect rules, and once with the entire rule book pasted in. Greedy decoding, fixed seed, identical prompts.

On throughput: the fine-tune is served here at higher precision than the stock base model (Ollama's default build is more heavily compressed), so it generates more slowly per token. Quantisation was not matched in this comparison — see the limitations.

Counted over replies that actually contained code. The upper bar is the realistic condition; the lower, lighter bar is with the full rule book in the system prompt — the difference shows which habits an instruction can fix and which it cannot.

For comparison, this fine-tune's violations across its 14 delivered replies in the same condition: none.

Highlighted tokens are the ones that decide whether the code is accepted by the IDE. Both columns are verbatim model output.

Here is the Structured Text solution designed for Mikrodev LogicStudio (IEC 61131-3). 

This approach uses a **Type Definition** to encapsulate machine data, an **Array of Structures** to handle all three machines simultaneously in loops, and global variables to manage state persistence across scan cycles.

```st
(* 
   Project: Packaging Machine Monitoring System
   Description: Monitors 3 identical packaging machines using arrays for scalability.
               Handles Temperature deviation, Belt Speed, Cycle Counting, and EStop logic.
*)

TYPE T_MachineData :
    (* Configuration *)
    SetpointTemp     : REAL;      // Target temperature (e.g., in Celsius)
    ActualTemp       : REAL;      // Current sensor reading
    
    (* Process Parameters *)
    BeltSpeed        : REAL;      // Speed of the belt (e.g., m/s or RPM)
    
    (* Status & Control *)
    IsRunning        : BOOL;      // True if machine is in active running state
    CycleCounter     : INT := 0;  // Counts completed cycles
    
    (* Faulting State *)
    MachineFaulted   : BOOL;      // Indicates current fault status for this specific machine
END_TYPE

(* Global Variables - Persist across scan cycles *)
VAR_GLOBAL
    Machines         : ARRAY[1..3] OF T_MachineData; 
    PrevCycleDone    : ARRAY[1..3] OF BOOL := (FALSE, FALSE, FALSE); // For rising edge detection
    
    (* External Inputs/Outputs *)
    EStopInput       : BOOL;      // Emergency Stop Input from hardware/controller
    TotalFaultCount 

```iecst
(* Machine monitoring for 3 identical packaging machines *)
(* Each machine has the same structure and logic applied via array *)

TYPE MACHINE :
  nState : INT := 0;          (* 0=STOPPED, 1=RUNNING, 2=FAULTED *)
  rTempSetpoint : REAL;
  rTempActual : REAL;
  rBeltSpeed : REAL;
  nCycleCount : DINT;
  bEStop : BOOL;
  bFaulted : BOOL;
END_TYPE

VAR_INPUT
  arrTempSetpoint : ARRAY[0..2] OF REAL;
  arrTempActual : ARRAY[0..2] OF REAL;
  arrBeltSpeed : ARRAY[0..2] OF REAL;
  arrCycleDone : ARRAY[0..2] OF BOOL;
  bEStop : BOOL;
END_VAR

VAR_OUTPUT
  arrMachine : ARRAY[0..2] OF MACHINE;
  nFaultedCount : INT;
END_VAR

VAR
  i : INT;
  rCycleDoneEdge : R_TRIG;
END_VAR

(* Initialize machines *)
FOR i := 0 TO 2 DO
  arrMachine[i].nState := 0;
  arrMachine[i].nCycleCount := 0;
  arrMachine[i].bFaulted := FALSE;
END_FOR;

(* Process each machine with identical logic *)
FOR i := 0 TO 2 DO
  arrMachine[i].rTempSetpoint := arrTempSetpoint[i];
  arrMachine[i].rTempActual := arrTempActual[i];
  arrMachine[i].rBeltSpeed := arrBeltSpeed[i];
  
  (* Temperature deviation fault *)
  IF arrMachine[i].nState = 1 THEN
    IF (arrMachine[i].rTempActual - arrMachine[i].rTempSetpoint) > 5.0
       OR (arrMachine[i].rTempSetpoint - arrMachine[i].rTempActual) > 5.0 THEN
      arrMachine[i].bFaulted := TRUE;
      arrMachine[i].nState := 2;
    END_IF;
  END_IF;
  
  (* Belt speed fault *)
  IF arrMachine[i].nState = 1 AND arrMachine[i].rBeltSpeed < 10.0 THEN
    arrMachine[i].bFaulted := TR

Here is a reusable **Pump Control Function Block** written in Structured Text (ST), compatible with the Mikrodev LogicStudio IDE environment following IEC 61131-3 standards.

### PumpControl FB Definition

This block encapsulates all logic, timers, and fault handling into one instance per pump. It handles start delays, dry-run protection windows, overload latching, restart lockouts, and HMI reporting.

```st
FUNCTION_BLOCK PumpControl :
VAR_INPUT
    RunRequest   : BOOL;      // Operator request to run the pump (e.g., from level switch)
    OverloadIn   : BOOL;      // TRUE = Thermal Overload Relay Tripped / Fault Active
    DryRunSwitch : BOOL;      // TRUE = Low Suction Pressure Detected (Dry-run condition)
    ResetButton  : BOOL;      // Momentary or Level signal to clear fault latch and reset timers
END_VAR

VAR_OUTPUT
    MotorCmd     : BOOL;      // Output command for the motor starter/drive
    FaultFlag    : BOOL;      // General alarm flag for HMI (TRUE if any active fault)
    FaultCode    : INT;       // Specific code: 0=OK, 1=Overload, 2=Dry Run
END_VAR

VAR
    StartDelayTimer   : TON;     // Handles the 2s start delay after request
    SpinUpTimer       : TON;     // Waits for motor to stabilize (5s) before checking dry-run
    CooldownTimer     : TON;     // Enforces 10s restart lockout after pump stops
    
    MotorRunning      : BOOL := FALSE; // Internal flag to track if we are currently running
END_VAR

// --- Logic Implementation ---

// 1. Reset Fault L

```iecst
(* (*
  Reusable booster pump control block.
  Instantiate once per pump to avoid copy-paste.
*) *)
VAR_INPUT
    bRunReq       : BOOL;   (* (* Operator run request *) *)
    bOverload     : BOOL;   (* (* Motor thermal overload contact *) *)
    bDryRun       : BOOL;   (* (* Low suction / dry-run switch *) *)
    bFaultReset   : BOOL;   (* (* Fault reset button *) *)
    bStartPulse   : BOOL;   (* (* Start pulse for 2s delay *) *)
    bStopPulse    : BOOL;   (* (* Stop pulse for 10s off time *) *)
END_VAR
VAR_OUTPUT
    bMotorRun     : BOOL;   (* (* Motor run command *) *)
    bFault        : BOOL;   (* (* Latched fault flag *) *)
    nFaultCode    : INT;    (* (* Fault code for HMI *) *)
END_VAR
VAR
    tStartDelay   : TON;   (* (* 2s start delay *) *)
    tDryRunDelay  : TON;   (* (* 5s dry-run evaluation delay *) *)
    tOffDelay     : TON;   (* (* 10s minimum off time *) *)
    bStartDone    : BOOL;  (* (* Start delay elapsed *) *)
    bDryRunEval   : BOOL;  (* (* Dry-run evaluation ready *) *)
    bFaultLatched : BOOL;  (* (* Latched fault *) *)
END_VAR
VAR CONSTANT
    START_DELAY_MS : INT := 2000;
    DRYRUN_DELAY_MS: INT := 5000;
    OFF_DELAY_MS   : INT := 10000;
END_VAR

(* (* Start delay *) *)
tStartDelay(bStartPulse, START_DELAY_MS);
bStartDone := tStartDelay.Q;

(* (* Dry-run evaluation delay *) *)
tDryRunDelay(bMotorRun, DRYRUN_DELAY_MS);
bDryRunEval := tDryRunDelay.Q;

(* (* Off delay *) *)
tOffDelay(NOT bMotorRun, OFF_DELAY_MS);

(* (* Fault logic *) 

(* Drilling Station Cycle Logic *)
VAR
    (* Inputs *)
    bGuardClosed : BOOL;
    bPartPresent : BOOL;
    btnStart : BOOL;
    swDownLimit : BOOL;
    swUpLimit : BOOL;
    btnEStop : BOOL;
    alrDrillOverload : BOOL;

    (* Outputs *)
    clmClampClosed : BOOL;
    mtrFeedMotor : BOOL;
    mtrRetractMotor : BOOL;
    vlvOpenClamp : BOOL;
    
    (* Timers - clamp pressure build, dwell at depth, open clamp delay *)
    tClampPressure : TON;
    tDwellAtDepth : TON;
    tOpenClampDelay : TON;

    (* State machine for step sequencing *)
    eState : (IDLE, CLAMPING, DRILLING, DWELL, RETRACTING, OPEN_CLAMP);
    
    (* Fault state flag *)
    bFaultActive : BOOL;
END_VAR

(* Safety check: E-stop or overload drops all outputs and sets fault *)
IF btnEStop OR alrDrillOverload THEN
    clmClampClosed := FALSE;
    mtrFeedMotor := FALSE;
    mtrRetractMotor := FALSE;
    vlvOpenClamp := TRUE;  (* Open clamp for safety *)
    bFaultActive := TRUE;
END_IF

(* Reset fault when reset button pressed and no active faults *)
IF btnReset AND NOT (btnEStop OR alrDrillOverload) THEN
    bFaultActive := FALSE;
    clmClampClosed := FALSE;  (* Ensure clamp is open during reset *)
    mtrFeedMotor := FALSE;
    mtrRetractMotor := FALSE;
END_IF

(* Only allow cycle to start if guard closed, part present, no fault, and not already running *)
IF NOT bFaultActive AND btnStart THEN
    CASE eState OF
        IDLE:
            (* Start clamp closing sequence *)
            tClampPressure(IN :

```iecst
(* Drilling station cycle with clamp, drill, feed, dwell, retract, and clamp-open sequence *)
(* Safety: E-stop or overload forces fault state; reset button clears fault *)

VAR_INPUT
    bGuardClosed : BOOL;
    bPartPresent : BOOL;
    bStartCycle  : BOOL;
    bEStop       : BOOL;
    bResetBtn    : BOOL;
    bDrillOverload : BOOL;
    bClampClosed : BOOL;
    bDownLimit   : BOOL;
    bUpLimit     : BOOL;
END_VAR
VAR_OUTPUT
    bClampMotor   : BOOL;
    bDrillMotor   : BOOL;
    bFeedMotor    : BOOL;
    bClampOpen    : BOOL;
    bStationFault : BOOL;
    nPartsDone    : INT;
END_VAR
VAR
    nState : INT := 0;
    tClamp : TON;
    tDwell : TON;
    bFault : BOOL;
END_VAR
VAR CONSTANT
    CLAMP_BUILD_MS : INT := 1500;
    DWELL_MS       : INT := 3000;
    CLAMP_OPEN_MS  : INT := 800;
END_VAR

(* Safety interlocks *)
IF bEStop OR bDrillOverload THEN
    bStationFault := TRUE;
    bClampMotor := FALSE;
    bDrillMotor := FALSE;
    bFeedMotor := FALSE;
    bClampOpen := FALSE;
    nState := 0;
    RETURN;
END_IF;

CASE nState OF
    0: (* Idle *)
        bClampMotor := FALSE;
        bDrillMotor := FALSE;
        bFeedMotor := FALSE;
        bClampOpen := FALSE;
        IF bGuardClosed AND bPartPresent AND bStartCycle THEN
            nState := 1;
        END_IF;

    1: (* Clamp close *)
        bClampMotor := TRUE;
        tClamp(TRUE, CLAMP_BUILD_MS);
        IF tClamp.Q THEN
            bClampMotor := FALSE;
            nState := 2;
        END_IF;

    2: (* Dri

All 15 prompts, realistic condition (no rules in the system prompt). Prompt text is in the appendix below.

Quantisation compresses the weights: Q8_0 keeps roughly 8 bits per weight, Q6_K about 6, Q4_K_M about 4. Smaller file, less VRAM, slightly noisier arithmetic. All sizes here are GiB as reported by the build tooling: 9.11 GiB (Q8_0), 7.04 GiB (Q6_K), 5.38 GiB (Q4_K_M). A note on the filenames: the "-tc" in qwen35_9b-tc.*.gguf is a build-pipeline tag left over from the tool-call training stage. It does not mark a tool-calling build. These files are published and supported as chat-only, as described above. On the code task the quant spread is small. An earlier internal 2000-prompt evaluation of these same fine-tunes measured code composite 0.836 (Q8_0), 0.832 (Q6_K) and 0.828 (Q4_K_M), with ChrF 47.4 / 46.0 / 44.5 - roughly 0.008 of composite across the whole range, far less than the difference between prompting styles. That evaluation's code holdout overlapped the training distribution by about 84%, so those absolute code scores are inflated and weakly discriminative between models. They are quoted here only to compare quantisations within this one model, and must not be used to rank the four models against each other. The large Q4 penalty reported earlier for this family was measured on the tool-calling task, where low precision damaged structured argument emission (0.816 at Q8_0 down to 0.642 at Q4_K_M). Tool calling has been dropped from this line as a product decision, so for a chat-only deployment the quantisation choice is a memory decision, not an accuracy decision. Methodology, stated the same way in all four cards. The R24 and clean figures here are computed over the whole reply. Base replies were prose-wrapped 66.7-100% of the time and fine-tune replies 0-20%, so whole-reply scoring flatters the fine-tunes; scoring only the fenced code moves the pooled base clean rate from 6.7% to 10.0%. For this model's own base arm the two variants agree exactly (6.7% minimal, 26.7% full under both), and the base-to-fine-tune gap is not sensitive to the choice - but the variant is named for the record. Reproducibility. The head-to-head ran Ollama tags stcoder_qwen35-9b:q8 against base qwen3.5:9b; the siblings were stcoder_qwen25-7b:q8 / qwen2.5-coder:7b, stcoder_qwen25-14b:q6 / qwen2.5-coder:14b, and stcoder_gemma4-12b:q6 / gemma4:12b. The run data records no quantisation at all for the base arms, so "effectively Q4" is an inference from the Ollama library default, not a recorded value. The comparison is therefore not precision-matched.

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.
• Uses the standard blocks the dialect allows - RS, R_TRIG, TON - and the body-only VAR_INPUT / VAR_OUTPUT / VAR CONSTANT shape, with no PROGRAM or FUNCTION_BLOCK wrapper in any reply.
• With the full rule book in the prompt it became cheaper and more dependable to run: 15/15 delivered, 100% clean, 554 tokens and 9.0 s per answer against 1227 tokens and 17.2 s at the minimal prompt. One trade-off to know before you adopt that condition: doubled comment delimiters rose from 2 of 15 replies at the minimal prompt to 6 of 15 with the full rule book, so the full condition is more reliable to obtain and slightly more work to clean.

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.
• ChrF is modest in absolute terms - 40.9 over its 14 delivered minimal-prompt replies, 38.2 across all 15 - and one row fell to 23.58 (the reusable scaling helper). The structure is right; naming, decomposition and interface choices often differ from what a plant engineer would have written.
• Slowest of the four per answer at the minimal prompt (17.2 s, 1227 tokens against 5.8 s / 340 tokens for the 7B). Per token it is mid-field at 86.3 tok/s - the slowest per token is the 14B at about 50 tok/s. Its 86.3 tok/s against the base's 123.2 is not a precision-matched comparison: the fine-tune ran at Q8_0 while the base ran at the Ollama library default, whose quantisation the run data does not record. Total wall-clock still favours the fine-tune by about three times.
• At 9.11 GiB the Q8_0 file - the quant all published head-to-head numbers were measured on - does not fit an 8 GB card alongside a usable context.

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.
• Frontier-scale work - whole-project architecture, safety analysis, or reasoning over long documents. This is a 9B model for local hardware.
• Retained or global data. VAR RETAIN, VAR_GLOBAL and VAR_EXTERNAL are forbidden in the dialect, so the model will not solve persistence for you even when the prompt asks for it - that belongs on the IDE side.

240 controlled generations across four model families, 15 prompts each, run twice per model under two prompting conditions. Greedy decoding (temperature 0, seed 42), 8,192-token budget, local Ollama on an RTX 5080 (16 GB).

• R24 — dialect rule compliance. 33 forbidden patterns, individually weighted; the score is the share of total weight left intact (0–100). Comments, prose and string contents are removed before matching, so discussion never triggers a rule.
• ChrF — character n-gram F-score of the generated code against a hand-written reference solution (sacreBLEU chrF++). Higher means closer to house style. An alternative but correct solution legitimately scores lower, so it is always read together with R24.
• Clean — the reply delivered code and broke no rule. A reply containing no code scores R24 = 100 trivially, because there is nothing left to violate, so delivery is checked first.
• Which R24 variant. The R24 and clean figures on this page are computed over the whole reply. That matters because base replies were prose-wrapped 80.0% of the time for this model: scoring only the fenced code lifts the pooled base clean rate across the study from 6.7% to 10.0%. The base-versus-fine-tune gap is not sensitive to the choice, but the variant is named here so the numbers can be reproduced exactly.
• Test prompts — written as ordinary plant requests. No prompt mentions any dialect rule; a prompt that said “use milliseconds” would hand the answer to the base model. Reference solutions were verified rule-clean before use.

stcoder-qwen35-9b removes the dialect problem for this base: R24 100.0 with an empty violation table on every delivered reply, no POU wrappers, no TIME literals, no named function-block parameters, and code that lands close to the hand-written reference (ChrF 40.9 over its 14 delivered minimal-prompt replies, 38.2 over all 15). It also cut its base's runaway reasoning from 6345 tokens to 1227 and its answer time from 54.5 s to 17.2 s. What it does not do is guarantee an answer - one reply in fifteen reasoned until the budget ran out and returned nothing - nor guarantee working logic, since three clean replies in this study contained real defects and doubled comment delimiters appeared in 2 of 15 minimal and 6 of 15 full-condition replies. It is chat-only: tool calling was trained, measured, and then dropped from this line as a product decision. If you have not already chosen, start with the line default, stcoder-qwen25-7b at Q6_K, and come here for the reasoning family. Either way, keep the context at 8192 or more, treat the output as a fast first draft in the right dialect, and compile everything in LogicStudio before it goes near a machine.