System Error 20 with Romer Absolute arm

mhenson
User
User
Posts: 13
Joined: Wed Aug 02, 2017 2:13 pm

Re: System Error 20 with Romer Absolute arm

Post by mhenson » Tue Aug 15, 2017 9:09 am

mhenson wrote:We tried 2 Win10 PC's, and a Win7. We saw the same super-lag on all three with the RDS 4.2, only tried RDS 4.0 on the Win7, which gave us the least lag so far. Right now, we're rolling one of the Win10 laptops back to Win7 and we're going to reinstall everything to it with the RDS 4.0. I'll update once I've had a chance to test it; hopefully that brings the arm closer to real-time.
Now working with the laptop that was rolled back to Win7, still seeing the same lag issue however. Running Hexagon RDS 4.0, Nikon API 3.7.5.
medupriest wrote:This just helped another user, so hopefully it will work for you as well.

find the mxml file in:
C:\ProgramData\Nikon\NMAPI4\Localisers\RDS\RdsDriverStaticSettings.mxml

Locate the line:
<ToolStableRadius_mm type="float">1.000000000000000e-01</ToolStableRadius_mm>

Try changing "1.000000000000000e-01" to "5" and see if that fixes the lag issue.
That exact filepath doesn't exist on this laptop, but there is another file with the same name in a similar path . No "ToolStableRadius" line however.
MXML file.PNG
Do you think changing one or both of these trigger frequency lines could help the lag?
You do not have the required permissions to view the files attached to this post.

Murguel
Frequent User
Frequent User
Posts: 56
Joined: Mon Aug 13, 2018 9:59 am

Re: System Error 20 with Romer Absolute arm

Post by Murguel » Wed Sep 12, 2018 9:10 am

medupriest wrote:
Mon Aug 14, 2017 5:21 pm
This just helped another user, so hopefully it will work for you as well.

find the mxml file in:
C:\ProgramData\Nikon\NMAPI4\Localisers\RDS\RdsDriverStaticSettings.mxml

Locate the line:
<ToolStableRadius_mm type="float">1.000000000000000e-01</ToolStableRadius_mm>

Try changing "1.000000000000000e-01" to "5" and see if that fixes the lag issue.
Thank you very much. Nobody (even the Trainer) was able to help. I had from beginning on a warm feeling it might be somehow an error-correction-algorithm, that may force the user to hold the arm stable, before triggering the button. Seeing your post really made my day. Because exactly that seems to happen.

To have a better accuracy (because the arm is taking an average of many points), the driver is requiring a stable condition when taking the average point (to have a small deviation). It was set somehow to 0.1mm. Now I set it to 5 mm (as you proposed) and it works absolutely great. Perfect.

As I said. That made my day. Works. Now I love the arm. I was close to hate it.

PS: I may play a little with that value to achieve the optimum between comfortability and accuracy.

Post Reply