Structured Text Programing

[Duffanator 1]

Has anyone noticed that programing in Structured Text is very unsatisfactory? I was writing a function block today in Structured Text and I was about 25% of the way though and it stopped me and said I was out of memory. When I compiled it it was over 2,000 steps for a program that in, say Opto 22, would have been about 4Kb out of 6Mb. How is that possible? Am I doing something wrong or what? If I wrote the same program in ladder it would have been way less than half that many steps. It doesn't seem like it compiles very well. Has anyone else had any experience with it or have any tips that makes writing in it any easier?

[Crossbow 296]

GX Works2 or GX IEC Developer? My understanding is that GX IEC Developer didn't always write the best code when converting it. Not sure but have been told GX2 is better. I haven't had time to play with structured text or GX Works2 yet.

[Inntele 60]

Miracles ... It is impossible to help you with advice, because is need to see your FB code. The IEC Developer produces best compilation of FBs, if these are written in Melsec IL and/or are used with the parameter "Use macrocode".

[Duffanator 1]

I would have posted it but I got frustrated and deleted the whole thing and started over in ladder Oh well... I just wanted to see if anyone else had any experience with it and knew some tricks to get things to compile in less steps. Maybe using functions instead of writting out math in code or something like that. I'm using GX Developer Version 8.83M. We haven't gotten GX Works2 yet, but we will probably get it soon.

[Inntele 60]

May be I can help you? What do you want to get as result?

[Duffanator 1]

I started over and wrote a smaller function block that just takes care of stepping through available pushers and when I compile the function block it says it's 452 steps big. Ok, but when I check the size of the structured file when it sends it to the processor it says it's 5,456 steps..... Not sure what the deal with that is. I have a screen shot and I'll upload my (unfinished!) program if anyone wants to look at it. STStepNumbers.bmp FPRibLine.zip

[Inntele 60]

I looked at your program: 1. The function block could be much shorter (64 steps the code itself and 101 steps after compiling). 2. When you add function block into the program real markers does not replace the internal variables of FB. Before than FB perform the input markers are copied into the input variables, and after FB is performed the output variables are copied into the output markers. These are additional commands which you can not see in ladder diagram (in IL only). And it leads to an increase of program code. Of course, sorry for the remark, but would like to say, if to use certain methods of programming, is possible to make your program considerably shorter and even more readable.

[Duffanator 1]

