Internal PLC architecture?

[Homer_BL]

Omg

 

[Bobbias]

Well, when it comes to the fundamental model of a PLC, they are really kinda simple. A Propeller is more than capable for the processor, or so Peter has lead me to believe (though I have no idea what the specifications for the actual processor performance in industry standard PLCs is...) And after that, the important parts are I/O, Power circuitry, Isolation and maybe setting up some other way to program it.

Power, I don't think I'll have too much trouble with. I can buy a supply for some voltage and convert it to any other voltages I need. The hard part there will be making some robust filtering. I may end up just buying something for that, though I'd really rather not.

I'll need to figure out how to do each sort of I/O operation I'd like to have, but at the very least I should be able to get a digital, isolated I/O system set up fairly easily. Analog might be tricky.

Aside from being careful and selecting the right components and designing something that will actually work, the hardest part will likely be the actual programming. I'll need to find some way to create logic programs for it relatively quickly and easily, and have some core system which accepts a user program that is essentially completely compartmentalized from the core functionality (diagnostics/faults, etc.) And probably some formalized way of writing the user program.

I was thinking it might be better to force the program to be written in either PASM or Spin. That way there would be no need to compile it from some other language, and compromise the speed, or cripple the capabilities of the user program, by trying to force a language not meant to be run on a parallel architecture into running on one.

Working in native Propeller languages would be like avoiding trying to mash a square peg into a round hole. This, being a parallel architecture needs to be programmed differently than a traditional PLC to get the full capabilities out of it. Traditional PLC programming languages are not optimized to run on multi-core systems, and that alone would cause significant issues in trying to port it over to the Propeller.

The only immediate issue that I can see is that because PASM has a limit of 496 instructions per Cog, despite being much faster than Spin, it would make coding larger solutions in PASM a pain in the ***, either requiring sacrificing another Cog for the code, or possibly requiring some sort of program to stream the instructions from the larger memory and running them. But that also introduces slow-down in the system.

Mind you, since the Propeller can run at 80MHz Resulting in 160 MIPS total (all 8 Cogs) in Spin. And estimates put PASM at between 80 and 100 times faster than Spin, so even some pretty large programs should run at pretty fast scan times.

 

[Peter Nachtwey]

Another idea

I think it would be interesting enough to connect a Propeller CPU to a Ethercat slave chip. Supposedly the Ethercat slave chip can communicate using SPI or a parallel bus and requires minimal software support for simple devices. You would need to devote one cog to the Ethercat interface. The Ethercat interface would also provide galvanic isolation from the reset of the Ethercat system so you would worry about isolation of the analog and digital I/O. Another cog could run all the devices connect to a SPI port such as analog I/O devices.
You can make the equivalent of a Siemens FM-352 module on Ethercat.

By making your project a slave you dodge having to make full programming IDE. Just provide options for the digital and analog devices so a user can configure you module to do get some useful info and chip it out over the Ethercat.

Think in terms of complementing what the PLC cannot do or doesn't do well.

BTW, what propeller chip are you going to buy?
I find this guy amazing
http://hannoware.com/
That should provide inspiration.

 

[JesperMP]

Are you just yourself, or are there several persons on the same project ?

In stead of thinking about hardware already now, how about "merely" concentrating on the PLC Runtime logic and how the PLC Runtime communicates with the outside world ?
If you write you PLC Runtime logic in C for example, you could theoretically port your Runtime to almost any conceivable target. Especially if you chose TCP/IP as the means to access the PLC runtime.
You could run your PLC Runtime on a regular PC together with your development environment. That will make coding and testing more efficient. When the PLC Runtime works OK on a PC you can start thinking about porting to something else.

I think the PLC runtime is the most "interesting" part for a do-it-yourself project.
For example, shall you be able to change code during run (online programming) ? What about online monitoring of the code with realtime logic status display ? What about data retentivity ? What error checking to be built into the PLC runtime ? What software diagnostics will there be ? Do you want to follow a certain code standard ? IEC Structured Text would be a good candidate because it is textbased (so you dont have to create your own ladder editor, or SFC editor or whatever). You could decide to start with just a limited subset of the full ST standard.
There is enough to keep several talented persons occupied for many years.

The part about communicating with i/o I think you should lean to adapting a comercially available component for CanOpen, Profibus, Profinet, Ethernet/IP or EtherCat.

 

[Peter Nachtwey]

...
I think the PLC runtime is the most "interesting" part for a do-it-yourself project.

I think this alone is a big enough project for a college project. However, it is just a small part of a big project. Without the IDE and compiler the run time will not do much.
I would chose the whole of a small project.

The problem with interfacing with field buses is that many are very complicated and are a complete project themselves. Profinet and Ethernet/IP are too complicated. Profibus slaves can be implemented by experienced people in two weeks but the Profibus chips would use too many of the Propeller chip I/O pins.

