Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

SCL Conversion tool

Created by: AutomationNick at: 11/2/2012 3:21 PM (11 Replies)

Rating (2)

Thanks 4

Result pages:: |; 1 | 2; |

12 Entries

Entries per page: 10 | all

11/2/2012 3:21 PM	Rate (0)
AutomationNick Member Joined: 8/29/2012 Last visit: 2/25/2022 Posts: 2 Rating: (1)	Hi Huggy, huggy_d1 Today Siemens released an SCL Conversion tool (Deutsch/English language only) for free download. where is the link to download the SCL Conversion tool. cannot find on the web, desperately need it before the day is up. Kind regards Nick
	Last edited by: CS Moderator at: 11/2/2012 3:56 PM new subject after splitting from /tf/WW/en/Posts/75545#top ; Reverence inserted
Suggestion To thank Quote Answer

11/3/2012 3:52 AM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/27/2023 Posts: 13080 Rating: (2121)	https://support.industry.siemens.com/cs/document/62053296/wizard-for-converting-scl-source-files-from-v5.x-to-v1x?dti=0&lc=en-WW
	Last edited by: huggy_d1 at: 8/17/2015 3:04:52 PM science guy
Suggestion To thank Quote Answer

9/10/2014 5:21 PM	Rate (1)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 1/24/2023 Posts: 1516 Rating: (513)	I have been playing with this and, in my humble opinion, it doesn't do a lot for you. It gets stuff wrong too. For example, the CONST section is marked with some odd character string (~ at the start and ) at the end. I assume that it doesn't know how to handle program constants and as such it just marks them as to be removed / ignored. This is further supported by the fact that it then puts these in a csv file so they can be imported into TIA Portal to make PLC tags I assume. Alas the format for the csv file is not compatible with the TIA Portal import file structure. Oh well never mind. Really all it needed to do was change the "CONST" keyword to "VAR CONSTANT". Note that there is a space after the var instead of the usual underscore, which brings me rather nicely to the differences between classic S7 SCL file format and that of TIA Portal. The header information is different:- S7 TIA Portal Notes FUNCTION_BLOCK MYBLOCK FUNCTION_BLOCK "MYBLOCK" Block name in quotes in TIA TITLE = 'This is the title' TITLE = This is the title No single comments in TIA Portal AUTHOR Smiffy AUTHOR 'Smiffy' Single comments required in TIA Portal FAMILY Adams FAMILY 'Adams' Single comments required in TIA Portal NAME Mortisha NAME 'Mortisha' Single comments required in TIA Portal VERSION '1.0' VERSION '1.0' Same for both As already mentioned the start of the constant section has a "VAR CONSTANT" instead of the "CONST". Why this is different or has a space instead of an underscore like the rest of the declaration sections is a mystery. The end of the constant section has a "END_VAR" instead of "END_CONST". The FC/FB/DB name now has to be in double quotes. When constants are used they have to be unquoted and prefixed by the '#' character e.g. #MYCONST Why make it different between the 2 systems? What could possibly be the reason for this? This sort of thing drives users to the point of despair. Especially the header information as there is absolutely no valid reason to make one require quotes and the other not require quotes. Someone on the development team really should have consulted with the S7 developers to try and keep things a close as they could between the 2 systems and not change (or re-invent) something that really didin't need changing. The most spectacular mistake in the TIA Portal SCL format is the block comment handling. In S7 the title goes into the block comment field for the block which is OK (I would prefer it to be the comment after the block name on the same line). But in TIA Portal for some bizzare reason, any comment text between the end of the block header definition and the next VAR_XXX (or VAR XXX) section goes into the block comment field. I have tried all sorts of lines to see if I can terminate the block comment such as blank lines, blank comment lines, "VAR_INPUT" etc inside a comment. But nothing works. It has to be the first valid declaration line that terminates the block comment. No I cannot find a workaround. So in the example below the whole of the comment section goes into the block comment field for the block. // Pre amble comment - does appear anywhere in the finished block properties FUNCTION_BLOCK "MYBLOCK" // This really out to be the block comment but it is ignored AUTHOR : 'Smiffy' FAMILY : ' Adams' Name : 'My Block' VERSION : '1.0' // All this text // goes into the comment // field for the finshed // block, when really // it didn't ougth to. VAR_XXXX // This line will terminate the block comment Go figure! Very poor effort Siemens developers. I expect better.
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users 0_Einstein

