mike@biorealize
Are there well-defined ways to do the following:
- Extend the list of intrinsic blocks (hacking iec_std.csv or changing structures.py would work, butnia there a cleaner option)
- Add in a specialized code generator. I would like to compile the TC6 XML to JavaScript.

Quote 2 0
jinyistudio
I like your : a specialized code generator. I would like to compile the TC6 XML to JavaScript.
[jinyi_title_1p] 
Delphi, B4A, B4J, C#/Mono, Mitsubishi Q-PLC
[image]
Delphi, C#, Q-PLC, B4A, B4J, Raspberry PI2
Delphi, C#, Q-PLC, B4A, B4J, Raspberry PI2
[image]
Delphi, C#, Q-PLC, B4A, B4J, Raspberry PI2
Quote 0 0
thiagoralves
mike@biorealize wrote:
Extend the list of intrinsic blocks (hacking iec_std.csv or changing structures.py would work, butnia there a cleaner option)

The blocks are kinda standardized by IEC 61131-3. If you want to add more blocks, you will also need to add the code for it on the matiec compiler, or it won't be able to generate C code for them. However, that's the hole purpose of creating functions and functionBlocks on the editor. You can create your own customized block by writing code as a function in any of the 5 languages supported. After creating the block you just need to drag and drop it on the main program window, that's it.

mike@biorealize wrote:
Add in a specialized code generator. I would like to compile the TC6 XML to JavaScript.

Perhaps the easiest way to do it would be to develop a Structured Text (ST) to JavaScript compiler. The PLCopen Editor supports 5 different languages, where 3 of them are graphical. Generating JavaScript after all these languages would be a mess. PLCopen Editor already compiles all of them into a single ST code. If instead of calling matiec to compile the ST code into C, you call your own ST to JavaScript compiler, you will achieve what you want.
Quote 0 0
mike@biorealize
The structured text output does not seen to generate correct code for SFCs when there are selective transitions.  However, the TC6 representations seem to work perfectly -- I was able to write stuff in OpenPLC Editor and pull it into CODESYS and vice versa.  Interestingly, OpenPLC Editor seems like it is a more faithful implementation than CODESYS, and I found it a lot more intuitive (most of my experience was from being part of the team that did Moore APACS and 4Mation "back in the day").

The idea of a vendor-specific set of standard function blocks is not particularly novel -- for example Siemens has vast libraries of standard function blocks -- the idea is that "IEC Standard" is just a minimal set of standard function blocks.  It should be possible to add more function blocks that are "standard" (i.e. not necessarily build by compiling a user defined block.

Ideally, the compiler should be a plug-in that allows various compilation options for various targets.  Compiling to C is nice in some cases, but it makes it hard to do things like incremental configuration of a running system (which APACS could do over 20 years ago) -- so a more flexible compilation approach would open up a lot of options.  So using the TC6 as input for a compiler seems much easier.  Not only does the ST generator have some flaws, but using it as the source for a cross-compiler would involve making a comprehensive ST parser, generating a parse tree and then compiling from that parse tree.  Since the TC6 is fairly close to a parse-tree, it seems better to start with TC6 and use a mix of XSLT and some DOM hocus-pocus to generate code.  Such an approach would still need to contend with the embedded pieces of ST contained in the TC6, so there is no getting around the need to make an ST parser, but those chunks of ST would be fairly small, and most of the symbol table elements (local variables, steps, actions transitions etc.) are already in the TC6 XML, and already "contextualized" by being contained in the POU that owns them -- so that task is much simpler than the task of making a comprehensive ST compiler that acts on the ST exported by OpenPLC Editor.

At any rate, the core of the program is great.  I am thinking about seeing if I can reverse-compile a APACS configurations into OpenPLC editor.  I am pretty sure that it would work quite well, since the editor's object model seems to capture most of the more exotic features of IEC 61131-3 that make APACS so hard to port to other systems.
Quote 1 0
thiagoralves
mike@biorealize wrote:
most of my experience was from being part of the team that did Moore APACS and 4Mation "back in the day".

I didn't know you worked on the team that created these PLCs. That's very nice! I could use your help to improve the OpenPLC if you are willing to. My main focus right now is on communications protocol. I'm rewriting from scratch my Modbus implementation (because it had some security issues) and plan to write a DNP3 implementation shortly. I know very little about Siemens Profibus, but I would love to see OpenPLC supporting that as well. What exactly was your work on these projects?
Quote 0 0