Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual...

15
SoMachine Migration 27/04/2010 1/15 Migration from SoMachine V1.1 to SoMachine V2.0 April 2010

Transcript of Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual...

Page 1: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 1/15

Migration from SoMachine V1.1 to SoMachine V2.0

April 2010

Page 2: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 2/15

Version Date Author Description VA 22.03.2010 Y.Drouot Creation VB 06.04.2010 D. Castang Update and Corrections after feedbacks VC 14.04.2010 D. Castang New feedbacks review n°2 VD 27.04.2010 D. Castang New corrections and Thomas Langemeir feedbacks

1. Introduction ..................................................................................................................................... 2 2. Compatibility use cases .................................................................................................................. 2 2.1. UC 1: Standard exchange .......................................................................................................... 3 2.2. UC 2: Intervention on machines with SoMachine V2.0 .............................................................. 3 3. Install all the V1.1 Libraries & Devices in SoMachine V2.0 ............................................................ 4 4. Reuse a V1.1 application. Keep the project in V1.1. ...................................................................... 8 5. Reuse a V1.1 Application, and migrate it to V2.0 format................................................................ 9 6. Compatibility Breaks and manual operations ............................................................................... 10 6.1. Items not automatically updated............................................................................................... 10 6.2. Known compatibility breaks in Libraries ................................................................................... 10 6.2.1. Applications using toolbox library......................................................................................... 10 6.2.2. Applications using Packaging/Conveying Library ................................................................ 12 6.3. Known compatibility breaks in Code generation ...................................................................... 12 6.4. Miscellaneous........................................................................................................................... 13 6.4.1. Canopen............................................................................................................................... 13 7. XBT-GT Applications .................................................................................................................... 13 8. XBT-GC Applications .................................................................................................................... 14 9. About Visu..................................................................................................................................... 15 10. LMC20 application migration.................................................................................................... 15 11. ATV IC application migration.................................................................................................... 15

1. Introduction This document defines the technical operations to transform a V1.1 SoMachine application (project) into a V2.0 SoMachine application. It also lists the checking to be done, after transformation. This document describes the transformations to be done at Device level. According to device type, the migration operation may differ.

2. Compatibility use cases Here are the 2 Uses Cases when a customer has designed an application with SoMachine V1.1

With XBTGC application: no restriction (FW is automatically updated at first application download)

SoMachine V1.1

OKUC 1

(restriction)SoMachine

V2.0UC 2

(restriction)OK

proj

ect V

1.1

Target V1.1 Target V2.0

Page 3: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 3/15

2.1. UC 1: Standard exchange The Customer has SoMachine V1.1 He has some machines with V1.1 controllers, one is faulty He receives a new controller V2.0 to replace it

1. He wants to keep the same configuration He downgrades M238 PLC into V1.1 Firmware Reminder: Only 2 minutes since V1.1 No restriction

2. He uses V2.0 firmware Restriction: This case is not applicable if Sharing variables function is used (SoMachine protocol between M238 PLC & HMI device)

2.2. UC 2: Intervention on machines with SoMachine V2.0 The Customer has SoMachine V2.0 He has some machines with V1.1 controllers and wants to work on them

1. He wants to keep the same configuration: He installs V1.1 libraries and devices in SoMachine V2.0 He must changes compiler version to V1.1 and builds application Restriction: This case is not applicable if Sharing variables function is used (SoMachine protocol between M238 PLC & HMI device)

2. He uses V2.0 firmware He updates M238 PLC into V2.0 Firmware He installs V1.1 libraries and devices in SoMachine V2.0 No restriction

SoMachine V2.0Target V2.0

OK OK OK

M238 + HMIModbus Exch

M238 + HMISoM protocol

M238 alone

SoMachine V2.0Target V1.1

OK OK NOK

M238 + HMIModbus Exch

M238 + HMISoM protocol

M238 alone

SoMachine V1.1Target V2.0

OK OK NOK

M238 + HMIModbus Exch

M238 + HMISoM protocol

M238 alone

