diff --git a/kd240/bist.html b/kd240/bist.html index 233048c5..4816a62b 100644 --- a/kd240/bist.html +++ b/kd240/bist.html @@ -1,20 +1,14 @@ - -KR260 Documentation - -Redirecting to the main page. - + + + + Redirecting... + + + If you are not redirected automatically, please click here. \ No newline at end of file diff --git a/kd240/build/doctrees/docs/bist/bist_landing.doctree b/kd240/build/doctrees/docs/bist/bist_landing.doctree index e3efc8f0..daf989f5 100644 Binary files a/kd240/build/doctrees/docs/bist/bist_landing.doctree and b/kd240/build/doctrees/docs/bist/bist_landing.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/known_issues.doctree b/kd240/build/doctrees/docs/bist/docs/known_issues.doctree index e8e528e4..7b3e5662 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/known_issues.doctree and b/kd240/build/doctrees/docs/bist/docs/known_issues.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/can.doctree b/kd240/build/doctrees/docs/bist/docs/modules/can.doctree index 3df0b26c..f4495bd9 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/can.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/can.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree b/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree index 0a742923..5ce32db0 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/display.doctree b/kd240/build/doctrees/docs/bist/docs/modules/display.doctree index 9f8426f9..4ddf3ba9 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/display.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/display.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree b/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree index ab6a66ed..df0fe25f 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree b/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree index 12af1377..c6388f63 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree b/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree index c67bf548..f24d7eff 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree b/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree index ab44479d..fb2b9a29 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree b/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree index 44c6de5e..5d749f01 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree b/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree index 3641aa8e..1f6a567c 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree b/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree index 8bb83d8d..0f7c98ca 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree b/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree index 4b604f59..ebebeee1 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree b/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree index 994153be..8d40f9f0 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree b/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree index b56e3bec..90673239 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree b/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree index 6a5a1eb8..4bd3919e 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/modules/video.doctree b/kd240/build/doctrees/docs/bist/docs/modules/video.doctree index 72bb8f0f..46091b83 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/modules/video.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/video.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/overview.doctree b/kd240/build/doctrees/docs/bist/docs/overview.doctree index 1ffa55cd..58592d8e 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/overview.doctree and b/kd240/build/doctrees/docs/bist/docs/overview.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/run.doctree b/kd240/build/doctrees/docs/bist/docs/run.doctree index 1310eccc..ae920515 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/run.doctree and b/kd240/build/doctrees/docs/bist/docs/run.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree index 09aa5d9b..ace4d1ba 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree index c25dede2..dfa5de6b 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree differ diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree index ffe66fc6..e3f3c801 100644 Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree differ diff --git a/kd240/build/doctrees/docs/build_vivado_design.doctree b/kd240/build/doctrees/docs/build_vivado_design.doctree index f0210e9f..cfe85633 100644 Binary files a/kd240/build/doctrees/docs/build_vivado_design.doctree and b/kd240/build/doctrees/docs/build_vivado_design.doctree differ diff --git a/kd240/build/doctrees/docs/building_the_design.doctree b/kd240/build/doctrees/docs/building_the_design.doctree index d1646356..f920fe0e 100644 Binary files a/kd240/build/doctrees/docs/building_the_design.doctree and b/kd240/build/doctrees/docs/building_the_design.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree new file mode 100644 index 00000000..ac28b30d Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree new file mode 100644 index 00000000..b78d32d3 Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree new file mode 100644 index 00000000..98e7289e Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree new file mode 100644 index 00000000..3f7060c9 Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree new file mode 100644 index 00000000..d49b0731 Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree index d0b40833..35817b47 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree index 321a3153..285b2150 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree index 387f13b5..d7d00c63 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree index efb69eb6..a61e330e 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree index eeaecf45..fe313981 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree index 63e2adc9..9a2ac70a 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree differ diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree index 3ca3d59b..037a4744 100644 Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree differ diff --git a/kd240/build/doctrees/docs/generating_custom_firmware.doctree b/kd240/build/doctrees/docs/generating_custom_firmware.doctree index 36b28f3d..cb626693 100644 Binary files a/kd240/build/doctrees/docs/generating_custom_firmware.doctree and b/kd240/build/doctrees/docs/generating_custom_firmware.doctree differ diff --git a/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree b/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree index 39185063..23f6df4c 100644 Binary files a/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree and b/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree differ diff --git a/kd240/build/doctrees/docs/library_dependency.doctree b/kd240/build/doctrees/docs/library_dependency.doctree new file mode 100644 index 00000000..b9b47236 Binary files /dev/null and b/kd240/build/doctrees/docs/library_dependency.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree index b319705a..a1b443df 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree new file mode 100644 index 00000000..76817034 Binary files /dev/null and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree index 38578f8a..baea8378 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree index c2bb2a78..60e24238 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree index 27dd2412..706fe030 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree index 29d5fa51..2bce41f0 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree differ diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree index c0b0abd7..74453c68 100644 Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree differ diff --git a/kd240/build/doctrees/docs/yocto_port_example.doctree b/kd240/build/doctrees/docs/yocto_port_example.doctree new file mode 100644 index 00000000..a2802002 Binary files /dev/null and b/kd240/build/doctrees/docs/yocto_port_example.doctree differ diff --git a/kd240/build/doctrees/index.doctree b/kd240/build/doctrees/index.doctree index af29c478..b2bab0d2 100644 Binary files a/kd240/build/doctrees/index.doctree and b/kd240/build/doctrees/index.doctree differ diff --git a/kd240/build/html/.buildinfo b/kd240/build/html/.buildinfo index b084eff8..a071a0dd 100644 --- a/kd240/build/html/.buildinfo +++ b/kd240/build/html/.buildinfo @@ -1,4 +1,4 @@ # Sphinx build info version 1 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done. -config: a61d5a4b0808988c06c270cf556ec6d2 +config: 5ead5f5b738485b68485d231e614c3a7 tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/kd240/build/html/_images/sw_ros2_control.png b/kd240/build/html/_images/sw_ros2_control.png deleted file mode 100644 index 3e97d7f0..00000000 Binary files a/kd240/build/html/_images/sw_ros2_control.png and /dev/null differ diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt new file mode 100644 index 00000000..80763ed9 --- /dev/null +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt @@ -0,0 +1,223 @@ + + + + + + + +

Kria™ KD240 Drives Starter Kit
FOC Motor Control Application Tutorial

+

Setting up the Board and Application Deployment

