Constructor Issues about libplctag.net HOT 8 CLOSED

The intent of the C library plc_tag_create() constructor taking a single argument for all the attributes was to enable users to read in tag descriptions from outside the code. E.g from a config file or database. The code using tags should (ideally) be able to operate with any arbitrary tag description. This is a major part of the driver that led me to not have a PLC object anywhere in the code model. There are just tags. The cost is that it is difficult to validate the attribute string until run time.

Here are the main benefits that I see from the current model:

• Ability to change tags via text entries in config files.
• Cleaner app-level resource management with only one thing to manage: the tag itself.
• Makes it a little easier for the library to manage internal state and resources for performance, such as packing requests or caching tag types.

The big disadvantage is that string data is essentially untyped and there is not much you can do to validate it until run time. And that is a big disadvantage.

I can certainly revisit the idea of having a PLC object. But I would like to explore how to get the benefits of reading tags from a config file and still having compile time checks that help prevent errors.

Part of the "fun" here is that different attributes may interact and change behavior significantly or be invalid in some combinations.

I wonder if it would be useful to have a Zoom conference or some more direct talk? Does GitHub have a chat tool? I feel like some brainstorming might help.

from libplctag.net.

I posted a long idea of another core library API on the cross-team discussion list. It would result in a completely different API, but one that seems to match what you are trying to do more closely. Please let me know if that direction is one that would be useful!

from libplctag.net.

An implementation has been pushed to https://github.com/libplctag/libplctag.NET/tree/better-constructor.

This fixes a whole bunch of issues, and having the Plc object is not required - more a convenience than anything. I suppose the next thing people would want after that is to use the Plc to trigger a Read/Write of all of the tags embedded within it - maybe we should remove this for now until its clear what the use-case is.

from libplctag.net.

I was thinking about this during a long Zoom call today. Something has been bugging me about the PLC model and how it maps to the use cases.

There are two different use cases that people tend to solve with a PLC object:

1. To consolidate many of the duplicate attributes like the host information.
2. To enable the application to do actions against many tags at once.

I break it down like that because I think there are actually two very different use cases here and they are being conflated, at least in my mind. I will cover these in reverse order.

The second one stands out. I have two example use cases where I wanted to work with groups of tags, but the group <-> PLC mapping is not correct.

I have worked on several PLC systems where there are multiple machines each with its own PLC (or PLCs) and in order to get system status, you read the same tag in multiple places. In that case, the use of a PLC object for #2 fails. These tags are all in different PLCs.

Another thing that I find I have done a lot is reading status from multiple tags in the PLC at the same time, but with definite grouping: some groups of tags are read a lot, some rarely, some are really treated as singletons (often command triggers). In this case, often the underlying model is similar, there are many copies of the same machine, but there is a central PLC managing them. In systems like this, you may need to read all the wash tank temperatures every five seconds, but the autoclave temperatures every half second. So again, the use of a single PLC object fails to match the actual use. You could use read caching settings or multiple PLC objects, but then it starts getting a little weird.

So I think it might make sense to split out multiple tag handling from the PLC object. Set that aside for a minute.

For #1, consolidation of multiple attributes is a reasonable thing. There can be a lot of attributes and many are common. Even there, I can see a different possible way to describe this data.

Here is a different proposal: split the visible things into three: a) tags, b) tag groups, c) attribute groups.

1. Tags are pretty much as is today except that when created they take an attribute group or a string.
2. Tag groups simply group any set of arbitrary tags and allow read/write and abort operations on the group. Along with adding and removing tags from groups there are not many other operations.
3. Attribute groups collect key/value attributes. They have some special operations such as creating the union of multiple groups and returning a new group with all the attributes of the inputs (duplicates and conflicts would need to be dealt with in some way).

Now taking the use cases again:

1. sharing common attributes: use an attribute group. Create a group for a PLC. Then creating all the tags for that PLC becomes much less verbose. Have a lot of tags that are all the same type but different names? Use an attribute group to set up all the attributes except the name.
2. doing operations on groups of tags: use tag groups. If you want to read status words across multiple PLCs, tag groups are fine. If you want to read many status words within a PLC, use tag groups.

I think these three concepts would cover the two use cases I have above.

I could support these things in the C library, but there are some things that make this better in higher level languages. Most higher level languages have native support for dictionaries/hash maps etc. Most have much easier string handling. Creating something like an attribute group is just a hash map with some added entry validation and a few extra operations to deal with adding two together.

For tag groups, the challenge is what to do if one or some of the tags does not return the same status as the others. If you can throw exceptions or some other out-of-band error handling mechanism, you can throw for each tag and handle each tag. In C... not fun. I could call a callback I guess. Other than that, a tag group is just an object with a list/array of tags.

Assuming that C# can do pretty much everything that C++ can, then you could start with a Tag class that has multiple constructors:

• One that takes a string just like the C library.
• One that takes an attribute group.

Attribute groups need some specialized validation, but that can start off limited and gradually get more intelligent with time. No need to do massive effort initially. Any grouping of attributes can be broken out and shared.

I think that this breaks out the various concepts more cleanly with a separation of concerns. While a PLC object does model the physical aspect of the machine(s), it does not match the use cases as well. Tag groups allow you to model the systems (which may not match the physical plant).

This got a little long!

from libplctag.net.

Quite an educational post Kyle, nice work!

I must confess I haven't been in any multi-PLC scenarios but this makes a tonne of sense.

I've updated the branch to remove the Plc object and added two new objects:

• AttributeGroup is for configuration, which can be passed into the Tag constructor.
• TagGroup is for bulk actions (Init/Read/Write) which is a collection of tags and provides those three actions (plus async versions).

Example usage can be found here.

I haven't actually tried any of these examples because I only have one controller, but they seem to do roughly the appropriate thing.

from libplctag.net.

I'm not super happy with the API for these - I might search around for other drivers to see how they implement it, or how they expect consumers to make use of their API.

from libplctag.net.

I might merge the work around this that pertains the different constructors and move this discussion to a different issue.

Update: maybe I won't close this issue, but I will mention that the first 4 (of 5) points of the proposal were implemented in #68

The branch that now contains the TagGroup and AttributeGroup is https://github.com/libplctag/libplctag.NET/tree/groups

from libplctag.net.

Works for me. I have not had time to look at the new object APIs. Work calls :-(

from libplctag.net.