SoMachine V1.1Target V1.1

OK OK OK

M238 + HMIModbus Exch

M238 + HMISoM protocol

M238 alone

Page 4: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 4/15

3. Install all the V1.1 Libraries & Devices in SoMa chine V2.0 SoMachine V2 does not install all V1.1 libraries, and CANopen Devices, to simplify the library tree for customers starting with V2.0. For reusing V1.1 application, the first mandatory step is to install all V1.1 Libraries and CANopen devices. Here the procedure to follow: Step 1: Create an empty SoMachine project Use “Create New Machine” Use “Start with Empty Project” Step 2: Install the V1.1 Libraries These libraries are located in the installation folder of SoMachine, for example: D:\Program Files\Schneider Electric\SoMachine\Legacy\V1.1 Libraries They are also available on the DVD: E:\...\Accessories\Legacy\V1.1 Libraries Select the “Program” tab Select menu item “Tools” then “Library repository”

Page 5: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 5/15

Click on “Install…”

Page 6: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 6/15

Select the correct directory: …\Legacy\V1.1 Libraries

Select all the libraries of this directory, and click on “Open” Check if no error messages appear in the messages window. Step 3: Install the V1.1 Devices The V1.1 devices are also stored in the “Legacy” directory of SoMachine. Here is the procedure to install them:

Page 7: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 7/15

Example : installation of ATV31. All needed devices must be installed in the same way.

Page 8: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 8/15

4. Reuse a V1.1 application. Keep the project in V1 .1. Use case: the customer needs to keep its Controller at V1.1 level and keep the same application, with some code changes. Step 1: Open the project , If you already have installed the legacy libraries and devices, you should have no error at this step. If some libraries are still missing, you will have the following message:

� Identify them, and install them in SoMachine V2.0. When the project is opened, go in the programming task clicking on the "program" tab to access the messages list as following example.

Page 9: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 9/15

� Remark: Solution libraries

� It has been agreed that SoMachine v1.1 solution libraries (Packaging / Conveying) will be definitively removed from the SoMachine V2.0 DVD. Customer situations will be managed by the ADEs case by case.

� The Solution libraries delivered in V2.0 can only run on S-Type platforms. So the application must be re-entered with a new controller device (S-Type).

Step 2: Build ,

Optional: Change compiler version � V1.1 uses compiler version 3.3.1.2 Remark: Building the application with the exact same compiler as in V1.1 insures that the generated code is the same. Nevertheless a full download to the PLC will stay mandatory. Using the most up-to-date compiler can improve the performance and fix problems. Build � Should be OK. Nevertheless, the V2.0 environment may be less permissive than the V1.1. This means that some build errors may occur, where V1.1 builds without errors. Check §6.3 for known situations Step 3: Download & run , It is not possible to reconnect to the PLC running the V1.1 application without performing a full download. Download � Message: “Unknown version … do you want to download”. Answer Yes. Run � OK

5. Reuse a V1.1 Application, and migrate it to V2.0 format This operation is not mandatory, but is needed if you want to take advantage of V2 Features: IPR fixes, new services, The application migrated to V2.0 will not be compatible any more with the Controllers V1.1 (V2.0.10.xx). So you will also need to update the controller firmware to V2.0 (V2.0.20.yy). Step 1: Open the project , Open the V1.1 Application (project file) in SoMachine V2.0 � You may have error messages about not found libraries and devices. You may ignore them. Step 2: Update Device Version , This operation will transform your V1.1 application into a V2.0 application Right Click on each Device of the project, and select Update Device Version Check that you don’t get any error message Important note 1: IecVarAccess Library must be at version V3.3.1.20. If not, manually remove it, and add the IecVarAccess library at version V3.3.1.20. Important note 2: POUs in SFC: The SFC POUs created with V1.1 are using the SfcIec Library V3.0.2.0. If some more POUs are created in V2.0, they will use the IecSfc library V3.3.1.10. So this will create a duplicated library. � The customer must then open each POU properties and select the Sfc version V3.3.1.10. Important note 3: In some circumstances, some libraries may be duplicated after the Update Device Version. If this occurs, manually remove the oldest one. Step 3: Build application ,

