stcoder-qwen25-14b

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.

First, the thing every card in this line states up front: tool calling was trained and evaluated for this line, but only the Qwen3.5-9B family learned it (tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, falling to 0.642 at Q4_K_M) while the code-focused families scored 0.02-0.06 and the Gemma family 0.00. Because it was not usable across the line, tool calling was dropped as a product decision and these builds are published and supported as chat-only models. If you have not decided which model to take, take stcoder-qwen25-7b at Q6_K (5.82 GiB). It is the line default: fastest per answer (5.8 s), smallest, 100% delivery, and the highest ChrF among models that answered every prompt (38.5 at 15/15). Choose stcoder-qwen25-14b instead, on 12 GB or more, for one measured reason: in the 240-run head-to-head it was the only fine-tune at 100% clean in both the minimal and the full-prompt condition (7B 93.3/100, stcoder-qwen35-9b 93.3/100, stcoder-gemma4-12b 86.7/80), with 0% prose leakage in both and 100% delivery in every arm. It is also the most economical of the four in output length at the minimal prompt: 288 tokens mean against 340 for the 7B, 401 for the Gemma and 1227 for the 9B. What you give up is measurable too: it has the lowest ChrF of the four at the minimal prompt (34.9, against 7B 38.5 at 15/15, stcoder-qwen35-9b 40.9 at 14/15, stcoder-gemma4-12b 35.9 at 15/15), and it is the slowest of the four per token at roughly 50 tok/s, which puts it at 8.6 s per answer - slower than the 7B's 5.8 s, but not the slowest per answer in the set (that is stcoder-qwen35-9b at 17.2 s). Hardware: Q4_K_M is 8.37 GiB and Q6_K is 11.29 GiB, so an 8 GB card is out. The other two, by their one measured difference: stcoder-qwen35-9b is the reasoning-family option and had the highest ChrF of the four (40.9) but delivered only 14 of 15 at the minimal prompt, so its ChrF carries a smaller denominator than everyone else's; stcoder-gemma4-12b is there for non-Qwen lineage diversity and is the weakest fine-tuning case in the set. Composites are within noise across the three Qwen fine-tunes (stcoder-qwen35-9b 0.845, stcoder-qwen25-7b 0.844, stcoder-qwen25-14b 0.842), so do not choose on that number.

1. Install Ollama

   Any recent release. Ollama supplies the GGUF loader, the local HTTP API and the chat REPL used below. llama.cpp works equally well if you prefer it; the Modelfile parameters map onto its command-line flags.

   # Windows / macOS: download the installer from ollama.com
   # Linux:
   curl -fsSL https://ollama.com/install.sh | sh

2. Download one GGUF file

   Take Q4_K_M (8.37 GiB) on 12 GB of VRAM, or Q6_K (11.29 GiB) on 16 GB or more. You need one file, not the whole repository.

   pip install -U "huggingface_hub[cli]"
   
   # 12 GB VRAM - recommended default
   hf download Mikrodev/stcoder-qwen25-14b-gguf qwen25_coder_14b-tc.q4_k_m.gguf --local-dir .
   
   # 16 GB+ VRAM - the quant the published numbers were measured on
   # hf download Mikrodev/stcoder-qwen25-14b-gguf qwen25_coder_14b-tc.q6_k.gguf --local-dir .

3. Write a Modelfile next to the GGUF

   The sampling settings and the system prompt the model was evaluated with. No chat template: Ollama formats the chat from the template stored inside the GGUF - the one this model was trained with - and on current Ollama a TEMPLATE line in this file is ignored anyway (verified by comparing prompt token counts with and without one). Edit the FROM line if you downloaded Q6_K. Do not add the dialect rule book to the system prompt - the weights already hold it, and the study found the full rule book changed rule compliance not at all.

   cat > Modelfile <<'EOF'
   FROM ./qwen25_coder_14b-tc.q4_k_m.gguf
   
   PARAMETER temperature 0.2
   PARAMETER top_p 0.95
   PARAMETER top_k 20
   PARAMETER repeat_penalty 1.0
   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 are STCoder, a conversational coding assistant for the Mikrodev LogicStudio IDE and an expert in IEC 61131-3 Structured Text. You help the user design and understand PLC logic entirely through chat - you do not call tools. Answer the user's message directly and helpfully. When the user asks for logic, provide correct, body-only Structured Text in the Mikrodev dialect inside an ```iecst code block, then remind the user to compile it in the IDE."""
   EOF

