stcoder-gemma4-12b

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 product line, but it was not usable across the line, so it was dropped as a product decision: stcoder-gemma4-12b is published and supported as a chat-only model. Measured tool-call composite was 0.816 for the Qwen3.5-9B family at Q8_0 (0.805 at Q6_K, 0.642 at Q4_K_M), 0.02-0.06 for the code-focused Qwen2.5-Coder builds, and exactly 0.00 for this Gemma family. This is the only STCoder build on Google Gemma rather than Qwen, which makes it useful as an architecturally independent cross-check: when two different lineages produce the same block, you have some evidence the request was unambiguous. That is the reason to pick it, and it is the only one supported by the data. Head-to-head figures from this study (minimal system prompt, 15 prompts per model, greedy decoding at seed 42; ChrF averaged over DELIVERED replies so the denominator is identical across models): model clean delivery ChrF composite out-tok wall stcoder-qwen25-7b 93.3% 100% (15/15) 38.5 0.844 340 5.8 s stcoder-qwen25-14b 100.0% 100% (15/15) 34.9 0.842 288 8.6 s stcoder-qwen35-9b 93.3% 93.3% (14/15) 40.9 0.845 1227 17.2 s stcoder-gemma4-12b 86.7% 100% (15/15) 35.9 0.830 401 8.5 s So its 86.7% clean (13 of 15) is the lowest of the four, and its composite 0.830 is the lowest. Its ChrF is NOT the lowest in this study: 35.9 is above the 14B's 34.9. It is the lowest of the four only in the earlier 2000-prompt evaluation (38-41 there, against 47-52 for the Qwen-based siblings), and those absolute code scores must not be used to rank models against each other: that evaluation's code holdout overlapped the training distribution by about 84%, so its code figures are inflated and weakly discriminative between models. They are cited in this card only for the within-model quant comparison. Two disclosures that bound every base-versus-fine-tune claim below. First, quantisation was not controlled in the head-to-head: the fine-tune ran at Q6_K (Ollama tag stcoder_gemma4-12b:q6) while the stock base ran the Ollama library default (base tag gemma4:12b). The run data records no quantisation for the base arms, so "effectively Q4" is an inference from the library default, not a recorded value. Second, R24 and clean rates quoted here are computed over the WHOLE reply. Base replies were prose-wrapped 66.7-100% of the time while fine-tune replies were 0-20.0%, so whole-reply scoring flatters the fine-tune; scoring only the fenced code moves the pooled base clean rate from 6.7% to 10.0%, and this model's own base figure from 6.7% (1 of 15) to 20.0% (3 of 15). The gap survives either variant, but the variant has to be named. This is also the one model where prompting alone nearly closes the gap, and in one respect closes it. Given the whole rule book in the system prompt, the stock base is 73.3% clean (11 of 15) against this fine-tune's 80.0% (12 of 15) - roughly level - and the base's mean R24 in that condition is actually HIGHER than the fine-tune's: 99.80 pooled over all 15 rows, 99.75 over its 12 delivered replies, against the fine-tune's 99.41. The fine-tune still wins the full condition on delivery (15 of 15 against 12 of 15) and on ChrF (32.9 against 24.9 over delivered replies), but if you are willing to paste a long rule preamble every session, the fine-tune buys you much less on this lineage than it does on the other three. Which one should I download. Default: stcoder-qwen25-7b at Q6_K (5.82 GiB). It is the fastest per answer (5.8 s), the smallest, joint-top on composite (0.844), and highest on ChrF at full delivery (38.5 over 15 of 15). Choose stcoder-qwen25-14b at Q4_K_M (8.37 GiB) on 16 GiB or more if you want the one model that was 100% rule-clean and 0% prose in both conditions, accepting the lowest head-to-head ChrF (34.9) and the slowest generation per token (about 50 tok/s). Choose stcoder-qwen35-9b only if you want the reasoning family, accepting one empty reply in fifteen and the slowest wall time per answer (17.2 s). Choose stcoder-gemma4-12b only for non-Qwen lineage diversity, or because you already run Gemma locally, with the caveats above.

