klauer
commented
2 years ago At least one more thing to add, I just realized - PROPERTY is missing, too.
Closed klauer closed 2 years ago
klauer
commented
2 years ago At least one more thing to add, I just realized - PROPERTY is missing, too.
ZLLentz
commented
2 years ago Is this a typo in the description's example?
$ pytmc code pytmc code FB_PositionStatePMPS_Base.TcPOUThe tradeoffs here with making the "invalid" twincat code seem well-motivated. I don't think there are any plans to use this project to generate runnable twincat programs, right?
klauer
commented
2 years ago Fixed example, consolidated code (PROPERTY made it almost a necessity).
Added more syntactical oddness with PROPERTY:
PROPERTY PUBLIC FB_Listener.LogToVisualStudio.GET : BOOL
VAR
END_VAR
LogToVisualStudio := bLogToVisualStudio;
END_PROPERTY
PROPERTY PUBLIC FB_Listener.LogToVisualStudio.SET :
VAR
bValue : BOOL;
END_VAR
THIS^.bLogToVisualStudio := bValue;
END_PROPERTYThe unfortunate nature of action/method is even worse here, as there is now a getter/setter, and one has a return type whereas the other does not.
(If any external PLC coder people take a look at this output, they're likely to be rather confused. 🤷♂️ Sorry, PLC people!)
ZLLentz
commented
2 years ago Random thought: would it better to have the output look something this?
// Context: FB_Listener.LogToVisualStudio.GET
PROPERTY PUBLIC GET : BOOL
VAR
END_VAR
LogToVisualStudio := bLogToVisualStudio;
END_PROPERTY
// Context: FB_Listener.LogToVisualStudio.SET
PROPERTY PUBLIC SET :
VAR
bValue : BOOL;
END_VAR
THIS^.bLogToVisualStudio := bValue;
END_PROPERTYe.g., annotated real code rather than edited code?
klauer
commented
2 years ago I'll give it some thought, @ZLLentz - I'm not sure, to be honest. I'm pretty sure I'll need something where I can fully derive the context of a getter/setter/method based on its name - or at least something that's not a comment, though.
For reference, the underlying source from TwinCAT is: https://github.com/pcdshub/lcls-twincat-general/blob/d757b7fe70c695f852da11cb648394b9edb52a83/LCLSGeneral/LCLSGeneral/POUs/Logger/FB_Listener.TcPOU#L109-L129
klauer
commented
2 years ago I think I'll walk back my above statement a bit. It feels a bit off, but requires no modifications to syntax for ACTION/METHOD, at least:
FUNCTION_BLOCK abc
END_FUNCTION_BLOCK
ACTION action_name
END_ACTION
METHOD method_name
END_METHODaction_name and method_name can be assumed to be members of the most-recently-defined FUNCTION_BLOCK, even without a qualified abc.method_name in the definition.
However, PROPERTY is a bit different. I suppose the getter and setter could be defined with the same name, and one could have a return value and the other not?
The getter:
PROPERTY PUBLIC LogToVisualStudio : BOOL
VAR
END_VAR
LogToVisualStudio := bLogToVisualStudio;
END_PROPERTYThe setter:
PROPERTY PUBLIC LogToVisualStudio
VAR
bValue : BOOL;
END_VAR
THIS^.bLogToVisualStudio := bValue;
END_PROPERTYSeem a bit better, @ZLLentz?
ZLLentz
commented
2 years ago I don't fully understand all the implications, nor can I immediately tell the difference. I just thought it was worth considering if it was possible to annotate instead of modify. If it has at least been considered then I have no further input :+1:
klauer
commented
2 years ago OK, I walked back the dotted methods and such. I think this is probably good to go.
PROPERTY may still deserve a follow-up at some point (it's annoying to not know if it's the getter or setter, at the very least).
Closes #270 Closes #211
So, um
~The actual result here may not be "valid" IEC 61131-3 method/action definition code. Why? Well, TwinCAT, for example, does not store the source code of methods in plain text along with its respective function block. It has an XML container that describes a hierarchy of "POU contains actions, methods, declaration, implementation". So in the method definition itself,
METHOD methodnamethere does not need to be a reference to the containing POU.~~What is suggested and implemented here is the only thing I can think of - aside from giving up on plain text altogether for these - is to prefix methods and actions with
FB_Name- e.g.,FB_Name.MethodName.~~This will have consequences downstream for anything desiring to parse pytmc's "code" output (it'll be vital for blark, once I get there; otherwise it'll have no idea which method goes with which POU).~
~Open to thoughts/suggestions for alternatives.~
pytmc codeoutputpytmc codeto work with just a single code object, not a whole projectpytmc.__main__such thatpython -m pytmc {code,summary} ...worksExample
Property and method example:
Action example:
Additionally
I misconfigured my text editor at some point, leading to brackets-in-quotes wreaking havoc on further input. Please excuse the additional end-of-line comments that close those open brackets.