• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 23 subscribers
  • Views 175 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK5B12204: TICS Pro "Run Script" overrides 1PPS optimization values from release notes

Kazunori Kasajima
Prodigy 30 points

Part Number: LMK5B12204

Hi TI Team,

I am using LMK5B12204 with a 1PPS input and would like to clarify the behavior of TICS Pro.

Background

  • Device: LMK5B12204
  • Input: 1PPS (PRIREF)
  • TICS Pro Version: 1.7.10.1
  • XO: 19.2 MHz

Observed Behavior 

First, I reproduced the following behavior under the default XO condition (12.8 MHz):

Steps:

  1. Load "Default Configurations → 1PPS Default"
  2. Export register settings (baseline)
  3. Run "Run Script"
  4. Export register settings again

Result:

After running Run Script, the following register changes were observed:

  • R303 : 0 → 1
  • R319 : 2 → 3
  • R290/R291 : 513 → 320

HexRegistersValues_RunScriptChange.txt 

These changes appear to revert the values that were specifically corrected in the TICS Pro release notes (Version 1.7.7.4) for improving 1PPS DPLL lock / re-lock (which were: R303: 1→0, R319: 3→2, R290/R291: 973→513).

image.png

In other words, the "Default Configuration" correctly reflects the updated (fixed) values, but executing "Run Script" seems to revert them back to the pre-fix values.

Impact when XO = 19.2 MHz

For my application using an XO of 19.2 MHz, the Default configuration cannot be used directly, so executing "Run Script" is mandatory.

  • However, this causes the following issues:
    The same "reversion" behavior observed at 12.8 MHz always occurs.
  • The configuration generated by "Run Script" alone fails to achieve a stable lock under the 19.2 MHz XO condition.
  • Workaround: After manually modifying R303, R319, and R290/R291 to match the release-note corrected values (0, 2, and 513 respectively), improved lock behavior was successfully observed.

Questions

  1. Is it expected behavior that Run Script overrides the 1PPS optimization values described in the release notes?
  2. For 1PPS applications, which values should be prioritized: the values calculated by "Run Script", or the corrected values from the release notes (Default configuration)?
  3. For a 1PPS input, should parameters such as R303, R319, and R290/R291 be treated as fixed (recommended values independent of XO frequency), or should they be recomputed depending on the XO frequency?
  • 0
    TI__Genius 16360 points

    Hi Kazunori, 

    It is expected for some parameters to change after clicking "run script", especially if the XO frequency has been updated. In particular for R290/291, these correspond to a DPLL REF Delay timer which sets the minimum DPLL lock time and is derived from the XO frequency. Another thing to note is that we made further optimizations to the 1pps default profile in the 1.7.9 release in May 2025: 

    In the release notes I see that we don't specifically call out any changes to R303 or R319, but looking through the TICS Pro source code I see that we hard-code R303 = 1 and R319 = 3 so I assume that these are intentional changes. 

    I have observed that the DPLL loop filter settings in the 1PPS default actually has a LBW > 0.1Hz, so it should be very easy for the DPLL to achieve lock. However after the script is executed the DPLL loop filter is updated to have a 0.1Hz LBW (or whatever value has been entered in the GUI), which can restrict the DPLL filter and make it more difficult to achieve lock. This is especially true if you have a 1pps source with high jitter. 

    Could you provide a few more details about the lock behavior that you observe before you update R303/R319/R290/R291? For example does the DPLL successfully exit holdover? Could you also read back the value of PLL1_NUM_STAT to see what the DPLL sets the APLL numerator to before/after your workaround solution? 

  • 0 in reply to Connor Lewis
    Prodigy 30 points

    Thank you for your detailed explanation, and I apologize for the delayed response.

    Based on your suggestion, I collected logs before and after modifying R303 / R319 / R290 / R291.
    I am attaching the full log and the TICS Pro configuration file for your reference.

    XO192_RunScripts.tcs
    runscript_result.log
    after_modification.log


    Observed behavior

    Before modification (Run Script result only):

    • The DPLL does eventually achieve lock (R14 = 0x80), but it takes a very long time (~8600 seconds).
    • PLL1_NUM_STAT shows large jumps between values (for example, 0x1555555555 <---> 0x5555555554) before convergence.
    • After lock is achieved, R14 remains at 0x80 for at least about 4000 seconds in my test.

    DPLLDBG t=11.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=12.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=13.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=14.03 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=15.03 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=16.03 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=17.04 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=18.04 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x0