+ +
+ +# Board Setup and Application Deployment + +## Introduction + +This document shows how to set up the board, and run the motor control application. + +This guide is targeted for Ubuntu® 22.04 and the AMD 2023.1 toolchain. + +## Prerequisite + +### Hardware Requirements + +* [KD240 Drives Starter Kit](https://www.xilinx.com/products/som/kria/kd240-drives-starter-kit.html) + +* [KD240 Motor Accessory Kit](https://www.xilinx.com/products/som/kria/kd240-motor-accessory-pack.html) + +* KD240 power supply and adapter (included with the KD240 Drives Starter Kit) + * 12V AC adapter for the KD240 Starter Kit and 24V AC adapter for the Motor Accessory Kit + +* USB-A to micro-B cable (included with the KD240 Drives Starter Kit) + +* MicroSD card (32 GB card is included with the KD240 Drives Starter Kit) + +* CAT6 Ethernet cable + +* Host machine with display + +### Hardware Setup + +![KD240-Setup](./media/KD240.png) + +* Connect the USB cable from the host machine to the J4 UART/JTAG interface on the board. + + ![KD240-Setup](./media/Connect_USB_to_J4.jpg) + +* Connect the Ethernet cable from J24 to your local network with DHCP enabled to install the Linux packages. + + ![KD240-Setup](./media/Connect_Ethernet_to_J24.jpg) + +* Connect a 12V power supply to the J12 DC jack. + + ![KD240-Setup](./media/Connect_12V_to_J12.jpg) + +* Connect a 24V power supply to the J29 DC link connector. + + ![KD240-Setup](./media/Connect_24V_to_J29.jpg) + +* Connect the encoder header pins to the J42 QEI connector. Ensure J44 is in the "SE" selection. + + ![KD240-Setup](./media/Connect_EncoderPin_to_J42.jpg) + +* Connect the motor input to a J32 3-phase inverter connector. + + ![KD240-Setup](./media/Connect_ACpower_to_J32.jpg) + +### Tested Artifacts + +Testing was performed with the following artifacts: + +#### KD240 platform Artifacts + +| Component | Version | +|--------------------------------|----------------------------| +| Boot Firmware | K24-BootFW-01.01 | +| Linux Kernel | 5.15.0-1027-xilinx-zynqmp | +| xlnx-firmware-kd240-motor-ctrl | 0.10.1-0xlnx1 | + +To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/1641152513/Kria+K26+SOM#Boot-Firmware-Updates). + +#### Application Packages + +| Package | Version | +|--------------------------------|--------------| +| xlnx-app-kd240-foc-motor-ctrl | 0.3.1-0xlnx5 | + +### Initial Setup + +1. Go through [Booting Kria Starter Kit Linux](https://xilinx.github.io/kria-apps-docs/kd240/linux_boot.html) to complete the minimum setup required to boot Linux before continuing with instructions on this page. + +2. Get the latest motor control application and firmware package: + + * Download the firmware. + * Search package feed for packages compatible with the KD240. + + ```bash + ubuntu@kria:~$ sudo apt search xlnx-firmware-kd240 + Sorting... Done + Full Text Search... Done + xlnx-firmware-kd240-bist/jammy,now 0.10-0xlnx1 arm64 [installed] + FPGA firmware for Xilinx boards - kd240 bist application + xlnx-firmware-kd240-motor-ctrl-qei/jammy,now 0.10-0xlnx1 arm64 [installed] + FPGA firmware for Xilinx boards - kd240 motor-ctrl-qei application + ``` + + * Install the firmware binaries. + + ```bash + sudo apt install xlnx-firmware-kd240-motor-ctrl-qei + ``` + + * Install the motor control application. + + ```bash + sudo apt install xlnx-app-kd240-foc-motor-ctrl + ``` + +## Run the Motor Control Application + +* Load the firmware: + + * Show the list and status of available application firmware. + + After installing the firmware, execute xmutil listapps to verify that it is captured under the listapps function and to have dfx-mgrd rescan and register all accelerators in the firmware directory tree. + + ```bash + ubuntu@kria:~$ sudo xmutil listapps + Accelerator Accel_type Base Base_type #slots(PL+AIE) Active_slot + + kd240-motor-ctrl-qei XRT_FLAT kd240-motor-ctrl-qei XRT_FLAT (0+0) -1 + ``` + + * Load the desired application firmware. + + When there is already another accelerator/firmware loaded, unload it first, then load the kd240-foc-motor-ctrl firmware. + + ```bash + sudo xmutil unloadapp + sudo xmutil loadapp kd240-motor-ctrl-qei + ``` + +* Run the bokeh server: + + ```bash + # Run the application to launch bokeh server for the dashboard + export PATH=${PATH}:/opt/xilinx/xlnx-app-kd240-foc-motor-ctrl/bin + start_motor_dashboard + # Enter the sudo password if required and note the ip address of the board + ``` + + Sample screenshot of the terminal on launching the motor dashboard. + + ![Terminal](./media/terminal.png) + +## On the Host PC + +* Open <ip>:5006 in a web browser. + + >**NOTE:** Once the server is running, it retains its settings no matter how many times the browser is closed, opened, or refreshed. + +* The system is set to OFF mode/state on starting the dashboard, observe the blue LED DS10 is off. +* If the unit is plugged into a network with DHCP, an IP will be assigned automatically. If not on a network, then configure a static IP. For help on setting up static IP, see [Setting up a private network](https://github.com/Xilinx/vck190-base-trd/blob/2022.1/docs/source/run/run-dashboard.rst#setting-up-a-private-network). + +>**NOTE:** The open-loop mode of motor operation is a test mode intended for users with motor control knowledge and experience. Incorrect configurations of values of Vd and Vq can cause the motor to spin at speeds higher than its rating and potentially cause excessive motor heating. Use caution when using the open-loop mode. + +## Dashboard + +### Dashboard Features + +* The Mode drop-down is used to select the control system mode of operation. +* The Sample Size text box is used to indicate how many samples are collected and plotted on the graphs for each type of data. The samples are collected at 100 microsecond intervals. The maximum number of samples is limited to 3000 due to dashboard performance limitations. For a large number of samples, there might be a small delay before a dashboard command takes effect. +* The Refresh Interval text box is used to indicate how often the dashboard plots will refresh. A minimum refresh interval will be enforced based on the current sample size (a larger sample size requires a larger refresh interval). +* The gain text boxes are used to adjust the proportional and integral gains of the corresponding control loop. +* The Speed Setpoint text box is used to set the speed setpoint when running the motor in speed mode. The valid range of speed setpoints is -10000 to 10000 rpm. +* The Torque Setpoint text box is used to set the torque setpoint when running the motor in torque mode. The valid range of torque setpoints is -2.5 to 2.5 amps. +* The Open Loop - Vd text box is used to set the direct voltage (Vd). The valid range for Vd is -24 to 24 volts. + >**NOTE:** Normally this should be set to ~0V. +* The Open Loop - Vq text box is used to set the quadrature voltage (Vq). The valid range for Vq is -24 to 24 volts. +* The Fault Status indicators show if any faults have occured. When a critical fault occurs, the corresponding indicator will turn red. For a warning level faults, the corresponding indicator will turn yellow. +* The Clear Faults button is used to clear all faults and put the system into Off mode. +* The Electrical Data plot shows the currents and voltages for Phase A, B, and C. The voltage lines are hidden by default. The visibility of each current and voltage line can be toggled by clicking the legend labels. The current axis is shown on the left if any current lines are visible, and the voltage axis is shown on the right is any voltage lines are visible. +* The Mechanical Data plot shows the speed and position of the motor. The visibility of each line can be toggled by clicking on the legend labels. The speed axis is shown on the left is speed is visible and the position axis is shown on the right if position is visible. +* The Live Analysis plot shows the data that is selected for each axis using the buttons on the right. + +When the dashboard is first launched, the system will be in Off mode, and the dashboard will look similar to the following image. Observe that the electrical readings are near zero. + +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_Off.png) + +To run the application in Speed mode, select **Speed** from the Mode drop-down, and use the Speed Setpoint text box to enter a speed setpoint. The following image shows the motor running in speed mode with a speed setpoint of 2000 rpm and the load disk that is included in the Motor Accessory Kit. + +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_Speed.png) + +To run the application in Torque mode, select **Torque** from the Mode drop-down and use the Torque Setpoint text box to enter a torque setpoint. The following image shows the motor running in torque mode with a torque setpoint of 1 amp and the load disk that is included in the Motor Accessory Kit. + +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_Torque.png) + +To run the application in Open Loop mode, select **Open Loop** from the Mode drop-down, and use the Vd/Vq text boxes to set Vd/Vq. The following image shows the motor running in open loop mode with Vd set to 0, Vq set to 4 volts, and the load disk that is included in the Motor Accessory Kit. + +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_OpenLoop.png) + +The following images show what the dashboard looks like when a larger load is applied to the motor. As the load on the motor increases, the currents will increase and the I_alpha/I_beta circle will expand. + +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_Speed_Loaded.png) +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_Torque_Loaded.png) +![Motor-Control-Dashboard](./media/Motor_Control_Dashboard_OpenLoop_Loaded.png) + +## Next Steps + +* Go back to the [KD240 FOC Motor Control Application Start Page](../foc_motor_control_landing) + + + +

Copyright© 2023 Advanced Micro Devices, Inc

diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt new file mode 100644 index 00000000..62b86b9d --- /dev/null +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt @@ -0,0 +1,305 @@ + + + + + + + +

Kria™ KD240 Motor Control Starter Kit
Motor Control Tutorial

+

Hardware Architecture of the Platform

