Library with no code

Share Info & Ideas Other Info
1

Check this mind experiment. A Software Library with No Code

3

Spec-Only Libraries for B&R PLC Programming

Inspired by the concept of “software libraries with no code” – libraries that contain only specifications and tests, with AI generating the actual implementation on demand.

1. Utility Libraries for Structured Text

Similar to utility libraries in other languages, spec-only libraries could exist for common PLC tasks:

Library Description
stringutils String manipulation (parsing, formatting, validation)
timeutils Time handling, format conversions, timers
mathutils Interpolation, filters, statistical functions
datalog Data logging to files/databases

SPEC.md would define:

  • Input/output data types (REAL, STRING, UDINT…)
  • Boundary behavior (overflow, null values)
  • Timing requirements (max execution time)

2. Function Blocks from Specification

Instead of copying ready-made FBs, there would be a specification + tests:

SPEC: MotorController_FB
- Inputs: Enable, SetSpeed, Direction
- Outputs: Running, AtSpeed, Error, ErrorID
- States: IDLE -> STARTING -> RUNNING -> STOPPING
- Timeout for StartupTime: parameterizable
- ErrorID according to B&R conventions (see table)

tests.yaml:

- name: "Start motor"
  inputs: {Enable: TRUE, SetSpeed: 1000}
  after_cycles: 10
  expected: {Running: TRUE}
  
- name: "Emergency stop"
  inputs: {Enable: FALSE}
  expected: {Running: FALSE, immediately: TRUE}

3. Communication Patterns

Specifications for typical communication tasks:

  • OPC UA client for reading/writing variables
  • MQTT publisher with retry logic
  • Modbus TCP master for specific devices
  • REST API client for cloud services

Advantage: AI generates code tailored to the specific project and HW configuration.

4. Motion Control Sequences

Motion sequence specifications:

SPEC: HomingSequence
Purpose: Safe axis homing with sensor reference

Parameters:
- HomingVelocity: REAL (default 10 mm/s)
- HomingDirection: DIRECTION (default NEGATIVE)
- SensorInput: BOOL reference

Sequence:
1. Verify MC_Power is active
2. Move towards sensor at HomingVelocity
3. On sensor detection: MC_Stop
4. Move opposite direction at HomingVelocity/4
5. On leaving sensor: MC_SetPosition(0)
6. Done

Errors:
- Timeout 60s -> ErrorID 1001
- Limit switch -> ErrorID 1002

5. HMI Templates and Visualization

Specifications for mappView widgets and pages:

SPEC: AlarmPage
- Display active alarms with timestamp
- Filter by severity
- Acknowledge individually or in bulk
- History of last 100 alarms
- Export to CSV

Practical Implementation

Spec-only B&R library structure:

/my_br_library/
├── SPEC.md              # Detailed specification
├── tests.yaml           # Test cases
├── INSTALL.md           # AI prompt
├── datatypes.typ        # Data type definitions (must be fixed)
└── examples/
    └── usage_example.st # Usage example

INSTALL.md for B&R:

Implement [NAME] for B&R Automation Studio in Structured Text.

1. Read SPEC.md
2. Use data types from datatypes.typ
3. Implement as FUNCTION_BLOCK / FUNCTION
4. Follow B&R conventions (AsXxx libraries, Error handling)
5. Generate test program
6. Reference: plc.h, plctypes.h for data types

When It Makes Sense vs. When It Doesn’t

Makes Sense Doesn’t Make Sense
Simple utilities (string parsing) Safety functions
One-off sequences Critical motion control
Prototyping Certified libraries
Specific customer requirements Performance-critical code
Communication with non-standard devices Core automation

Concrete Ideas to Start With

  1. String Parser - parsing configuration strings (e.g., “IP:192.168.1.1;Port:502”)
  2. DataLogger - saving variables to CSV with file rotation
  3. StateMonitor - generic state machine with transition logging

References

4

Thanks for your post @Vratislav , very interesting!

1 Like