----
DPLLDBG t=2839.85 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=2840.85 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=2841.86 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=2842.86 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=2843.86 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=2844.86 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=2845.86 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=2846.87 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
---
DPLLDBG t=4493.27 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=4494.28 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=4495.28 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=4496.28 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=4497.28 R14=0xC0 PLL1_NUM_STAT=0x5555555553 R168=0x08 R411=0x04
DPLLDBG t=4498.28 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=4499.29 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=4500.29 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=4501.29 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=4502.29 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
---
DPLLDBG t=6221.83 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=6222.83 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=6223.83 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=6224.83 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=6225.84 R14=0xC0 PLL1_NUM_STAT=0x50F3C6D9C9 R168=0x00 R411=0x04
DPLLDBG t=6226.84 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=6227.84 R14=0xC0 PLL1_NUM_STAT=0x5555555553 R168=0x08 R411=0x04
DPLLDBG t=6228.84 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=6229.84 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=6230.85 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
---
DPLLDBG t=7007.46 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=7008.46 R14=0xC0 PLL1_NUM_STAT=0x5555555554 R168=0x08 R411=0x04
DPLLDBG t=7009.46 R14=0xC0 PLL1_NUM_STAT=0x268A5F98F6 R168=0x00 R411=0x04
DPLLDBG t=7010.46 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=7011.46 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=7012.47 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
---
DPLLDBG t=7498.46 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=7499.46 R14=0xC0 PLL1_NUM_STAT=0x1555555556 R168=0x08 R411=0x04
DPLLDBG t=7500.46 R14=0xC0 PLL1_NUM_STAT=0x1555555555 R168=0x08 R411=0x04
DPLLDBG t=7501.46 R14=0xC0 PLL1_NUM_STAT=0x24B32CBBC0 R168=0x00 R411=0x04
DPLLDBG t=7502.46 R14=0xC0 PLL1_NUM_STAT=0x3C37F68E23 R168=0x00 R411=0x04
DPLLDBG t=7503.47 R14=0xC0 PLL1_NUM_STAT=0x4606963027 R168=0x00 R411=0x04
---
DPLLDBG t=8597.73 R14=0xC0 PLL1_NUM_STAT=0x3559059D65 R168=0x00 R411=0x04
DPLLDBG t=8598.73 R14=0xC0 PLL1_NUM_STAT=0x3558C4508C R168=0x00 R411=0x04
DPLLDBG t=8599.74 R14=0x80 PLL1_NUM_STAT=0x3558DC1B4F R168=0x02 R411=0x04
DPLLDBG t=8600.74 R14=0x80 PLL1_NUM_STAT=0x3558E88D58 R168=0x02 R411=0x04
DPLLDBG t=8601.74 R14=0x80 PLL1_NUM_STAT=0x3558C438BF R168=0x02 R411=0x04

    After modification:

    • The DPLL reaches lock much faster, within approximately 20 seconds.
    • PLL1_NUM_STAT starts moving immediately and converges much more quickly.
    • However, after lock is achieved, I sometimes observe R14 toggling between 0x80 and 0x00 for several seconds, as shown below:

    DPLLDBG t=0.00 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=1.00 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=2.00 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=3.01 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=4.01 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=5.01 R14=0xD0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=6.01 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=7.01 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=8.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=9.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=10.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=11.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=12.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=13.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=14.03 R14=0xC0 PLL1_NUM_STAT=0x355EB237F1 R168=0x00 R411=0x04
DPLLDBG t=15.03 R14=0xC0 PLL1_NUM_STAT=0x355A71AF3C R168=0x00 R411=0x04
DPLLDBG t=16.03 R14=0xC0 PLL1_NUM_STAT=0x3558D56480 R168=0x00 R411=0x04
DPLLDBG t=17.03 R14=0xC0 PLL1_NUM_STAT=0x35586B8652 R168=0x00 R411=0x04
DPLLDBG t=18.04 R14=0xC0 PLL1_NUM_STAT=0x35581A690F R168=0x00 R411=0x04
DPLLDBG t=19.04 R14=0xC0 PLL1_NUM_STAT=0x3558063BFC R168=0x00 R411=0x04
DPLLDBG t=20.04 R14=0x80 PLL1_NUM_STAT=0x3558063BFC R168=0x02 R411=0x04


    DPLLDBG t=2363.90 R14=0x80 PLL1_NUM_STAT=0x3557E0E43D R168=0x02 R411=0x04