+ +
+ +# Hardware Architecture of the Platform + +## Introduction + + This section describes the design implemented in the programmable logic (PL). The following figure shows the top-level hardware architecture of the reference design. + +![Hardware Architecture block diagram](./media/hw_arch.png) + + At a high-level, the design is comprised of a motor control system, a data monitoring system, a data processing system, and a communication system. + +* Motor Control System: These are the blocks that control the motor speed and direction. All but the Gate Driver are High-Level Synthesis (HLS) blocks from the AMD Vitis™ Motor Control Library. + + * Quadrature Encoder Interface (QEI) + * Field-Orientated Control (FOC) + * Space Vector Pulse Width Modulation (SVPWM) + * Pulse Width Modulation Generation (PWM Gen) + * Gate Driver + +* Data Monitoring System: These are the blocks that monitor data from the motor and DC power supply. + + * ADC Sample Control + * Current and Voltage Analog to Digital Controller (ADC) Interface for Motor phases A, B, C, and DC Link + * Unicode Straight Binary (USB) to Binary Two's Complement (BTC) Conversion + * Bipolar Offset Binary (BOB) to BTC Conversion + +* Data Processing System: This is the block that controls the ADC interface and decides when to sample the ADCs. It also does basic filtering, scales the data, and formats it in Q-Scale format. + + * ADC Hub + +* Time-Sensitive Networking (TSN) System: This system support transmission of Ethernet traffic based on traffic shaping protocols. The traffic can be control information to be passed between different nodes in a robotics system or between various Industrial Field devices. The requirement in these systems would be that the traffic is deterministic. + + * TSN IP + * AXI Multi Channel DMA (MCDMA) + * Time Aware DMA (TADMA) + * Test PMOD controller + +## Motor Control System + +### QEI + +The QEI module from the Vitis Motor Control Library reads the encoder on the motor and provides the data to the FOC block. + +For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html). + +### FOC + +The FOC module from the Vitis Motor Control Library implements a sensor-based field-orientated control. The eight control modes it supports cover basic speed and torque control modes, as well as field-weakening control. + +For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html). + +### SVPWM + +The SVPWM module from the Vitis Motor Control Library implements the front-end for Space Vector Pulse Width Modulation to calculate phase ratios for the motor. + +For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html). + +### PWM Gen + +The PWM Gen module from the Vitis Motor Control Library implements the back-end for Space Vector Pulse Width Modulation to generate output signals based on the ratios from SVPWM. + +For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html). + +### Motor Control + +The motor control block collects all the fault information generated from ADC Hub and uses this information along with its own phase balance calculations on the Phase A, B, and C data to decide whether to allow the gate drivers to drive the motors. + +## Data Monitoring System + +### ADC Sample Control + +This custom IP converts the motor pwm_sync pulse from the HLS module hls_pwm_gen to an update signal that initiates the ADC capture cycle at regular intervals. The ADC Sample Control module acts much like a phase-locked loop (PLL), in that it tries to align the ADC captures to the pwm_sync pulse and keep the ADC samples to an integer number of samples during the pwm_sync cycle. + +### ADC7352 Interface + +The voltage and current for DC Link and Motor Phase A, B, and C, are captured by the ADC7352 Interface IP. The IP can be configured for up to 16 channels, each with its own bit resolution. Each channel can control one ADC7352, with its own Chip Select (CS). The KD240 Motor Control Kit uses eight channels at 12 bits resolution. DC Link ADC uses one chip select, and the Phase A/B/C Motor ADCs share another chip select for simultaneous data collection. + +### ADC Encoding Conversions + +The KD240 Motor Control Kit makes use of the AD7352 which is a unipolar ADC using USB encoding. The DC link and stator voltages are measured and encoded without any analog offsets while the current measurements require direction. For current measurements, an instrumentation amplifier with an analog offset output is used to be able to make use of the unipolar ADC to encode both positive and negative measured currents. The following table outlines the expected mapping. + +| KD240 Measurement | -FS Input | -FS Code | Midpoint | Midpt Code | +FS Input | +FS Code | +| --------------------- |:---------:|:--------:|:---------:|:----------:|:---------:|:---------:| +| DC Link Voltage | 0V | b0000 | +18.432V | b1000 | +36.864V | b1111 | +| Motor Stator Voltages | 0V | b0000 | +18.432V | b1000 | +36.864V | b1111 | +| DC Link Current | 0A | b0000 | +10.24A | b1000 | +20.48A | b1111 | +| Motor Stator Current | -10.24A | b0000 | 0A | b1000 | +10.24A | b1111 | + +For DC Link voltage and current and for motor voltages, the conversion is done in USB to BTC IP. + +For motor currents, the conversion is done in BOB to BTC IP. + +## Data Processing System + +### ADC Hub + +This custom IP is the center of the processing for ADC data. It is parameterizable up to 16 channels, and each channel can be a different width. Each channel can also be treated as BTC or USB individually and can be customized to use DSP blocks or logic to implement the multipliers used for scaling the ADC data. There is also a choice for whether the channel is a Current or Voltage channel. This information is only to help the software understand what units to use for the data it reads from the ADC Hub. The KD240 Motor Control Kit uses eight channels, 12-bits, BTC encoding, and all channels are using the DSP for multipliers. + +Inside the ADC Hub are several functions, which are described in the next few sections. + +#### Simple Moving Average + +The data from the ADCs comes into the ADC Hub and goes into the Simple Moving Average (SMA) block. If there is an offset programmed by the software, first the offset is subtracted from the raw data coming in from the ADC. The offset can be positive or negative, which will result in either a smaller or larger value, respectively. + +After the offset is applied, then the data is entered into a FIFO, implemented in a block RAM. Software can program the number of taps to use for the SMA, from 1 to 128 in powers of two. The SMA function adds each new data to the sum of the previous data until the number of samples reaches the number of taps programmed by the software. At that time, the newest sample is added to the sum, and the oldest sample is read out of the block RAM and subtracted from the sum. The new sum is then shifted by the log2 of the tap count and becomes the output of the SMA module. + +There is no output from the SMA until the number of sammples has reached the number of taps. If the number of taps changes while the SMA is running, the whole datapath is reset, and the block RAM and adders are cleared. Once again, there will be no output until the new number of taps matches the number of samples received. + +#### Q-Scaler + +The ADC Hub scales the averaged data in the Q-Scaler module. Software programs the scaling factor, which is then multiplied with the averaged data. This multiplier can be implemented by a DSP or by logic in the configuration of the ADC Hub, on a per-channel basis. The scaled data is converted to Q-format, with 24 total bits. The integer portion is 7 bits, the fractional portion is 16 bits, and one sign bit. This scaled value is passed to the rest of the system as an AXI4-Stream interface, with no dependence on `tready` so that the data is always the most recent value. + +The scaling factors used in the KD240 Motor Control Kit are in the following table. + +| KD240 Measurement | ADC Scale Multiplier | ADC Scale (V/cnt) | Q-Format | +| --------------------- |:--------------------:|:-----------------:|:-----------:| +| DC Link Voltage | 1179.6480 | 0.018 | 0x00_049C | +| Motor Stator Voltages | 1179.6480 | 0.018 | 0x00_049C | +| DC Link Current | 655.3600 | 0.010 | 0x00_028F | +| Motor Stator Current | 327.6800 | 0.005 | 0x00_0148 | + +#### Motor Fault Generation + +The averaged and scaled data is compared against limits set by the software to determine whether a fault has occurred. Software can program over-limits and under-limits per channel. If such limits are enabled, and the scaled data exceeds these limits, then a fault will be generated. There are over-faults and under-faults, and if enabled and triggered will result in an error being generated. + +Errors can only be cleared by writing a specific value to the associated clear register (one for over-fault and one for under-fault). These faults are used to generate interrupts for the ADC Hub, if interrupts are enabled. They are also used by the Motor Control module to generate the gate drive enable signal to the Gate Driver. + +#### Register Map + +The AXI Interface in the ADC Hub allows the software to control and monitor the hardware. The register map is as follows: + +Address Decode + +| 31:12 | 11:08 | 07:00 | +| ------|:---------:|:---------------:| +| n/a | Channel | Register Offset | + +Channel: Up to 16 Channels supported + +Register: Up to 64 channels supported + +| Offset | Register Name | Signed | R/W | Bits Used | Reset Value | +| -------|:-------------------------------------:|:------:|:---:|:---------:|:-------------:| +| 0x00 | Over Limit Value (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0000 | +| 0x04 | Under Limit Value (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0000 | +| 0x08 | Scaling Factor (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0320 | +| 0x0C | Number of Taps for Averaging | N | R/W | 8:0 | 0x0000_0004 | +| 0x10 | Raw ADC Value | Y | R | 15:0 | 0x0000_0000 | +| 0x14 | Scaled ADC Value (Q8.16 Format) | Y | R | 1:0 | 0x0000_0000 | +| 0x18 | Error Status | N | R | 15:0 | 0x0000_0000 | +| 0x1C | Clear Over Limit Error (0x0BAD00FF) | N | R/W | 31:0 | 0x0000_0000 | +| 0x20 | Clear Under Limit Error (0x0BAD00FF) | N | R/W | 31:0 | 0x0000_0000 | +| 0x24 | Over Limit Error Enable | N | R/W | 0:0 | 0x0000_0000 | +| 0x28 | Under Limit Error Enable | N | R/W | 0:0 | 0x0000_0000 | +| 0x2C | Signed (1) or Unsigned (0) Data | N | R | 0:0 | HW Value | +| 0x30 | Voltage (1) or Current (0) Channel | N | R | 0:0 | HW Value | +| 0x34 | Total Number of Channels used in Hub | N | R | 3:0 | HW Value | +| 0x38 | IRQ Disable | N | R/W | 0:0 | 0x0000_0000 | +| 0x3C | ADC Offset | N | R/W | 31:0 | 0x0000_0000 | + +## TSN System + + The following figure shows the blocks in the TSN System. + +![TSN System block diagram](./media/TSN_kd240.png) + +### TSN IP + +The LogiCORE™ 100M/1G TSN Subsystem IP implements IEEE 802.1 Time Sensitive Networking (TSN) standards and provides a low latency bridged endpoint. The bridged endpoint solution consists of a 3-port switch, two ports connects to the network and one port connects to an internal endpoint. In this design, reduced gigabit media independent interface +(RGMII) interfaces connect to a Marvel physical-side interface (PHY) supporting a maximum bandwidth of 1 Gbps. The TSN IP is configured to support: + +* Network Time Synchronization- 1588 Precision Time Protocol (PTP) +* Scheduled and Best Effort traffic types +* Time aware scheduling (IEEE 802.1 Qbv) +* Frame replication and elimination (IEEE 802.1 CB) +* Per Stream Filtering and Policing (IEEE 802.1 Qci) + +For more information on the IP, refer to the *100M/1G TSN Subsystem IP Product Guide* ([PG275](https://www.xilinx.com/content/dam/xilinx/member/1gtsn_doc/2020_1/pg275-tsn-endpoint-ethernet-mac.pdf)). + +>***NOTE:** You will need access to [1GTSN Documentation Lounge](https://www.xilinx.com/member/1gtsn_doc.html) to view the document. + +#### MCDMA + +The AXI MCDMA provides high-bandwidth direct memory access between memory (AXI Memory Mapped) and stream (AXI4-Stream) target peripherals. It supports both Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) transfers. The AXI MCDMA core provides a Scatter Gather (SG) interface with multiple channel support with independent configuration. In this design, the MCDMA is responsible to fetch Best Effort traffic for transmission by the TSN IP. It reads frames from the DDR memory and passes the data to the TSN IP on an AXI4-Stream interface. It is also responsible for writing the Schedule traffic and Best Effort traffic frames received from the TSN IP to the memory. The IP uses the S_AXI_HP0_FPD on the AMD Zynq™ UltraScale+™ MPSoC Processing System (PS) IP to read/write from/to DDR memory. + +For more information on the IP, refer to the *AXI MCDMA LogiCORE IP Product Guide* ([PG288](https://docs.xilinx.com/v/u/en-US/pg288-axi-mcdma)). + +#### TADMA + +TADMA is aware of QBV schedule cycles, stream time slots, and by using PTP +generated time, it is capable of fetching frames for different streams/traffic classes from the system memory (DDR) at precisely required time, providing excellent time precision for TSN traffic. In this design, TADMA fetches scheduled traffic from memory, based on the Qbv programming and passed it to the TSN IP for transmission. + +For more information on the IP, refer to the *Time Aware DMA Product Guide* ([PG316](https://www.xilinx.com/content/dam/xilinx/member/1gtsn/2018_2/pg316-tadma.pdf)). + +>**NOTE:** You will need access to the [1GTSN Documentation Lounge](https://www.xilinx.com/member/1gtsn_doc.html) to view the above document. + +#### Test PMOD Controller + +The Test PMOD controller is a user IP that drives the [Digilent Test PMOD](https://digilent.com/shop/pmod-tph2-12-pin-test-point-header/) pins. The IP implements the following registers. + +| Register Offset | Register Name | Description | +| :---- | :--- | :---- | +|0x00 |slv_reg0| Bit0 is a MUX enable. If 1, then drive Qbv signals on PMOD. If 0, drive TSN publisher/subscriber 8-bit signatures| +|0x04 |slv_reg1| 8-bit signature when publisher 1 transmits a TSN frame | +|0x08 |slv_reg2| 8-bit signature when subscriber 1 receives a TSN frame | +|0x0c |slv_reg3| 8-bit signature when publisher 2 transmits a TSN frame | +|0x10 |slv_reg4| 8-bit signature when subscriber 2 receives a TSN frame | + +The TSN application can support multiple publishers and subscribers. When the publisher queues up a packet for transmission, it writes a unique 8-bit word to `slv_reg*`, which is then transmitted on the PMOD pins. Similarly when the subscriber receives a packet, it writes a unique 8-bit word to `slv_reg*` which is then transmitted on the PMOD pins. The PMOD pins of the publisher and subscriber are hooked up to a scope and are used to measure end to end application latency. The TSN pub sub application sets the MUX (`slv_reg0`) to 0 before writing the signature value. The following figure shows the mapping on the PMOD pins when MUX is set to 0 and 1. + +![Test PMOD pin mapping](./media/TSN_pmod.png) + +To view scheduled and best effort traffic, the MUX value is set to 1. If the Qbv schedule is set, for example, a time slot is programmed with 70% scheduled traffic and 30% best effort traffic, then viewing `tlast` signal of received scheduled traffic and `tlast` signal of received best effort traffic on a scope will confirm that Qbv is working as expected. `tlast` indicates the end of a packet. Transmit signals can also be monitored, but these signals are the on the outside of the TSN IP and the traffic is yet to be scheduled. + +The other signal which is monitored to see if the Transmitter and Receiver clocks are in sync is the PTP clock. + +For more information on how to use PMOD signals to check clock synchronization and to measure latency and confirm Qbv programming, refer to [application deployment page](./app_deployment.md). + +## Clocks, Resets, and Interrupts + +### Clocks + +The following table identifies the main clocks of the PL design, their source, their clock frequency, and their function. + +| Clock | Clock Source | Clock Frequency | Function | +| :--- | :----: | :---: | :----- | +| pl_clk0 | PS | 100 MHz | Clock source for clocking wizard (clk_wiz_0) | +| clk_out_100M | clk_wiz_0 | 100 MHz | Clock for data on CIPS port M_AXI_HPM0_FPD and most of the system | +| clk_out_48M | clk_wiz_0 | 48 MHz | Clock for SCLK to ADC and ADC7352 Interface Module | +| CLK_IN_gem | External Pin | 25 MHz | Clock for TSN Subsystem clocking wizard (clk_wiz_0) generating clocks | +| clk_out1 | TSN clk_wiz_0 | 200 MHz | TSN IP fifo clock, TADMA IP and MCDMA IP data transactions clock | +| clk_out2 | TSN clk_wiz_0 | 125 MHz | TSN IP and TADMA IP Real Time clock (RTC) for internal timers for time sensitivity | +| clk_out3 | TSN clk_wiz_0 | 300 MHz | reference clock for IDELAY control block for PHY operation on TSN IP | +| clk_out4 | TSN clk_wiz_0 | 100 MHz | AXI4-Lite clock to configure TSN IP, MCDMA IP, and Register interface IP | + +### Resets + +The following table summarizes the resets used in this design. + +| Reset Source | Function | +| :--- | :---- | +| pl_resetn0 | PL reset for proc_sys_reset modules and TSN Subsystem | +| proc_sys_reset_0 | Synchronous resets for clk_out_100M clock domain | +| proc_sys_reset_1 | Synchronous resets for clk_out_48M clock domain | +| TSN Phy_reset_n | Reset for External Phy (tied high) | +| TSN rst_clk_wiz_0_100M | Synchronous Reset for clk_out100M clock domain | +| TSN rst_clk_wiz_0_125M | Synchronous Reset for clk_out125M clock domain | +| TSN rst_clk_wiz_0_200M | Synchronous Reset for clk_out200M clock domain | +| TSN rst_clk_wiz_0_300M | Synchronous Reset for clk_out300M clock domain | + +### Interrupts + +The following table lists the PL-to-PS interrupts used in this design. + +| Interrupt ID | Instance | +| :--- | :---- | +|pl_ps_irq0[0]| ADC Hub IP | +|pl_ps_irq0[1]| Motor Control IP | +|pl_ps_irq0[2]| AXI Quad SPI 0 IP | +|pl_ps_irq0[3]| HLS QEI IP | +|pl_ps_irq0[4]| HLS FOC IP | +|pl_ps_irq0[5]| HLS SVPWM Duty IP | +|pl_ps_irq0[6]| HLS PWM Gen IP | +|pl_ps_irq0[7]| TSN Subsystem | + +The TSN Subsystem interrupts are itemized in the following table. + +| Interrupt ID | Instance | +| :--- | :---- | +|intr[0-7]| TSN IP | +|intr[8]| TADMA IP | +|intr[9-14]| MCDMA IP | + +## Resource Utilization + +The resource utilization numbers on this platform post implementation is reported in the following table. + +| Resource | Utilization | Available | Utilization % | +| :--- | :---- | :--- | :---- | +| LUT | 57895 | 70560 | 82.05 | +| LUTRAM | 4098 | 28800 | 14.23 | +| FF | 84715 | 141120 | 60.03 | +| BRAM | 116 | 216 | 53.70 | +| DSP | 133 | 360 | 36.94 | +| IO | 63 | 81 | 77.78 | +| BUFG | 21 | 196 | 10.71 | +| MMCM | 2 | 3 | 66.67 | +| PLL | 0 | 6 | 0.00 | + +## Next Steps + +* [Software Archicture](./sw_arch.md) +* Go back to the [KD240 FOC Motor Control Landing Page](../foc_motor_control_landing) + diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt new file mode 100644 index 00000000..5928e5f3 --- /dev/null +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt @@ -0,0 +1,67 @@ + + + + + + + + +

