stcoder-qwen25-7b

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.

Start here unless you have a specific reason not to. First, the boundary: this is a chat model. You describe a plant requirement, it replies with a Structured Text body. Tool calling and function calling were trained and evaluated for this line, but the capability was not usable across the four models, so it was dropped as a product decision and these builds are published and supported as chat-only models. There are no tool or function calls, no JSON actions, no MCP schemas. Head-to-head standing, minimal (short) system prompt, this study, ChrF averaged over delivered replies so the denominator is identical for all four: stcoder-qwen25-7b 93.3% rule-clean, 100% delivery (15/15), ChrF 38.5, composite 0.844, mean 340 output tokens, 5.8 s per reply. Its actual standing is: highest ChrF among the models that delivered every reply (38.5; stcoder-qwen35-9b scored 40.9 but delivered 14 of 15); joint second on clean rate with stcoder-qwen35-9b (both 93.3%), behind stcoder-qwen25-14b's 100.0%; composite 0.844, which is inside the noise band with stcoder-qwen35-9b (0.845) and stcoder-qwen25-14b (0.842); fastest per answer of the four. Which one should I download? Default: stcoder-qwen25-7b at Q6_K (5.82 GiB), or Q4_K_M (4.36 GiB) on an 8 GB card, because it is the fastest per answer, the smallest to run, and at the top of the head-to-head on ChrF at full delivery. Choose stcoder-qwen25-14b at Q6_K (11.29 GiB) only on 16 GB or more, if you want the one model that was 100% rule-clean in both prompt conditions, accepting the lowest head-to-head ChrF (34.9) and roughly half the generation rate per token (about 50 tok/s against this model's 103.6). Choose stcoder-qwen35-9b only if you want the reasoning family, accepting about 3.6x the output tokens per answer (1227 against 340) and one reply in fifteen that spent its entire 8,192-token budget on reasoning and returned no code at all after 99 seconds, which is why it is the slowest per answer at 17.2 s. Choose stcoder-gemma4-12b only for non-Qwen lineage diversity; it is the weakest fine-tuning case in this study (80.0% clean in the full condition against its fully-prompted base's 73.3%, and its base scored a higher mean R24 than the fine-tune in that condition). At matched quantisation this model is roughly half the size of the 14B, not a third: 7B Q6_K 5.82 GiB against 14B Q6_K 11.29 GiB. Three disclosures apply to all four cards: no tool calling in this release; compile every block in LogicStudio before deployment; and quantisation was not controlled in the head-to-head (fine-tunes ran at Q8_0 or Q6_K, the stock bases at whatever the Ollama library default is).

1. Install Ollama

   Ollama 0.3 or later. llama.cpp works equally well if you prefer it; the GGUF files are standard.

   winget install Ollama.Ollama   # or: brew install ollama

2. Download one GGUF file

   Take Q6_K for a 12 GB card, Q4_K_M for 8 GB, Q8_0 for 16 GB or more. You need exactly one file, not the whole repository.

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

3. Write a Modelfile next to the GGUF

   Keep the system prompt short. In this study the short 'minimal' system prompt gave a higher ChrF (38.5) than pasting the entire rule book (35.3) - the dialect is in the weights, and restating it adds nothing. Greedy decoding matches how the model was measured.

   cat > Modelfile <<'EOF'
   FROM ./qwen25_coder_7b-tc.q6_k.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 are a PLC programming assistant for the Mikrodev LogicStudio IDE. You write IEC 61131-3 Structured Text for Mikrodev controllers. Reply with the code body only."
   EOF

4. Create the Ollama model

   Names the model locally. Use a tag that records the quant so you can keep more than one. For reference, the tags actually run in the study were stcoder_qwen25-7b:q8 (fine-tune) and qwen2.5-coder:7b (stock base); the sibling arms were stcoder_qwen25-14b:q6, stcoder_qwen35-9b:q8, stcoder_gemma4-12b:q6 against qwen2.5-coder:14b, qwen3.5:9b and gemma4:12b.

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

5. Ask it for a block

   Describe the plant requirement in plain language, as you would to a colleague. Do not list dialect rules.

   ollama run stcoder-qwen25-7b:q6_k "Silo inlet: on a fill request with the high-level switch clear, open the inlet valve; 3 seconds after the valve open-confirm is made, start the blower. Any fault stops the blower at once and closes the valve 2 seconds later."

6. Paste into LogicStudio and compile

   The model returns a code body - variable blocks plus statements, no PROGRAM or FUNCTION_BLOCK wrapper, because the IDE owns the shell. Compile before you go anywhere near a controller. In the 15-prompt study the fine-tune broke no dialect rule on 14 of 15 prompts, but rule-clean is not the same as logically correct: the study found an undeclared enumeration member, an unused constant and a reset branch that counted up instead of clearing.

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

• Keep the system prompt short. The dialect is in the weights: with no rules listed the model scored R24 99.80 and ChrF 38.5; with the whole rule book pasted in, R24 reached 100.0 but ChrF fell to 35.3. A one-line role description is enough.
• Describe the plant, not the code. Every prompt in the study was written the way an engineer talks - 'the fan should keep running for 30 seconds after the motor is switched off so the duct clears'. None mentioned a dialect rule, and the model still produced INT millisecond presets and positional timer calls.
• Convert hex before you paste. If a drive or device manual gives masks as 16#0F00, translate them to decimal or to bit indices in your prompt. Quoting hex is what pulled a forbidden literal into the output on the one prompt where this model broke a rule in its minimal arm.
• Run greedy. The reported numbers are temperature 0, single seed. Raising temperature buys variety you do not want in control code.
• Compile first, read second, deploy third. Then read the declarations specifically: check that every VAR CONSTANT is actually used, that every enumeration member referenced in a CASE is declared, and that reset branches clear rather than increment. Those are the three defects found in rule-clean output.
• Ignore the paragraph after the code block. Roughly 1 in 15 replies adds explanatory prose, and in one measured case that prose contradicted the code it described.
• Ask for one block at a time. The model is at its best on a single well-bounded requirement - a timer, a latch, an interlock, a scaling calculation - and its weakest ChrF rows were the most open-ended structural prompts.
• Iterate by naming the defect, not by re-listing rules. 'The shift counter increments on reset instead of clearing - fix that branch' works; re-pasting the dialect rules does not improve output.
• It has no tools and no memory of your project. Give it the signal names you want in the prompt, or expect it to invent its own (bStartBtn, rPressureBar and so on - consistent Hungarian-style prefixes, but its own choices).

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

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

Certainly! Below is an example of a reusable pump control block in IEC 61131-3 Structured Text (ST) that you can instantiate once per pump. The block includes the necessary inputs and outputs, as well as the logic to handle the behavior described.

### Pump Control Block

```st
FUNCTION_BLOCK FB_PumpControl
VAR_INPUT
    RunRequest : BOOL;  // Request to start the pump
    MotorThermalOverload : BOOL;  // Motor thermal overload contact
    DryRunSwitch : BOOL;  // Low suction switch (dry-run)
    FaultReset : BOOL;  // Fault reset signal
END_VAR

VAR_OUTPUT
    MotorRunCommand : BOOL;  // Command to run the motor
    FaultFlag : BOOL;  // Fault flag indicating if a fault has occurred
    FaultCode : INT;  // Fault code for HMI display
END_VAR

VAR
    StartDelayTimer : TON;  // Timer for start delay
    DryRunTimer : TON;  // Timer to evaluate dry-run switch
    MotorRunning : BOOL;  // Flag indicating if the motor is running
    LastFaultTime : TIME;  // Time when a fault occurred
END_VAR

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

IF MotorThermalOverload OR DryRunSwitch THEN
    FaultFlag := TRUE;
    FaultCode := 1;  // Thermal overload or dry-run fault code
    LastFaultTime := GET_TIME();
ELSE IF FaultReset THEN
    FaultFlag := FALSE;
    FaultCode := 0;  // No fault code
END_IF;

IF StartDelayTimer.Q AND NOT MotorRunning THEN
    DryRunTimer(IN := TRUE, PT := T#5s);
ELS

```iecst
VAR_INPUT
  bRunReq : BOOL;
  bOverload : BOOL;
  bDryRun : BOOL;
  bResetFault : BOOL;
END_VAR
VAR_OUTPUT
  bMotorRun : BOOL;
  bFault : BOOL;
  nFaultCode : INT;
END_VAR
VAR
  tStartDelay : TON;
  tDryRunDelay : TON;
  tStopDelay : TON;
  rsFault : RS;
  bFaultLatched : BOOL;
END_VAR
VAR CONSTANT
  START_DELAY_MS : INT := 2000;
  DRY_RUN_DELAY_MS : INT := 5000;
  STOP_DELAY_MS : INT := 10000;
END_VAR

(* 2 s start delay *)
tStartDelay(bRunReq AND NOT bOverload AND NOT bDryRun, START_DELAY_MS);

(* Dry-run only after the motor has started *)
tDryRunDelay(tStartDelay.Q, DRY_RUN_DELAY_MS);

(* Stop delay: 10 s after the pump stops *)
tStopDelay(NOT bMotorRun, STOP_DELAY_MS);

(* Latch fault on overload or dry-run, reset only when reset button pressed *)
rsFault(bOverload OR (tDryRunDelay.Q AND bDryRun), bResetFault);
bFaultLatched := rsFault.Q1;

(* Motor run: start delay, no dry-run while stopping *)
bMotorRun := tStartDelay.Q AND NOT bDryRun AND NOT tStopDelay.Q AND NOT bFaultLatched;

(* Fault flag and code *)
bFault := bFaultLatched;
IF bFaultLatched THEN
  IF bOverload THEN
    nFaultCode := 1;
  ELSIF tDryRunDelay.Q AND bDryRun THEN
    nFaultCode := 2;
  END_IF;
ELSE
  nFaultCode := 0;
END_IF;
```

Each pump instance is called with a unique `bRunReq`, `bOverload`, `bDryRun`, and `bResetFault` input, and the same `bMotorRun`, `bFault`, and `nFaultCode` output. The three instances are instantiated in the main program with different input and output names.

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

```structured-text
PROGRAM DrillingStationCycle
VAR
    GuardClosed : BOOL;
    PartPresent : BOOL;
    NoAlarms : BOOL;
    StartPressed : BOOL;
    ClampClosed : BOOL;
    DrillMotorRunning : BOOL;
    HeadFeedingDown : BOOL;
    DownLimitSwitch : BOOL;
    UpLimitSwitch : BOOL;
    EStopPressed : BOOL;
    DrillOverload : BOOL;
    PartCounter : INT := 0;
    ClampTimer : TON; // Timer for clamp pressure build
    DrillMotorTimer : TON; // Timer for drill motor dwell
    RetractTimer : TON; // Timer for retraction after drilling
    FaultState : BOOL := FALSE;
END_VAR

// Step Sequencing and Timers
IF NOT FaultState THEN
    IF GuardClosed AND PartPresent AND NoAlarms THEN
        IF StartPressed THEN
            ClampClosed := TRUE;
            ClampTimer(IN := TRUE, PT := T#1500ms); // 1.5 seconds for clamp pressure build

            IF ClampTimer.Q THEN
                DrillMotorRunning := TRUE;
                DrillMotorTimer(IN := TRUE, PT := T#3s); // 3 seconds dwell at depth

                IF DrillMotorTimer.Q THEN
                    HeadFeedingDown := TRUE;

                    IF DownLimitSwitch THEN
                        HeadFeedingDown := FALSE;
                        RetractTimer(IN := TRUE, PT := T#800ms); // 0.8 seconds retraction after drilling

                        IF Re

Here is the complete drilling station cycle program. I used the IEC 61131-3 Structured Text standard function blocks for the timers and the logic. The station is in one of four states: IDLE, CLAMPING, DRILLING, and RETRACTING. The E-stop and drill overload are monitored with a priority check — the E-stop wins. The part counter increments only when the part is successfully drilled and the clamp is opened.

```iecst
(*
  Drilling station cycle with clamp, drill, and retract sequence.
*)

TYPE E_Station : (IDLE, CLAMPING, DRILLING, RETRACTING); END_TYPE
VAR_INPUT
  bGuardClosed : BOOL;
  bPartPresent : BOOL;
  bStart     : BOOL;
  bEStop     : BOOL;
  bDrillOverload : BOOL;
  bReset     : BOOL;
END_VAR
VAR_OUTPUT
  bClamp     : BOOL;
  bDrill     : BOOL;
  bHeadFeed  : BOOL;
  bFault     : BOOL;
  nPartCount : INT;
END_VAR
VAR
  eState     : E_Station := IDLE;
  tClamp     : TON;
  tDrill     : TON;
  tRetract   : TON;
  tDwell     : TON;
  bClampCmd  : BOOL;
  bDrillCmd  : BOOL;
  bHeadCmd   : BOOL;
  bFaultSet  : BOOL;
  bFaultClr  : BOOL;
END_VAR
VAR CONSTANT
  CLAMP_MS   : INT := 1500;
  DRILL_MS   : INT := 10000;
  RETRACT_MS : INT := 2000;
  DWELL_MS   : INT := 3000;
  DWELL_S    : INT := 3;
END_VAR

(* Priority: E-stop > drill overload > start *)
bClampCmd := FALSE;
bDrillCmd := FALSE;
bHeadCmd  := FALSE;

(* Fault detection *)
bFaultSet := bEStop OR bDrillOverload;
bFaultClr := bReset AND NOT bEStop AND NOT bDrillOverload;

(* Fault latch *)
IF bFaultSet THEN
  bFault :=

To solve this problem, you need to maintain a persistent storage for the lifetime total count across power cycles. One way to achieve this is by using non-volatile memory (NVM) or a file system on an external storage device like an SD card. However, since Mikrodev LogicStudio IDE does not directly support NVM or file systems, we can use a workaround by storing the lifetime total in a variable that is saved and restored from a configuration file when the PLC starts.

Here's how you can implement this logic using Structured Text (ST):

1. **Define Variables:**
   - `bPartDetect`: Input signal from the photo eye.
   - `nShiftTotal`: Shift total counter.
   - `nLifetimeTotal`: Lifetime total counter.
   - `bShiftReset`: Input signal to reset the shift total.

2. **Configuration File Handling:**
   - Use a configuration file to store and load the lifetime total when the PLC starts and stops.

3. **Counting Logic:**
   - Increment the shift total on each bottle detection.
   - Reset the shift total when `bShiftReset` is active.
   - Save the lifetime total to the configuration file before stopping the PLC.
   - Load the lifetime total from the configuration file when starting the PLC.

Here's an example of how you can implement this in ST:

```st
VAR
    bPartDetect : BOOL;  // Input signal from the photo eye
    nShiftTotal : INT := 0;  // Shift total counter
    nLifetimeTotal : INT := 0;  // Lifetime total counter
    bShiftReset : BOOL;  // Input signal to reset the shift total

```iecst
VAR_INPUT
  bPartDetect : BOOL;
  bShiftReset : BOOL;
END_VAR
VAR_OUTPUT
  nShiftCount : DINT;
  nLifetimeCount : DINT;
END_VAR
VAR
  rEdge : R_TRIG;
  bResetEdge : BOOL;
  bResetActive : BOOL;
  bResetDone : BOOL;
END_VAR
VAR CONSTANT
  MAX_LIFETIME : DINT := 3000000000;
END_VAR

rEdge(bPartDetect);
bResetEdge := bShiftReset;

(* Shift counter - reset on rising edge of bShiftReset *)
IF bResetEdge THEN
  bResetActive := TRUE;
END_IF;
IF NOT bShiftReset THEN
  bResetActive := FALSE;
END_IF;

IF bResetActive THEN
  nShiftCount := nShiftCount + 1;
  IF nShiftCount >= MAX_LIFETIME THEN
    nShiftCount := 0;
  END_IF;
END_IF;

(* Lifetime counter - never resets *)
IF rEdge.Q THEN
  nLifetimeCount := nLifetimeCount + 1;
  IF nLifetimeCount >= MAX_LIFETIME THEN
    nLifetimeCount := 0;
  END_IF;
END_IF;
```

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

Quantisation is how many bits each weight keeps. Q8_0 is close to the original precision, Q6_K is a modest reduction, Q4_K_M roughly halves the file again. For this model the published files are 7.54 GiB, 5.82 GiB and 4.36 GiB. All file sizes in this card are GiB, as reported by the build tooling. Which quant to take depends on the task you care about. On an earlier internal 2000-prompt evaluation of these same fine-tunes, this model's code task showed a code composite of 0.844-0.846 and ChrF in the 38-52 band across Q4_K_M, Q6_K and Q8_0 - a spread of 0.002 or less. Important caveat: 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. It is quoted here purely for the within-model quant comparison and must not be used to rank the four models against each other; for cross-model comparison use the head-to-head figures in this card. With that caveat attached, the practical reading holds: for writing Structured Text the quantisation choice is close to irrelevant, so pick the largest file your card holds comfortably and spend the rest on context. The large Q4 penalty in that older material was on the tool-calling task, which needs exact JSON argument structure and degrades sharply at 4 bits. Tool calling is not part of this release. It was trained and measured across the line: the Qwen3.5-9B family did learn it (tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, collapsing to 0.642 at Q4_K_M), while the code-focused families including this one scored 0.02-0.06 and the Gemma family exactly 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. So the Q4 tool-calling warning does not apply to how you will use this model. Practical reading: Q6_K is the default, Q4_K_M is the 8 GB fallback with no measurable code-quality cost, Q8_0 is for reproducing the exact numbers in this card. One further caveat: the base-versus-fine-tune comparison below was not quantisation-controlled. The fine-tune ran at Q8_0 (tag stcoder_qwen25-7b:q8); the run data records no quantisation at all for the base arm (tag qwen2.5-coder:7b), so calling it "effectively Q4" is an inference from the Ollama library default, not a recorded value.

Strengths

• Dialect compliance is in the weights, not the prompt. With a short realistic system prompt that lists no rules ('minimal'), the fine-tune scored R24 99.80 and produced rule-clean code on 14 of 15 prompts (93.3%). The stock base weights under the same prompt scored R24 93.34 with 13.3% clean (2 of 15). All R24 and clean figures in this card are the whole-reply variant; see the methodology note under weaknesses.
• Prompting cannot close the gap. Pasting the entire rule book into the base model's system prompt lifted it from 93.34 to 97.16 R24 and from 13.3% to 33.3% clean - better, but still two thirds of replies broke at least one rule. The fine-tune reached 100.0 R24 and 15 of 15 clean in the same condition, with zero recorded violations.
• The two habits that break Mikrodev compilation are gone. Across the base model's 30 delivered replies, named function-block parameters were the most persistent violation (7 replies in each condition) and TIME literals appeared in 7 minimal-condition replies. The fine-tune emitted neither, in either condition.
• It stops wrapping code in POU shells. The base produced POU headers in the minimal condition (no_pou_program in 5 replies, no_pou_fb in 2); the fine-tune produced none, delivering the body-only form the IDE expects.
• Terse and fast. Mean 340 output tokens against the base's 728 (median 269 against 680) and 5.8 s per reply against 7.2 s, falling to 5.1 s in the full condition. At 5.8 s it is the fastest per answer of the four models in this line; stcoder-qwen25-14b emitted fewer tokens per answer (288) but took 8.6 s to do it.
• It answers with code, not a lesson. The prose flag fired on 100% of this model's base replies and on 6.7% (1 of 15) of fine-tune replies. There are no thinking tokens to strip: the think metric is 0.0 in all four arms.
• Delivery was 100% in all four arms - every one of the 60 calls for this model returned code. No refusals, no empty replies. In the head-to-head that matters: it is the reason this model, not stcoder-qwen35-9b, holds the highest ChrF at full delivery (38.5 over 15 of 15, against 40.9 over 14 of 15).
• The quantisation choice is cheap for this model. An earlier internal 2000-prompt evaluation put its code composite at 0.844-0.846 across Q4_K_M, Q6_K and Q8_0, a spread of 0.002 or less. That evaluation's code holdout overlapped the training distribution by about 84%, so its absolute code scores are inflated and weakly discriminative between models - use it for this within-model quant comparison only, not for ranking the line. At matched quant this model is roughly half the size of the 14B (Q6_K 5.82 GiB against 11.29 GiB).

Weaknesses

• Hex literals survive when the prompt supplies them. On the VFD status-word prompt, where the drive manual's masks were quoted as 16#0001, 16#0002, 16#0008, 16#0080 and 16#0F00, the fine-tune reproduced them verbatim - R24 97.06, no_based_literal, and the only violation in this model's minimal arm. It occurred in the minimal condition only: with the full rule book in the system prompt the model's full arm recorded zero violations on all 15 prompts. Give it decimal masks or bit indices instead.
• Rule-clean is not compile-clean. On the drilling station prompt the fine-tune scored R24 100 but declared TYPE E_Station : (IDLE, CLAMPING, DRILLING, RETRACTING) and then branched to a DWELLING state that is not a member of that enumeration. It will not compile as written.
• Logic errors occur in rule-clean code. The bottle counter block (R24 100) incremented the shift counter inside IF bResetActive THEN instead of clearing it. The blink oscillator (R24 100) called the same TON instance twice in one scan with two different presets, tBlink(..., BLINK_MS) then tBlink(..., DARK_MS), which will not produce a 500 ms / 1500 ms flash. R24 is reference-free and scores dialect compliance only.
• Declarations can drift from the body. The seal-in block declared HOLD_MS : INT := 500 and never used it, while a comment claimed the button 'must be held for 500 ms before pump runs' - behaviour the code does not implement.
• Trailing prose can be wrong. On the pump-block prompt under the full system prompt, the fine-tune appended an explanation stating 'The fault latch is shared across all instances, so a single overload trip on any pump will trip the latch for all three' - untrue of the code it had just written, which is per-instance. Read the code, not the summary.
• Closer to the reference is not universal. ChrF fell below the base on 3 of the 15 minimal-condition prompts: the reusable scaling helper (25.94 against 27.76), the first-out fault annunciator (32.23 against 35.92) and the machine data grouping prompt (29.54 against 29.83). On the scaling helper it also invented raw endpoints the prompt did not specify (RAW_MIN : INT := 3200).
• Rule-book prompting slightly hurts. The full condition raised R24 from 99.80 to 100.0 but lowered ChrF from 38.5 to 35.3 and the composite from 0.844 to 0.833. There is no benefit to restating the dialect.
• The comparison was not quantisation-controlled. The fine-tune ran at Q8_0 (stcoder_qwen25-7b:q8); the run data records no quantisation for the base arm (qwen2.5-coder:7b), so 'effectively Q4' is an inference from the Ollama library default rather than a recorded value. The tokens-per-second figures (103.6 fine-tune against 154.1 base) are therefore not comparable - the fine-tune wins on wall clock per answer only because it emits under half as many tokens.
• Methodology, stated identically in all four cards: the R24 and clean figures quoted here are computed over the whole reply. Base replies were prose-wrapped 66.7-100% of the time across the line (100% for this model's base), and scoring only the fenced code moves the pooled base clean rate from 6.7% to 10.0%; this model's own base figure happens not to move (13.3% clean and R24 93.34 whole-reply against 93.53 fence-only). The base-to-fine-tune gap is not sensitive to the choice, but the variant has to be named.
• The study is 15 prompts, one seed, greedy decoding, on one machine. It is a controlled comparison, not a broad benchmark.

Not the right tool for

• Tool calling or function calling of any kind. The capability was trained and measured across this line, but only the Qwen3.5-9B family learned it usefully (tool-call composite 0.816 at Q8_0, 0.805 at Q6_K, 0.642 at Q4_K_M); this model's family scored 0.02-0.06 and the Gemma family 0.00. Because it was not usable across the line it was dropped as a product decision, and these builds are published and supported as chat-only models.
• Agent frameworks that expect structured JSON actions, MCP tool schemas, or a ReAct-style action loop.
• IEC 61131-3 dialects other than Mikrodev LogicStudio. The fine-tune was trained to suppress TIME literals, named FB parameters, POU wrappers, STRUCT and based literals - all of which other runtimes legitimately require. Output will need rewriting.
• Safety-instrumented functions, emergency-stop chains or any SIL-rated logic without full engineering review. Nothing in this evaluation measures functional safety.
• Whole-project architecture. The study covers single blocks up to about 970 tokens; multi-block projects, device configuration and signal maps are outside what was measured.
• STRING handling and text formatting. STRING types, string functions and single-quoted literals are outside the dialect, and the base model's attempts at them were among the recorded violations (no_STRING_type, no_single_quote).
• General programming, code review, or reasoning tasks. This is a 7B model fine-tuned on one narrow dialect, not a general assistant.
• Anyone unwilling to compile before deployment. Every failure case listed above was found by reading the code, and would have been caught by the compiler.

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.

stcoder-qwen25-7b buys you one thing reliably: Structured Text that obeys the Mikrodev LogicStudio dialect without being told the rules - R24 99.80 and 14 of 15 replies rule-clean from a short system prompt (whole-reply scoring), where the same base weights managed R24 93.34 and 2 of 15, and where pasting the entire rule book into the base still left two thirds of its replies non-compliant. It does that in under half the tokens and about 5-6 seconds a reply, from a 5.82 GiB file, which is why it is the default recommendation of the four at Q6_K: fastest per answer, smallest to run, 100% delivery in all four arms, and the highest ChrF among the models that delivered every reply. What it does not buy you is correct logic: it produced an undeclared enumeration member, a counter that incremented on reset and an oscillator that reuses one timer instance twice per scan, all while scoring a perfect dialect score. It is also a chat-only model - tool calling was dropped for this release. Compile every block in LogicStudio and read the declarations before anything reaches a controller.