Backlash compensation in Y axis fails

[@technolitrix]

Hey,

I have following problem with my backlash compensation.

It works totally fine when I do the compensation on the x-axis, but on the y-axis its a total different story, as you can see in the picture.

I get this error... okay, so I checked my steps/millimeter for this axis, but if I move it along a ruler this setting is correct. So I checked Units per Pixel: I calibrated with the dot pattern but no difference. What I don't get is, if I jog the machine with the mouse curser in the camera field, it moves exactly where the curser is released. So that means unit per pixel should be okay.

I have no clue how to move on with this issue. It overshoots by ruffly 1.5mm, but why?

@Mark I followed your youtube video how to set this up.

Best regards Jake.

[mark maker]

Aside from the things mentioned in the dialog box, also look at steps per mm in your controller configuration.

Put a ruler on the machine table and jog in Y direction using 1mm steps, check if the ruler ticks correspond to jog steps.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5c221564-d1c0-4472-ab7f-31b55bd9885bn%40googlegroups.com.

[@technolitrix]

Yes that is what I mentioned above. I laid a ruler down and looked on the camera, while moving the y-gantriy along. I even moved it in 0.1mm stepps, it moves exactly 0.1mm with each movement. So the controller should be correct?  The controller is a smoothie board. 

[mark maker]

Ahh, sorry, I missed the text underneath the image.

Hmmm... I'm down to guessing...

1. A Unit conversion problem? Are you using Inches?
2. Camera Settling issue? Have you used I&S to tune Camera Settling? This is rather new and the heuristic  might be failing in situation that I did not anticipate correctly. You could set it to a long FixedTime settling and test if that solves the issue. In any case report back, so I can improve the heuristics.
   
3. Camera swinging? How stiff is your head/camera holder etc.?
4. Fiducial mismatch? Something else nearby is mistaken as the fiducial (including reflections)? 

Please send the log at TRACE level.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a8cea6ba-1ee4-4414-aa7f-92f3074788ean%40googlegroups.com.

[@technolitrix]

So,

I've made some tests based on your information's and guesses.

1. I am using millimeter in my setup (I checked this settings in camera view, axes and in the gcode controller)

2. I checked this and your video. So I changed settling from 1 second to 4 seconds, but no difference there. Same issue.

3. The holder is as stiff as it can be. See in the video.

4. In the video you can see that there is no fid mismatch.

In this video you can also see what I do and an the difference between x-calibration and y-calibration. You can skip forward where the machine does the calibration. At the beginning you can see that if the curser is released it is somehow offset but with the jog-controlls it moves correctly.

Also please check the log.

One question I got while testing, is: how does the steps/mm (see in picture) in openPNP work? To me it looks like it does not affect the controller in any way. 

Jake :)

[mark maker]

Thanks. I'm quite at a loss. Please send the machine.xml

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/123f93fa-574c-4efb-b90d-8e060e56b2b9n%40googlegroups.com.

[@technolitrix]

Here you go.

[mark maker]

Erm... what the heck? You got 500'000mms^-2 acceleration and 500'000mm/min feed-rate on that machine? But only 1000mms^-3 jerk?

Probably not.

I don't exactly know if or how this could end up creating the issues you reported, but you should fix this first.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6afc82a7-668f-48ed-9401-2183354cf77en%40googlegroups.com.

[bert shivaan]

I want to point out, in the past when something like this comes up and Mark has NO idea why, it is usually something wrong on the machine. Like a set screw is loose on a pulley, or a belt mis-match, or something. It could even be a structural part flexing.

It is likely NOT openPNP. That does not mean openPNP should not be considered, just saying usually (>99%) it is not.

So Please double check all the mechanical bits and pieces as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/263b424f-d38c-33cc-c97b-fe976b4695cb%40makr.zone.

[@technolitrix]

Hey,

I did some more investigation.

@Mark you are correct with my motor settings, I have now 10.000 for Jerk,Accel&feed rate. What I don't understand is the setting for steps/unit, what is this for in OpenPNP, does this not get set by my controller? Or is this for units per pixel necessary?

What I should point out, I have a machine with a nema34 motor on the y-axis.

So yesterday I found my issue with the in camera jogging not moving where the curser is released. This was cause of units per pixel. I missed this in I&S setup. This works now. So jogging in camera and with the arrows is now equal.

But this did not fix the issue with y-axis compensation. I checked the mechanical part, motor,pulley&belt play, there is none.

Jake :)

[mark maker]

> What I don't understand is the setting for steps/unit, what is this for in OpenPNP

It should be described in the tool-tip of the Resolution setting. If this is not good enough, please report back specifically what is unclear, so it can be improved.