I don't doubt that at all. But considering how I've had to teach myself how to write PLC code, I think I do pretty good.... Still, the question remains. If I write a function block that is 456 setps long and put it in the program 8 times and it comes out to over 5,000 steps then why use a function block at all? Isn't that supposed to be one of the advantages to function blocks? If it uses the same amount of steps (or more, it seems) then I could just as easily write it in ladder and just integrate it into the program. I understand that the PLC has to map the M contacts to the input and output variables but that shouldn't take up steps.... that should just take CPU time. Since the PLC scans each program from top to bottom (it's not scanning multiple programs simultaneously) then why not move the variable inputs and outputs into the function block when it gets there and then perform the function block code.... If I load that program into the PLC and then upload it the function block ladder code is there in each program. Seems very wasteful to me....

[Inntele 60]

Such method of substitution of input / output variables in the functional blocks is classical. The method, in which a standard piece of program is being replaced onto a piece of program with the actual input / output variables, is called Macro. And this function is in the GX Developer. But, unfortunately, in the GX Developer is not possible to assign functional blocks as Macro. In order to understand, where steps are being lost, is need to convert the program from LD to IL, and you will immediately see how many steps each operator or the procedure takes. I did it... I do not mean to offend you. Any programmer thinks that he writes programs very well. And I did not said that your program is written bad. But the fact is that when you write a program you often are using a redundant code and you are not using the some opportunities that available in GX Developer, for example, STRUCTURE. To illustrate it, I have attached the picture of functional block with the same function as in your program, as it might look like. Edited 23 Jan 2010 by Inntele

[Duffanator 1]

That isn't the same function at all.... In my function block it will activate 1 pusher at a time from all available pushers. So, for instance, say I have pushers 1,3 and 5 enabled for cutoff #1. Then it will activate pusher 1 for the first rib, then pusher 3 for the second rib then pusher 5 for the 3rd rib, so on and so forth... actually now that I think about it I think it's wrong but that's what I was trying to do. Each cutoff that is enabled can have any of the pushers assigned to it, so there may be 1 pusher assigned to it or there may be 8 pushers assigned to it. I needed to step through each pusher that is enabled. The code you posted will just activate any pusher that is enabled. The other problem I had was that once I step through the pushers they are all a different amount of "counts" (Encoder pulses) away from the scale. So when I assign a rib a pusher to be diverted at I also have to assign that rib "slot" a number of counts until divert and the time that that pusher needs to divert. There can be up to 8 (I put in 10 slots just in case) ribs on the line at a time so I need to track the weight of each rib, what pusher it's been assigned and what count that the rib is currently at. This would be easy if they wanted only 1 pusher per weight range, but they want it to be dynamic. Able to be changed at any time and the ability to have any number of cutoff/pusher combinations.

[Inntele 60]

I do not understand all aspects of your task yet, but I think, is need to move step by step.

[Inntele 60]

May be this code will be more applicable in your case. If try to select several pushers, the pusher will be selected with priority from 1 to 8. GX_Developer_print.pdf

[Inntele 60]

Hi Duffanator, Thanks to allocation of PLC memory competently made by you, a piece of code, that contains commands of choice of parameters and control of pusher for each Rib slot, can be significantly reduced with usage of indexing and FOR-NEXT cycles: GX_Developer_print_Ladder_Pusher_Control.pdf

[Duffanator 1]

hmmm... that's very interesting. I had to run it through in my head a few times until I figured out what you were doing but that is very nice. That will free up a lot of steps. Thank you for the help!

[Inntele 60]

Don't mention it I once again want to draw attention to the fact that such method of programming may be used only because you have assigned PLC memory very well.

[Duffanator 1]

Inntele, Do you mind taking a look at my cutoff programs starting at step number 193 and see if it makes sense to you? I took what you did with the other part of the program and did something similar to step through the available pushers that are selected. Just want to make sure I am doing it right. Thanks! FPRibLine20100125.zip

[Inntele 60]

OK. I'll look at program tomorrow morning, because now is 1 a.m. at my clock. Good night!

[Inntele 60]

Hi Duffanator, I've looked your program and I was confused by steps with the numbers 208 and 218. In order to give you specific recommendations on finalizing the program, I need to clearly understand the algorithm that you want to implement. Please describe it consistently and in detail. Also you can send it as personal message.

[Inntele 60]

Have you a time? Because I have several ideas on your program, which are need to think up tomorrow.

[Duffanator 1]

No offense, but when I spend all day Saturday trying to get code to work that was recommended by you and then (apparently incorrectly) assume that since you recommended this way of writing the code that you would know why these specific problems may be happening and ask you why, the answer I get shouldn't be that the way I'm trying to figure out what's going on in the program is a "Voodoo" practice and I should start over. My original ladder code, while long, WORKED! I don't appreciate being ridiculed for writting code that works and being told that it could be much more efficient if I do it such and such a way and then waste a week of my time rewritting the program and then trying to get that to work, and at the end of all of that being told that I should just start over.... If you want to tell someone that they are an idiot and don't know how to write PLC programs, then the program you tell them to write better dang well work or at least be feasible. All you did is waste my time and delay my project. I'll go back to my original code and continue from there.

[Inntele 60]

Once again, I convinced that good deeds and intentions are punishable. In fairness, you could publish all our personal correspondence about this task and not just my answer onto your last post in it. But I myself will not do that. 1. I never dreamed to get this job, but instead wanted to help you, because this problem seemed to me interesting. But, on the other hand, I have no desire to waste my time if the results of my work does not arouse your interest. 2. Loops, which I recommended you do to reduce the length of the code, are a full equivalent of those structures that were written in your program. But, of course monitoring of such structures is very difficult. 3. Once again, to jointly analyze the problem and then write code to CUTOFF, refusing FOR-NEXT loops, I suggested to you long ago, after I've scrolled the problem entirely in my head and realized that it is much easier to solve. I offered you this again when I saw that the adjustment of existing programs is problematic and cause a strange movements. 4. Perhaps my letter you found offensive, but his goal was just to warn you against of rushing, during to adjustment program. It happens that after such ravings of the program works, but may completely lost the logic of its reading. Good luck Edited 2 Feb 2010 by Inntele

[Crossbow 296]

OK guys, it might be wise for everyone to take a deep breath and calm down a bit. There are many different ways to write the same code. Some people will like one more than the other. Some are easier to troubleshoot than others.