K-WANG



Migration core process
1. Data migration (general process)
Step operation command/tool key instructions
Backup and export NFCP100/NFJT100 data, FcxBackup all - u<username>- p<password><IP/hostname>, generate a "ACKUP" folder containing resource configuration, DUONUS.PRP, etc
Convert to NFCP500 format FcxConvert - t<NFCP501/NFCP502>- i<source folder>- o<destination folder>NFJT100 backup file cannot be converted, I/O needs to be reset
Before restoring the import of NFCP500 FcxRestore<IP/hostname>, the target folder needs to be renamed to "ACKUP" and the SRAM cleared to preserve data
Assist in clearing and holding data FcxSaveRetain-c<IP/hostname>to ensure that the backed up data is correctly mapped to SRAM
2. Control application migration
Project upgrade: R1-R3 format project automatically converts to R4 format after opening, R4 project is not backward compatible
Resource reconstruction rules (by PLC type):
Notes on PLC type processor type migration operation
IPC_40 FCX/FCX_A can be recompiled directly without modifying the project
IPC40 FCX_B/FCX_C reconstruction resources (IPC40+FCX_B/FCX_C)+compilation extension to maintain data area usage
IPC_32/IPC_33- Rebuilding resources (PLC type changed to IPC_40)+Definition of tasks/variables/labels to be copied for compilation
SH_40- Rebuilding resources (changing PLC type to IPC_40)+compiling compatible with existing functions
Download requirements: Offline download of the control application is required, and the startup project and source files should be downloaded as needed
3. Comparison of two migration modes
Advantages of core steps in applicable scenarios
Directly migrating to the on-site environment is simple and does not require pre validation of A1 (acquisition tool) - A10 (APC execution). The 10 step process is concise and does not require internal device support
The pre migration site environment is complex, and it is necessary to verify the site (B1-B3) → internal (B4-B10) → site (B11-B16) in advance, with a total of 16 steps to reduce the risk of on-site downtime and identify problems in advance

Special configuration migration
1. New feature settings (exclusive to NFCP500)
Need to configure through Resource Configurator: CPU dual machine hot standby, SNTP server, 3/4 Ethernet port of NFCP502, SD card, Duolet function
NFJT100 migration requires additional I/O definition settings
2. Field bus migration (NFLF111/NFLP121/NFLC121 modules)
Need to copy and import configuration files: FOUNDATION field bus (CF/DD file), PROFIBUS (GSD file), CANopen (EDS file)
Original project PC → New project PC: Export resource configuration → Import configuration → Download to NFCP500
3. Duolet (Java) application migration
Edit DUONUS.PRP: Remove the "#" comment before JavaStart and AdditionalClassPath
Replace batch files: CallJavac.bat, Ftp2Fcx.bat (copied from installation directory template)
Configuration parameters: Set controller IP, JAR package information, perform compilation validation
Key Limitations and Precautions
License: Cannot be migrated from the original device, NFCP500 CPU module with pre bundled required license must be used
Keep data: When expanding the hold data area, the hold data saved by the original NFCP100 is unavailable
Port adaptation: The COM2 of FCJ needs to be migrated to the RS-232C communication module, and the port name in the program needs to be changed to "RS02", etc
Dual machine hot standby: The control side and standby side CPUs must be of the same model and have the same basic software version. After migration, APC must be executed
Key issues
Question 1: What are the differences in core operations for different PLC types (IPC32/33/40) when controlling application migration?
answer:
IPC40 (processors FCX/FCX_A): No project modification required, simply recompile to adapt to NFCP500; If you need to expand and maintain the data area, you need to rebuild the resources as "IPC40+FCX_B/FCX_C" and compile them.
IPC32/IPC33: It is necessary to rebuild the resources (change the PLC type to IPC40), and copy the task definitions, global variables, device labels, software wiring, and other configurations of the original project before compiling and downloading.
The core difference lies in whether resources need to be rebuilt. The root cause is that NFCP500 is only compatible with IPC40 and above PLC types, and lower version PLC types need to be upgraded and adapted.
Question 2: What are the applicable scenarios and core differences between the two migration modes (direct migration vs pre migration)?
answer:
Applicable scenarios: Direct migration is suitable for scenarios where on-site downtime is allowed and the environment is simple (without complex field buses or special applications); Pre migration is suitable for complex on-site environments (including field buses and Duolet applications) that require minimizing downtime risks.
Core difference: Pre migration adds an "internal device verification" step (steps B4-B10), which allows for early completion of data conversion, application compilation, and functional testing. On site, only CPU replacement, data recovery, and application download need to be performed; Direct migration means that all operations are completed on the target device on site without pre validation, resulting in a simpler process but higher risks.
Question 3: How to migrate the configuration of the field bus module (NFLF111/NFLP121/NFLC121) during the migration process? What should I pay attention to?
answer:
Migration steps: ① Export field bus definition information from the original project PC (NFCP100); ② Copy the configuration files (CF/DD/GSD/EDS) to the new project PC (NFCP500); ③ Import definition information and download it to NFCP500; ④ Verify the field bus communication function.
Attention: ① If using FF engineering tools before R2.20, the configuration needs to be converted to FF configurator format first; ② The field bus definition information is bound to the controller IP, and when replacing the project PC, "export import" must be performed. Upgrading the same PC does not require any operation; ③ After migration, it is necessary to focus on verifying the communication connectivity of field bus devices to avoid configuration omissions.