Kria™ KD240 Drives Starter Kit
FOC Motor Control Application Tutorial

+

Introduction

+ +
+ +# Introduction + +The KD240 Field Oriented Control (FOC) Motor Control Application is intended to capture general inverter and motor control examples using AMD-Xilinx standard IP/libraries. The IPs, libraries, and drivers serve as a design example demonstrating the K240 SOM capabilities in implementing applications that require precise control of the motor's speed and torque while minimizing energy losses and reducing system noise. The IPs, libraries, and drivers created are general in the sense they do not assume specific board level hardware for implementing the necessary cyber-physical boundaries around a given application. + +An overview of the motor field orientated control library functionality is summarized in the following three types of FOC based motor control that are to be implemented for supporting the KD240. Each focuses on either controlling the torque or speed of the motor. + +* Torque Control: Default FOC control is focused on maximizing the torque output of a motor by optimizing the quadrature (q) vector which represents the useful motor torque and minimizing the direct (d) vector component. In this mode of operation, the goal is to keep motor torque constant by adjusting motor speed. + +* Speed Control: Speed control is implemented through an additional PI control that adjusts the motor torque to the motor to maintain a constant speed. + +* Field Weakening Control: The field weakening control method trades off optimal torque to increase the speed of the motor. This is accomplished by adjusting the relationship of the q-vector and d-vector in FOC. + +## Design and Implementation + +The following provide more detailed definitions around the defined motor control modes of operation. + +### Torque Control + +Torque control implements a closed loop control focused on maintaining a specified torque value In this mode of operation, the q-vector provides the useful torque output of the motor, and the d-vector provides the force that is parallel to the rotor. The d-vector represents non-useful force, and thus any non-zero value is considered an error. + +![Torque-Control](./media/torqc.png) + +### Speed Control + +Constant speed control is achieved through a PI controller that adjusts the motor torque to maintain a specified motor speed. + +![Speed-Control](./media/speedc.png) + +## Sensored FOC Application + +The following block diagram shows the implementation of the Sensored FOC application. + +Motor Voltage and Current Feedbacks are provided by the ADC-HUB. The QEI Encoder provides the measured RPM from the BLDC motor as a feedback to the FOC control block. The generic PWM block is to provide a series of commands for each switch of a three leg inverter, with discrete on/off commands for each device. The Gate drive Pin control (GD Pin Control) and enable block is intended to implement the translation from the PWM functionality provided by the SVM PWM HLS IP to the KD240 specific gate drive circuit implementation. The gate drive enable signal is used to enable the power stage. This signal is shared across all three power bridge phases. The KD240 Motor Control block provides motor fault generation and system fault protection logic, which is used to check for gross failures in the system, such as shorted motor winding or failed phase leg. + +As seen by the block diagram in the kernel space, all the soft IPs are supported by kernel drivers using the industrial I/O framework. The drivers provide a number of features that make the hardware easier to configure and use these devices. It has support for buffers, common sysfs interface and integration with libiio framework in the user-space. A Motor Control application library is integrated with the device drivers to seamlessly operate different modes you set. You can control the various set points and gain parameters using the Dashboard GUI, as well as observe live plots of important metrics such as speed, feedback current/voltages, and torque. Instructions to test demo application are presented in the next section. + +![Sensored-FOC](./media/sensor-foc-blk.png) + +## Next Steps + +* [Application Deployment](app_deployment.md) +* Go back to the [KD240 FOC Motor Control Application Start Page](../foc_motor_control_landing) + + + +