1. Install Ollama

   Any recent release. Confirm it is running before continuing.

   ollama --version

2. Download one GGUF file

   Q4_K_M (6.87 GiB) is the recommended default. Use Q6_K (9.11 GiB) on a 16 GiB card if you want the exact build used in the evaluation. Q8_0 is 11.8 GiB and needs more than 16 GiB.

   hf download Mikrodev/stcoder-gemma4-12b-gguf gemma4_12b-tc.q4_k_m.gguf --local-dir .

3. Write a Modelfile next to the GGUF

   Deterministic decoding and a short system prompt. For this model a short prompt is the better default: pasting the whole rule book lowered its clean rate from 86.7% to 80.0% and its ChrF from 35.9 to 32.9.

   cat > Modelfile <<'EOF'
   FROM ./gemma4_12b-tc.q4_k_m.gguf
   PARAMETER temperature 0
   PARAMETER top_p 1
   PARAMETER num_ctx 8192
   # the published numbers were measured with num_ctx 16384 / num_predict 8192
   # num_predict 2048 is a practical local default (longest reply in the study: 708 tokens); raise it to 8192 to reproduce them or if a long block truncates
   PARAMETER num_predict 2048
   SYSTEM """You write IEC 61131-3 Structured Text for the Mikrodev LogicStudio IDE. Reply with the code body only: variable blocks plus logic, no POU wrapper. Timer presets are INT milliseconds. Function blocks are called positionally."""
   EOF

4. Create the Ollama model

   One-off import. Takes a minute or two depending on disk speed. This is a chat-only model; do not attach tool definitions to it.

   ollama create stcoder-gemma4-12b:q4 -f Modelfile

5. Smoke-test it

   You should get a short reply that is mostly one code block: VAR blocks, a TON called positionally, and a millisecond preset. No PROGRAM or FUNCTION_BLOCK line, no T#5s.

   ollama run stcoder-gemma4-12b:q4 "Grain dryer discharge auger. Start button sounds a siren for 8 seconds, then the auger runs and the siren stops. Stop or any fault drops both immediately."

6. Reproduce the study numbers (optional)

   The head-to-head in this card used these exact Ollama tags. Fine-tunes: stcoder_qwen25-7b:q8, stcoder_qwen25-14b:q6, stcoder_qwen35-9b:q8, stcoder_gemma4-12b:q6. Bases: qwen2.5-coder:7b, qwen2.5-coder:14b, qwen3.5:9b, gemma4:12b. The base arms' quantisation was NOT recorded in the run data, so the Ollama library default (effectively Q4) is an inference, not a measurement - quantisation was not controlled across the base and fine-tune arms. The study's q6 build is a different file from the q4 default recommended above, so edit the Modelfile's FROM line to the q6 GGUF before running ollama create.

   # the Modelfile written in step 3 points at the q4 file - repoint it before creating the q6 tag
   hf download Mikrodev/stcoder-gemma4-12b-gguf gemma4_12b-tc.q6_k.gguf --local-dir .
   #   edit Modelfile:  FROM ./gemma4_12b-tc.q6_k.gguf
   ollama create stcoder_gemma4-12b:q6 -f Modelfile
   ollama pull gemma4:12b                             # base arm, library default quant

7. Compile before you deploy

   Paste the block into LogicStudio and compile it. This is not optional. The rule checker used in the evaluation is reference-free and pattern-based, and in this model's own test rows it passed code that would not compile, including a FOR loop whose index variable was never declared.

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