As to the problem of Y axis backlash calibration I really have no ideas left. The log shows that the G-code sent is right, but the video (1:30 to 3:20) shows a different behaviour. Normally, this would simply point to the steps/mm not being configured right on the controller side. But you said jogging against a ruler is OK, so I'm now at the end of my rope. All I can suggest is to tripple-check everything I said. Sorry.

One thing that I noticed (0:12)  is that your camera seems to be on Auto-Exposure which is no good for Computer Vision. In the video you see how it adapts to the switched-on light slowly. You should be told by Issues & Solutions to switch Auto-Exposure off (if the camera model supports it).

Please report back what I&S suggests. This is rather new functionality (newest testing version) and may still be buggy on camera models I couldn't test. If your camera model does not support manual exposure, consider buying a new camera. I'm serious, Auto-Exposure is very bad because you cannot set stable thresholds, which are crucial for some ops.

But this does not explain the problem with your Y axis.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e2290441-87fd-43b7-9aa6-46f1de920699n%40googlegroups.com.

[tonyl...@gmail.com]

Jake,

Is it possible that your y-axis motor is missing steps? Perhaps you are trying to push the performance too far or have a bad driver.  You may want to try turning-down your y-axis feed rate/acceleration/jerk values to see if that makes a difference.

[@technolitrix]

Hey Mark,

you are the best, thank you for letting me know about the Auto-Exposure with the camera, this makes a huge difference with overall settling time. But I&S did not point that out to me. This is my camera I am using.

>It should be described in the tool-tip of the Resolution setting. Yes this explained it to me, thank you.

What I did today is following: As you said, I tripple-checked my steps/unit again but instead of a ruler, I used a dial-gauge and you are right my settings are not correct. So the gauge showed me on 10mm movement a -0.1 miss movement, what adds up to -5mm over my whole y axis travel.

Issue here is I don't know the exact gear ratio, so I try to calculate this the next days, its a machine from Juki (Zevatech Placemat 560 from 2002) and there is no information about its gear ratio (Maybe somebody in this group knows this value? XD).

I hope that adjusting the ratio will fix my problem. But I don't think so, because then the backlash compensation would show me an error less then 1mm, instead of the 1.9mm, because the motor moves as the dial-gauge showed less then expected.

@tonyl I understand this concern about the missing steps, but I am using closed loop motors who track position and  alarm out if steps are lost. But after Mark pointed out about my 500'000mms-2 acceleration I reduced its values. And I can verify that the motors do not miss steps.

Thank you guys, I will let you know when I get it to work.

Jake

[mark maker]

> So the gauge showed me on 10mm movement a -0.1 miss movement

No, this will almost certainly not solve the problem. According to the video, you have a factor 1.88 in the step test. So the machine moves almost double the distance it is told to move by G-code (according to the log).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/be1d95df-8216-4653-aa60-52deec450cefn%40googlegroups.com.

[@technolitrix]

New update,

I found a strange behavior with the gcode send to the controller. When I move the motors in x & y by 1mm in the jog contol-panel after fid-homing it moves 1mm.

But If I move after fid-homing with the e.g. DRO showing 66.5mm with a gcode command in the command line by + 1mm (G1Y67.5F50000) it moves 3mm and after that with the 

command (G1Y68.5F50000) it moves 1mm.

So I checked the log. In the log the command is send out by openPNP to Smoothie but Smoothie responds with a different value 

(e.g. Cam1 (DOWN).moveTo((33.000000, 67.500000, ... ) responds: (//COM11 commandQueue.offer(M204 S538.61 G1  Y64.5379). How is this possible? Please see the log I attached.

Maybe I am miss interpreting this?

Jake.

[tonyl...@gmail.com]

Jake,

Don't confuse OpenPnP's coordinate system with the controller's coordinate system - they are not necessarily the same.  For instance, suppose you have 1mm of backlash on your Y-axis and both OpenPnP and the controller are currently setting at Y coordinate 100mm (and all the backlash has been taken-up so that any positive controller motion results in real positive machine motion).  Then you jog using OpenPnP another +100mm so OpenPnp sends G1Y200 to the controller.  Both OpenPnP and the controller will now be at +200mm.  And now you use OpenPnp to jog -100mm to return to the starting point. OpenPnP sends the controller G1Y99 because it has to move back 100mm plus the 1mm of backlash (200-100-1 = 99), so now the controller coordinate is +99mm but OpenPnp will display (correctly) that the machine is back at the +100mm starting point.

Tony

[@technolitrix]

Thank you Tony didn't know that.

I am done with my tests, it works know. But please don't ask what I did to fix this. I have no idea what fixed my problem in the end.

What I changed is this in motion planning: (allow-uncoordinated="false" & interpolation retiming ="false") before it was set to true.

Thank you for your help guys. :D