Copyright© 2023 Advanced Micro Devices, Inc

diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt new file mode 100644 index 00000000..cadc1aff --- /dev/null +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt @@ -0,0 +1,76 @@ + + + + + + + +

Kria™ KD240 Drives Starter Kit
FOC Motor Control Application Tutorial

+

Known Issues and Debug Help

+ +
+ +# Known Issues and Limitations + +* QEI reported speed is showing glitches. The QEI library computation of the speed has a known issue and will be addressed with a QEI library update. +* Motor lower speed mode control capability is approximately 250 rpms. +* Default motor tuning values are provided for the KD240 Motor Accessory Kit based the Anaheim motor with the plastic disk visual load. This load disk primarily acts as an inertial load and thus if you are connecting other loads to your motor, you should plan on conducting your own tuning process and defining custom tuning defaults based on your load testing. +* Open-loop control mode is intended as a test mode and thus does not implement any software based ramp control. You will see fault protections triggered if immediately trying to set open-loop mode control with a Vq voltage > ~10V. If using an open-loop, you are responsible for incrementally stepping up the Vq command to your desired voltage setting. Typical use cases of open-loop mode have Vd set to 0V. +* DC link current reading is limited to reading analog values > ~0.5A due to a limitation in the KD240 hardware. You should not assume the DC link current feedback is accurate until it is > ~0.5A. +* If the bokeh server is stopped while the motor is running, the motor will not stop. The motor should be stopped through the GUI by switching to Off mode before stopping the bokeh server. + +# Debugging Motor Control Application + +If the motor control application is not functioning as intended, follow these debugging steps to diagnose and resolve issues. + +1. **Check Wire Connections** + * Ensure that wire connections matches the configuration shown in the application deployment page. + * Verify that the 24V DC supply is connected and the wall power is up. + * Check DS9 LED, which represents the DC link; it should be in a high state. + * Confirm that the Quadrature Encoder Interface (QEI) encoder from the motor is properly connected to the board. + +2. **Read DC Link Voltage** + * If the application repeatedly fails to start with system faults, measure the DC link voltage by reading data from the ADC interface (ADC-HUB voltage channel 6). + * Use the command `iio_attr -c xilinx_adc_hub voltage6` to check the voltage reading and should read around 24V. + + ```bash + iio_attr -c xilinx_adc_hub voltage6 + dev 'xilinx_adc_hub', channel 'voltage6' (input), attr 'input', value '25.116806030' + ``` + + A reading significantly lower or higher than the tolerance range of the power supply could indicate a hardware failure on the board. + +3. **Debug PL Interfaces** + * If unexpected behavior occurs, start probing different blocks of the programmable logic (PL) interfaces for debugging. + * Utilize the IIO utilities or the IIO driver sysfs for the specific hardware interface. + * For detailed information on debugging hardware interfaces, refer to the [Device and Channel Attributes](./sw_arch.md#device-and-channel-attributes) section. + +4. **Gate Drive Mode** + * Ensure that the software application is set to a valid mode that turns the Gate Drive ON, except for the off mode. + * Monitor DS10 LED: it should go high in modes other than off. + +5. **Observe Errors and Messages from the Application** + * Keep an eye on the serial console for error messages or other relevant information. + * Review the `dmesg` logs, which provide valuable information from the respective hardware drivers. These logs can be a helpful source of diagnostic information. + +6. **Network Connection** + * If the application does not respond to changes from the GUI, verify the network connection by pinging the host address. + * Sometimes, a web socket disconnection message may appear, indicating a communication issue. If you encounter such disconnection issues, try killing the Bokeh server and relaunching the server and the dashboard. + + Sample Disconnection Message: + + ```bash + 2023-09-13 18:47:32,361 WebSocket connection closed: code=None, reason=None + `````` + + + +

Copyright© 2023 Advanced Micro Devices, Inc

diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt new file mode 100644 index 00000000..56d7026b --- /dev/null +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt @@ -0,0 +1,358 @@ + + + + + + + +

Kria™ KD240 Drive Starter Kit

+

Software Architecture