4. Register the model with Ollama

   This copies the GGUF into Ollama's store and binds the template, parameters and system prompt to the tag. Takes a minute or two for a file this size. For reproduction, the tags actually run in the study were: 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 run data records no quantisation for the base arms, so calling them "effectively Q4" is an inference from the Ollama library default, not a recorded value.

   ollama create stcoder-qwen25-14b:q4 -f Modelfile

5. Smoke-test it

   You should get a body-only ```iecst block with a VAR CONSTANT holding 4000 and a positional TON call - no PROGRAM wrapper, no T#4s, no IN := / PT :=. If you see any of those, the wrong GGUF or the wrong template is loaded.

   ollama run stcoder-qwen25-14b:q4 "Surface grinder: when the operator presses start, sound the warning siren for 4 seconds, then energise the spindle contactor. Stop button and a coolant-low fault both drop the spindle."

6. Set temperature 0 when you need repeatability

   The published study used greedy decoding with seed 42 at 8192 context. The Modelfile ships temperature 0.2 because it reads better in an interactive session; set it to 0 if you are comparing runs or filing a bug.

   ollama run stcoder-qwen25-14b:q4 --verbose
   >>> /set parameter temperature 0

7. Paste into LogicStudio and compile - every time

   The output is a POU body: paste it into the block, then run the IDE compiler and fix what it reports. This is not optional. Rule compliance was measured without a compiler, and at least six of this model's thirty study replies carry a real defect while scoring a perfect rule score - including one that referenced two undeclared symbols and would not have built.

   # In Mikrodev LogicStudio: paste into the block body, then Compile and read the diagnostics.

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

• Do not paste the rule book into your system prompt. Under a short realistic prompt with no rules listed, this fine-tune was already 100% clean at R24 100; the full rule book changed rule compliance not at all and moved ChrF by 1.9 points. The system prompt in the setup steps is all you need.
• Ask for one block at a time. Every prompt in the study was a single, self-contained plant request, and the model's median reply is 262-292 tokens. Multi-part requests are where it starts stubbing things out - the three-pump call site is the documented example.
• Put the real numbers in the request: milliseconds, raw counts, engineering range, ohms, degrees. The model reliably turns them into a named VAR CONSTANT (SIREN_MS : INT := 4000) rather than burying magic numbers in the body, and hex masks from a drive manual come back as decimal constants.
• Read the VAR blocks against the body before you compile. One of the fifteen study replies used two symbols it never declared. It is a five-second check that catches the most common failure.
• Read loops and scan order. The highest-fidelity reply in this model's whole set also reused a ring-buffer index as its FOR loop counter. The rule score is blind to this class of bug; you are not.
• Check comment syntax on annunciator-style requests. On the first-out fault prompt the model emitted nested comments, (* (* ... *) *), in both prompt conditions - 2 occurrences under the minimal prompt, 4 under the full one - and Mikrodev will not accept them.
• Anything that lives outside the code body - symbol retention, I/O mapping, instance wiring, POU shells - must be asked about separately, and the model will not always tell you it is missing. The retained-counter request is the clear case: retention is an IDE symbol setting in this dialect, and the reply just counted.
• Expect code, not commentary: prose was 0% in both study conditions. If you want the design rationale, the state numbering or the safety reasoning explained, ask in a second turn - it is a chat model and it answers follow-ups.
• Set temperature 0 when you want a result you can reproduce or file a bug against. The published numbers are greedy decoding, seed 42, 8192 context, tag stcoder_qwen25-14b:q6.
• If a long block truncates mid-listing, raise num_predict. This model’s longest reply at the minimal prompt was 568 tokens, so 2048 is generous, but a multi-part request can run past it.
• Iterate with the compiler in the loop rather than trying to get it right in one shot: paste, compile, feed the diagnostics back as your next message, compile again. That is how the model is meant to be used.
• If you find yourself wanting shorter turnaround or closer-to-reference structure, switch to stcoder-qwen25-7b at Q6_K - it is the line default and it was faster per answer (5.8 s) with higher ChrF at full delivery (38.5).
• Do not port its output to other IEC 61131-3 environments. The constructs it deliberately avoids are the constructs those environments require.

The same 15 requests were sent to the stock base model (qwen2.5-coder:14b) 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: none.

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

Certainly! Below is a reusable pump control block implemented in Structured Text (ST) that you can instantiate for each of your three booster pumps. This block will handle the logic for start delay, dry-run detection, overload protection, fault latching, and restart delay.

### Pump Control Block (PumpControlBlock)

```st
FUNCTION_BLOCK PumpControlBlock
VAR_INPUT
    RunRequest : BOOL; // Start request from HMI or PLC
    OverloadContact : BOOL; // Motor thermal overload contact
    DryRunSwitch : BOOL; // Low suction switch indicating dry-run condition
    FaultReset : BOOL; // Reset fault command from HMI or PLC