• Keep the system prompt short. This is the one model in the line where the full rule book hurts: clean drops from 86.7% to 80.0%, ChrF from 35.9 to 32.9, and mean output more than doubles to 921 tokens while the median stays at 354. The rules are in the weights; leave them out of the prompt.
• Run it greedy. temperature 0, top_p 1. Every figure quoted here comes from greedy decoding at seed 42, and sampling will move them.
• Treat it as chat-only. Tool calling was dropped as a product decision for this line and this family measured 0.00 on the tool-call metric, so do not attach tool definitions and do not expect tool syntax back.
• Write the request the way you would describe it to a colleague: the plant, the signals, the timings in seconds, what has to drop out immediately. All 15 study prompts were written that way and none mentioned a dialect rule.
• State your wiring conventions. On the study's seal-in prompt it treated the stop button as TRUE-when-pressed although the prompt said NC, so say "NC stop, TRUE means healthy" if that is your convention.
• If a manual gives you hex masks, convert them yourself or say "decimal constants only, no 16# literals". This is its most repeatable rule failure, and it persisted in both prompt conditions.
• Same for conversions: if the answer needs an integer for the HMI, add "no conversion functions, assign between REAL and INT directly", because this is where it reached for REAL_TO_INT - on two different scaling prompts in the full condition.
• Check the variable blocks before you check the logic. Its replies sometimes put an input in a plain VAR block, omit an output you asked for, use an index variable it never declared, or attach a RETAIN qualifier the dialect forbids.
• Check every timer's arming expression. Rule compliance says nothing about whether the timer resets when you expect. Look for timers driven from their own Q output, and for run requests that are not sealed in.
• For counters, ask explicitly for edge detection on the input signal. Left to itself it tested the level of the photo eye, which increments once per scan.
• If a reply starts repeating declarations or runs much longer than usual, stop it and re-ask with a shorter system prompt. In this study one full-condition reply ran to the 8192-token limit as a wall of repeated BOOL declarations - and still scored R24 100.
• Compile in LogicStudio before anything reaches a panel, and treat R24-clean as a style check only. It is reference-free and pattern-based; it will pass code that does not build.
• If you have not committed to the Gemma lineage, the line's default is stcoder-qwen25-7b at Q6_K (5.82 GiB) and it is the better first download.

The same 15 requests were sent to the stock base model (gemma4:12b) 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 15 delivered replies in the same condition: no_based_literal×1, no_cast_function×1.

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

To solve this problem efficiently in Mikrodev LogicStudio, we will create a **Function Block (FB)**. This allows you to define the logic once and then "instantiate" it three times in your main program, each with its own set of inputs and outputs.

### 1. The Function Block: `FB_PumpControl`

Create a new Function Block named `FB_PumpControl`. This block handles all the timing, fault logic, and state management for a single pump.

**Variables (Declaration):**
```pascal
FUNCTION_BLOCK FB_PumpControl
VAR_INPUT
    xRunRequest : BOOL;      // Request from HMI/PLC to run
    xOverload   : BOOL;      // Physical input from motor overload relay
    xDryRun     : BOOL;      // Input from dry-run sensor
    xReset      : BOOL;      // Reset button for faults
END_VAR
VAR_OUTPUT
    xMotorRun   : BOOL;      // Command to the motor contactor
    xFault      : BOOL;      // Fault status for HMI
    iFaultCode  : INT;       // 0=OK, 1=Overload, 2=Dry Run
END_VAR
VAR
    timerStart     : TON;    // Handles the 2s start delay
    timerDryRun    : TON;    // Tracks the 5s grace period for dry run
    timerStopLock  : TON;    // Handles the 10s "off" timer
END_VAR
```

**Implementation (Structured Text):**
```pascal
(* --- Fault Logic --- *)
(* Overload takes priority. If it exists, code is 1. *)
IF xOverload THEN
    iFaultCode := 1;
ELSIF xDryRun AND timerDryRun.Q THEN
    (* Dry run only triggers if the motor has been running for > 5s *)
    iFaultCode := 2;
ELSE
    iFaultCode := 0;
END_IF

Here is the reusable `PumpControl` block.

```iecst
VAR_INPUT
    runReq      : BOOL;
    motorOver   : BOOL;
    dryRun      : BOOL;
    faultReset  : BOOL;
