Heh, those blueprints weren’t really easy to follow, you may want to clean them up a bit as it’ll make your life easier later on. 
For the functionality itself, it looked pretty good, I’d change the logic on damping though as it doesn’t take existing velocity into account at all. If you look at this article: Spring Physics | Gaffer On Games it explains commonly used formula for it: F = - kx - bv where k is spring stiffness, x is the travel (trace length), b is damping coeff and v is velocity (be sure to start testing with really low b value at first so you’ll not overdo it). You are already doing this all, except your damping doesn’t use velocity.
To get the velocity, you can use the same method you used on grip calculations where you used “Get physics Linear Velocity at Point”, just use up vector instead of right vector on the dot product and you’ll get the springs up/down velocity (assumption here that spring isn’t in any angle).
I also suggest you to cache all vector values that you need more than once right at the start of tick/update. This will make your BP more readable and probably bit efficient as well. One thing to note that if you do all these calculations on tick, make sure you limit the tick update to some update rate, like say 0.1 which will make the force calculations happen only 10 frames per second, if you update them on every tick, you’ll get different results on different frame rates. This of course isn’t ideal but you can’t really control much of the update rates on BPs. On c++ you can do it like I described on the previous thread.