Sign in to follow this  
Followers 0
Paulo Ferreira

Bulk adding Actions to SFC program

12 posts in this topic

Hello there. New to the forum, didn't write anything till today as I always found what I needed through search. Using a CJ1M-CPU11, with a CJ1W-OC211. 1) I have an SFC program with 8 subcharts, and 12 steps in each subchart. Each step as an action that just connects a bit in H memory to the relay output. The output needs to be completely parameterizable, that's why it's stored in H memory. So that totals to 8x12 = 96 actions and 96x16 = 1536 lines of code. Is there any way of bulk introducing this? I tried creating the actions using a CXR reusable file. The actions were added to the symbols list but don't show up in the project treeview neither show as an option when adding an existing action to the Step. 2) With so many actions, memory is a problem, each action takes 52 steps, multiply it by 96 and CPU11 can't hold it. Do you know any other way to do this? Thanks, Paulo Ferreira

Share this post


Link to post
Share on other sites
If it were in Ladder i would suggest indirect adressing

Share this post


Link to post
Share on other sites
Probably some more information required, well for me at least! Can you post an overview of you SFC, or a bit more detail? I think I know what you mean, but would like to be sure. Are you trying to use the SFC functions? I have never used them, but I think that they are pretty memory intensive, and the CPU11 would easily be full. I would be looking at ladder & indirect addressing, this will make the code much more manageable I would think.

Share this post


Link to post
Share on other sites
Hi lostcontrol. Here's a printscreen. I believe you can see everything you need. - The Main control SFC - The subcharts - Subchart1 open with its Steps - The Actions it lets me add (1, 21 and 22 that were added manually), despite the symbol list having a lot more actions that were added with the CXR file - The list of Digital Outputs for each step on the right stored in H memory. - The ladder program which outputs the STEPx_DOxx that are stored on H memory. I would prefer using SFC, but it really is memory intensive. Can you give an example on how it would be made with indirect addressing? Thanks.

Share this post


Link to post
Share on other sites
Hi, I think you answered your own question: you end up with 96 different actions, which take a lot of memory. Assuming the actions are similar what you really want is 1 Function Block, which you call 96 times with different parameters. Then you only have the code 'footprint' once but with 96 different instances - therefore reusing the same memory. Regards, BB

Share this post


Link to post
Share on other sites
96 different instances in the same ladder program/action? And all sfc states use the same action? Is that what you're saying? I also read the indirect address tutorial and it seems obvious that it's the way to go. Should I use 16IR's for the HR memory and connect them to I1.00 to I1.15, or should I use 2 IR's, one to go through the HR memory and another for the CIO? What do you think?

Share this post


Link to post
Share on other sites
Still need more information to give better answer. Lets forget about the Omron 'SFC' style to begin with. 1. You have a process, that is suited to SFC. 2. The process has 8 steps, within each step, another process operates that have 12 steps each? 3. The 12 step sub-process is required to control the outputs, but each process requires different outputs to operate? 4. The H memory is pre-configured/allocated for each sub-process, and this dictates what outputs are operated in each step? 5. Are the sub-process's similar, or have completely different code/conditions? If my assumptions here are close, then this could be relatively easily, with only some code that will be a lot less memory intensive than the SFC.

Share this post


Link to post
Share on other sites
That seems about right. Every main process is activated with different conditions (flags, timers, dates, buttons pressed, etc). Every subprocess activation is controlled only with timers (after X time the next step is activated). That's why I used SFC, states and subcharts are easy to create and control of their time is incredibly simple. The H memory is (like you said) pre-configured for each subprocess. So each subprocess just needs to activate/deactivate the 16 digital outputs acording to the table stored in H memory. Example: Process_1.Subprocess_1 ::: H30.00 -> Q1.00; H30.01 -> Q1.01; ...; H30.15 -> Q1.15 Process_1.Subprocess_2 ::: H31.00 -> Q1.00; H31.01 -> Q1.01; ...; H31.15 -> Q1.15 ... Process_2.Subprocess_1 ::: H42.00 -> Q1.00; H42.01 -> Q1.01; ...; H42.15 -> Q1.15 ... I'm currently programming this with 16 IR,DR, one for each output... and whenever the subprocess changes I just add a constant to the offset. I'll be waiting for your opinion. Thanks for the help.

Share this post


Link to post
Share on other sites
I have done a simple example for a sub-process and indirect. Have a look, see if it helps to simplify things. Obviously you will need to get more creative to do what you want. You could also use a single timer, and use IR to index through different step times... Indirect.cxp

Share this post


Link to post
Share on other sites
Ok. Simple and feasible. Off course I'll need to add some stuff, but it's a real solid base to start from. I'll use your advice to use another IR for the times, since they need to be customizable too. Thanks for the help.

Share this post


Link to post
Share on other sites
No problem. You will probably also find that you will use a lot less memory going down this method. It is quite common to implement SCF/Grafcet style code using standard ladder, we have been doing it this way for some time. It is only recently that the IEC standards came in and started being followed (last 5-10years) by all the major players.

Share this post


Link to post
Share on other sites
I'm new to PLC programming when compared with most of the people here on the forum, so my brain is already formatted with the IEC 1131 and 1499... it's somewhat hard to learn "oldschool" techniques when the new ones are so rooted. In a "8GB pocket mp3 player" age, shouldn't industrial controller memory not be a problem at all? Is it just an economic interest to limit the evolution of PLC memory so that companies can charge a lot more for a little more memory? Well, thanks for all the help

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0