END_VAR

VAR_OUTPUT
    MotorRunCommand : BOOL; // Command to start the motor
    FaultFlag : BOOL; // General fault flag
    FaultCode : INT; // Specific fault code for HMI display
END_VAR

VAR
    StartDelayTimer : TON; // Timer for 2s start delay
    DryRunCheckTimer : TON; // Timer for 5s dry-run check after motor starts
    RestartDelayTimer : TON; // Timer for 10s restart delay after pump stops
    MotorRunning : BOOL := FALSE; // Internal state to track if the motor is running
    FaultLatched : BOOL := FALSE; // Internal state to latch faults
END_VAR

METHOD Run : VOID
VAR
    DryRunDetected : BOOL;
END_VAR

    // Start delay timer logic
    IF NOT MotorRunning AND RunRequest THEN
        StartDelayTimer(IN := TRUE, PT := T#2s);
    ELSE
        StartDelayTimer(IN := FALSE);
    END_IF;

    // Check if the motor can start after the delay
    IF StartDelayT

```iecst
(* Reusable pump control block *)
VAR_INPUT
  bRunReq : BOOL;
  bOverload : BOOL;
  bDryRun : BOOL;
  bReset : BOOL;
END_VAR
VAR_OUTPUT
  bMotor : BOOL;
  bFault : BOOL;
  nFaultCode : INT;
END_VAR
VAR
  tStart : TON;
  tDryRun : TON;
  tRestart : TON;
  rsFault : RS;
END_VAR
VAR CONSTANT
  START_MS : INT := 2000;
  DRY_MS : INT := 5000;
  RESTART_MS : INT := 10000;
END_VAR

(* Start delay *)
tStart(bRunReq, START_MS);
(* Dry-run check only after motor has started *)
tDryRun(bMotor, DRY_MS);
(* Restart cooldown *)
tRestart(NOT bMotor, RESTART_MS);

(* Thermal overload trips immediately *)
rsFault(bOverload OR (tDryRun.Q AND bDryRun), bReset);
bFault := rsFault.Q1;
IF bFault THEN
  nFaultCode := 1;
  IF bOverload THEN nFaultCode := 2; END_IF;
  IF bDryRun THEN nFaultCode := 3; END_IF;
END_IF;

(* Motor run command *)
bMotor := tStart.Q AND NOT bFault AND NOT tRestart.Q;
```

```iecst
(* Main program *)
VAR
  bP1RunReq, bP2RunReq, bP3RunReq : BOOL;
  bP1Overload, bP2Overload, bP3Overload : BOOL;
  bP1DryRun, bP2DryRun, bP3DryRun : BOOL;
  bP1Reset, bP2Reset, bP3Reset : BOOL;
  bP1Motor, bP2Motor, bP3Motor : BOOL;
  bP1Fault, bP2Fault, bP3Fault : BOOL;
  nP1FaultCode, nP2FaultCode, nP3FaultCode : INT;
END_VAR

(* Instantiate the pump block three times *)
bP1Motor := bP1RunReq;
bP2Motor := bP2RunReq;
bP3Motor := bP3RunReq;
bP1Fault := bP1Overload OR bP1DryRun;
bP2Fault := bP2Overload OR bP2DryRun;
bP3Fault := bP3Overload OR bP3DryRun;
nP1FaultCode := 0;
nP2FaultCode := 0

Certainly! Below is an example of how you might implement this drilling station cycle using Structured Text (ST) in the Mikrodev LogicStudio IDE, following the IEC 61131-3 standard.

```pascal
PROGRAM DrillingStationCycle
VAR
    // Inputs
    GuardClosed : BOOL;       // Guard switch input
    PartPresent : BOOL;     // Part presence sensor input
    NoAlarms : BOOL;         // Alarm status input
    StartButton : BOOL;      // Start button input
    EStop : BOOL;            // Emergency stop input
    DrillOverload : BOOL;    // Drill overload sensor input

    // Outputs
    ClampClose : BOOL;       // Close clamp output
    DrillMotorStart : BOOL;  // Start drill motor output
    HeadFeedDown : BOOL;     // Feed head down output
    HeadRetract : BOOL;      // Retract head output
    ClampOpen : BOOL;        // Open clamp output

    // Internal variables
    PartCounter : INT := 0;   // Counter for parts processed
    State : INT := 0;         // State machine state variable
    Timer1 : TON;             // Timer for clamp pressure build-up
    Timer2 : TON;             // Timer for dwell at depth
    Timer3 : TON;             // Timer for clamp opening delay

    // Constants
    CLAMP_PRESSURE_BUILD_TIME : TIME := T#1.5S;
    DWELL_AT_DEPTH_TIME : TIME := T#3S;
    CLAMP_OPEN_DELAY_TIME : TIME := T#0.8S;

END_VAR

// State machine logic
CASE State OF
    0: // Idle state
        ClampClose := FALSE;
        DrillMotorStart := FALSE;
        HeadFeedDown := FALSE;
     

```iecst
(* Drilling station cycle *)
VAR_INPUT
  bGuardClosed : BOOL;
  bPartPresent : BOOL;
  bStart       : BOOL;
  bReset       : BOOL;
  bEStop       : BOOL;
  bDrillOverload : BOOL;
END_VAR
VAR_OUTPUT
  bClampClosed : BOOL;
  bDrillMotor  : BOOL;
  bFeedDown    : BOOL;
  bFeedUp      : BOOL;
  nPartCount   : DINT;
  nState       : INT;
END_VAR
VAR
  tClamp, tDwell, tOpen : TON;
  rStartEdge : R_TRIG;
END_VAR
VAR CONSTANT
  CLAMP_MS : INT := 1500;
  DWELL_MS : INT := 3000;
  OPEN_MS  : INT := 800;
END_VAR

rStartEdge(bStart);

IF bEStop OR bDrillOverload THEN
  bClampClosed := FALSE;
  bDrillMotor  := FALSE;
  bFeedDown    := FALSE;
  bFeedUp      := FALSE;
  nState := 0;
ELSIF rStartEdge.Q AND bGuardClosed AND bPartPresent THEN
  nState := 1;
END_IF;

CASE nState OF
  0: (* Idle *)
    bClampClosed := FALSE;
    bDrillMotor  := FALSE;
    bFeedDown    := FALSE;
    bFeedUp      := FALSE;
  1: (* Close clamp *)
    bClampClosed := TRUE;
    tClamp(nState = 1, CLAMP_MS);
    IF tClamp.Q THEN nState := 2; END_IF;
  2: (* Feed down *)
    bFeedDown := TRUE;
    bDrillMotor := TRUE;
    IF bDownLimit THEN nState := 3; END_IF;
  3: (* Dwell at depth *)
    tDwell(nState = 3, DWELL_MS);
    IF tDwell.Q THEN nState := 4; END_IF;
  4: (* Feed up *)
    bFeedDown := FALSE;
    bFeedUp := TRUE;
    IF bUpLimit THEN nState := 5; END_IF;
  5: (* Open clamp *)
    bFeedUp := FALSE;
    tOpen(nState = 5, OPEN_MS);
    IF tOpen.Q THEN
      nPartCount := nPartCount + 1;
      nState :=

Certainly! Below is a Structured Text (ST) program that implements a flashing warning beacon based on your requirements. The program assumes you have two variables: `WarningFlag` (a boolean input indicating whether the warning is active) and `LampOutput` (a boolean output controlling the lamp).

```st
PROGRAM FlashingBeacon
VAR
    WarningFlag : BOOL; // Input: Machine warning flag
    LampOutput  : BOOL; // Output: Control for the lamp
    Timer       : TON;   // Timer to control the blinking sequence
    BlinkState  : BOOL;  // State to alternate between on and off
END_VAR

// Initialize timer if not already done
IF NOT Timer.PT := T#2s THEN
    Timer.PT := T#2s;
END_IF;

// Main logic for flashing beacon
IF WarningFlag THEN
    // Start the timer if it's not running
    IF NOT Timer.Q THEN
        Timer(ET:=T#0ms);
    END_IF;

    // Alternate blink state based on timer elapsed time
    IF Timer.ET >= T#1500ms THEN
        BlinkState := NOT BlinkState;
        Timer(ET:=T#0ms); // Reset the timer for the next cycle
    END_IF;

    // Set lamp output based on the current blink state
    LampOutput := BlinkState;
ELSE
    // Turn off the lamp when warning is cleared
    LampOutput := FALSE;
END_IF;
```

### Explanation:
1. **Variables**:
   - `WarningFlag`: A boolean input that indicates whether a warning condition exists.
   - `LampOutput`: A boolean output that controls the lamp's state (on or off).
   - `Timer`: A timer object (`TON`) used to manage the timing of the bl

```iecst
VAR_INPUT
    bWarningFlag : BOOL;
END_VAR
VAR_OUTPUT
    bBeaconLamp : BOOL;
END_VAR
VAR
    tBlink : TON;
    bLit   : BOOL;
END_VAR
VAR CONSTANT
    BLINK_ON_MS  : INT := 500;
    BLINK_OFF_MS : INT := 1500;
END_VAR

(* Blink timer toggles every 2 seconds *)
tBlink(bWarningFlag, BLINK_ON_MS + BLINK_OFF_MS);
IF tBlink.Q THEN
    tBlink(FALSE, BLINK_ON_MS + BLINK_OFF_MS);
    bLit := NOT bLit;
END_IF;

(* Beacon lamp is lit only when warning is active and blink is in the on phase *)
bBeaconLamp := bWarningFlag AND bLit;
```

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

All file sizes in this card are GiB, as reported by the build tooling. Q4_K_M, Q6_K and Q8_0 are increasingly faithful compressions of the same trained weights: more bits per weight means a larger file and a closer match to the original, at no change in behaviour or licence. For this model only Q4_K_M (8.37 GiB) and Q6_K (11.29 GiB) are published; a Q8_0 would land near 14.6 GiB and was left out deliberately. The reason it was left out is the earlier 2000-prompt internal evaluation, where this fine-tune scored a code composite of 0.851-0.852 and ChrF 52.0 across Q4, Q6 and Q8 - a spread of 0.001 or less. One disclosure is required before you read those figures: that evaluation's code holdout overlapped the training distribution by about 84%, so its absolute code scores are inflated and only weakly discriminative between models. They are used here for one purpose only - comparing quantisations of this single model - and never to rank the four models against each other. For that within-model purpose the conclusion holds: on the code task, quantisation is effectively free here, and Q4_K_M produces the same quality of Structured Text as Q8 would. That is worth stating plainly because an earlier report showed a large Q4 penalty. That penalty was measured on the tool-calling task, where argument-level precision collapses first under quantisation - the Qwen3.5-9B family fell from 0.816 at Q8_0 to 0.642 at Q4_K_M. Tool calling was dropped as a product decision and these builds are published and supported as chat-only models, so that Q4 penalty does not apply to anything these models are asked to do. Practical guidance: run Q4_K_M unless you have spare VRAM. Q6_K is the quant the head-to-head actually used (tag stcoder_qwen25-14b:q6), so choose it if you want to reproduce the published numbers exactly.

Strengths

• Highest clean rate in the head-to-head: R24 100.0 and 100% clean across all 30 fine-tune replies, in both the minimal and the full-prompt condition. It is the only one of the four fine-tunes that reached 100% clean in both (stcoder-qwen25-7b 93.3/100, stcoder-qwen35-9b 93.3/100, stcoder-gemma4-12b 86.7/80).
• The dialect lives in the weights, not the prompt. Under the minimal prompt - a short realistic system message that lists no rules at all - the fine-tune was 100% clean while the same base weights were 0.0% clean. Pasting the entire rule book into the base model's prompt only lifted it to 40%.
• No prose leakage in either condition (0%, against 80% for the base at the minimal prompt and 100% at the full prompt). Replies are a code fence, not an essay wrapped around a code fence, so the output can be pasted straight into a block.
• Fewest output tokens in the head-to-head at the minimal prompt: 288 mean and 262 median, against 340 for stcoder-qwen25-7b, 401 for stcoder-gemma4-12b and 1227 for stcoder-qwen35-9b - and 2.5x more economical than its own base on the same 15 requests (713 mean / 674 median). Mean wall clock was 8.6 s against 11.1 s for the base.
• 100% delivery in both conditions and both arms - no empty or non-delivered replies. Of the four fine-tunes only stcoder-qwen35-9b missed one (14 of 15 at the minimal prompt), which is why its higher ChrF carries a smaller denominator.
• The only fine-tune in the set whose ChrF improved when the rule book was added to the prompt (34.9 to 36.8); the other three all dropped. Extra context does not destabilise this model.
• Reaches for the right Mikrodev idioms unprompted: positional TON(bRunReq, START_MS), RS latches read via .Q1, R_TRIG for pushbutton edges, INT millisecond values in VAR CONSTANT, bitwise masks as decimal constants, IF clamps instead of LIMIT, and no POU wrapper.
• Quantisation-insensitive on the code task within this model: composite 0.851-0.852 across Q4, Q6 and Q8 in the earlier 2000-prompt evaluation, a spread of 0.001 or less, so Q4_K_M costs nothing measurable in exchange for 2.9 GiB less VRAM. That evaluation's code holdout overlapped the training distribution by about 84%, so its absolute scores are inflated and weakly discriminative; it is used here only to compare quantisations of this one model, never to rank models against each other.

Weaknesses

• Lowest ChrF of the four at the minimal prompt: 34.9 over 15 delivered replies, against stcoder-qwen25-7b 38.5 (15/15), stcoder-qwen35-9b 40.9 (14/15) and stcoder-gemma4-12b 35.9 (15/15). Rule-clean output is not the same as output that resembles hand-written reference code, and on this metric this model is last in the set.
• Fine-tuning made reference similarity worse on 5 of the 15 minimal prompts, where the fine-tune's ChrF fell below its own base: analog_scale_helper 24.46 against 30.97, io_terminal_seal_in 25.82 against 37.01, first_out_fault_annunciator 26.18 against 32.56, machine_data_grouping 28.76 against 31.91, setpoint_clamp_and_ramp 36.11 against 37.79. The training buys dialect compliance and brevity, not uniformly closer structure.
• Clean does not mean correct. R24 is reference-free and has no compiler behind it. In the heater_power_avg_squared row the model scored R24 100 while reusing the ring-buffer index nIdx as the FOR loop counter (FOR nIdx := 0 TO 7), which destroys the index every scan. The metric cannot see that.
• Undeclared symbols occur. The machine_cycle_full_program reply is dialect-clean at R24 100 but branches on bDownLimit and bUpLimit, neither of which appears in any VAR block. That code does not build. Compile before you trust it.
• It can hand back a stub instead of admitting a limit. Asked to show how a reusable pump block is called for three pumps, it produced a second block that instantiates nothing - bP1Motor := bP1RunReq; and similar - with all three fault codes set to 0. Under the full prompt condition it dropped the call-site block entirely.
• It can answer the dialect while missing the engineering question. The retain_counter_power_cycle prompt was explicitly about totals surviving a nightly power-down; retention is forbidden in code in this dialect and must be set on the symbol in the IDE, but the reply just counts and never mentions it. ChrF 25.7 on that row reflects the gap.
• Unused logic slips through. In the full-condition pump-block reply the 10 s restart cooldown timer tStop is computed and assigned to bStopEdge, then never used in the motor equation. The cooldown requirement is silently unmet.
• First-out latching was not actually first-out: the fault annunciator reply re-evaluates its IF/ELSIF chain every scan, so the captured code follows the highest-priority active fault rather than the one that tripped first, and a later bAlarmLamp := bAnyFault; overwrites the acknowledge handling above it.
• Nested comments, (* (* ... *) *), which Mikrodev does not accept. They appear on the same prompt in both conditions - first_out_fault_annunciator, 2 occurrences under the minimal prompt and 4 under the full prompt - so this is a reproducible failure on that request rather than a one-off. It will stop a compile and the rule score does not catch it.
• At least six of the thirty fine-tune replies contain a real defect while scoring R24 100: heater_power_avg_squared (FOR-index reuse), machine_cycle_full_program (two undeclared symbols), reusable_pump_block minimal (stub call site, all fault codes 0), reusable_pump_block full (cooldown computed then unused, call site dropped), first_out_fault_annunciator in both conditions (nested comments plus the priority and overwrite bugs) and retain_counter_power_cycle (the retention requirement never addressed).
• Slowest of the four per token: 50.0 tok/s at Q6_K on an RTX 5080 (49.6 at the full prompt), against 103.6 for stcoder-qwen25-7b, 86.3 for stcoder-qwen35-9b and 72.7 for stcoder-gemma4-12b. Per answer it is not the slowest - 8.6 s against 5.8 s for the 7B, 8.5 s for the Gemma and 17.2 s for the 9B - because it also emits the fewest tokens. Name the axis when comparing: slowest per token, mid-pack per answer.
• The tok/s comparison against its own base (50.0/49.6 fine-tune against 84.3/84.1 base) is not precision-controlled. The fine-tune ran at Q6_K and the stock base at the Ollama library default, and the run data records no quantisation for the base arms at all, so "effectively Q4" there is an inference from that default rather than a recorded value. Part of the throughput difference is precision, not training.
• Terse by design. Prose was 0% in both conditions, so you get code and almost no reasoning. If you want the design explained, ask for it in a follow-up turn.
• No Q8_0 is published, and Q6_K at 11.29 GiB is a tight fit on a 16 GB card. An 8 GB card cannot hold either published quant in VRAM.
• Study caveat: quantisation was not controlled in the head-to-head, so some of the base-versus-fine-tune gap may be precision rather than training - though a precision difference does not plausibly explain 0.0% clean against 100%. Also note the metric variant: the R24 and clean figures in this card are computed over the whole reply. The same data holds a fence-only variant, and because base replies were prose-wrapped 66.7-100% of the time while fine-tune replies were 0-20%, the variant matters for the base arms - pooled base clean at the minimal prompt moves from 6.7% whole-reply to 10.0% fence-only. For this model specifically both variants give the same numbers (base 0.0% clean, fine-tune 100%), so the gap reported here is not an artefact of the choice.

Not the right tool for

• Tool calling or function calling of any kind. Tool calling was trained and evaluated for this line; only the Qwen3.5-9B family learned it (0.816 at Q8_0, 0.805 at Q6_K, 0.642 at Q4_K_M) while the code-focused families scored 0.02-0.06 and the Gemma family 0.00. Because it was not usable across the line it was dropped as a product decision, and these builds are published and supported as chat-only models. If you are building an agent that drives IDE tools, do not use them.
• Agent frameworks that expect structured JSON actions, MCP calls or an OpenAI tools schema. This is a chat model that returns Structured Text in a code fence.
• Machines with 8 GB of VRAM or less - the smallest published file is 8.37 GiB of weights. Use stcoder-qwen25-7b there (Q4_K_M, 4.36 GiB).
• Readers who want the line default. That is stcoder-qwen25-7b at Q6_K: faster per answer, smaller, and higher ChrF at full delivery. Come to the 14B for the clean rate, not as a general upgrade.
• Any dialect other than Mikrodev LogicStudio. It was trained to violate conventions that other IEC 61131-3 environments require, so its output is deliberately wrong for them: no POU wrappers, no TIME literals, no named parameters, no output arrows.
• Unreviewed deployment to a live machine. At least six of the thirty replies in this model's own study data would have failed to build or would have misbehaved despite scoring a perfect rule score. Compile it, review the logic, and test it.
• Safety-instrumented functions. Nothing here substitutes for a rated safety controller and a proper functional-safety assessment.
• General-purpose programming, or PLC languages other than Structured Text. The system prompt declines non-PLC requests and the training gives it no advantage outside this narrow task.
• Frontier-scale work: long multi-file project generation, deep architectural reasoning, or specification review. This is a 14B model running locally.

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.

What this model buys you is a local assistant that has stopped writing generic textbook Structured Text and writes Mikrodev Structured Text instead: across 30 fine-tune replies in the controlled study it broke no dialect rule and leaked no prose, from the same weights whose stock version was 0.0% clean when the rules were not spelled out. Within the four-model line that clean rate is its one measured distinction - it is the only fine-tune at 100% clean in both prompt conditions - and it is bought at a real price: the lowest ChrF of the four at the minimal prompt (34.9 against 38.5, 40.9 at 14/15 delivery, and 35.9), the slowest generation per token at roughly 50 tok/s, and 8.4-11.3 GiB of VRAM. If you have not decided, the line default is stcoder-qwen25-7b at Q6_K. This is a small chat model, tool calling was dropped from the product and it is supported as chat-only, and its clean score says nothing about whether the logic is right - at least six of its thirty study replies scored a perfect 100 and still carried a real defect - so treat every reply as a first draft that goes to the IDE compiler before it goes anywhere near a machine.