DPLLDBG t=2364.90 R14=0x80 PLL1_NUM_STAT=0x3557E9DDED R168=0x02 R411=0x04
DPLLDBG t=2365.90 R14=0x00 PLL1_NUM_STAT=0x3557E4768E R168=0x06 R411=0x04
DPLLDBG t=2366.90 R14=0x00 PLL1_NUM_STAT=0x3557FA4775 R168=0x06 R411=0x04
DPLLDBG t=2367.91 R14=0x00 PLL1_NUM_STAT=0x3557CFECF7 R168=0x06 R411=0x04
DPLLDBG t=2368.91 R14=0x00 PLL1_NUM_STAT=0x3557E3666B R168=0x06 R411=0x04
DPLLDBG t=2369.91 R14=0x00 PLL1_NUM_STAT=0x3557DDAC46 R168=0x06 R411=0x04
DPLLDBG t=2370.91 R14=0x00 PLL1_NUM_STAT=0x3557F06FF2 R168=0x06 R411=0x04
DPLLDBG t=2371.91 R14=0x00 PLL1_NUM_STAT=0x3557C0485D R168=0x06 R411=0x04
DPLLDBG t=2372.92 R14=0x80 PLL1_NUM_STAT=0x3557E0732B R168=0x02 R411=0x04
DPLLDBG t=2373.92 R14=0x80 PLL1_NUM_STAT=0x3557ED3D63 R168=0x02 R411=0x04

    Answers to your questions

    • The DPLL does exit holdover in both cases.
    • Before modification, convergence is very slow and unstable before lock.
    • After modification, the transition from holdover to lock is much faster and smoother.
    • PLL1_NUM_STAT shows large discrete jumps before modification, and smoother convergence after modification.

    Interpretation

    Based on your explanation, this behavior appears to be related to the DPLL loop bandwidth (LBW):

    • The Run Script configuration results in a narrower LBW (~0.1 Hz), which significantly slows convergence and makes lock acquisition difficult.
    • The modified configuration behaves as if it has a wider effective loop response, allowing faster lock acquisition.
    • However, this also seems to make the lock detect status (R14) more sensitive, resulting in occasional toggling between 0x80 and 0x00.

    Question

    Based on this trade-off, I would like to ask:

    For a practical 1PPS input (which may include some jitter), which behavior is generally preferred or recommended:

    • Faster lock acquisition with occasional lock-status toggling, or
    • Slower but more stable lock status after lock?

    Additionally, is there a recommended way to tune LBW and/or lock detect thresholds to achieve a good balance between lock speed and stability for 1PPS applications?

    Thank you for your support.

  • +1 in reply to Kazunori Kasajima
    TI__Genius 16360 points

    Hi Kazunori, 

    Thanks for the detailed response here. I investigated this further and discovered that R303 should be set to 0 to lock to 1pps, and it should be set to 1 for high frequency inputs. Currently the DPLL script will always overwrite R303 as 1 regardless of the actual input frequency. We are planning to update TICS Pro to handle this automatically, but first we will do some further testing to find the optimal threshold of the input frequency to switch this between 0 vs. 1. 

    In general, for 1pps inputs I expect optimal lock behavior after running the script in TICS Pro to set the desired XO frequency and DPLL LBW, and manually setting R303 = 0. Let me know if this helps. 

  • 0 in reply to Connor Lewis
    Prodigy 30 points

    Hi Connor,

    Thank you for the suggestion regarding R303.
    I tested the configuration as follows:

    • Run TICS Pro “Run Script”
    • Then manually set R303 = 0
    • Input reference: 1PPS

    With this change, the behavior improved significantly.

    Observations

    • The device transitioned to R14 = 0x80 (DPLL lock acquisition / frequency lock) within ~20–30 seconds
    • Full lock (phase + frequency, R14 = 0x00) was achieved in approximately 250–260 seconds
    • The PLL1_NUM_STAT value converged smoothly without large excursions

    Below is an excerpt of the log:

    DPLLDBG t=0.00 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=1.00 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=2.00 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=3.01 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=4.01 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=5.01 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=6.01 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=7.01 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=8.02 R14=0xF0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x00
