I’ve got a constant speed throughout my program for all the J moves but when I implement a P or L move they are slower and the values are in mm/s not degrees/s so it becomes a guessing game for me. Is there a way to ensure consistency?
Well. To begin with, a MoveJ is not a consistent speed. You tell each joint to move at a certain speed to reach its target. It will result in varying TCP speeds depending on the robot’s position. 
So you can’t compare MoveJ and MoveL/P like that, where the speed in a MoveL is the speed your TCP moves at. This disregards all joint speeds.
A workaround could be to limit the TCP speed in the safety settings, and then turn up all the MoveJs, so the robot is always restricted to the safe TCP speed. Then you can set the MoveL to the same TCP speed as the one in the safety settings.
You might record the tcp position at the start of the movej. Then record the tcp position at the end of the movej. Record the time taken, too. The movel velocity would then be (pos_end - pos_beg)/time_taken. I would recommend this over “playing” with safety limits…
Also note that movel() doesn’t handle tcp orientation change at the correct tcp speed (it moves way slower)
you can also work the other way around and get an estimate of your current TCP speed in a moveJ by adding a thread writing the measured TCP speed in a variable with get_actual_tcp_speed(), you’d have to derive the absolute speed from the XYZ components then you can check in the variables panel your live TCP speed. You could then set your moveJ to not exceed your moveL
@mvrooij not forgetting that this would work accurately only for straight paths, you will be underestimating the actual tcp speed in moveJ with arcs/curves as the path will follow longer distances in space (eg a half-circle instead of a straight line from a to b).