12/17/2013 1:23 AM | |
Posts: 2 Rating: (0) |
Hi all. I'm working with a system integrator in the USA that has created a MASSIVE SCL source file that generated a single FB in excess of 120KB. He was essentially forced to berak the source file into multiple blocks to get under the 64K limit for the 319F CPU, but now he's complaining that breaking the code down any further wouldn't be efficient and would cause more problems for maintenance people. The SCL file now generates 5 FB's, and they range in size from 64 K to 30 K. The kick in the pants with this account is that they're a staunch Rockwell house doing robot automaton and determining machine states on the fly that allow the robot to' "make decisions" related to what task it does next, and they never have any memory issues on the Logix 5000 platform. I personally have never seen anyone write a code container so large that it exceeded the 64KB limit for block sizes! The 1500 CPUs offer much larger block sizes (300K and up), but since there's no safety CPU yet, that's not an option. We've also discussed using WinAC, but I just found that it also has a 64K limit. The "simple" answer is to have him use the SCL source to generate more FBs in smaller sizes, but he's adamant that this "shouldn't be necessary". That's whay I'm asking about "code bloat", or if there is any way to clean up this code to reduce the size of generated FB. I have attached the SCL files and the associated blocks and UDTs used. Any guidance would be most appreciated! AttachmentScl_sources.zip (159 Downloads) |
12/17/2013 9:22 AM | |
Joined: 10/7/2005 Last visit: 9/25/2024 Posts: 3022 Rating: (1054)
|
Hello ScottGross not too sure if I can really help you out, but perhaps at least give you some general pointers and ideas: To start with, the price one must pay for using high level languages is increased code memory and runtime (no matter how efficient the compiler is). As for S7 SCL compilation,you have the option to create debug info when compiling. If selected, it adds a fair bitofextra code to the compiled logicso check if that's the case. Have a lookat How can an S7-SCL source be tested online with the debugger? for more on thisand note too thatindividual SCL cources can also contain the keyword "SCL_CreateDebugInfo". If so, it's setting overules theglobal compiler setting (and is in use in at least some of your SCL sources). I suggest you do some with and without debug info test compilation and seewhat difference it makes. Possibly more memory consuming though may bethefair amountof UDT'sas IN_OUT Parameters. There is of course nothing technically wrong with making use complex variables asFC/FB parameters, butyou do pay a high pricefor it in terms of memory requirements(and runtime). Have a look at Shall UDT make the difference in CPU Scan Time? for more on this. Purely for completeness (and I haven't tested this yet myself),it seemsthat the "issue" of greatly increased memory requirements for UDT Parameter usage is no longer applicable in an S7 1500. Lastly, just because everything can be programmed in SCL, does not necessarily mean it makes sense to do. Perhaps a fair amount of "simple"control logic is better implemented in Ladder or FBD (it'll certainly reduce code size compared to SCL). Also,you can't beat STL for efficiency and it can do what all other higher level S7 languages can do. If properly programmed, STL will allow you to implement you lgoci at a fraction of the code size and runtime compared to SCL (which does compile down to STL anyhow). All from my side, I hope this helps and hopefully others have more ideas on this matter. |
Cheers |
|
Follow us on