END_VAR
VAR_OUTPUT
    motorRun    : BOOL;
    faultFlag   : BOOL;
    faultCode   : INT;
END_VAR
VAR
    startDelay  : TON;
    dryRunDelay  : TON;
    stopDelay   : TON;
    latched     : BOOL;
    faultLatched: BOOL;
END_VAR
VAR CONSTANT
    START_MS    : INT := 2000;
    DRYRUN_MS   : INT := 5000;
    STOP_MS     : INT := 10000;
END_VAR

// 1. Fault detection and latching
IF motorOver OR (motorRun AND dryRun) THEN
    faultLatched := TRUE;
    faultCode := 0;
    IF motorOver THEN faultCode := 1; END_IF;
    IF (motorRun AND dryRun) THEN faultCode := 2; END_IF;
END_IF;

// 2. Fault reset
IF faultReset AND NOT motorOver AND NOT (motorRun AND dryRun) THEN
    faultLatched := FALSE;
END_IF;

faultFlag := faultLatched;

// 3. Start/Stop logic
IF faultLatched THEN
    motorRun := FALSE;
ELSE
    // Start delay: 2s after runReq
    startDelay(runReq, START_MS);
    
    // Stop delay: 10s after runReq goes FALSE
    stopDelay(NOT runReq, STOP_MS);
    
    // Motor run command
    IF startDelay.Q AND NOT stopDelay.Q THEN
        motorRun := TRUE;
    ELSE
        motorRun := FALSE;
    END_IF;
END_IF;

// 4. Dry-run evaluation: only 5s after motorRun is TRUE
IF motorRun THEN
    dryRunDelay(TRUE, DRYRUN_MS);
    IF dryRunDelay.Q AND dryRun THEN
        faultLatched := TRUE;
        faultCode := 2;
    END_IF;
ELSE
    dryR

To implement this in Mikrodev LogicStudio, I have structured the program using a **State Machine** (using a `CASE` statement). This is the industry-standard way to handle sequential processes like drilling cycles because it ensures that only one step happens at a time and makes debugging much easier.

Here is the complete Structured Text (ST) code.

### Variable Declarations
You should define these variables in your Global Variable List (GVL) or the local variable area of your program:

```pascal
VAR
    (* Inputs *)
    i_GuardClosed   : BOOL;    // Physical sensor for safety gate
    i_PartPresent    : BOOL;    // Sensor detecting a part
    i_StartBtn       : BOOL;    // Operator Start button (Momentary)
    i_DownLimit      : BOOL;    // Limit switch at bottom of stroke
    i_UpLimit        : BOOL;    // Limit switch at top of stroke
    i_EStop           : BOOL;    // E-Stop Button (Normally Closed - Logic High = OK)
    i_Overload       : BOOL;    // Drill Motor Overload sensor
    i_Reset           : BOOL;    // Manual Reset button

    (* Outputs *)
    q_Clamp          : BOOL;    // Solenoid to close/hold clamp
    q_DrillMotor     : BOOL;    // Main drill motor
    q_FeedDown       : BOOL;    // Actuator/Motor for downward movement
    q_StatusLamp     : BOOL;    // Indicator light

    (* Internal Logic *)
    e_State          : INT := 0;      // Current step in the cycle
    e_PartCount      : INT;            // Counter for finished parts
    
    (* Timers *)
   

```iecst
VAR_INPUT
  bStart      : BOOL;
  bGuard      : BOOL;
  bPartPresent: BOOL;
  bDownLimit  : BOOL;
  bUpLimit     : BOOL;
  bDrillOver  : BOOL;
  bReset      : BOOL;
  bEStop      : BOOL;
END_VAR
VAR_OUTPUT
  bClamp      : BOOL;
  bDrill      : BOOL;
  bFeedDown   : BOOL;
  bFeedUp     : BOOL;
  bFault      : BOOL;
  nPartCount  : INT;
