Skip to content

JeremyMedders/LogixLibraries

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

LL

This is my approach to implementing production-ready, "object-oriented" and "functional" styles of programming on Rockwell Logix5000 controllers.

With the exception of supporting sample files (FactoryTalk View ME screens/definitions, etc.), this repository contains only .L5X (Logix 5000 XML) files.

Structured text is generally used for AOI definitions to ease porting between IEC 61131-3 platforms. Dependencies will be documented where possible.

Wiki: https://github.com/JeremyMedders/LogixLibraries/wiki

Content

  • Array (Array_)
  • CIP (CIP_): Common Industrial Protocol utilities and structs.
  • Device (Dvc_): Device drivers.
  • Filter (Filter_)
  • I/O (IO_): IO helpers and diagnostics.
  • Math (Math_): Assorted functions.
  • Message (Msg_): Generic message helpers and utilities.
  • Modbus TCP (MBTCP_): Modbus TCP client driver.
  • Numeric (N_): Forms string representations of various types of numbers.
  • Parameter (Par_): Experimental generic parameter handling.
  • Process (Op_): Lightweight PAx-style blocks.
  • Recipe (Rec_)
  • RTC (RTC_): Precision pulse/timing utilities.
  • String (Str_): String utilities.
  • System (Sys_): Diagnostics, WallClock utility/format generator, ISA 18.2 alarms with parent "class", and other utils.
  • Time (T_): Date and Time utilities (ISO 8601 included).
  • UI (UI_): HMI helpers.

Naming follows PlantPAx (sensibly)

  • Inp_, Cfg_, PCmd_, OCmd_, MCmd, XCmd, PSet_, OSet_, MSet, XSet
  • Out_, Sts_, Val_
  • Ref_
  • Wrk_: Avoided using this for local AOI tags (forgoing a prefix distinguishes them from parameters).
  • At times, parameter names were modified for consistency / clarity, particularly with my CmdSrc substitute.
  • External access (Read, Read/Write, None) are set where sensible.

UDTs follow the corresponding AOI:

  • ST_Dvc_abc
  • ST_Sys_xyz
  • And so on.
  • External access (Read, Read/Write, None) are set where sensible.

AOI variants (future)

Depending on use case, some of the features of an AOI will go unused. Tentatively, I think a simple suffix to the block name could differentiate it from others. Example:

  • Dvc_PF525: Full features. Drive parameters managed and updated dynamically from the PLC using added Class 3 messaging.
  • Dvc_PF525_L: Light version. Block capable of running the device but limited to the scope of its Class 1 connection data. Unused block parameters deleted.
  • Both of these would still contain an "Op" strategy Command Source block and identitical core Local data to keep overall UDT sprawl to a minimum.

So we have...

  • No suffix: base/full
  • L: Light
  • M/T: Mirror/Monitor or Twin. This would be an AOI in structure only, no other code. Perhaps useful for a monitoring or concentrator PLC/DCS.
  • S: Simulator

To-Do

  • Performance profiling database
  • Documentation about known working .L5X attribute values
  • How to put the CanBeNull parameter attribute in AOIs to use
  • Alarm class documentation
  • Design pattern guides and rationale
  • Overall repository continuous improvements
  • Documentation for the PowerFlex 525
  • OSCAT library port
  • Arduino PLC data exchange
  • Pointers vs. InOut / ByRef data handling and (safe!) examples
  • AOI dependency chart/tree/spreadsheet
  • Produce/Consume tags "the smart way" guide with UDTs and sample
  • UI_ListVisitor
  • Improved PowerFlex 525 AOI

Done:

  • Open discussion board
  • OSCAT vector math
  • CIP base data types (Identity, Port, EnetLink, TCPIP)
  • REAL array math
  • Preliminary wiki structure and topics
  • MBTCP client basic documentation
  • UDT templates to aid in implementing the BIT overlay construct
  • IO module / connection templates (ongoing)
  • Numeric library release
  • PackML state machine starter and sample
  • MIT license
  • Str_Copy
  • Initial parameter library (experimental)

"Legacy" hazards

  • Some of the library content makes use of unsigned (USINT/UINT/UDINT/ULINT) and 64-bit (ULINT/LINT) types, limiting their use to current-generation hardware (CompactLogix 5380/5480 and ControlLogix 5580 families).
  • Logix 5370/5570 and earlier families are unfortunately artificially limited to signed types (SINT/INT/DINT/LINT), so code will need to be modified to accomodate where necessary. I built this library to be as lean as possible, so the backwards accomodation would have ended up bloating solutions across the division.
  • Sample code heavily favors program-scoped tags to promote organization and consistent naming. For that reason, these sample programs will sometimes have program-scoped Messages and will require accomodation for pre-5x80 hardware.

Always

  • Engineer to win.
  • Feel free to ask any questions.
  • Please provide any feedback you have.

JeremyM