motion-master-client 0.0.64 → 0.0.66

package/src/lib/motion-master-req-res-client.js

@@ -244,7 +244,7 @@ class MotionMasterReqResClient {
     /**
      * Get device file list.
      *
-     * Motion Master will use Filetransfer over EtherCAT (FoE) to get the list of files from a device.
+     * Motion Master will use Filetransfer over EtherCAT (FoE) to obtain the list of files from a device.
      * There isn't an actual command for getting the list, but rather the content of a specially named file "fs-getlist" is the file list.
      * The list can be read like any other file from a device using the IgH EtherCAT Master for Linux CLI program:
      *
@@ -252,10 +252,10 @@ class MotionMasterReqResClient {
      * $ ethercat foe_read fs-getlist
      * ```
      *
-     * At the time of writing this document "fs-getlist" can return a maximum of 32 files (subject to change) in the list. This is a firmware limitation.
-     * However, more than 32 files can be stored on device flash memory, but they won't appear in the list.
-     * Also note that FoE can behave differently in the bootstrap firmware which runs in the BOOT EtherCAT state and
-     * SOMANET firmware which runs in other EtherCAT states like PREOP/OP. Bootstrap tends to be buggier since it cannot be updated easily, so
+     * At the time of writing this document, "fs-getlist" can return a maximum of 32 files (subject to change) in the list. This is a firmware limitation.
+     * However, more than 32 files can be stored on the device flash memory, but they won't appear in the list.
+     * Also, note that FoE can behave differently in the bootstrap firmware, which runs in the BOOT EtherCAT state, and
+     * SOMANET firmware, which runs in other EtherCAT states like PREOP/OP. Bootstrap tends to be buggier since it cannot be updated easily, so
      * Motion Master has certain workarounds to overcome these FoE differences and bugs.
      */
     getDeviceFileList(props, requestTimeout, messageId) {
@@ -268,24 +268,24 @@ class MotionMasterReqResClient {
     /**
      * Get device file.
      *
-     * Motion Master uses the Filetransfer over EtherCAT (FoE) to read and send back the content of a file from the device flash memory.
+     * Motion Master uses Filetransfer over EtherCAT (FoE) to read and send back the content of a file from the device flash memory.
      *
      * The IgH EtherCAT Master library used by Motion Master limits the file read buffer to 9KB, so any file written to flash that is larger than 9KB
      * needs to be split into parts of max 9KB. Motion Master does this automatically on request to {@link setDeviceFile}.
      *
-     * Upon receiving this request Motion Master will first read the list of files on a device, see {@link getDeviceFileList}.
-     * It does that in order to determine if the requested file, for example "SOMANET_CiA_402.xml", has been stored in multiple parts.
-     * The parts are named like "SOMANET_CiA_402.xml.zip.part000", "SOMANET_CiA_402.xml.zip.part001" and so on.
-     * Motion Master will read all parts of the requested file, unzip it and send the content back to a client.
-     * Since the number of items in the list of files is limited to 32 (based on the firmware version) Motion Master might not see the file,
-     * but in any case it will try to read the content of it.
-     * If the file exists it will return its content, otherwise it will return the file not found error.
+     * Upon receiving this request, Motion Master will first read the list of files on a device, see {@link getDeviceFileList}.
+     * It does that in order to determine if the requested file, for example, "SOMANET_CiA_402.xml," has been stored in multiple parts.
+     * The parts are named like "SOMANET_CiA_402.xml.zip.part000," "SOMANET_CiA_402.xml.zip.part001," and so on.
+     * Motion Master will read all parts of the requested file, unzip it, and send the content back to a client.
+     * Since the number of items in the list of files is limited to 32 (based on the firmware version), Motion Master might not see the file,
+     * but in any case, it will try to read the content of it.
+     * If the file exists, it will return its content; otherwise, it will return the file not found error.
      *
-     * Zipped files will be automatically unzipped and their content returned, for example: stack_image.svg.zip can be stored
-     * in one or multiple files depending on the size. No matter how its stored it will be unzipped and its content returned as
+     * Zipped files will be automatically unzipped, and their content returned; for example, "stack_image.svg.zip" can be stored
+     * in one or multiple files depending on the size. No matter how it's stored, it will be unzipped, and its content returned as
      * text (SVG) instead of zipped content (binary).
      *
-     * In BOOT EtherCAT state it's only allowed to read the .hardware_description file. This was done because
+     * In BOOT EtherCAT state, it's only allowed to read the .hardware_description file. This was done because
      * the bootloader firmware would hang when trying to read a corrupted or missing file.
      *
      * If the requested file content is empty, Motion Master will return a not found error. This is subject to change now that Motion Master reads the file error codes.
@@ -300,11 +300,11 @@ class MotionMasterReqResClient {
     /**
      * Set device file.
      *
-     * Motion Master uses the Filetransfer over EtherCAT (FoE) to write files to the device flash memory.
+     * Motion Master uses Filetransfer over EtherCAT (FoE) to write files to the device flash memory.
      *
      * The IgH EtherCAT Master library used by Motion Master limits the file read buffer to 9KB, so any file written to flash that is larger than 9KB
      * needs to be split into parts of max 9KB. Motion Master does this automatically by first zipping the content and then writing the parts.
-     * The parts are named in the following manner: "SOMANET_CiA_402.xml.zip.part000", "SOMANET_CiA_402.xml.zip.part001" and so on.
+     * The parts are named in the following manner: "SOMANET_CiA_402.xml.zip.part000," "SOMANET_CiA_402.xml.zip.part001," and so on.
      */
     setDeviceFile(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -316,12 +316,12 @@ class MotionMasterReqResClient {
     /**
      * Delete device file.
      *
-     * Motion Master uses the Filetransfer over EtherCAT (FoE) to delete files from the device flash memory.
+     * Motion Master uses Filetransfer over EtherCAT (FoE) to delete files from the device flash memory.
      *
      * If the file to delete is written in parts, Motion Master will ensure that all parts are deleted.
-     * It does that by reading the list of files on a device, see {@link getDeviceFileList}, removing all parts from that list and then
-     * it re-reading the list again to ensure that there are no leftovers if there were more than 32 files in the list. If there are still
-     * more than 32 files in the list, Motion Master will blindly try to make sure there are no file parts left in the memory (may, or may not work).
+     * It does this by reading the list of files on a device, see {@link getDeviceFileList}, removing all parts from that list, and then
+     * re-reading the list again to ensure that there are no leftovers if there were more than 32 files in the list. If there are still
+     * more than 32 files in the list, Motion Master will blindly try to make sure there are no file parts left in the memory (may or may not work).
      */
     deleteDeviceFile(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -333,19 +333,19 @@ class MotionMasterReqResClient {
     /**
      * Reset device fault.
      *
-     * When an error occurs on a device, the device will go into Fault reaction active state (transition 13) and then automatically to Fault state (transition 14).
-     * The CiA402 state of a device can be derived from the value of Statusword object (0x6041:00).
-     * In order to go out of Fault and into Switch on disabled state (transition 15) master must send Fault reset command via Controlword object (0x6040:00).
+     * When an error occurs on a device, the device will go into the Fault reaction active state (transition 13) and then automatically to the Fault state (transition 14).
+     * The CiA402 state of a device can be derived from the value of the Statusword object (0x6041:00).
+     * In order to exit the Fault state and enter the Switch on disabled state (transition 15), the master must send a Fault reset command via the Controlword object (0x6040:00).
      *
-     * When this request is sent to Motion Master, it will try to reset the fault. Resetting the fault can succeed or fail.
-     * While resetting the fault, Motion Master will use the current Controlword value and set the Reset fault bit to 1,
-     * but when it completes (either success or error), it will set it back to 0.
+     * When this request is sent to Motion Master, it will attempt to reset the fault. Resetting the fault can either succeed or fail.
+     * While resetting the fault, Motion Master will use the current Controlword value and set the Reset fault bit to 1.
+     * However, upon completion, whether successful or encountering an error, Motion Master will set it back to 0.
      *
-     * Motion Master will return "No Fault" warning when this request is sent and device is not in Fault or Fault reaction active state.
-     * If this request is sent when device is in Fault reaction active state, then Motion Master will
-     * wait for the automatic transition (14) to Fault state before trying to reset fault.
-     * When Motion Master sets the Controlword Fault bit to 1, it will also occasionally check if the device is no longer in Fault state.
-     * After a couple of seconds, if the device is still in Fault state, it will give up and return the timeout error.
+     * Motion Master will return a "No Fault" warning when this request is sent, and the device is not in the Fault or Fault reaction active state.
+     * If this request is sent when the device is in the Fault reaction active state, Motion Master will
+     * wait for the automatic transition (14) to the Fault state before attempting to reset the fault.
+     * When Motion Master sets the Controlword Fault bit to 1, it will also periodically check if the device is no longer in the Fault state.
+     * After a few seconds, if the device is still in the Fault state, Motion Master will give up and return a timeout error.
      */
     resetDeviceFault(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -358,8 +358,8 @@ class MotionMasterReqResClient {
      * Stop device.
      *
      * Motion Master will use the current value of the Controlword object and set the command on it to Quick stop.
-     * It will then wait for up to 2 seconds for a device to get into one of the following CiA402 states: Switch on disabled, Operation enabled, Fault.
-     * It does that by periodically checking the value of the Statusword object. If the device doesn't go into one of those states,
+     * It will then wait for up to 2 seconds for a device to enter one of the following CiA402 states: Switch on disabled, Operation enabled, Fault.
+     * This is achieved by periodically checking the value of the Statusword object. If the device fails to enter one of those states within the specified time,
      * Motion Master will return a timeout or a quick stop failed error.
      */
     stopDevice(props, requestTimeout, messageId) {
@@ -372,16 +372,16 @@ class MotionMasterReqResClient {
     /**
      * Start device firmware installation.
      *
-     * When Motion Master receives this request for a device, it will do the following:
-     * - switch the device to the BOOT EtherCAT state - the device will then run the bootloader instead of the firmware
-     * - validate the firmware package
-     * - delete files the files found in the package from the device flash memory (SOMANET_CiA_402.xml and stack_image.svg)
-     * - write files other than the firmware binaries and SII from package to the device (SOMANET_CiA_402.xml and stack_image.svg)
-     * - (optional) install the SII file using the IgH EtherCAT Master library write SII function
-     * - write the firmware binaries to the device using predefined names like app_firmware.bin and com_firmware.bin
+     * When Motion Master receives this request for a device, it will perform the following steps:
+     * - Switch the device to the BOOT EtherCAT state; the device will then run the bootloader instead of the firmware.
+     * - Validate the firmware package.
+     * - Delete files found in the package from the device flash memory (SOMANET_CiA_402.xml and stack_image.svg).
+     * - Write files other than the firmware binaries and SII from the package to the device (SOMANET_CiA_402.xml and stack_image.svg).
+     * - (Optional) Install the SII file using the IgH EtherCAT Master library write SII function, or SOEM EEPROM tool.
+     * - Write the firmware binaries to the device using predefined names like app_firmware.bin and com_firmware.bin.
      *
      * During the firmware installation, Motion Master will send progress messages back to clients.
-     * If Motion Master fails in any step other than SII write, it will send an error. If SII write fails, only a warning will be sent.
+     * If Motion Master encounters a failure in any step other than SII write, it will send an error. If SII write fails, only a warning will be sent.
      */
     startDeviceFirmwareInstallation(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -393,8 +393,8 @@ class MotionMasterReqResClient {
     /**
      * Get device log.
      *
-     * The device log is stored in two files due to IgH EtherCAT Master library 9KB file size limitation, see {@link getDeviceFile}.
-     * A device automatically writes the log to logging_curr.log and copies that file to logging_prev.log once it reaches 9KB.
+     * The device log is stored in two files due to the IgH EtherCAT Master library 9KB file size limitation, as explained in {@link getDeviceFile}.
+     * The device automatically writes the log to logging_curr.log and copies that file to logging_prev.log once it reaches 9KB.
      * When Motion Master receives this request, it will read both of these files and return their combined contents.
      */
     getDeviceLog(props, requestTimeout, messageId) {
@@ -407,27 +407,27 @@ class MotionMasterReqResClient {
     /**
      * Start cogging torque recording.
      *
-     * Cogging torque compensation (CTC) recording can be started with or without auto-config.
-     * In the proto file skipping the auto-config is currently named skip_auto_tuning. The field name is deprecated and will be renamed.
+     * Cogging torque compensation (CTC) recording can be initiated with or without auto-config.
+     * In the proto file, skipping the auto-config is currently named skip_auto_tuning. The field name is deprecated and will be renamed.
      *
-     * If CTC recording is started without auto-config, the users must ensure that the encoder on the motor shaft is used for all functions: commutation, position, and velocity.
-     * If this is not the case, then Motion Master will return an invalid encoder configuration error.
+     * If CTC recording is started without auto-config, users must ensure that the encoder on the motor shaft is used for all functions: commutation, position, and velocity.
+     * If this is not the case, Motion Master will return an invalid encoder configuration error.
      * Recording can also fail if the position controller is not tuned.
      *
-     * If CTC recording is started with auto-config then Motion Master will:
-     * - change the encoder configuration to have all encoder functions on the motor shaft
-     * - disable CTC
-     * - change the velocity feed forward value
-     * - change the position and velocity filter types and cutoff frequencies
-     * - run iterative sharpening position controller auto-tuning in order to compute the optimal PID values (gains) for CTC recording
+     * If CTC recording is started with auto-config, Motion Master will:
+     * - Change the encoder configuration to have all encoder functions on the motor shaft.
+     * - Disable CTC.
+     * - Change the velocity feed forward value.
+     * - Change the position and velocity filter types and cutoff frequencies.
+     * - Run iterative sharpening position controller auto-tuning to compute the optimal PID values (gains) for CTC recording.
      *
-     * All parameter values that Motion Master changes as part of the auto-config are first stored in memory and once the CTC recording is done are reverted back.
+     * All parameter values that Motion Master changes as part of the auto-config are first stored in memory and once the CTC recording is done, they are reverted back.
      *
-     * CTC recording is started by changing the Modes of operation (0x6060) parameter value to -1 (Cogging compensation recording mode).
-     * During the operation Motion Master will monitor the Cogging torque compensation state parameter (0x2008:01) to know when the recording is in progress and when it's done.
+     * CTC recording is initiated by changing the Modes of operation (0x6060) parameter value to -1 (Cogging compensation recording mode).
+     * During the operation, Motion Master will monitor the Cogging torque compensation state parameter (0x2008:01) to know when the recording is in progress and when it's done.
      *
-     * The result of CTC recording is the cogging_torque.bin file written to device flash memory. The size of this file is 2048 bytes.
-     * Each pair of bytes represents a 16-bit signed integer value in mNm (millinewton meter).
+     * The result of CTC recording is the cogging_torque.bin file written to the device flash memory. The size of this file is 2048 bytes.
+     * Each pair of bytes represents a 16-bit signed integer value in mNm (millinewton-meter).
      *
      * This request will turn the motor.
      */
@@ -441,10 +441,10 @@ class MotionMasterReqResClient {
     /**
      * Get cogging torque data.
      *
-     * The cogging_torque.bin file is the result of cogging torque compensation recording, see {@link startCoggingTorqueRecording}.
-     * The size of this file is 2048 bytes where each pair of bytes represents a 16-bit signed integer value in mNm (millinewton meter).
+     * The cogging_torque.bin file is the result of cogging torque compensation recording, as explained in {@link startCoggingTorqueRecording}.
+     * The size of this file is 2048 bytes, where each pair of bytes represents a 16-bit signed integer value in mNm (millinewton-meter).
      *
-     * Motion Master will read the cogging_torque.bin file, convert bytes to 16-bit signed integer values and return that as an array of values.
+     * Motion Master will read the cogging_torque.bin file, convert the bytes to 16-bit signed integer values, and return them as an array of numbers.
      */
     getCoggingTorqueData(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -456,17 +456,17 @@ class MotionMasterReqResClient {
     /**
      * Start offset detection.
      *
-     * Running offset detection is different for firmwares <v5 and >=v5.
+     * Running offset detection differs for firmwares <v5 and >=v5.
      *
-     * For devices that run firmware >=v5, Motion Master will run multiple OS commands.
-     * Before starting any command, device is switched to Modes of operation -2 (Diagnostics mode) and
-     * it's put into operation enabled CiA402 state. The OS commands are then run in the following order:
-     * - open phase detection
-     * - phase resistance measurement
-     * - phase inductance measurement
-     * - pole pair detection
-     * - motor phase order detection
-     * - commutation offset measurement
+     * For devices running firmware >=v5, Motion Master will execute multiple OS commands.
+     * Before initiating any command, the device is switched to Modes of operation -2 (Diagnostics mode), and
+     * it's put into the operation-enabled CiA402 state. The OS commands are then executed in the following order:
+     * - Open phase detection
+     * - Phase resistance measurement
+     * - Phase inductance measurement
+     * - Pole pair detection
+     * - Motor phase order detection
+     * - Commutation offset measurement
      *
      * Motion Master will return an error if any of the following OS commands fail: open phase detection,
      * phase order detection, commutation offset measurement.
@@ -475,10 +475,11 @@ class MotionMasterReqResClient {
      * Once the commutation offset measurement command completes, it will update the following parameter values:
      * - 0x2001:00 Commutation angle offset to the computed offset value
      * - 0x2009:01 Commutation offset State to 2 (OFFSET_VALID)
+     * - 0x2003:05 Motor phases inverted will be changed by the firmware
      *
-     * For devices that run firmware <5 the same Modes of operation -2 is used, but it's named Commutation offset detection mode
-     * and it will run as a single procedure as soon as the device is switched to CiA402 operation enabled state.
-     * The end result is the same, the procedure will update 0x2001:00 and 0x2009:01 parameter values.
+     * For devices running firmware <5, the same Modes of operation -2 is used, but it's named Commutation offset detection mode,
+     * and it will run as a single procedure as soon as the device is switched to CiA402 operation-enabled state.
+     * The end result is the same; the procedure will update 0x2001:00 and 0x2009:01 parameter values.
      *
      * This request will turn the motor.
      */
@@ -500,13 +501,13 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Compute auto tuning gains.
+     * Compute auto-tuning gains.
      *
-     * Auto tuning gains can be computed for the position or the velocity controller.
+     * Auto-tuning gains can be computed for the position or the velocity controller.
      *
      * The prerequisites for running this procedure are a configured motor and the existence of
-     * plant_model.csv file created by previously running the system identification {@link startSystemIdentification}.
-     * Motion Master will return error if the plant_model.csv file is not found.
+     * the plant_model.csv file created by previously running the system identification {@link startSystemIdentification}.
+     * Motion Master will return an error if the plant_model.csv file is not found.
      *
      * In OBLAC Drives, this request is called when the tuning sliders (damping ratio, bandwidth) are moved and
      * during the CTC recording {@link startCoggingTorqueRecording} when auto-config is not skipped.
@@ -539,7 +540,7 @@ class MotionMasterReqResClient {
      *
      * This request will set the mode of operation to CSP, CSV, or CST and optionally enable filtering.
      *
-     * If filtering is enabled Motion Master will compute an intermediate target value in each cycle and, depending on the active mode of operation,
+     * If filtering is enabled, Motion Master will compute an intermediate target value in each cycle, and depending on the active mode of operation,
      * set the value of one of 0x607A Target position, 0x60FF Target velocity, 0x6071 Target torque to that value.
      *
      * The target value can be updated with {@link setMotionControllerParameters}.
@@ -554,9 +555,9 @@ class MotionMasterReqResClient {
     /**
      * Disable motion controller.
      *
-     * Depending on the current CiA402 state this request will do the following:
-     * - if device is in Quick stop active it will transition to Switch on disabled state
-     * - if device is in Operation enabled it will transition to Switched on state
+     * Depending on the current CiA402 state, this request will do the following:
+     * - If the device is in Quick stop active, it will transition to Switch on disabled state.
+     * - If the device is in Operation enabled, it will transition to Switched on state.
      */
     disableMotionController(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -570,7 +571,7 @@ class MotionMasterReqResClient {
      *
      * This request will update the signal generator parameter values for a device on Motion Master.
      * The selected signal generator is then started by {@link startSignalGenerator}.
-     * Signal generator must be started within the next 60 seconds before Motion Master invalidates the previously set parameters.
+     * The signal generator must be started within the next 60 seconds before Motion Master invalidates the previously set parameters.
      */
     setSignalGeneratorParameters(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -586,7 +587,7 @@ class MotionMasterReqResClient {
      * previously set parameters with {@link setSignalGeneratorParameters}.
      *
      * Signal generators are started by changing the mode of operation, putting the device into Operation enabled CiA402 state,
-     * and setting the target value. What mode of operation is set depends on the type of signal generator and the selected controller:
+     * and setting the target value. The mode of operation set depends on the type of signal generator and the selected controller:
      * - For the simple & advanced step response and the sine wave, one of CSP, CSV, or CST is set.
      * - For the ramp, trapezoidal, and bidirectional signal generators, also called profiles, one of the PP, PV, TQ is set.
      *
@@ -596,29 +597,29 @@ class MotionMasterReqResClient {
      * Firmwares >=5.2 will support generating and running sine wave profiles on devices themselves. This will enable lossless profile
      * execution on possibly higher frequencies. Future Motion Master versions will switch to this method.
      *
-     * For the simple step response, Motion Master will only set the target value,
-     * wait for the specified holding duration, and then send a Quick Stop command.
+     * For the simple step response, Motion Master will only set the target value, wait for the specified holding duration,
+     * and then send a Quick Stop command.
      *
      * The advanced step response is similar to the simple one, but, after the holding duration, it will set the new target
      * multiple times depending on the shape, and then send a Quick Stop if the repeat option is set to NO. If repeat is set to YES,
-     * then the signal generator will run indefinitely and the users must stop it manually.
+     * then the signal generator will run indefinitely, and the users must stop it manually.
      *
-     * Before running a profile, Motion Master will check if device supports the profile modes by looking at 0x6502 Supported drives modes.
-     * If profile modes are not supported, then the profiles will be generated on Motion Master. This means the targets will be computed up-front.
-     * If profiles are supported, then ramp, trapezoidal, and bidirectional signal generators are run in profile mode of operation.
-     * To prepare the signal generator foe execution, Motion Master will set the following parameters:
-     * - 0x6081:00 Profile velocity (only for position controller)
+     * Before running a profile, Motion Master will check if the device supports the profile modes by looking at 0x6502 Supported drive modes.
+     * If profile modes are not supported, then the profiles will be generated on Motion Master. This means the targets will be computed upfront.
+     * If profiles are supported, then the ramp, trapezoidal, and bidirectional signal generators are run in profile mode of operation.
+     * To prepare the signal generator for execution, Motion Master will set the following parameters:
+     * - 0x6081:00 Profile velocity (only for the position controller)
      * - 0x6083:00 Profile acceleration
      * - 0x6084:00 Profile deceleration
      * Motion Master knows when the profile has completed by comparing the demand with the actual value, taking into account the
      * holding duration and the shape of the profile. Once the profile is considered complete, Motion Master will send a Quick Stop, but
      * only if repeat is set to NO.
      *
-     * The sine wave profile is generated up-front on Motion Master. Targets are computed for each master cycle (millisecond).
+     * The sine wave profile is generated upfront on Motion Master. Targets are computed for each master cycle (millisecond).
      * Once the last computed target has been set, Motion Master will send a Quick Stop if repeat is set to NO.
      *
      * For all signal generators, Motion Master will check the requested target against the currently set software position limits
-     * and, if necessary, alter it whilst returning a warning.
+     * and, if necessary, alter it while returning a warning.
      *
      * This request will turn the motor.
      */
@@ -632,7 +633,7 @@ class MotionMasterReqResClient {
     /**
      * Stop signal generator.
      *
-     * This request will send a Quick Stop to the device.
+     * This request will send a Quick Stop command to the device.
      */
     stopSignalGenerator(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -645,23 +646,23 @@ class MotionMasterReqResClient {
      * Start monitoring device parameter values.
      *
      * When monitoring is started, Motion Master will begin and continue reading values from the device
-     * and send them back to a client in the specified interval on the given topic.
+     * and send them back to a client at the specified interval on the given topic.
      *
      * The request is made through the req/res socket {@link MotionMasterReqResSocket},
      * but the status messages will arrive on the pub/sub socket {@link MotionMasterPubSubSocket}.
      *
      * The same monitoring can read both PDO and SDO values. PDO values will be updated on every Motion Master cycle (1ms).
-     * How fast will SDO values update depends on the number of SDOs being monitored. Motion Master reads the SDO values in a sequence
-     * so, for example, if there are 10 SDOs and it takes 20ms to read a single SDO it will take approximately 200ms for each SDO to get updated.
+     * How fast SDO values will update depends on the number of SDOs being monitored. Motion Master reads the SDO values in a sequence,
+     * so, for example, if there are 10 SDOs and it takes 20ms to read a single SDO, it will take approximately 200ms for each SDO to get updated.
      * IgH EtherCAT Master supports non-blocking SDO reading with a request to read and check the state of the request (one of not used, busy, failed, succeeded).
-     * Future version of Motion Master will likely leverage this and update SDO values out of order as each of the requests to update SDO succeeds.
+     * A future version of Motion Master will likely leverage this and update SDO values out of order as each of the requests to update SDO succeeds.
      * This should decrease the time it takes to read multiple SDOs.
      * If a parameter is required to be updated more frequently, it should be mapped as a PDO.
      *
-     * Firmware versions >=5.2 supports SDO complete access, but it is currently not being supported in Motion Master.
-     * With SDO complete access RECORD and ARRAY subitems can be read with a single request.
+     * Firmware versions >=5.2 support SDO complete access, but it is currently not being supported in Motion Master.
+     * With SDO complete access, RECORD and ARRAY subitems can be read with a single request.
      *
-     * Interval is given in microseconds.
+     * The interval is given in microseconds.
      *
      * The topic should be unique. The previous monitoring will stop if the given topic is reused.
      * Clients can easily stop one another's monitoring by using the same topic.
@@ -670,7 +671,7 @@ class MotionMasterReqResClient {
      * When the monitoring request is received, Motion Master will mark all requested parameters as stale.
      * The first time a parameter gets refreshed from a device, it'll be marked as not stale.
      * Motion Master won't start publishing parameter values until all parameters are marked as not stale.
-     * This was done in order to satisfy the firmware test client applications.
+     * This was done to satisfy the firmware test client applications.
      *
      * Stopping the ongoing monitoring is done through the req/res socket using
      * the request message ID of the initial start monitoring message {@link stopMonitoringDeviceParameterValues}.
@@ -683,7 +684,7 @@ class MotionMasterReqResClient {
     /**
      * Stop monitoring device parameter values.
      *
-     * Message ID used for {@link startMonitoringDeviceParameterValues} uniquely identifies a monitoring and is used for stopping it.
+     * The Message ID used for {@link startMonitoringDeviceParameterValues} uniquely identifies a monitoring and is used for stopping it.
      */
     stopMonitoringDeviceParameterValues(props, messageId) {
         const stopMonitoringDeviceParameterValues = types_1.MotionMasterMessage.Request.StopMonitoringDeviceParameterValues.create(props);
@@ -709,7 +710,7 @@ class MotionMasterReqResClient {
      * Set the EtherCAT network state to one of: BOOT, INIT, PRE-OP, SAFE-OP, OP.
      * The state is set by an enum value: INIT: 1, PREOP: 2, BOOT: 3, SAFEOP: 4, OP: 5.
      *
-     * When switching from PRE-OP to OP, MM will reinitialize slaves in order to update the PDO mapping.
+     * When switching from PRE-OP to OP, MM will reinitialize slaves to update the PDO mapping.
      */
     setEthercatNetworkState(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -733,12 +734,12 @@ class MotionMasterReqResClient {
      *
      * This request will update the client timeout.
      *
-     * Client timeout specifies how long Motion Master will wait for the client to send a ping or any other message before
+     * The client timeout specifies how long Motion Master will wait for the client to send a ping or any other message before
      * considering it gone and clearing the resources (stopping procedures and monitorings) related to that client.
      *
-     * Default client timeout is 1000ms.
+     * The default client timeout is 1000ms.
      *
-     * Client will typically change this once the socket connection is established.
+     * Clients will typically change this once the socket connection is established.
      */
     setSystemClientTimeout(props, messageId) {
         const setSystemClientTimeout = types_1.MotionMasterMessage.Request.SetSystemClientTimeout.create(props);
@@ -748,27 +749,27 @@ class MotionMasterReqResClient {
     /**
      * Start system identification.
      *
-     * This request will run the system identification procedure which identifies the plant model.
+     * This request will run the system identification procedure, which identifies the plant model.
      *
      * Pre-conditions: a configured motor and configured encoders.
      *
-     * The chirp signal that the procedure does only uses the torque controller.
-     * The chirp signal is generated on Motion Master and then, on every master cycle (1ms), the target torque value is set on a device.
+     * The chirp signal that the procedure generates only uses the torque controller.
+     * The chirp signal is generated on Motion Master, and then, on every master cycle (1ms), the target torque value is set on a device.
      * Motion Master will send a Quick Stop to a device after the last target value is set.
      *
-     * The request can fail for multiple reasons: device is in the fault state, cannot set the op mode state,
+     * The request can fail for multiple reasons: the device is in the fault state, cannot set the op mode state,
      * or the system identification fails because not enough data points have been collected.
-     * While running the chirp signal, the data points are collected, but due to potential communication lag it can happen
-     * that master doesn't collect enough data points. If more than 80% of data points are missing, the procedure will fail.
-     * If between 20%-80% of data points are missing, only a warning will be returned.
+     * While running the chirp signal, the data points are collected, but due to potential communication lag, it can happen
+     * that the master doesn't collect enough data points. If more than 80% of data points are missing, the procedure will fail.
+     * If between 20%-80% of data points are missing, only a warning will be returned. The exact thresholds are subject to change.
      *
      * Before computing the plant model data based on the collected data points, Motion Master will interpolate the missing data points.
-     * Plant model data is then computed and written to plant_model.csv file on the device flash memory.
+     * Plant model data is then computed and written to the plant_model.csv file on the device flash memory.
      * The plant model file is later used to compute the PID values using {@link computeAutoTuningGains} and {@link startFullAutoTuning}.
      * It's also used indirectly in {@link startCoggingTorqueRecording} when auto-config is turned on.
      * Motion Master will also update the integral limit values in 0x2011: Velocity controller and 0x2012: Position controller during this procedure.
      *
-     * In future versions of firmware, the chirp signal would be executed on the devices themselves, so no data points will be missing
+     * In future versions of the firmware, the chirp signal would be executed on the devices themselves, so no data points will be missing,
      * and the system identification will be able to run at higher frequencies and with higher precision.
      *
      * This request will turn the motor.
@@ -785,8 +786,8 @@ class MotionMasterReqResClient {
      *
      * This feature is only available for firmwares >=v5. For older firmwares, Motion Master will return an error.
      *
-     * Motion Master will read registers 0x2B and 0x2F on the specified encoder (by encoder ordinal) and then it will compute the magnet distance.
-     * The computation depends on the Circulo type, encoder port and ring revision.
+     * Motion Master will read registers 0x2B and 0x2F on the specified encoder (by encoder ordinal), and then it will compute the magnet distance.
+     * The computation depends on the Circulo type, encoder port, and ring revision.
      */
     getCirculoEncoderMagnetDistance(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -796,7 +797,7 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Start the Circulo encoder narrow angle calibration procedure.
+     * Start the Circulo encoder narrow-angle calibration procedure.
      *
      * This feature is only available on firmwares >=v5.
      *
@@ -804,7 +805,7 @@ class MotionMasterReqResClient {
      * - the firmware version is not >=v5
      * - software position limits are set so that the required motor rotation is not possible
      * - for SMM devices, the encoder source type is not set to None
-     * - the velocity resolution determined by the gear ratio, SI unit velocity and feed constant is not high enough
+     * - the velocity resolution determined by the gear ratio, SI unit velocity, and feed constant is not high enough
      *
      * Before starting the procedure, Motion Master will do the following:
      * - send OS command 14 (Ignore BiSS status bits) so that no firmware warnings or errors are raised during the procedure.
@@ -813,29 +814,27 @@ class MotionMasterReqResClient {
      * - change the values of some device parameters: profile acceleration, deceleration, max motor speed, etc.
      *
      * The parameter values Motion Master sets depend on the type of the device (fetched from the hardware description file).
-     * Once the operation has completed, Motion Master will rollback all of the above parameters to their initial values.
+     * Once the operation has completed, Motion Master will roll back all of the above parameters to their initial values.
      *
      * Procedure:
      * - The procedure is run in velocity profile mode of operation.
      * - The procedure will do multiple iterations until the encoder data is satisfactory.
      * - The procedure can fail for various reasons: data out of range, motor too slow, bad data, internal error, etc.
      * - The procedure will run a maximum of 13 calibration iterations, up to 2 mins in total.
-     * - One iteration turns the motor in one direction and then the next one reverses the direction.
+     * - One iteration turns the motor in one direction, and then the next one reverses the direction.
      * - Each iteration will record encoder data into HRD files (4kHz) that contain the raw data from the specified encoder.
-     * - Motion Master will remove previous high resolution data (HRD) files after each iteration. HRD streaming is configured/started using OS commands.
+     * - Motion Master will remove previous high-resolution data (HRD) files after each iteration. HRD streaming is configured/started using OS commands.
      * - After each iteration, which lasts ~6 seconds, the recorded data in HRD files is read and passed to the iC House library.
-     * - The recorded data is sliced into 32-bit pair of values of master and nonius track data. Motion Master creates two arrays out of this data and
+     * - The recorded data is sliced into 32-bit pairs of values of master and nonius track data. Motion Master creates two arrays out of this data and
      * passes that to the iC House library which computes the new calibration parameters depending on encoder type sine and cosine offset, gain, etc.
      * - The iterations are being repeated until the encoder (raw) data satisfies a certain threshold.
      *
      * The result of a successful calibration is setting multiple parameters into registers of the specified encoder.
      *
      * At the end of the procedure Motion Master will rotate the motor back to the starting position and run commutation offset detection.
-     * There will also be a final iteration which only measures the values of a (now) calibrated encoder for display.
+     * There will also be a final iteration that only measures the values of a (now) calibrated encoder for display.
      *
      * This request will turn the motor.
-     *
-     * @todo improve documentation
      */
     startCirculoEncoderNarrowAngleCalibrationProcedure(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -845,7 +844,7 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Get device cia402 state.
+     * Get device CiA402 state.
      */
     getDeviceCia402State(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -855,7 +854,7 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Set device cia402 state.
+     * Set device CiA402 state.
      */
     setDeviceCia402State(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -867,9 +866,9 @@ class MotionMasterReqResClient {
     /**
      * Get system log.
      *
-     * The system log represents the collected standard output from Motion Master process.
+     * The system log represents the collected standard output from the Motion Master process.
      *
-     * This request will return the whole system log which can be max ~2MB.
+     * This request will return the entire system log, which can be a maximum of approximately 2MB.
      *
      * The log level can be set as an environmental variable when the Motion Master process is started.
      * The log level can be selected in the OBLAC Drives Update Service expert mode before installing a release.
@@ -893,17 +892,17 @@ class MotionMasterReqResClient {
     /**
      * Start device SII restore.
      *
-     * This request uses the EEPROM tool from SOEM to overwrite the SII portion of EEPROM on a device.
+     * This request uses the EEPROM tool from SOEM to overwrite the SII portion of the EEPROM on a device.
      *
      * Motion Master will verify the provided SII file before writing it to EEPROM. It will:
-     * - check the file content length,
-     * - compute CRC from a part of the SII file content and compare it to the CRC inside the file,
-     * - check the SII category types in the category header.
+     * - Check the file content length,
+     * - Compute CRC from a part of the SII file content and compare it to the CRC inside the file,
+     * - Check the SII category types in the category header.
      *
-     * Unlike IgH EtherCAT Master which identifies interfaces by MAC address, the SOEM tool requires an adapter name.
-     * Before calling SOEM tool Motion Master will find the adapter name by looking into /sys/class/net.
+     * Unlike IgH EtherCAT Master, which identifies interfaces by MAC address, the SOEM tool requires an adapter name.
+     * Before calling the SOEM tool, Motion Master will find the adapter name by looking into /sys/class/net.
      *
-     * The SOEM tool binary is being delivered as a part of the Motion Master Docker image.
+     * The SOEM tool binary is delivered as a part of the Motion Master Docker image.
      */
     startDeviceSiiRestore(props, requestTimeout, messageId) {
         const startDeviceSiiRestore = types_1.MotionMasterMessage.Request.StartDeviceSiiRestore.create(props);
@@ -911,28 +910,28 @@ class MotionMasterReqResClient {
         return this.socket.message$.pipe((0, operators_2.transformMotionMasterMessageToStatus)('deviceSiiRestore', requestTimeout, id));
     }
     /**
-     * Start open loop field control.
+     * Start open-loop field control.
      *
-     * The precondition for running the open loop field control is to have a configured motor.
+     * The precondition for running the open-loop field control is to have a configured motor.
      * No encoder configuration or offset detection is required.
      *
-     * Open loop field control is started by changing the Modes of operation (0x6060) parameter value to -3 (Open loop field mode) and
+     * Open-loop field control is started by changing the Modes of operation (0x6060) parameter value to -3 (Open-loop field mode) and
      * setting the CiA402 state to Ready to switch on.
-     * After that, Motion Master will run several OS commands that configure the open loop field control parameters:
-     * - start angle [milliradian]
-     * - end angle [milliradian]
-     * - max rotational speed [radian/s]
-     * - rotational acceleration [radian/s^2]
-     * - start length [permille of rated torque]
-     * - end length [permille of rated torque]
-     * - length speed [permille of rated torque]
-     *
-     * After the configuration Motion Master will switch device to Operation enabled CiA402 state and the profile will start.
-     *
-     * While the open loop field control is running Motion Master will monitor the target reached bit in the statusword.
+     * After that, Motion Master will run several OS commands that configure the open-loop field control parameters:
+     * - Start angle [milliradian]
+     * - End angle [milliradian]
+     * - Max rotational speed [radian/s]
+     * - Rotational acceleration [radian/s^2]
+     * - Start length [permille of rated torque]
+     * - End length [permille of rated torque]
+     * - Length speed [permille of rated torque]
+     *
+     * After the configuration, Motion Master will switch the device to Operation enabled CiA402 state, and the profile will start.
+     *
+     * While the open-loop field control is running, Motion Master will monitor the target reached bit in the statusword.
      * When the target reached bit becomes 1, Motion Master will stop the procedure by changing the CiA402 state to Switched on.
      *
-     * Motion Master will return an error if the device goes out of Operation enabled state before target reached bit becomes 1.
+     * Motion Master will return an error if the device goes out of the Operation enabled state before the target reached bit becomes 1.
      * There is no timeout on the Motion Master side.
      *
      * This request will turn the motor.
@@ -955,21 +954,21 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Start full auto tuning.
+     * Start full auto-tuning.
      *
-     * The preconditions for running the full auto tuning are properly configured motor, brake and encoders,
-     * and to have executed the offset detection and the system identification procedures.
+     * The preconditions for running the full auto-tuning are a properly configured motor, brake, and encoders,
+     * and having executed the offset detection and the system identification procedures.
      *
-     * In order to successfully run the full auto tuning procedure, the motor must not rotate and the device must not be in CiA402 Operation enabled.
+     * In order to successfully run the full auto-tuning procedure, the motor must not rotate, and the device must not be in CiA402 Operation enabled.
      *
-     * Motion Master will try to read the plant_model.csv file and if doesn't exist it will return an error.
+     * Motion Master will try to read the plant_model.csv file, and if it doesn't exist, it will return an error.
      *
-     * Before the operation starts, Motion Master will measure the actual velocity for 500ms at a standstill in order to determine the encoder noise.
-     * The noise is then sent, along with some other parameters (velocity feedback filter, feed forward, dc link voltage, firmware version and similar)
+     * Before the operation starts, Motion Master will measure the actual velocity for 500ms at a standstill to determine the encoder noise.
+     * The noise is then sent, along with some other parameters (velocity feedback filter, feed forward, DC link voltage, firmware version, and similar)
      * and data to a proprietary computation algorithm.
-     * ADC current ratio which is used in the computation script is determined by the firmware version and the device hardware) ID (e.g. 9500, 9501, 8501...).
+     * ADC current ratio, which is used in the computation script, is determined by the firmware version and the device hardware ID (e.g., 9500, 9501, 8501...).
      *
-     * Full auto tuning will compute the PID gains and Motion Master will update the parameter values in the velocity or position controller depending on the request.
+     * Full auto-tuning will compute the PID gains, and Motion Master will update the parameter values in the velocity or position controller, depending on the request.
      *
      * Motion Master will return the damping ratio, settling time, and bandwidth values when the procedure completes. UI will use these values to update the sliders in the Tuning screen.
      *
@@ -983,11 +982,11 @@ class MotionMasterReqResClient {
         }));
     }
     /**
-     * Stop full auto tuning.
+     * Stop full auto-tuning.
      *
      * Motion Master has only one exit point for this procedure, which is after the computation algorithm ends.
      * This means that, once stopped, the procedure will compute the gains, but Motion Master will not update the controller parameters.
-     * Previously started full auto tuning request will complete with an aborted error.
+     * A previously started full auto-tuning request will complete with an aborted error.
      */
     stopFullAutoTuning(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -1008,17 +1007,19 @@ class MotionMasterReqResClient {
     /**
      * Start Circulo encoder configuration.
      *
-     * The preconditions for this procedure are to have Circulo device with internal encoders and a firmware >=v5.
+     * The preconditions for this procedure are to have a Circulo device with internal encoders and firmware >=v5.
      *
-     * This procedure will set various internal encoder registers based on the hardware description, Circulo device type and the encoder ordinal.
+     * This procedure will set various internal encoder registers based on the hardware description, Circulo device type, and the encoder ordinal.
      *
-     * Before updating the registers, Motion Master will send an OS command to ignore the BiSS status bits. Once the procedure is done the value of this register will be reverted.
+     * Before updating the registers, Motion Master will send an OS command to ignore the BiSS status bits.
+     * Once the procedure is done, the value of this register will be reverted.
      *
      * Depending on the setup, this procedure can take up to 30 seconds.
      *
-     * This procedure can fail if it's already running, if it's not supported because of the firmware version, or if the hardware description file is missing.
+     * This procedure can fail if it's already running, if it's not supported because of the firmware version,
+     * or if the hardware description file is missing.
      *
-     * While this procedure runs, Motion Master will return its progress.
+     * While this procedure runs, Motion Master will report its progress.
      */
     startCirculoEncoderConfiguration(props, requestTimeout, messageId) {
         return this.resolveDeviceAddress(props).pipe((0, operators_1.mergeMap)((deviceAddress) => {
@@ -1040,7 +1041,7 @@ class MotionMasterReqResClient {
     /**
      * Start OS command.
      *
-     * This request will execute an OS command and return a result as a bytearray.
+     * This request will execute an OS command and return the result as a byte array.
      *
      * Motion Master will check if an OS command is already running and use a mutex to ensure only one OS command runs at a time.
      *
@@ -1057,6 +1058,14 @@ class MotionMasterReqResClient {
             return this.socket.message$.pipe((0, operators_2.transformMotionMasterMessageToStatus)('osCommand', requestTimeout, id));
         }));
     }
+    /**
+     * Send request.
+     *
+     * Create a Motion Master message with the provided request, optionally generate a unique message ID,
+     * and then send the message through the socket.
+     *
+     * @returns the message ID
+     */
     sendRequest(request, messageId) {
         const id = messageId !== null && messageId !== void 0 ? messageId : (0, uuid_1.v4)();
         const message = types_1.MotionMasterMessage.create({ request, id });
@@ -1066,6 +1075,11 @@ class MotionMasterReqResClient {
     //
     // Helpers
     //
+    /**
+     * Get the device serial number by device address.
+     *
+     * This function does not make any requests; instead, it utilizes the previously mapped device serial number to an instance of a device.
+     */
     getSerialNumberByDeviceAddress(deviceAddress) {
         for (let [serialNumber, device] of this.deviceMap.entries()) {
             if (device.deviceAddress === deviceAddress) {
@@ -1074,6 +1088,16 @@ class MotionMasterReqResClient {
         }
         return;
     }
+    /**
+     * Resolve a device.
+     *
+     * Resolves the device object by its reference, which can be a position, serial number, or device address.
+     *
+     * This function will make requests to retrieve the list of devices and the .hardware_description file for each device,
+     * but only if it has not been previously retrieved for this session.
+     *
+     * @throws errors if the device reference is invalid
+     */
     resolveDevice(deviceRef, requestTimeout = 5000) {
         const deviceRefObj = (typeof deviceRef === 'object') ? deviceRef : (0, util_1.makeDeviceRefObj)(deviceRef);
         if (!(0, util_1.isValidDeviceRefObj)(deviceRefObj)) {
@@ -1105,10 +1129,10 @@ class MotionMasterReqResClient {
     /**
      * Resolve device address.
      *
-     * This method should return device address by device reference object,
-     * or throw an Error if device address cannot be found.
+     * This method should return the device address by a device reference object,
+     * or throw an error if the device address cannot be found.
      *
-     * Read the description of this class for more info.
+     * Refer to the description of this class for more information.
      */
     resolveDeviceAddress(deviceRef, requestTimeout = 5000) {
         const deviceRefObj = (typeof deviceRef === 'object') ? deviceRef : (0, util_1.makeDeviceRefObj)(deviceRef);
@@ -1117,8 +1141,9 @@ class MotionMasterReqResClient {
     /**
      * Get devices.
      *
-     * Get device info from Motion Master and for each device in the list
-     * read its .hardware_description file and assign its content to the device.
+     * Retrieve device information from Motion Master.
+     *
+     * For each device in the list, read its .hardware_description file and assign its content to the device.
      */
     getDevices(requestTimeout = 5000) {
         return this.getDeviceInfo(requestTimeout).pipe((0, operators_1.mergeMap)((deviceInfo) => {
@@ -1714,6 +1739,62 @@ class MotionMasterReqResClient {
             yield this.download(deviceRef, 0x6040, 0, controlword);
         });
     }
+    /**
+     * Run OS command.
+     *
+     * The OS command is a standard way of triggering actions or services that cannot be accommodated through a single SDO upload/download.
+     *
+     * The Dictionary object 0x1023 is used for executing OS commands. The following is the subindex list and their meanings:
+     *
+     * - 1: Command (OCTET_STRING), 8 bytes
+     *   - Byte 0: OS command ID, OS commands are identified by number, and here we specify which OS command to run, for example, 0 is encoder register communication
+     *   - Byte 1-7: Service request data, the remaining 7 bytes serve as arguments to the OS command, specifying details such as what register to read the value from
+     * - 2: Status (UNSIGNED8), 1 byte
+     *   - 0: last command completed, no errors, no response data
+     *   - 1: last command completed, no errors, response data available
+     *   - 2: last command completed, error, no response data
+     *   - 3: last command completed, error, response data available
+     *   - 100-200: command executing with percentage (100 = 0%, 200 = 100%)
+     *   - 255: command executing (if percentage display is not supported)
+     * - 3: Response (OCTET_STRING), 8 bytes
+     *   - Byte 0: Same as subindex 2
+     *   - Byte 1: unused
+     *   - Byte 2-7: Service response data, if the last command completed with response data, it will be available in these 6 bytes, for example, the value of the BiSS register
+     *
+     * Note that:
+     * - As soon as the value of 1: Command Byte 0 changes, the OS command will start to execute.
+     * - If the last command completed with response data, it will be available in bytes 2-7 of 3: Response subindex.
+     * - The value of subindex 2: Status will be the same as that of 3: Response Byte 0.
+     *
+     * All possible cases of 0x1023:03 Response subindex:
+     *
+     * | Description                                           |  Byte 0 | Byte 1 |     Byte 2    | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |
+     * |-------------------------------------------------------|:-------:|:------:|:-------------:|:------:|:------:|:------:|:------:|:------:|
+     * | Command in progress with percentage                   | 100-200 |    -   |       -       |    -   |    -   |    -   |    -   |    -   |
+     * | Command in progress without percentage                |   255   |    -   |       -       |    -   |    -   |    -   |    -   |    -   |
+     * | Command completed without errors and without response |    0    |    -   |       -       |    -   |    -   |    -   |    -   |    -   |
+     * | Command completed without errors and with response    |    1    |    -   |      Data     |  Data  |  Data  |  Data  |  Data  |  Data  |
+     * | Command completed with error and without response     |    2    |    -   |       -       |    -   |    -   |    -   |    -   |    -   |
+     * | Command completed with error and with response        |    3    |    -   | OS error code |  Data  |  Data  |  Data  |  Data  |  Data  |
+     *
+     * Note that in the case of "Command completed without errors and with response," 6 bytes can be used for data.
+     * However, only 5 bytes are available in the case of "Command completed with error and with response."
+     * This limitation arises because Byte 2 in the latter response is allocated for the OS error code.
+     * The OS error code serves to indicate the reason behind the error occurrence.
+     *
+     * 0x1023: OS command is used in combination with 0x1024: OS command mode object.
+     * In our firmware, only the values 0 and 3 from the 0x1024 command mode object (USINT) are handled, and their meanings are as follows:
+     * - 0: Execute the next command immediatelly (default)
+     * - 3: Abort the current command and all commands in the buffer
+     *
+     * Note that if
+     * TODO: ensure that command was aborted, must switch to 0 after the OS command was aborted
+     *
+     * @returns
+     */
+    runOsCommand() {
+        return;
+    }
     /**
      * Set halt bit.
      *