+ +
+ +# Software Architecture of the Platform + +## Introduction + +This section describes software components involved in the design and their relation with each other. The application requires a hardware platform as described in [Hardware Architecture of the Platform](./hw_description.md) for the stack explained in this section to work. + +The software stack here provides a comprehensive library that can be interfaced using various user interfaces and efficiently drive the motor through the Kria Drive SOM board. + +The following diagram illustrates the top-level architecture and arrangement of various software components: + +![Software Architecture Overview](media/sw_arch.jpg) + +- Kernel: Ubuntu Linux kernel + - Drivers: + - `xilinx_adc_hub`: IIO driver for analog-to-digital converter (ADC) HUB + - `hls_qei_axi`: IIO driver for the QEI sensor + - `hsl_foc_periodic`: IIO driver for the sensor based field oriented controller + - `hls_pwm_gen`: IIO driver for PWM GEN + - `hsl_svpwm_duty`: IIO driver for SVPWM +- Middleware + - IIO Framework and libiio library + - Generic UIO framework +- Application and library + - Motor Control Library (includes UIO driver for the custom Motor Control IP) + - Bokeh dashboard + +## Kernel Drivers + +All the kernel drivers developed for the platform hardware are Industial I/O (IIO) based and adhere to the IIO kernel framework. The IIO subsystem covers many sensor and ADC devices in the industry. It provides the following features to fetch and control various parameters: + +- Divide the stream and type of data into logical channels. +- Each channel can have specific attributes along with device attributes to fine-tune the behavior. +- Efficient data collection using buffers to get deterministic data with timestamps and sync with other channels. +- Interrupt handling to provide user side event handling. + +The following drivers are added to support this app: + +- ADC Hub (`xilinx_adc_hub`): Provides an interface to monitor current, voltage, and related faults that occur during the operation of the motor. +- QEI Encoder (`hls_qei_axi`): External encoder to monitor the real-time speed and position of the motor. +- FOC (`hsl_foc_periodic`): Field oriented controller driver to support various operational modes and state of the motor. +- PWM_GEN (`hls_pwm_gen`): PWM_GEN provides PWM signal generation for motor control. +- SVPWM_GEN (`hsl_svpwm_duty`): SVPWM provides space vector PWM to calcualte phase ratio for the motor. + +There is also custom Motor control IP, which is responsible for the design specific glue logic and driving the motor's Gate Driver. The driver for this IP is a UIO based and the device will instantiate the UIO device for this IP. The userspace driver for this is implemented inside the motor control library in the control block. + +### Device and Channel Attributes + +As explained in the [next section](#userspace-access-to-iio-drivers), the attributes exposed by each drivers can be accessed through sysfs interface or through libraries like libIIO. + +Most of the attribute names are self-explanatory. If a channel attribute is named `input`, it indicates that the device requires raw data for processing, and the final processed data can be read from the `input` channel attribute. If the `input` channel attribute is not present, the raw data itself represents the final value from the device. + +A couple of common device attributes accross IIO drivers in this application are: + +- `sample_interval_us`: This parameter represents the time period in microseconds. It determines the rate at which data is sampled and stored into the buffer. Only channel data is captured within the buffer. +- `ap_ctrl`: This attribute conforms to the standard AMD HLS interface for IP, enabling the initiation of its operation. + +The device attributes applies to entire device for all the channels. The channel attributes are per channel configurations or data. Here are some of the attributes exposed by above drivers: + +#### Xilinx ADC Hub Channels + +List of available channels for the device `xilinx_adc_hub`. + +```bash +ubuntu@kria:# iio_attr -c xilinx_adc_hub +dev 'xilinx_adc_hub', channel 'voltage0' (input, index: 0, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'current1' (input, index: 1, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'voltage2' (input, index: 2, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'current3' (input, index: 3, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'voltage4' (input, index: 4, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'current5' (input, index: 5, format: le:S32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'voltage6' (input, index: 6, format: le:U32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'current7' (input, index: 7, format: le:U32/32>>0), found 9 channel-specific attributes +dev 'xilinx_adc_hub', channel 'timestamp' (input, index: 16, format: le:S64/64>>0), found 0 channel-specific attributes +``` + +Individual Channel Properties for Voltage0 in `xilinx_adc_hub`: + +```bash +ubuntu@kria:# iio_attr -c xilinx_adc_hub voltage0 +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'calibrate', +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'fault_clear', +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'input', value '0.865447998' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'offset', value '0.000000000' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'over_range_fault_status', value '0' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'raw', value '47' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'scale', value '0.018814086' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'set_filter_tap', value '4' +dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'under_range_fault_status', value '0' +``` + +- `calibrate`: One-time calibration at the very start to offset any residual value in the system. +- `fault_clear`: Clears all faults on the channel. +- `input`: Final voltage value read by the ADC in volts (raw * scale factor). +- `offset`: Automatically populated after calibration. +- `over_range_fault_status`: Status indicating if an over-range fault occurred (0 - for no fault). +- `raw`: The ADC raw value. +- `scale`: The scaling factor. +- `set_filter_tap`: Number of filter taps. +- `under_range_fault_status`: Status indicating if an under-range fault occurred (0 for no fault). + +The attributes for the currentX channel would be similar to `voltage0`, but the readings are in amperes (amps). + +#### HLS PWM Generator Channels + +List of available channels for the device `hls_pwm_gen`. + +```bash +ubuntu@kria:# iio_attr -c hls_pwm_gen +dev 'hls_pwm_gen', channel 'voltage0', id 'Va_duty_ratio' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_pwm_gen', channel 'voltage1', id 'Vb_duty_ratio' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_pwm_gen', channel 'voltage2', id 'Vc_duty_ratio' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_pwm_gen', channel 'timestamp' (input, index: 3, format: le:S64/64>>0), found 0 channel-specific attributes +``` + +Individual Channel Properties for Va_duty_ratio in the HLS PWM Generator: + +```bash +ubuntu@kria:# iio_attr -c hls_pwm_gen voltage0 +dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'label', value 'Va_duty_ratio' +dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'raw', value '0.000000000' +dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'scale', value '1' +``` + +- `label`: The label of the channel is 'Va_duty_ratio'. +- `raw`: The raw value for this channel is '0.000000000', and in this case, it represents the final reading for the channel. +- `scale`: The scaling factor for this channel is '1'. + +The attributes are similar to the other channels from the PWM-GEN driver. + +#### HLS SVPWM Duty Channels + +List of available channels for the device `hls_svpwm_duty`. + +```bash +ubuntu@kria:# iio_attr -c hls_svpwm_duty +dev 'hls_svpwm_duty', channel 'voltage0', id 'Va_cmd' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_svpwm_duty', channel 'voltage1', id 'Vb_cmd' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_svpwm_duty', channel 'voltage2', id 'Vc_cmd' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_svpwm_duty', channel 'timestamp' (input, index: 3, format: le:S64/64>>0), found 0 channel-specific attributes +``` + +Individual Channel Properties for `Va_cmd` in HLS SVPWM Duty: + +```bash +ubuntu@kria:# iio_attr -c hls_svpwm_duty voltage0 +dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'label', value 'Va_cmd' +dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'raw', value '0.000000000' +dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'scale', value '1' +``` + +- `label`: The label of the channel is `Va_cmd`. +- `raw`: The raw value for this channel is `0.000000000`, and in this case, it represents the final reading for the channel. +- `scale`: The scaling factor for this channel is `1`. + +The attributes are similar to the other channels from the SVPWM driver. + +#### QEI Channels + +List of available channels for the device `hls_qei_axi`. + +```bash +ubuntu@kria:# iio_attr -c hls_qei_axi +dev 'hls_qei_axi', channel 'rot0', id 'rpm' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_qei_axi', channel 'rot1', id 'theta_degree' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_qei_axi', channel 'timestamp' (input, index: 2, format: le:S64/64>>0), found 0 channel-specific attributes +``` + +Individual Channel Properties for RPM in QEI: + +```bash +ubuntu@kria:# iio_attr -c hls_qei_axi rot0 +dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'label', value 'rpm' +dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'raw', value '0' +dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'scale', value '1' +``` + +- `label`: The label of the channel is 'rpm'. +- `raw`: The raw value for this channel is '0', and in this case, it represents the final reading for the channel. +- `scale`: The scaling factor for this channel is '1'. + +The attributes are similar to the other channels from the QEI driver. + +#### FOC Channels + +List of available channels for the device `hls_foc_periodic`. + +```bash +ubuntu@kria:# iio_attr -c hls_foc_periodic +dev 'hls_foc_periodic', channel 'current0', id 'Id' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'current1', id 'Iq' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'current2', id 'I_alpha' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'current3', id 'I_beta' (input, index: 3, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'current4', id 'I_homopolar' (input, index: 4, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'rot5', id 'speed_pi_out' (input, index: 5, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'rot6', id 'torque_pi_out' (input, index: 6, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'intensity7', id 'flux' (input, index: 7, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'rot8', id 'speed' (input, index: 8, format: le:U32/32>>0), found 3 channel-specific attributes +dev 'hls_foc_periodic', channel 'angl9' (input, index: 9, format: le:U32/32>>0), found 2 channel-specific attributes +dev 'hls_foc_periodic', channel 'timestamp' (input, index: 10, format: le:S64/64>>0), found 0 channel-specific attributes +``` + +Individual Channel Properties for current0 in FOC: + +```bash +ubuntu@kria:~$ iio_attr -c hls_foc_periodic current0 +dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'label', value 'Id' +dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'raw', value '0.000000000' +dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'scale', value '1' +``` + +- `label`: The label of the channel is 'Id'. +- `raw`: The raw value for this channel is '0.000000000', and in this case, it represents the final reading for the channel. +- `scale`: The scaling factor for this channel is '1'. + +The attributes are similar to the other channels from the FOC driver. + +For detailed information on other device attributes, consult the [hardware documentation](./hw_description.md). + +For more details of IIO subsystem, refer to [Analog Devices Wiki](https://wiki.analog.com/software/linux/docs/iio/iio). + +For more details on kernel drivers for IIO, refer to [Kernel Documentation](https://static.lwn.net/kerneldoc/driver-api/iio/core.html). + +## Middleware + +### Userspace Access to IIO Drivers + +The driver exposes the IIO devices through the sysfs interface. The drivers can be accessed from the path `/sys/bus/iio/devices/iio\:deviceX`, where `X` is the numeric enumeration of the IIO device. + +libIIO is the userspace library to easily access the kernel IIO subsystem. It also provides various methods and command line interfaces, packaged in libiio-utils, to access the IIO devices. There are other Python wrappers around this library, but the motor control library uses a native C/C++ library. + +For example, to list all the available IIO devices: + +``` +ubuntu@kria:~$ iio_attr -c +IIO context has 7 devices: + iio:device0, ams: found 30 channels + iio:device1, ina260-u14: found 6 channels + iio:device2, hls_foc_periodic: found 11 channels + iio:device3, hls_qei_axi: found 3 channels + iio:device4, xilinx_adc_hub: found 9 channels + iio:device5, hls_svpwm_duty: found 4 channels + iio:device6, hls_pwm_gen: found 4 channels +``` + +For more details, refer to the [libIIO Documentation](https://analogdevicesinc.github.io/libiio/v0.23/index.html). + +### Userspace Access to UIO + +The custom motor control IP is accessed from the motor control library using the UIO interface. A device tree node with compatible string as `generic-uio` is added to connect this hardware to the UIO subsystem. + +The device is now accessible in the userspace through the `/dev/uioX` device. Information about the device is obtained by scanning `/sys/class/uio/uioX`, where `X` is the UIO device id automatically assigned by the kernel. + +For more information on the UIO interface, refer to the kernel [documentation](https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html). + +## Application and Library + +The motor control library is a C++ library that provides APIs for the front end application to control and fetch motor parameters. It also has a pybind11 wrapper to support the library APIs through python front end. The front end GUI included with this application is based on a python bokeh server, which can be accessed in a web browser in the network. + +### Motor Control Library + +The library can be divided into four blocks: + +- Communication +- State Management and Coordination +- Event/Fault Management +- Control + +![Motor Control Library](media/sw_lib_interface.jpg) + +#### Communication + +The external user interfacing exposes the supported APIs through the C++ shared library and Python module. + +The library allows the user application to fetch following values: + +- Speed +- Position +- Current (Phase A, Phase B, Phase C, DC Link) +- Voltage (Phase A, Phase B, Phase C, DC Link) +- Fault status + - Over current for A, B, C, DC + - Over and under voltage for DCLink + - RMS power fault + - Phase imbalance fault +- Intermediate FOC calculations (example: iq, id, i_alpha, etc) + +The library allows the user application to set following motor controls: + +- Clear faults +- Speed +- Torque +- Open loop parameters (vq and vd) +- Gain P/I gains (for current, speed and flux controller) + +For details list of APIs, refer to the [motor-control.hpp](https://github.com/xilinx/foc-motor-ctrl/blob/main/lib/include/motor-control/motor-control.hpp) file. + +Python binding for the application is provided using the pybind11 library. + +#### State Management and Coordination + +This is the central part of the library, which receives and processes all the request from the communication block and is responsible for: + +- Executing the initialization sequence for the motor. +- Maintaining the current state of the platform and handling the state transitions. +- Splitting, merging, and coordinating the request with various handlers in the control block. + +#### Event/Fault Management + +The Event Manager is responsible for configuring and monitoring events/faults from various hardware blocks. This block is aware of event capabilities of various control blocks and configures the events accordingly. + +It caches the event status in realtime and returns that to user when requested. The event is monitored in a separate thread which waits on epoll events for the registered events. Optionally, it also provides callback function registration in case additional action is expected when a realtime event occurs. + +#### Control + +This block is responsible for hardware access. There are interface classes which implement common interfaces for all the IIO based control handlers and all the UIO based control handlers. It also provides abstraction for the sensor interface to support more than one sensor (only one used at a given time). + +The following various handlers are for controlling the respective hardware: + +- FOC: For controlling and fetching data from the FOC hardware through the libiio framework. +- ADCHub: For controlling and fetching data from the ADCHub hardware through the libiio framework. +- Sensor: Abstraction for controlling and fetching data from the sensor hardware through the libiio framework (QEI in this case). +- PWM_Gen: For controlling the PWM_GEN hardware through the libiio framework. +- SVPWM: For controlling the SVPWM hardware through the libiio framework. +- MC_UIO: For controlling custom Motor Control IP hardware through the UIO framework. +- SW_AvgPower: Software based average power calculator to generate fault and control gate driver through MC_UIO. + +#### Additional Threads + +The following additional threads are implemented in the library: + +- Speed Ramp: When a new *speed* set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in `default_config.h`. +- Torque Ramp: When new *torque* set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in `default_config.h`. +- Event Monitor: The event manager waits on any event using epoll_wait in its own thread. + +### Bokeh Server (GUI) + +A python based bokeh server is implemented to provide a GUI interface to the application. It imports the motor control python library. The plot updates are handled by an update function which is called at the interval specified in the Refresh Interval text box. For each update, the function requests the number of samples specified in the Sample Size text box and update the plots with new data. + +For more details on the GUI usage, refer the [Application Deployment](./app_deployment.md) page for the details on the components and its usage. + +## Next Steps + +- [Application Deployment](./app_deployment.md) +- Go back to the [KD240 FOC Motor Control Landing Page](../foc_motor_control_landing) + + diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt index 7088fe1c..11eb54e0 100644 --- a/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt @@ -9,7 +9,7 @@ Overview .. toctree:: :maxdepth: 1 - Introduction + Introduction Features ================================ @@ -33,7 +33,7 @@ Quick Start .. toctree:: :maxdepth: 1 - Setting Up the Board and Application deployment + Setting Up the Board and Application deployment *************************** Tutorials @@ -54,8 +54,8 @@ Architecture .. toctree:: :maxdepth: 1 - Hardware Architecture - Software Architecture + Hardware Architecture + Software Architecture ******************************* Repository @@ -73,7 +73,7 @@ Other .. toctree:: :maxdepth: 1 - Known Issues + Known Issues .. License diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt index 0dd0ce67..3b4470fe 100644 --- a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt @@ -87,8 +87,8 @@ Testing was performed with the following artifacts: | Component | Version | |--------------------------------|----------------------------| | Boot Firmware | K24-BootFW-01.01 | -| Linux Kernel | 5.15.0-1030-xilinx-zynqmp | -| xlnx-firmware-kd240-motor-ctrl | 0.12-0xlnx2 | +| Linux Kernel | 5.15.0-1027-xilinx-zynqmp | +| xlnx-firmware-kd240-motor-ctrl | 0.10.1-0xlnx1 | To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/1641152513/Kria+K26+SOM#Boot-Firmware-Updates). @@ -96,7 +96,7 @@ To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](htt | Package | Version | |--------------------------------|--------------| -| xlnx-app-kd240-foc-motor-ctrl | 0.4-0xlnx1 | +| xlnx-app-kd240-foc-motor-ctrl | 0.3.1-0xlnx5 | ### Initial Setup @@ -126,10 +126,6 @@ To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](htt * Install the motor control application. ```bash - # Add lely PPA for lely-core libraries - sudo add-apt-repository ppa:lely/ppa - sudo apt-get update - sudo apt install xlnx-app-kd240-foc-motor-ctrl ``` @@ -266,7 +262,7 @@ The following images show what the dashboard looks like when a larger load is ap to enable to PMOD-CAN interface on KR260. ```bash - sudo apt install xlnx-firmware-kr260-tsn-rs485pmod + sudo apt install kr260-tsn-rs485pmod sudo xmutil unloadapp sudo xmutil loadapp kr260-tsn-rs485pmod ``` @@ -274,17 +270,11 @@ The following images show what the dashboard looks like when a larger load is ap * Set up the CAN interface on both the KR260 and KD240. ```bash - sudo ip link set can0 up type can bitrate 100000 - sudo ip link set can0 txqueuelen 10000 + sudo ip link set can0 up type can bitrate 1000000 + sudo ip link set can0 txqueuelen 1000 sudo ip link set can0 up ``` -* Verify the CAN interface state - - ```bash - ip -d -s link show can0 - ``` - * Install can-utils on both the KR260 and KD240. ```bash @@ -313,14 +303,6 @@ The following images show what the dashboard looks like when a larger load is ap start_motor_server ``` -* To terminate the server - - If it is required to kill the server kill fmc_canopen application - - ```bash - sudo killall fmc_canopen - ``` - ### On the KR260 (master) * Download the docker image on the KR260. @@ -344,37 +326,41 @@ The following images show what the dashboard looks like when a larger load is ap --net=host \ --privileged \ --volume=/home/ubuntu/.Xauthority:/root/.Xauthority:rw \ - --name=motor_control \ - --rm \ -v /tmp:/tmp \ -v /dev:/dev \ -v /sys:/sys \ -v /etc/vart.conf:/etc/vart.conf \ -v /lib/firmware/xilinx:/lib/firmware/xilinx \ -v /run:/run \ - -it xilinx/foc-motor-ctrl-ros2-canopen-host:latest bash + -it foc-motor-ctrl-ros2-canopen-host:latest bash ``` -* Inside the container, run canopen host tests using the launch file described in the following - subsections. There are 2 tests: +* Make sure you are inside the docker container and source the ROS setup files. - * *Simple CiA402 system*: where host accesses motor directly using ros2_canopen 402 driver. - * *ROS2 Control example*: where host accesses motor over ros2_control interface. + ```bash + source /opt/ros/humble/setup.bash + source /root/ros_ws/install/setup.bash + ``` - > **Note**: Do not run both the launch files together as they will interfere in the operations. Only one test can be running at a given time. +* Start the launch file. -#### Run a simple CiA402 system host + ```bash + ros2 launch foc_motor kd240.launch.py + ``` -* In the docker run terminal start the canopen 402 host ros container using the launch file +* Open a new terminal, find the docker container id, and launch another + session connected to the same container. ```bash - ros2 launch kria_motor_control kd240.system.launch.py + docker ps # Copy container_id from output of this command + docker exec -it bash ``` -* Open a new terminal, start another session of the the same container. +* In the new docker session, source the ROS setup files. ```bash - docker exec -it motor_control bash + source /opt/ros/humble/setup.bash + source /root/ros_ws/install/setup.bash ``` * Check the available services and their types. @@ -384,7 +370,6 @@ The following images show what the dashboard looks like when a larger load is ap ``` The output should look similar to this: - ```bash ubuntu@KR260:~$ ros2 service list -t /device_container_node/change_state [lifecycle_msgs/srv/ChangeState] @@ -432,7 +417,6 @@ The following images show what the dashboard looks like when a larger load is ap ``` * To view an interface definition, use: - ```bash ros2 interface show ``` @@ -440,7 +424,6 @@ The following images show what the dashboard looks like when a larger load is ap For example, to view the interface definition for the canopen_interfaces/srv/COTargetDouble type which is used for the /kd240/target service, run the command below. This will print the input (target) and output (success). - ```bash ubuntu@KR260:~$ ros2 interface show canopen_interfaces/srv/COTargetDouble float64 target @@ -454,121 +437,43 @@ The following images show what the dashboard looks like when a larger load is ap [Cia402 Driver documentation](https://ros-industrial.github.io/ros2_canopen/manual/humble/user-guide/cia402-driver.html). Reset: - ```bash ros2 service call /kd240/nmt_reset_node std_srvs/srv/Trigger ``` Init: - ```bash ros2 service call /kd240/init std_srvs/srv/Trigger ``` Change to velocity mode: - ```bash ros2 service call /kd240/velocity_mode std_srvs/srv/Trigger ``` Change target speed: - - ```bash - ros2 service call /kd240/target canopen_interfaces/srv/COTargetDouble "target: 3000" - ``` - - > **Note**: For the Anaheim motor kit, the speed range is 250 to 10000 rpm in - both directions. If the motor does not spin at 250 rpm, try a faster speed. - The minimum speed can vary by motor. - -#### Run a ROS2 Control based example - -* In the docker run terminal start the canopen 402 control system host using the launch file - - ```bash - ros2 launch kria_motor_control kd240.ros2_control.launch.py - ``` - -* Open a new terminal, start another session of the the same container. - ```bash - docker exec -it motor_control bash + ros2 service call /kd240/target canopen_interfaces/srv/COTargetDouble "target: 800" ``` -* List the available controllers using ros2 control cli utility - + Halt: ```bash - ros2 control list_controllers + ros2 service call /kd240/halt std_srvs/srv/Trigger ``` - The output should look similar to this: - - ```bash - ubuntu@KR260:~$ ros2 control list_controllers - forward_velocity_controller[velocity_controllers/JointGroupVelocityController] active - joint_state_broadcaster[joint_state_broadcaster/JointStateBroadcaster] active - ``` - -* To view the available hardware interfaces, use: - - ```bash - ros2 control list_hardware_interfaces - ``` - - The output should look similar to this: - ```bash - ubuntu@KR260:~$ ros2 control list_hardware_interfaces - command interfaces - wheel_joint/velocity [available] [claimed] - state interfaces - wheel_joint/position - wheel_joint/velocity - ``` - -* List the Ros2 Topics - - ```bash - ubuntu@KR260:~$ ros2 topic list - /dynamic_joint_states - /forward_velocity_controller/commands - /forward_velocity_controller/transition_event - /joint_state_broadcaster/transition_event - /joint_states - /kd240_wheel/joint_states - /kd240_wheel/nmt_state - /kd240_wheel/rpdo - /kd240_wheel/tpdo - /parameter_events - /robot_description - /rosout - /tf - /tf_static - ``` - -* Observe the live state of the system using dynamic_joint_states - - ```bash - ros2 topic echo /dynamic_joint_states - ``` - - This continuously updates the current state of the system and shows the position and speed of the motor. - - -* Open a new terminal, start another session of the the same container. - - ```bash - docker exec -it motor_control bash - ``` +## Run One Wire Temperature Sensor Demo -* Update the speed of the motor using velocity controller in a new terminal +### Tested Artifacts - ```bash - ros2 topic pub --once /forward_velocity_controller/commands std_msgs/msg/Float64MultiArray "data: [5000]" - ``` +Testing was performed with the following artifacts: -![Ro2_control_demo](./media/sw_ros2_control.png) +#### KD240 platform Artifacts -## Run One Wire Temperature Sensor Demo +| Component | Version | +|--------------------------------|----------------------| +| Boot Firmware | K24-BootFW-01.00.bin | +| Linux Kernel | 5.15.0-1030 | +| xlnx-firmware-kd240-motor-ctrl | 0.12-0xlnx1 | * In this demo, the lm-sensors utility probes the One Wire Temperature sensor, reads and displays the captured temperature value on the serial terminal. diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt index 660dfd7e..cadc1aff 100644 --- a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt +++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt @@ -58,23 +58,11 @@ If the motor control application is not functioning as intended, follow these de * Sometimes, a web socket disconnection message may appear, indicating a communication issue. If you encounter such disconnection issues, try killing the Bokeh server and relaunching the server and the dashboard. Sample Disconnection Message: - + ```bash 2023-09-13 18:47:32,361 WebSocket connection closed: code=None, reason=None `````` -# CAN bus issue - -Sometime, if the CANopen setup is left running for long time, them TX queue of the CAN interface can fillup resulting in the interface hang, especially on KR260. -There is no indication for this situation except KR260 and KD240 do not receive can message. To fix this just bring the can interface down and up again. - -```bash -sudo ip link set can0 down -sudo ip link set can0 up -``` - -If this is frequent enough then consider increasing the tx queue length on KR260 with `sudo ip link set can0 txqueuelen 10000` - @@ -27,9 +26,11 @@ - - - + + + + + @@ -47,6 +48,7 @@