Page 10: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 10/15

At this step, you may see several categories of errors

- Some errors in the POUs because of some compilation rules less permissive than in V1.1 - � Fix them by modification in POUs

- Some errors in FB parameters, or FB names because of some changed library interfaces

� Fix them by pulling new libraries, or by changing the interface parameters See §6.2 for the list of changed libraries interfaces

6. Compatibility Breaks and manual operations

6.1. Items not automatically updated • SFC version

SFC version is attached to each POU. The IecSfc lib used in each POU (defined in POU properties) must be same version: V3.3.1.10

6.2. Known compatibility breaks in Libraries

6.2.1. Applications using toolbox library The functions of the toolbox library have been reorganized. Here is the description of changes between SoMachine V1.1 and SoMachine V2.0.

Page 11: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 11/15

Becomes the TeSys Library ; For quality reasons, many FB have been removed

(11 FB does not exist anymore)

V 1.1 Scope V 2.0 Scope

TeSys Library : v 2.0.0.6 Toolbox Library : v 1.0.0.2

Util Library (3S) : v 3.3.0.20

Util Library (3S) : v 3.3.1.40

Move from Toolbox to Util Lib : � 6 BCD FB; � 6 Gray FB; � 3 String FB

Move from Toolbox to Util Lib : � Pack16 / Pack32 replaced by ??? � 3 BIT_AS_xxx to Util Lib � WORD_AS_BIT to Util Lib

Toolbox Library : v 2.0.0.6

Simplification of Toolbox Library

Pack8 to be replaced by BIT_AS_BYTE Pack16 to be replaced by BIT_AS_WORD Pack32 to be replaced by BIT_AS_DWORD UnPack8 to be replaced by BYTE_AS_BIT UnPack16 to be replaced by WORD_AS_BIT UnPack32 to be replaced by DWORD_AS_BIT Take care :

� interfaces has changed ! � Pack was a function; BIT_AS_BYTE is a FB !

Page 12: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 12/15

6.2.2. Applications using Packaging/Conveying Libra ry These libraries V1.1 are no more delivered in V2.0. No compatibility is insured for such applications. To use the V2.0 libraries, the Platform type must be changed into S-Type, the new packaging / Conveying libraries must be used, and the application has to be reworked accordingly. In regards to scenario 1 (to keep the V1.1 applicat ion in V1.1 environment under V2): 1) Recommendation for the easiest way: The ADE/user creates a project archive out of his project. For Packaging it is important to outline that he includes the visualization profile in it also to catch up as well the right version for the CoDeSys visualisation. When he unpacks in V2.0 he needs just to create the missing profiles coming out of V1.1 definition without overwriting existing information or libs. 2) In case a V1.1 installation does not exist any more: The ADE/user needs to follow the recommendations given in chapter 4. In regards to scenario 2 (V1.1 application should b e upgraded to V2): 1) Controller range is different: no G-Types are supported; insertion of an S-Type controller in the project is mandatory 2) Library profile is different: a mix of V1.1 & V2.0 libraries is not allowed; the application needs to be switched completely to the V2.0 library profile following the device description 3) CANopen is different: instead of updating the existing CANopen network with its devices it is recommended to create a new configuration based on the old configuration. 4) FB instances are different: Even though the names are the same (V1.1 Packaging lib compared with V2.0) the instance names remain and reference still to the old V1.1 library (despite of the fact that the old library is not existing any more in the configuration). For the replacement of the AFBs it is necessary to: - delete the former instance name from the variable list - insert a space and enter (deletion of the old existing links) - insert afterwards the desired FB name from the selection list - create a new instance name for the variable list - re-establish the links between the FB pins and the input and output variables 5) Visualization has been changed: In case visualization has been used in V1.1 the frames might be filled after the update but will be empty after reloading the program or refreshing the visualization. As only the image will be deleted from the frame but the link to the (old and now invalid) instance name will be kept, the entire frames have to be deleted and to be created new.

