Add Support for POU Properties

[engineerjoe440]

Might just be something I'm overlooking, but as it exists, I don't think there's a way to parse POU Properties; or is there one that I'm just missing?

This seems a bit tricky, since a property has one or two methods, but neither method has a traditional "declaration" like other METHOD objects or, really, anything else in 61131. This makes me wonder if it's necessary to have a separate function responsible for parsing them and using a subset of the Lark rules? Not sure... What do you think?

[klauer]

It's a good question - one I waffled back and forth with for a bit before settling on what's in blark right now. There's a longer discussion - more a monologue perhaps? - here: https://github.com/pcdshub/pytmc/pull/274

The current state is that the grammar allows for this for the getter:

PROPERTY PUBLIC LogToVisualStudio : BOOL
VAR
END_VAR
LogToVisualStudio := bLogToVisualStudio;
END_PROPERTY

And this for the setter:

PROPERTY PUBLIC LogToVisualStudio
VAR
    bValue : BOOL;
END_VAR
THIS^.bLogToVisualStudio := bValue;
END_PROPERTY

Note the return type in the getter and not on the setter.

Now you might then wonder "how do you associate a method or a property or an action with a function block?" The best I could come up with is that it's parsed-order-dependent. Properties/methods/actions defined as part of of a larger set of source code would implicitly apply to the most-recently-seen function block. That's what this first pass at the summary module does: https://github.com/klauer/blark/blob/e572219d9a6d29493b8a542e1801faa94ee5ead7/blark/summary.py#L789-L889

None of this is set in stone, though, and I'm definitely open to better suggestions!

[engineerjoe440]

FWIW, I've been using the method of "constructing" properties in this way, and it seems to be working for the most part.

[klauer]

Glad it's at least mostly worked. I'm honestly not entirely convinced of the method, as I think the above comment touched on.

It's been on the back of my mind to look back into maybe natively supporting .TcPOU (and related) files here without any pytmc translation. I think it'd likely be cleaner in the end, even if it means the grammar has to get restructured to support it. (Don't hold me to this statement, though 😁 )

[klauer]

64 aims to address this without custom grammar.

Properties from TwinCAT source code files can be parsed piece-by-piece getter/setter declaration/implementation (for a total of 4 different code blocks). Then it's up to you to keep track of which corresponds to the getter and which corresponds to the setter.

Writing a custom blark input handler can be an option here. That PR also tries to make it easier to parse arbitrary individual code sections more easily (even without the input handler) in blark.parse.parse_source_code - starting_source can be specified to a grammar rule such as data_type_declaration or program_declaration (or any other library declarations). new_parser still lets you dig deeper into non-top-level rules.

[klauer]

Properties are reasonably well-supported now (as of v0.7.0) - some tweaks may come down the line. Closing for now