Writing a ST compiler

Join Date
Apr 2002
Location
No income tax, no capital gains tax. Freedom!
Posts
8,351
When it comes to compiler writing I am a newb. However, I am not like the major PLC manufacturers that have a piece of sh!t ST compiler just to say they have one. By now you should know I am a no compromise fanatic. I want to be best but I am almost starting from zero.

What I do know is that I should start with the public domain version of lex and yacc. The public domain version is flex and bison. These two programs require a lex and yacc files. The lex file specifies what the tokens are. Tokens are key words like if then, while , variables and operators.

Yacc or Bison generates a parse tree. Once you have the lex and yacc definition you are 90% of the way there. Once you have the lex and yacc file working then the last part is the code generator. There is one function called ex() that generates all the code and it is a big switch or case statement.

I will write more as I make more progress. I intend this thread to be kind of like a blog. So far I have been able to get some example programs going.
 
And this still will be a compiler for IEC61131 ST, with all its limitations, outdateness and ugliness, right?

I understand this is what your business requires. But I wish someone was thinking on some major improvements some day.
 
And this still will be a compiler for IEC61131 ST, with all its limitations, outdateness and ugliness, right?
Yes, that is what the market wants or will accept. I would be happy with a stripped down version of C# or even basic. The big thing is to be able to do math easily since motion control requires more math than other types of projects.

I understand this is what your business requires. But I wish someone was thinking on some major improvements some day.
What would be an improvement? C#, Python, Pascal, VB? C# or other languages would need to be extended to be able to force variables to be at a certain location.

Object oriented languages are much harder to implement but object oriented languages would be the next step forward. I have a pretty good idea of how to generate code and parse data. The part I haven't worked out is declaring variables and setting up the symbol table. I haven't looked at our current compiler to see how that was done yet.

At this point I just want to be able to convert the BNF ( compiler language description ) to a Lex and Yacc file.
 
What would be an improvement? C#, Python, Pascal, VB? C# or other languages would need to be extended to be able to force variables to be at a certain location.
I think VB has the most global appeal but C# would likely be acceptable as well. I know Beijer has selected C# as the scripting language for their latest HMI offering. CoDeSys has adopted Python as a scripting language but I believe it is only for things such as conditional compiling or repetitive GUI tasks and does not directly affect the code on the processor.

Object oriented languages are much harder to implement but object oriented languages would be the next step forward.
I hear this a lot but it also seems people have trouble or reluctance even writing their own Function Blocks (which in my mind are simple objects: they have code and encapsulate their own data). Do you really want to support inheritance, polymorphism, overloaded operators, etc. for the 3rd shift maintenance guy?

Sounds like you have your work cut out for you!
 
None of the curremt automation vendors use object oriented languages on the controller level. It is all IEC ST, only exception I know is B&R that has ANSI C which isnt OO.
On the HMI level, many support some kind of "scripting", VBS, VBA, C script. I think I saw a press release that Siemens intend to go to C# for the higher level SCADAs. But that is for HMI/SCADA, not for the controllers.

I think that it is very wise to chose IEC ST, even if not everyone find it to be perfect. It is the closest there is to an industri standard at the moment.
 
It is the closest there is to an industri standard at the moment.
ST a specification. I wouldn't call it a standard unless it is used by most people and comes standard with the PLCs.

I am going to write a ST compiler but there appears to be 3 main parts to the complier. The lexical scanner(Lex), the parser(Yacc) and the code generator. The code generator is where I will need to spend the most time to get something running. The code generator can be common between many languages. This may be a naive comment but the different languages must do the same math, IF, THEN, WHILE, CASE and other common tasks. There should be a lot of common code in the code generator.

Anyway, I found out that there is a Bison++ and Flex++ that supposedly generate C++ code instead of awful, 1870's like C code. I will try my current calculator flex and yak file with Bison++ and Flex++ to make sure they work.
 
As far as structured text in a PLC environment vs. some type of language for a heavy motion enabled platform goes, I would suggest looking at ABB's RAPID robot language. It is based on C and is very easy to learn and typically find it more powerful than the limited version of structured text based on IEC61131.

You can download a copy of RobotStudio from http://www.abb.com/product/ap/seitp327/049ffeb82687791ec12574b9004958cf.aspx