6.3. Known compatibility breaks in Code generation Located variable, with type mismatch

Toto AT %MWx : DINT; was accepted in V1.1, refused in V2.0 with following error message:

� (Not solved by Compiler version change) In this case, the POU code must be changed into Toto AT %MDx : DINT;

Page 13: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 13/15

The example shows type mismatch between INT and DINT, but the situation is the same with other types mismatch. Retain Persistent Located variables In V1.1, it was accepted to declare located variables in the Retain Persistent section.

This now leads to the build error message:

The 1000 first %MW are automatically persistent. So in this case, the variable “truc” can be declared in a regular POU declaration section. It will be retain + Persistent anyway.

6.4. Miscellaneous

6.4.1. Canopen • Application using CANopen will consume 50Kbytes more memory • Application using Altivar or Lexium libraries may execute 15% slower than in V1.1 • Wrong COB-IDs in some cases (to be manually reworked):

After message:

if you select to use the new PDO mapping, the updated device may have COB-ID corresponding to a slave with a node id of 1. Manual rework is needed.

7. XBT-GT Applications XBT-GT applications will be reused without changes in VJD. Between V1.1 and V2.0, the serial line configuration menu has been moved from VJD to SoMachine device browser. In case the customer wants to change the Serial Line configuration, he has to do “Update Device Version” on the XBT-GT device, to get the SL configuration menu accessible. IN SoMachine V2.0, the serial Line configuration parameters cannot be accessed any more from VJD (button is not active)

Page 14: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 14/15

After Update Device Version on the XBT-GT device, we get

We can change the SL CONFIG parameters by double click on the COM1 item.

8. XBT-GC Applications Most of the points described in the M238 chapter also apply to XBT-GC migration. Here are the specificities: Step 1: Open the project (Same as for M238) If you already have installed the legacy libraries and devices, you should have no error at this step. If some libraries are still missing, you will have the following message:

� Identify them, and install them in SoMachine V2.0. � Remark: Solution libraries

� It has been agreed that SoMachine v1.1 solution libraries (Packaging / Conveying) will be definitively removed from the DVD. For the customer issues, ADE will manage the situation case by case.

Step 2: Update Device Version ,

To be consistent with the general HMI policy (Runtime of platforms are automatically updated to the most recent versions), the Update Device Version is not mandatory, but is highly recommended.

After Update Device Version, the IecVarAccess library may be duplicated. Just remove the oldest version.

Inactive button

Page 15: Migration from SoMachine V1.1 to SoMachine V2.0 April 2010 · 6. Compatibility Breaks and manual operations ... SoM protocol M238 alone SoMachine V2.0 Target V1.1 OK OK NOK M238 +

SoMachine Migration

27/04/2010 15/15

Step 3: Check Symbol configuration , Step 4: Build: Some errors may appear at build. They are due to

- libraries needing to be updated - Interface change in libraries, needing manual rework at POU level

Step 5: Download to PLC Step 6: Save the application will trigger a popup. The user will answer Yes to save in V2.0 format (not possible to open with SoM V1.1 anymore) Remark: The XBT firmware has been (automatically) upgraded to the V2.0 level. It is no more possible to download an application into the XBT, using the SoMachine V1.1 Software.

9. About Visu When an application uses some frames from libraries (PLCOpen for example), Update Device Version will update the library, but some traces remain in the visualisation, causing the library included twice.

• Manual removal of the oldest lib is requested. • Suppressing the frame and recreating it is necessary.

10. LMC20 application migration In spite of this strategy, we should have the case where customers want to migrate from an application based on Motion Pro (Codesys V2.3) to an application based on SoMachine V2.0. In order to keep easy this request, an additional document is available (“LMC058 - LMC20 comparison_V3.doc”).

11. ATV IC application migration In spite of this strategy, we should have the case where customers want to migrate from an application based on Motion Pro (Codesys V2.3) to an application based on SoMachine V2.0. In order to keep easy this request, an additional document will be available soon.