9/10/2014 5:28 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/27/2023 Posts: 13080 Rating: (2121)	That FAMILY joke was not lost on me at least ;)
	science guy
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users smiffy

9/10/2014 5:32 PM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 1/24/2023 Posts: 1516 Rating: (513)	But seriously, huggy, it is a very poor effort don't you think? I accept that some things have to change between versions, but not some of the stuff that they have changed. I believe it is simply down to the TIA Portal developers not talking to the S7 developers.
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users 0_Einstein

9/10/2014 6:50 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/27/2023 Posts: 13080 Rating: (2121)	I agree and not sure why they did it this way either. Not even a watch out FAQ either...
	science guy
Suggestion To thank Quote Answer

9/11/2014 10:12 AM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 1/24/2023 Posts: 1516 Rating: (513)	Discovered another howler with the conversion tool. It changes the OK var to ENO, which is fine. However, it also changes OK to ENO in comments too . Well tested then.
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer

9/11/2014 2:14 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/27/2023 Posts: 13080 Rating: (2121)	smiffy Discovered another howler with the conversion tool. It changes the OK var to ENO, which is fine. However, it also changes OK to ENO in comments too . Well tested then. I guess their automated find/replace hack needs bounds ;)
	science guy
Suggestion To thank Quote Answer

9/11/2014 3:09 PM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 1/24/2023 Posts: 1516 Rating: (513)	I am now quite clued-up in the differences between STEP 7 SCL and TIA Portal SCL. So I might produce a FAQ at some point, or possibly write my own conversion utility. It would only take a few days to write as it is a simple operation. I could then upload it on here, or even better sell in to Siemens maybe .
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer

9/11/2014 3:36 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/27/2023 Posts: 13080 Rating: (2121)	smiffy I am now quite clued-up in the differences between STEP 7 SCL and TIA Portal SCL. So I might produce a FAQ at some point, or possibly write my own conversion utility. It would only take a few days to write as it is a simple operation. I could then upload it on here, or even better sell in to Siemens maybe . If/when you decide to make this a "go" project for yourself, please consider the following: Source -> Destination 300/400 - 300/400 {pretty easy right?} 300/400 - 1200 {mostly easy, but some stuff is either firmware level dependent or does not work at all} 300/400 - 1500 { even easier but still some stuff is different } In the gui, have drop-downs for source/destination so you can adjust or flag code that does not transport. If it can be transported but needs a little coercing, please coerce and add a comment to note this is not the original code, showing original code in the block comment. For stuff that simply will never work, please rename the destination scl to source_name-failed.scl or something like that so we end users could tell it will not run and no automated tool could easily make it work. Samples of this are things that exist in the 300/400 family like timers, dt->dtl that kinda-sorta works, places where implicit datatype casting is now required, 300/400 knowing about restart versus power up, and other nuances that may not exist in the 1200/1500 world. If you can get 80% conversion & direct compile success of the OSCAT SCL library to convert for 1200's, 85% for 1500's, and > 90% for 300/400's, you have a good tool. The Siemens tool does way less than those numbers, but with personal knowledge we can skillfully take the Siemens results and approach those percentages quite readily. Biggest problems are time/date related, and timer/hardware related items. Also, the datatype conversions that happen automatically in 300/400 legacy step 7 no longer works in 1200/1500. I cannot speak to the 300/400 world in portal though. Hope this helps save some headache with your tool development.
	science guy
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users smiffy

|

Share this page:

Share this page on...

Follow us on