END_VAR
VAR
  nStep       : INT;
  tClamp      : TON;
  tDrill      : TON;
  tDepth      : TON;
  tClampOpen  : TON;
END_VAR

IF bEStop OR bDrillOver THEN
  bClamp := FALSE;
  bDrill := FALSE;
  bFeedDown := FALSE;
  bFeedUp := FALSE;
  bFault := TRUE;
  IF bReset THEN
    bFault := FALSE;
    nStep := 0;
  END_IF;
ELSE
  bFault := FALSE;
  CASE nStep OF
    0: // Idle - wait for start
      IF bStart AND bGuard AND bPartPresent THEN
        bClamp := TRUE;
        nStep := 1;
      END_IF;
    1: // Clamp pressure build (1.5 s)
      tClamp(NOT tClamp.Q, 1500);
      IF tClamp.Q THEN
        bDrill := TRUE;
        bFeedDown := TRUE;
        nStep := 2;
      END_IF;
    2: // Feed down until down limit
      IF bDownLimit THEN
        bFeedDown := FALSE;
        nStep := 3;
      END_IF;
    3: // Dwell at depth (3 s)
      tDrill(NOT tDrill.Q, 3000);
      IF tDrill.Q THEN
        bFeedDown := FALSE;
        bFeedUp := TRUE;
        nStep := 4;
      END_IF;
    4: // Retract until up limit
      IF bUpLimit THEN
        bFeedUp := FALSE;
        nStep := 5;
      END_IF;
    5: // Clamp open (0.8 s)
      bClamp := FALSE;
      tCla

To implement this logic in Mikrodev LogicStudio, we will use an array to handle the rolling average of the current samples, a standard calculation for power, and a `TON` (Timer On Delay) function block to handle the 3-second duration requirement.

Here is the Structured Text code:

```pascal
PROGRAM Heater_Control
VAR
    (* Inputs *)
    I_raw : REAL;            // Current sampled from sensor (Amps)
    Reset_PB : BOOL;         // Physical Reset Pushbutton
    
    (* Internal Processing *)
    I_Buffer : ARRAY[0..7] OF REAL; // Buffer for last 8 samples
    i_Idx : INT := 0;                // Index for the circular buffer
    I_Sum : REAL;                    // Sum of buffer values
    I_Avg : REAL;                    // Averaged current
    
    (* Constants & Calculations *)
    R_Value : REAL := 4.7;           // Resistance in Ohms
    Power : REAL;                    // Calculated Power (Watts)
    
    (* Outputs *)
    Overload : BOOL;                  // Latch bit for over-power condition
    
    (* Timer *)
    Timer_Overload : TON;             // Timer to check 3s duration
END_VAR

***

(* 1. Rolling Average Logic *)
(* Store the current sample in the buffer and increment index *)
I_Buffer[i_Idx] := I_raw;
i_Idx := (i_Idx + 1) MOD 8;

(* Calculate the sum of all samples in the buffer *)
I_Sum := 0.0;
FOR i := 0 TO 7 DO
    I_Sum := I_Sum + I_Buffer[i];
END_FOR;

(* Calculate average current *)
I_Avg := I_Sum / 8.0;

(* 2. Power Calculation *)
(* P = I^2 * R *)
Pow

```iecst
VAR_INPUT
  rCurrentSample : REAL;
  bResetBtn : BOOL;
END_VAR
VAR_OUTPUT
  bOverload : BOOL;
END_VAR
VAR
  rSamples : ARRAY[0..7] OF REAL;
  rAvgCurrent : REAL;
  rPower : REAL;
  rR : REAL := 4.7;
  rOverloadTimer : TON;
  rSampleIdx : INT := 0;
END_VAR

(* 8-sample moving average *)
rSamples[rSampleIdx] := rCurrentSample;
rSampleIdx := rSampleIdx + 1;
IF rSampleIdx >= 8 THEN rSampleIdx := 0; END_IF;

