Topic: DMD0190 Migrate DirectSOFT Project |
|
The Migrate DirectSOFT Project utility will assist the programmer in moving a DirectSOFT project that was written for a DirectLOGIC PLC to a Do-more Designer project that will be used in a Do-more CPU. If you want to see a list of how the individual DirectSOFT instructions will be mapped to Do-more Instructions use this link to the DirectLOGIC to Do-More Instruction Map.
This is a migration utility, it is NOT a conversion utility. This is because there are some programming elements in DirectSOFT projects for DL CPUs that are not available in a Do-more CPU, or not required in a Do-more CPU.
Many of the program elements in the DirectSOFT project - like contacts, coils, timer, counters, shift registers - that require only that the memory or I/O references be remapped; these will be moved across to the Do-more Designer project with minimal effort. But there are many programming elements and registers that have no equivalents in Do-more, and these must be handled differently. A good example are the various math instructions that are not required in the Do-more project at all. DirectLOGIC CPU would use a sequences of individual arithmetic instructions to perform math operations whereas a Do-more CPU would use a single MATH instruction where all of the arithmetic operations are performed.
Any issue that cannot be handled automatically by the migration tool will be stored in the Do-more project in the form of DirectLOGIC Stub instructions ($DL, $DL1, and $DLBLK). They will need to be manually replaced with appropriate Do-more ladder logic instructions then deleted from the Do-more project before the project can be downloaded to a Do-more CPU.
I/O and memory references that do not have an equivalent in a Do-more CPU will be migrated into Unassigned Nicknames. These too must be resolved or removed from the project before the project can be downloaded to a Do-more CPU.
The source project can be a DirectSOFT 4, DirectSOFT 5, or DirectSOFT 6 project, for
any of the following Automationdirect CPUs:
The destination project can be targeted for any of the following CPUs:
|
|
Use the File -> Import -> Migrate DirectSOFT Project menu selection to open the migration wizard and start the process.
|
|
The migration process uses a DirectSOFT project that has been exported to a text file. If you already have an exported copy of the DirectSOFT project, skip ahead to the sections dealing with mapping.
Create the DirectSOFT Export File
|
|
Open the DirectSOFT Export FileClick the Browse button to locate the folder where the Export file is located and highlight the file to be used, then click Open.
|
|
Remapping OptionsThe next five sections of the migration process which deals with how the I/O and memory references will be re-mapped during the migration process. As stated before, some parts of these will migrate directly, some will be remapped, and some will not migrate at all and will have to be rewritten.
The selection options are similar so make sure to read them closely. As you select the different mapping options, the graphics will change to visually display a simple example of how the remapping would proceed using that option. Because these five section deal with the context of remapping program elements from DirectLOGIC addressing to Do-more addressing, the selection made on the first section will be the default selection for the remaining four sections.
|
|
Handling I/O Module MappingDiscrete I/O Module MappingBoth the DirectLOGIC and Do-more CPUs use X and Y memory for Discrete Input and Discrete Output modules, X and Y memory in DirectLOGIC PLCs is numbered in octal, whereas the default numbering in Do-more is decimal.
The migration utility provides three options for dealing with this:
Refer to the following examples: all references to X100 with Nickname 'Start_Motor' will be mapped to an Unassigned Nickname 'Start_Motor' and the Description field will have 'X100' appended Analog I/O Module MappingAnalog I/O Modules in DirectLOGIC PLCs are mapped into Discrete I/O memory. They then use ladder logic to generate the analog input values and store these values in User V-Memory. Ladder logic is also used to retrieve values from User V-Memory and generate the required data for Analog Output modules. Depending on the DirectLOGIC PLC used in the project, and the analog module being used, this ladder logic will either be multiplexing / de-multiplexing logic, or what is referred to as 'pointer method' ladder logic which references slot-specific locations in System V-Memory. These rungs of logic are not required in a Do-more project and will need to be removed before the project can be downloaded to a Do-more CPU.
Do-more CPUs do not require any ladder logic to handle the analog I/O modules like the DirectLOGIC CPUs. Refer to the help topic on Analog I/O Module Mapping to see the I/O map required for each part number.
Analog
Input modules are automatically mapped into WX memory (and
X memory for error reporting). Each WX memory location is a Signed Word (16 bits).
Analog output modules are automatically mapped into WY memory (and Y memory for configuration as required). Each WY memory location is a Signed Word (16 bits).
Because raw analog values are typically not a convenient form for human use, the project most likely contains additional ladder logic that is converting these raw values to engineering units for use in the project. The math operations on these rungs of ladder logic can be replaced with Scale Value (SCALE) instructions. To complete the process, also consider placing the SCALE instructions for Analog Input Modules in the $tTopOfScan System Code block, and placing the SCALE instructions for Analog Output Modules in the $tBottomOfScan System Code block.
|
|
Handling Control Relay MappingBoth DirectLOGIC CPUs and Do-more CPUs use provide C memory for general purpose Control Relays. C memory in DirectLOGIC PLCs is numbered in octal, whereas the default numbering in Do-more is decimal.
Refer to the following examples: all references to C100 with Nickname 'Start_Motor' will be mapped to an Unassigned Nickname 'Start_Motor' and the Description field will have 'C100' appended |
|
Handling User V Memory MappingBoth DirectLOGIC CPUs and Do-more CPUs use provide V-Memory for general purpose, Unsigned Word (16-bit) registers. V-Memory in DirectLOGIC PLCs is numbered in octal, whereas the default numbering in Do-more is decimal.
DirectLOGIC CPUs have additional sections of 16-bit register locations (System V-Memory, Timer/Counter memory, etc) that are used for configuration and status reporting. References to these V-Memory locations can not be migrated because they have no corresponding function in a Do-more CPU. References to these locations will always be migrated as Unassigned Nicknames, and any ladder logic that has references to these location will need to be removed.
Refer to the following examples: |
|
Handling Timer and Counter MappingTimers in DirectLOGIC PLCs are numbered in octal from T0 through T377. Timers numbered T0 through T377 use V0 through V377 respectively to store their 16-bit accumulator values. Accumulating Timers numbered T0 through T377 use two successive V-Memory locations per Timer in the range V0 through V777 respectively to store their 32-bit accumulator values.
Counters in DirectLOGIC PLCs are numbered in octal from CT0 through CT377. Counters numbered CT0 through CT377 use V1000 through V1377 respectively to store their 16-bit accumulator values. Up / Down Counters numbered CT0 through CT377 use two successive V-Memory locations per Counter in the range V1000 through V1777 respectively to store their 32-bit accumulator values.
Counters and Timer in Do-more CPUs use structures with appropriate member fields as storage for their status data.
Contacts that reference a Timer or Counter will be migrated as <Timer>.Done or <Counter>.Done. Relational Contacts that reference a Timer or Counter will be migrated as <Timer>.Acc or <Counter>.Acc.
Other references to Timer current value locations (V0 through V377) will be migrated as <Timer>.Acc. Other references to Counter current count locations (V1000 through V1377) will be migrated as <Counter>.Acc.
All of the Timers in Do-more PLCs use a millisecond resolution time-base; there are no 'normal - 0.1 second resolution' and 'fast - 0.01 resolution' variants of the Timers. Both Timers and Fast Timers will be migrated into Timer structures. The constant Timer Preset values in the DirectLOGIC project will be converted to milliseconds during the migration process. Any other references to Timer Preset value will have to be manually changed accordingly.
Refer to the following examples: |
|
Handling Stage Bit MappingBoth DirectLOGIC CPUs and Do-more CPUs use provide S memory for Stages. A DirectLOGIC PLC can contain up to 128 Stage instructions which are numbered in octal from S0 through S127.
Each PROGRAM code block in a Do-more PLC can contain up to 128 Stage instructions which are numbered in decimal from <CodeBlockName>.0 through <CodeBlockName>.127.
Refer to the following examples: |
|
Select the Target Do-more CPUUse the Do-more Hardware Class and the Type selections to specify the Target Do-more CPU. The CPU type for a Do-more Designer project can be changed later using the Setup Offline CPU utility.
If the DirectSOFT project was written for a DL05, DL06, or DL105 CPU you should select, the most appropriate selection would be one of the BRX CPUs.
If the DirectSOFT project was written for one of the DL205 or DL405 CPUs you should select the Do-more H2 Series and H2-DM1E CPU as this selection will match the widest range of I/O configurations of the original DirectSOFT project.
Migration Process Log FileAppend Original DirectLOGIC Element and Nickname to Do-more Description
By default, the Element (for example V0, X37, C2000 ) and the Nickname (if one exists) will be appended to the Description text in the Do-more project. Because of the octal-to-decimal numbering conversion that occurs as part of the migration process this is very useful as it will let you know where the Element or I/O point was originally mapped to in the DirectSOFT project. You will most likely want to delete this information from the Description field after you've completed the migration.
Generate migration log file
By default, the migration process creates a log file (called <Project_Name>_DoMore_Log.Txt in the folder where the DirectSOFT export file is located). This file will contain all of the status information generated during the migration process, which will prove invaluable during the remaining portions of the migration.
Merge similar log items
A typical DirectSOFT project will contain many instances of the same instructions and memory references that cannot be automatically migrated to an equivalent Do-more instruction or memory reference. Each instance will be noted by the migration process and this selection will specify how to handle reporting the multiple instances.
Enabled (default) will generate a single entry in the log file for multiple references to a single message item regardless of how many times it appears in the DirectSOFT project.
Disabled will generate an entry in the log file for each and every instance of a message. |
|
Review Migration SelectionsThis step will display the migration settings you've specified in the previous steps. Review them and either click Back to return to a previous step so that the setting can be changed, or click Finish which will begin migrating the project.
The Migrate operation is a multiple-pass process which begins with creating a new, offline Do-more Designer project for the target Do-more CPU specified in the previous step. The migration process steps through each programming element on each rung of the ladder logic, processing each element the mapping selections specified on the initial dialog. As each element is processed, any status messages or error messages will be displayed in the Output Window.
If the option was enabled, the migration process will create a log file (named <Export_Filename>_DoMore_Log.Txt in the folder where the export file is located). This file will contain all of the status information generated in the Output Window during the migration process, which will prove invaluable during the remaining portions of the migration.
|
|
When the migration process has successfully completed, the following message box is displayed:
Click OK to finish the migration process and view the Do-more Designer project that was created.
Once the Do-more Designer project is opened, the following will prompt you to open the log file created during the migration process.
|
|
Manually Completing the MigrationThe automatic portion of the migration process will generate a valid Do-more Designer project that contains the ladder logic rungs and programming elements. The migration process will typically not be able to automatically process all of the elements in a DirectSOFT project, meaning that most project migration efforts will require additional manual editing to complete the process.
What follows are some general guidelines to follow to get the manual
portion completed as quickly as possible. The required manual editing
will be an iterative process as you step through each of the issues detailed
in the log file. To get through the required work you will need:
Complete the I/O Module MappingDiscrete Input and Output
Modules
Analog Input and Output
Modules
Complete the Communications with External Devices
Resolve $DL, $DL1, and $DLBLK (DirectLOGIC Stub) instructionsAll of the $DL, $DL1 and $DLBLK instructions
will have to be manually processed. They will need to be replaced with
the appropriate ladder logic instructions then deleted from the Do-more
project and before the project can be downloaded to a Do-more CPU. These
instructions will contain three string entries:
Note: refer to the Help topic for the Instruction Set for a complete list of the instructions available for use in a Do-more CPU.
Most of the DL SP (Special Purpose) Bits do not map into Do-more ST (Status) bits because those functions are not required in Do-more. They will be mapped to Unassigned Nicknames which must be resolved or removed from the project.
Note: refer to the Help topic on the System Nicknamed Bit Locations for a list of Bit locations in a Do-more CPU that have a System-Assigned Nickname.
All references to System Variable Memory locations are mapped to Unassigned Nicknames because most of them are not required in Do-more.
They must be resolved or removed from the project. Note: refer to the Help topic on the System Nicknamed DWord Locations for a list of DWord locations in a Do-more CPU that have a System-Assigned Nickname.
Arithmetic operations (Add, Subtract, Multiply, Divide, etc.) in DirectLOGIC PLCs are done with sequences of stack-based instructions. Do-more CPUs use a single MATH - Calculate Expression instruction to perform all arithmetic operations. The native numeric format for arithmetic operations (Add, Subtract, Multiply, Divide, etc.) in DirectLOGIC PLCs is BCD (unless expressly converted to a different format with ladder logic instructions). Do-more CPUs use decimal (aka binary) and Real as the native numeric format. Any ladder logic that is performing arithmetic calculations will need to be checked to make sure the numeric format used will generate the correct result.
Do-more uses array references for indirect addressing - like D[ V0 ], where V0 contains the index number from 0 to 65535. DirectLOGIC PLCs used the P memory type - like P2000, where the contents of V2000 is interpreted as an Octal V-Memory address. Any references to P memory will be mapped to Unassigned Nicknames and must be resolved or removed from the project.
Do-more uses Date / Time structures and Date / Time instructions for runtime date and time calculations, whereas DirectLOGIC PLCs use a series of System V-Memory locations to hold each component of the clock and calendar information. The ladder logic using these locations must be rewritten to use the $Now Date / Time structures and Date Time instructions. Any references to these locations will be mapped to Unassigned Nicknames and must be resolved or removed from the project.
Note: refer to the Help topic on the Date and Time Overview for information on the Date / Time structures and the Date / Time instructions that use them. |
|
Convert the Project to Do-more Converting a DirectLOGIC project to a Do-more project is more than simply getting the ladder logic elements, I/O and memory references moved across, that's why at this point the programmer's action is "conversion". Project conversion will typically involve rewriting sections of the ladder logic to take full advantage of doing things the Do-more way.
Take advantage of Do-more's inherent modularity by moving sections of ladder logic into Program or Task code blocks. Some good examples of using the built-in System Tasks are:
Take further advantage of modularity by moving sections of ladder logic into user-created Program, Task, Subroutine, and Interrupt Service Routine code blocks. Some good examples of doing this are:
If the DirectLOGIC system is using an ERM as a remote I/O master for an EBC100 or GS-EDRV100, you should consider removing the ERM and using Do-more's built-in Ethernet I/O Master function which can use BX-DMIOs, BX-EBC100s, H2-EBC100s, T1H-EBC100s, and GS-EDRV100s as Ethernet I/O Slaves. The major benefit is that it allows the Do-more CPU to interact with the I/O modules in the EBC100 Slave systems the same as it does with the I/O modules in the local base.
|
|
See Also:
Migrate DirectSOFT Project
DirectLOGIC
to Do-More Instruction Map
|
|
Related Topics:Insert Instructions
from a File
Using Cut / Copy / Paste to Move Rungs and Code Blocks
|
|