BTW, I was a fan of Profibus DP back in the mid 90's when we were using 16 bit 80186s but the Profibus interface chips have not kept up with technology. The 8 bit bus with many wait states cripples modern DSPs and 32 bit micro controllers. This will kill Profibus DP eventually unless something is done to make faster interfaces.









For example, shall you be able to change code during run (online programming) ? What about online monitoring of the code with realtime logic status display ? What about data retentivity ? What error checking to be built into the PLC runtime ? What software diagnostics will there be ? Do you want to follow a certain code standard ? IEC Structured Text would be a good candidate because it is textbased (so you dont have to create your own ladder editor, or SFC editor or whatever). You could decide to start with just a limited subset of the full ST standard.
There is enough to keep several talented persons occupied for many years.

The part about communicating with i/o I think you should lean to adapting a comercially available component for CanOpen, Profibus, Profinet, Ethernet/IP or EtherCat.[/quote]

 

[Peter Nachtwey]

...
I think the PLC runtime is the most "interesting" part for a do-it-yourself project.

I think this alone is a big enough project for a college project. However, it is just a small part of a big project. Without the IDE and compiler the run time will not do much.
I would chose the whole of a small project.

The problem with interfacing with field buses is that many are very complicated and are a complete project themselves. Profinet and Ethernet/IP are too complicated. Profibus slaves can be implemented by experienced people in two weeks but the Profibus chips would use too many of the Propeller chip I/O pins.

BTW, I was a fan of Profibus DP back in the mid 90's when we were using 16 bit 80186s but the Profibus interface chips have not kept up with technology. The 8 bit bus with many wait states cripples modern DSPs and 32 bit micro controllers. This will kill Profibus DP eventually unless something is done to make faster interfaces.

For example, shall you be able to change code during run (online programming) ?

That is advanced

What about online monitoring of the code with realtime logic status display ?

A real time interface is required first

What about data retentivity ?

That is a matter of spending more money to buy the retentive ram.

What error checking to be built into the PLC runtime ? What software diagnostics will there be ? Do you want to follow a certain code standard ? IEC Structured Text would be a good candidate because it is textbased (so you dont have to create your own ladder editor, or SFC editor or whatever). You could decide to start with just a limited subset of the full ST standard.
There is enough to keep several talented persons occupied for many years.

Yes, so why go there? Those are questions for someone like me not a college student and I know this which is why I am trying to get Bobbias to scale back his project to something that can be done.

 

[JesperMP]

As a realistic project that concentrate on the PLC runtime, and forget about the hardware in the 1st place, I would suggest this:

Write a "PLC runtime" that runs IEC IL program blocks.
The PLC runtime could contain a memory manager, so that for example instantanous switchover from old to new code is possible. That means program in run. As to change of data structures in run, either it is simply not possible, or a smart download routine could attempt to keep the online values and squeze in only the changed structures. That would be a really neat feature (I believe that Beckhoff Twincat can do it, whereas Siemens STEP7 cannot).
This PLC runtime could start on a Windows PC, but could later be ported to some other target platform.

Write an interface to download IEC IL code and data blocks to the PLC runtime.

Write an IEC ST "compiler" that generates IEC IL code and data program blocks.

Since both IEC and ST are text only, the "IDE" can be any text editor. To begin with, just a small subset of the complete IL or ST standard is implemented.

Write a "code monitor" that displayes the IL or ST source code, together with online values from the PLC runtime.

It does not have to be a perfect ready to run fully debugged and developed application. It also does not have to be very performant. It just have to showcase that the principles can be implemented, and that the student knows how to implement the rest.

Those are questions for someone like me not a college student and I know this which is why I am trying to get Bobbias to scale back his project to something that can be done.

Is he a college student ? I thought that maybe has was a software engineering student. I cant see why something like this could not be a realistic project just because it is more software than it is hardware.

edit: I have highlighed what would be minimally required, and waht could be implemented if there is enough time.

 

[Bobbias]

To clear things up:

I am a college student in the Electrical Engineering - Automated Systems program at my college.

The point was to concentrate on the hardware, rather than the software. The program I'm in only has 1 programming class, and minimal actual teaching about digital hardware. I just happen to actually know about low level programming, and digital hardware mostly from personal learning.

I think that if I was going to expand beyond what I'd want for the project, field bus communication would be a consideration.

I'll outline what I'd really personally like to accomplish:

• Isolated I/O
• Processor to read the input states, process a set of rules/commands, and then write the appropriate output states.
• Power supply and other necessary components that are required to create a system that satisfies those requirements.

I don't want to do something insanely beyond that. I dunno if I even want to deal with making it understand ST or IL or anything. I'll probably just make a document saying "here's how to translate something in language x into Spin or PASM".

I'd like to concentrate more on getting something that is basically the same hardware that you'd see in a PLC, and can operate much the same way PLCs do.