rAvgCurrent := 0.0;
FOR i := 0 TO 7 DO rAvgCurrent := rAvgCurrent + rSamples[i]; END_FOR;
rAvgCurrent := rAvgCurrent / 8.0;

(* Power calculation *)
rPower := rAvgCurrent * rAvgCurrent * rR;

(* Overload detection: 3 seconds above 1500 W *)
rOverloadTimer(rPower > 1500.0, 3000);

(* Latch/Reset logic *)
IF rOverloadTimer.Q THEN
  bOverload := TRUE;
END_IF;

IF bResetBtn THEN
  bOverload := FALSE;
END_IF;
```

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

Quantisation reduces the precision of the stored weights: Q8_0 is closest to the trained values, Q6_K is a middle ground, Q4_K_M is the smallest of the three published builds. All file sizes in this card are GiB as reported by the build tooling. For this model the practical spread is narrow. The earlier internal evaluation, which ran 2000 prompts across all three quants of these same fine-tunes, put the Gemma code composite between 0.800 and 0.810 and ChrF between 38 and 41 across Q4, Q6 and Q8. Dropping from Q8_0 (11.8 GiB) to Q4_K_M (6.87 GiB) therefore costs roughly one hundredth of a composite point on the code task while saving nearly 5 GiB of VRAM. That evaluation has to be read with one caveat, and it is a large one: its code holdout overlapped the training distribution by about 84%, so the absolute code scores are inflated and weakly discriminative between models. They are usable for the within-model quant comparison above - all three quants were scored on the same contaminated holdout, so the comparison between them is still informative - and they must not be used to rank stcoder-gemma4-12b against its siblings. For cross-model figures, use the head-to-head table in this card. One correction worth stating plainly, because an earlier version of the same report showed a much larger Q4 penalty. That penalty was measured on the tool-calling task, not on code, and it belonged to the Qwen3.5-9B family (tool-call composite 0.805 at Q6_K falling to 0.642 at Q4_K_M). This Gemma family scored exactly 0.00 on tool calling at every quant, and tool calling is not part of this release in any case. Structured Text generation is comparatively tolerant of low precision here. Two build-specific notes. The head-to-head study in this card was run at Q6_K, so those clean rates and ChrF figures describe that build. And Q8_0 is 11.8 GiB and has crashed on a 16 GiB card in internal testing, so the practical ceiling on a 16 GiB workstation is Q6_K. Q4_K_M is the recommended default.

Strengths

• Under a minimal system prompt the fine-tune lifts dialect compliance from 6.7% clean (1 of 15) to 86.7% clean (13 of 15) and mean R24 from 92.55 to 99.61, with no rules shown to the model. These are whole-reply figures; on fence-only scoring the base rises to 20.0% (3 of 15) and mean R24 94.71 while the fine-tune is unchanged at 86.7% and 99.61. Quantisation was not controlled: the fine-tune ran Q6_K and the stock base ran the Ollama library default, which is an inference of effectively Q4 rather than a recorded value.
• The habits that break the base model most often disappear. Across the 15 minimal-condition prompts the base broke TIME literals 7 times, named function-block parameters 7 times and POU wrappers 9 times (no_pou_program 6 plus no_pou_fb 3); the fine-tune broke none of the three, leaving one hex literal and one cast function in total. On fence-only scoring the base's TIME-literal and named-parameter counts fall to 4 each, while the 9 POU wrappers stand.
• It always answers. Delivery is 100% (15 of 15) in both fine-tuned arms, and under the full rule book the stock base returned code for only 12 of 15 prompts while the fine-tune returned 15 of 15.
• Output is short and paste-ready. Mean 401 tokens and median 360 against the base's 2490 mean and 2411 median, 8.5 s against 34.7 s per reply on an RTX 5080, no reasoning block at all (0% against the base's 100%), and prose around the code in 20% of replies against the base's 100% (6.7% under the full prompt).
• Different lineage from the other three STCoder models, which makes it usable as an independent second opinion on an ambiguous request rather than a correlated one.
• It respects some rules it was never shown. On the first-out annunciator prompt it avoided STRING types, single-quoted literals and string functions - all forbidden by the dialect - without being told, scoring R24 100 and ChrF 43.7, its highest ChrF outside the timer prompts.
• Quantisation is forgiving on this task: the earlier 2000-prompt evaluation put Q4, Q6 and Q8 of this fine-tune inside a code composite band of 0.800-0.810, so the 6.87 GiB Q4_K_M build is a reasonable default rather than a compromise. That evaluation's code holdout overlapped the training distribution by about 84%, so read the band as a within-model comparison only, never as a cross-model result.

Weaknesses

• Weakest fine-tune clean rate and lowest composite of the four models: 86.7% clean (13 of 15) under a minimal prompt and 80.0% (12 of 15) under the full rule book, against 93.3% for stcoder-qwen25-7b, 100.0% for stcoder-qwen25-14b and 93.3% for stcoder-qwen35-9b; composite 0.830 against 0.844, 0.842 and 0.845. Whole-reply scoring in every case.
• The fine-tuning case is weakest here, and in one respect the base wins. Given the whole rule book in the system prompt, the stock base is 73.3% clean (11 of 15) against this fine-tune's 80.0% (12 of 15), and the base's mean R24 in that condition is higher than the fine-tune's: 99.80 pooled over all 15 rows, 99.75 over its 12 delivered replies, against the fine-tune's 99.41. The fine-tune still wins that condition on delivery (15 of 15 against 12 of 15) and ChrF (32.9 against 24.9 over delivered replies), and quantisation was not controlled between the two arms - but on this lineage a long rule preamble gets a stock Gemma most of the way there.
• Similarity to house style is mid-pack in this study and last in the earlier one, and the two must not be spliced. In this head-to-head its ChrF is 35.9 over 15 of 15 delivered, above stcoder-qwen25-14b (34.9) and below stcoder-qwen25-7b (38.5, also 15 of 15) and stcoder-qwen35-9b (40.9, but over only 14 of 15). In the earlier 2000-prompt evaluation it is the lowest of the four (38-41 against 47-52 for the Qwen-based siblings) - and that evaluation's code holdout overlapped the training distribution by about 84%, so those absolute scores are inflated and weakly discriminative between models and should not be used to rank them.
• Adding the rule book makes it worse, not better: clean falls from 86.7% to 80.0%, ChrF from 35.9 to 32.9, and mean output more than doubles from 401 to 921 tokens while the median stays at 354. One reply is responsible for the whole tail, and it is in THIS study, not earlier testing: full condition, first_out_fault_annunciator, 8192 output tokens, truncated mid-declaration, a wall of bResetDone_2 through bResetDone_673 BOOL declarations. It scored R24 100.0 with no violations, so it is counted INSIDE the 80.0% clean figure - read that figure with this caveat. Its ChrF on that row was 6.29.
• Two rules it still breaks. It keeps hex literals when a manual gives them that way: the VFD status-word prompt produced bReady := (nStatusWord AND 16#0001) <> 0; in both conditions. And it reaches for cast functions in scaling work: the two no_cast_function rows in the full condition are two DIFFERENT prompts, analog_scale_raw_to_bar writing rBar := (REAL(iRawCount) - COUNT_4MA) / (COUNT_20MA - COUNT_4MA) * RANGE_BAR; and analog_scale_helper writing pressureBar := INT(scaled * 10.0); - the same helper prompt without the rule book reached for pressureTenths := REAL_TO_INT(pressureBar * 10.0); so the habit survives both prompt forms.
• The Q8_0 build (11.8 GiB) has crashed on a 16 GiB card in internal testing. Treat Q6_K as the practical ceiling on 16 GiB.
• Rule-clean is not compile-clean, and this model shows it plainly. Its heater reply scored R24 100 while writing FOR i := 0 TO 7 DO with no declaration of i. Its multi-machine reply scored R24 100 with declarations written as tempSet[3] : REAL;, which is not valid array syntax. Its counter reply scored R24 100 while declaring lifetimeCount : DINT RETAIN;, a retain qualifier the dialect forbids and the pattern checker did not catch.
• Logic errors survive rule compliance. The same counter reply comments "increment lifetime total on every rising edge of the photo eye" and then writes IF bPartDetect THEN - the level, not the edge - so it will count once per scan for as long as a case sits in front of the sensor.

Not the right tool for

• Tool calling or function calling of any kind. Tool calling was trained and evaluated for this line, but it was not usable across the line and was dropped as a product decision, so these builds are published and supported as chat-only models. Measured tool-call composite: 0.816 for the Qwen3.5-9B family at Q8_0 (0.805 at Q6_K, 0.642 at Q4_K_M), 0.02-0.06 for the code-focused Qwen2.5-Coder builds, and exactly 0.00 for this Gemma family. If you need an agent that drives IDE tools, do not use these models.
• Anyone who will not compile the output before deployment. In this model's own test rows, R24-clean code included an undeclared loop variable, an invalid array declaration and a forbidden RETAIN qualifier.
• Modbus or fieldbus status-word decoding where the manual quotes hex masks. This is its most repeatable rule failure: it keeps 16#0001 style literals rather than converting them to decimal constants.
• Undecided readers, and anyone choosing on measured quality alone. Take the line's default, stcoder-qwen25-7b at Q6_K (5.82 GiB): in this head-to-head it leads on composite (0.844) and on ChrF at full delivery (38.5 over 15 of 15), and it is the fastest per answer at 5.8 s. If you want the one model that was 100% rule-clean in both conditions, take stcoder-qwen25-14b at Q4_K_M (8.37 GiB), accepting the lowest head-to-head ChrF (34.9) and the slowest generation per token (about 50 tok/s).
• 8 GiB cards. Q4_K_M weights alone are 6.87 GiB, leaving no useful context budget; use stcoder-qwen25-7b at Q6_K (5.82 GiB) instead.
• 16 GiB cards at Q8_0. That build is 11.8 GiB and has crashed on a 16 GiB card.
• Frontier-model work: multi-file architecture, long-horizon reasoning, or anything requiring the model to hold a whole project in mind. This is a 12B model built to run on a workstation.

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

On a short, realistic system prompt this fine-tune turns a stock Gemma-4-12B from 6.7% dialect-clean into 86.7% dialect-clean (1 of 15 to 13 of 15), removes TIME literals, named parameters and POU wrappers entirely, and does it in 401 tokens and 8.5 seconds instead of 2490 tokens and 34.7 seconds. Three caveats travel with that claim, and they apply to every card in this set. Quantisation was not controlled: the fine-tune ran Q6_K while the stock base ran the Ollama library default, an inference of effectively Q4 rather than a recorded value. The R24 and clean figures are computed over the whole reply; scoring only the fenced code lifts this model's base clean rate from 6.7% to 20.0% and the pooled base rate from 6.7% to 10.0%, without closing the gap. And tool calling was dropped as a product decision, so this is a chat-only model. That said, this is the honest limit of what the model buys you. It has the lowest clean rate and the lowest composite (0.830) of the four builds in the head-to-head, and it is the only one where a stock base given the whole rule book is roughly level with the fine-tune (73.3% clean against 80.0%) and actually scores higher on mean R24 in that condition (99.80 pooled, 99.75 over delivered, against 99.41). Pick it if you want a Gemma lineage or a second opinion that is not correlated with the Qwen models. If you have not decided, the line's default is stcoder-qwen25-7b at Q6_K (5.82 GiB); take stcoder-qwen25-14b at Q4_K_M (8.37 GiB) instead if rule-cleanliness matters more than speed. Either way the code is a draft: compile it in LogicStudio and read the sequence logic before it goes near a machine.