DPLLDBG t=9.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=10.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=11.02 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=12.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=13.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=14.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=15.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=16.03 R14=0xC0 PLL1_NUM_STAT=0x3555555555 R168=0x00 R411=0x04
DPLLDBG t=17.04 R14=0xC0 PLL1_NUM_STAT=0x355E9B9749 R168=0x00 R411=0x04
DPLLDBG t=18.04 R14=0xC0 PLL1_NUM_STAT=0x355A5FC9EB R168=0x00 R411=0x04
DPLLDBG t=19.04 R14=0xC0 PLL1_NUM_STAT=0x3558CBCF89 R168=0x00 R411=0x04
DPLLDBG t=20.04 R14=0xC0 PLL1_NUM_STAT=0x3558663B9D R168=0x00 R411=0x04
DPLLDBG t=21.05 R14=0xC0 PLL1_NUM_STAT=0x3557E14854 R168=0x00 R411=0x04
DPLLDBG t=22.05 R14=0xC0 PLL1_NUM_STAT=0x3558025F8B R168=0x00 R411=0x04
DPLLDBG t=23.05 R14=0x80 PLL1_NUM_STAT=0x3558025F8B R168=0x02 R411=0x04
DPLLDBG t=24.05 R14=0x80 PLL1_NUM_STAT=0x3557D342B0 R168=0x02 R411=0x04
DPLLDBG t=25.06 R14=0x80 PLL1_NUM_STAT=0x3557DD4465 R168=0x02 R411=0x04
DPLLDBG t=26.06 R14=0x80 PLL1_NUM_STAT=0x3557A628DF R168=0x02 R411=0x04
DPLLDBG t=27.06 R14=0x80 PLL1_NUM_STAT=0x3558002B45 R168=0x02 R411=0x04
DPLLDBG t=28.06 R14=0xA0 PLL1_NUM_STAT=0x3557D4B6E7 R168=0x02 R411=0x04
DPLLDBG t=29.07 R14=0xA0 PLL1_NUM_STAT=0x3557E86816 R168=0x02 R411=0x04
DPLLDBG t=30.07 R14=0xA0 PLL1_NUM_STAT=0x3557E86816 R168=0x02 R411=0x04
DPLLDBG t=31.07 R14=0xA0 PLL1_NUM_STAT=0x3557A0E395 R168=0x02 R411=0x04
DPLLDBG t=32.07 R14=0x80 PLL1_NUM_STAT=0x3557E7A29D R168=0x02 R411=0x04

    DPLLDBG t=249.53 R14=0x80 PLL1_NUM_STAT=0x3557AFD9F8 R168=0x02 R411=0x04
DPLLDBG t=250.53 R14=0x80 PLL1_NUM_STAT=0x3557DA2A2F R168=0x02 R411=0x04
DPLLDBG t=251.53 R14=0x80 PLL1_NUM_STAT=0x3557DE5CA4 R168=0x02 R411=0x04
DPLLDBG t=252.54 R14=0x80 PLL1_NUM_STAT=0x35579C854D R168=0x02 R411=0x04
DPLLDBG t=253.54 R14=0x80 PLL1_NUM_STAT=0x3557E7ECBC R168=0x02 R411=0x04
DPLLDBG t=254.54 R14=0x80 PLL1_NUM_STAT=0x3557AF24BA R168=0x02 R411=0x04
DPLLDBG t=255.54 R14=0x00 PLL1_NUM_STAT=0x3557AD419B R168=0x06 R411=0x04
DPLLDBG t=256.54 R14=0x00 PLL1_NUM_STAT=0x3557B38755 R168=0x06 R411=0x04
DPLLDBG t=257.54 R14=0x00 PLL1_NUM_STAT=0x3557C24BF5 R168=0x06 R411=0x04
DPLLDBG t=258.55 R14=0x00 PLL1_NUM_STAT=0x3557D243DD R168=0x06 R411=0x04

    Interpretation

    • Setting R303 = 0 clearly enables correct behavior for 1PPS input
    • Lock acquisition is now stable and repeatable
    • This is a significant improvement compared to the previous behavior (very long lock time and unstable convergence when R303 = 1)

    Thanks again for your support. This change made a clear difference in our system.

  • 0 in reply to Kazunori Kasajima
    TI__Genius 16360 points

    Hi Kazunori, 

    Great, glad to hear that implementing the change helped improve the locking behavior. I'll go ahead and mark this thread as resolved, but feel free to create a new thread if you have any other questions.