This will work 30 days without a license, but other than that it also supplies all the reference manuals that can be accessed even after the license expires.

Anyway, I have worked on many different motion and PLC platforms and ABB's RAPID has always been one of my favorite systems to work with.

Just one opinion of many,

Darren
 
Things I like about the language:

1. User Defined Data Types
2. Great built-in data structures (check out robtarget, jointtarget, pos, etc)
3. Concept of modules, routines, functions
4. Full extent of program flow control statements
5. great built-in functions for Euler angles, vector functions, etc
6. public/private data
7. local/global data
8. ERROR handler statement
9. TRYNEXT statement
10. Interrupts and traps

Things I like about their controller:

1. All backups are in text. This includes controller configuration data, programs, datapoints, etc
2. See #1
3. See #1 again

Darren
 
I will look at the ABB software to see what good ideas I can borrow.

dash, I have to crawl and then walk before thinking about running and copying the advance features of ABB.

I like the UDT idea. We don't support and array of UDT. That is something I want to do and is at the top of the priority list. Many of the other features we already support.

I am still going to write a ST compiler.

The last couple of days I have been taking some example code that compiles a C like language and I am changing it to a simple ST like language that outputs an IL like text.

I will write more when I have done something significant. I am thinking of posting links to the compiler on my FTP site. At first I think I will make the ST compiler generate IL. It should be easy to check the IL output then without having to really generate machine code.
 
I understand the crawl before you can walk. I was kind of building off of LadderLogic's comment and expressing an opinion for language style that has been more flexible than ST for motion related applications.

I do like ST for complex calculations in a PLC and also for parsing text (barcodes, RFID, etc). It does have most of the flow control that is available in RAPID. Then if you look at the ST implementation done by CoDeSys you will see they support some additions like true pointers, great for making generic function blocks that can directly manipulate I/O. I believe in the spec for ST, they do give the manufacturers the ability to extend the language in certain areas.

Darren
 
Oh come on.
3S software is a company that ONLY make the Codesys software.
Dont know how many people they are, but I would not be surprised if there are 10 people doing nothing but writing and testing the compilers.
No disrespect for Peter, but one guy doing this part time means you should not set the bar way too high.
It is not just getting the compiler to work. It is to get it to work reliably.

Dont underestimate software projects.
Getting to that it works takes 90% of the alotted time, and getting it to work RELIABLY takes the other 90% of the alotted time (from experience). Writing the manual takes the 3rd 90% of the alotted time.
 
I am having extreme difficulty with CASE OF END_CASE statements. A simple line of code is stumping me.

CASE A OF 0: B:=0; 1: B:=1; ELSE B:=2; END_CASE

The part of the code
0: B:=0; is called a case element and there could be a case element list or more than one. In this case there are two.

The difficulty is that other languages have a key word that indicates the end of the case element. C uses the word break. Pascal uses begin and end. ST doesn't use anything to indicate the end of a case element.

Structured text CASE OF statements are a pain in the a$$. There are no similar languages that I can use as an example.

My ST compiler generates IL just to check the output. I am also work on a IL compiler. It will be much easier.

This isn't what I really wanted to do. I wanted to generate machine code directly.
 
I see the problem as each case can contain multible statements terminated by ";".
Can't you determine a new case by looking for ":"? (which would end the previous case)

Couldn't you "just" extend the IEC spec. and implement some of the features that it lacks?
Wouldn't it still conform to the IEC spec?
 

Similar Topics

Hello All: I have a Windows 10 PC running a FTView ME Station 10.00. I have a .mer file version 6.00. It has been running well on it for a long...
Replies
1
Views
138
My R55 Ingersollrand is tripping on motor overload and im falling to see the trip history it is writing Acquarring texts
Replies
0
Views
126
Hi. Not the fist time I'm saying this but just to give a background. 95% of my PLC programming has used Schneider over the last 10 years on...
Replies
66
Views
4,633
Hey Friends. I am currently trying to write approximately 700 tags from FtView13 to an Logix Emulate 5000. I am using rslinx DDE/OPC to create an...
Replies
0
Views
380
Hi all, Currently delving into Wonderware/Aveva System Platform for the first time, and I'm trying to set up a script to automatically write to...
Replies
3
Views
877
Back
Top Bottom