Hi Daniel,

Thanks for the explanation. The mapping you described is also one of the
main challenges we face in our domain.

We focus on CIM and EAP systems. Each piece of equipment has its own
process parameters and recipes, and each recipe contains a corresponding
set of parameter values. During
production, we need to monitor both the actual process values reported by
the PLC and the configured recipe setpoints.

A key challenge is mapping PLC variables to the equipment process-parameter
model. Efficient bulk reading is essential as well. In our current
implementation, we group
parameters into contiguous PLC address ranges and read each range as a
block, rather than issuing a separate request for every variable.

Our current architecture is EAP → CIM → PLC. The CIM system owns the
equipment model, the recipe-parameter mappings, and the equipment adapter.
It maps the model parameters to
PLC variables and communicates directly with the PLC. The EAP system uses
the CIM model and services for recipe management, equipment coordination,
and process supervision.

This is why I am particularly interested in where the mapping between a
Malbec process variable and its PLC variable will live. Will the Malbec
plant project contain the mapping
metadata, with Merlot acting as the communication adapter, or will Merlot
own both the mapping and the PLC communication?

I hope this real-world use case is useful for the design.

Best regards,
Tom

Daniel Campos <[email protected]> 于2026年9月20日周日 11:25写道:

> Hi, Tom!
>
> Thanks a lot, I appreciate your interest.
>
> Regarding the tags and their relationship to the physical model, the main
> goal of this model is to parameterize the plant and define the process
> variables that will mirror those in the PLC. In Malbec, they're given
> magnitudes, engineering units and other features for logging and auditing.
>
> As I mentioned at the end, communication is the scope of the batch module,
> which I left as a placeholder for now.
>
> I'm planning to develop a recipe editor that is fed with the variables
> defined in the plant project.
>
> Later, those recipes, which are basically just the variables with defined
> values and an execution order, will be downloaded to the PLC. Malbec will
> then be monitoring and controlling the process state, as well as generating
> logs.
>
> This entire communication loop will go through Merlot as a gateway
>
> Best regards, Daniel.
>
>
> El sáb, 19 de sept de 2026, 22:37, Tom NewChao <[email protected]>
> escribió:
>
> > Hi Daniel,
> >
> > Congratulations on your first ASF contribution!
> >
> > I am also relatively new to the PLC4X community and am currently working
> on
> > the plc4net revival. It is encouraging to see another contributor working
> > on industrial automation
> > tooling.
> >
> > The separation between the S88 domain model, persistence adapters,
> > application use cases, and the NetBeans UI looks very interesting. I am
> > also interested in how the physical
> > model may eventually relate to PLC tags and industrial data sources.
> >
> > I just wanted to say hello and wish you success with the contribution. I
> > look forward to following its progress.
> >
> > Best regards,
> > Tom
> >
> > Daniel Campos <[email protected]> 于2026年9月19日周六 05:02写道:
> >
> > > Hi everyone, let me introduce myself again. I'm Daniel Campos (Dandrvms
> > or
> > > dacmz), from the CEOS Automatización team, working alongside Luis
> > Rodríguez
> > > and César García. As I mentioned before, I'm working on Malbec, an IDE
> > for
> > > industrial configuration built on top of the NetBeans RCP.
> > >
> > > Today I just made my first PR for this project in the feature/app
> branch
> > at
> > > plc4x-extras, marking my very first contribution to the foundation.
> Here
> > is
> > > a breakdown of the project structure:
> > >
> > >
> > >    - /api : Domain model and ports. S88Element is the minimal model
> unit:
> > >    an S88 entity that can hold children and structured property bags.
> > >    S88PlantModel is the orchestrator: the in-memory root of the element
> > > tree,
> > >    the registry of classes/enumerations, and the event bus. Supporting
> > > classes
> > >    provide S88ElementClass (reusable property templates),
> S88Enumeration,
> > >    S88Level, DataType/EngineeringUnits/Magnitude, the
> > >    S88ChangeEvent/S88ChangeListener observer contract, and the
> > persistence
> > >    contracts S88Repository, S88Storage and S88RepositoryProvider.
> > >    - /data : Serialization adapters implementing the contracts above.
> > >    B2MMLRepositoryImpl parses/writes the main model using B2MML, the
> MESA
> > >    International schemas compiled with XMLBeans. AXMLRepositoryImpl
> > >    imports/exports the Rockwell FactoryTalk Batch .axml format. Formats
> > are
> > >    pluggable: a new format is a new S88RepositoryProvider discovered
> > > through
> > >    NetBeans Lookup.
> > >    - /core : Application layer. A set of use cases (create, update,
> > delete,
> > >    rename elements; manage class templates and struct entries) are the
> > only
> > >    way to mutate the model. Every mutation fires an S88ChangeEvent, so
> > the
> > > UI
> > >    stays in sync.
> > >    - /plant : The NetBeans sub-project in charge of the plant model's
> > >    lifecycle: project providers and factories, the hierarchy tree nodes
> > > (one
> > >    per S88 level), project actions (import/export, templates,
> > enumerations,
> > >    delete), and the shared panel/dialog builders reused across the
> > > different
> > >    S88 levels. Loading and saving delegates to data repositories; UI
> > > refresh
> > >    is event-driven, not manual.
> > >    - /project : The NetBeans project type (wizard, factory, folder
> > >    installer, logical view) that hosts the plant sub-project.
> > >    - /batch : Placeholder module reserved for future recipe management
> > and
> > >    supervision.
> > >
> > > The Process Cell config editor is intentionally empty; the properties
> > > dialog exposes only the General tab (name, level, class, display
> > creation),
> > > while content tabs (Attribute Tags, Parameters/Reports, Arbitration,
> > etc.)
> > > are placeholders. These are the targets of upcoming updates.
> > >
> > > Recipes/batch supervision and generic ISA-88 runtime support are
> outside
> > > the scope of this PR (batch is a placeholder).
> > >
> > > Best regards, Daniel.
> > >
> >
>

Reply via email to