Backlash compensation problems

[Peter Chaisty]

Hi

Moving on with the saga of my liteplacer setup.

I have confirmed by simulating the backlash functionality that I need backlash compensation.

I have set the backlash settings to an extreme value but it doesn't appear to do what I expect.

I set extreme values for backlash offset (-5) so that I would see it move the offset

then the feedrate factor to 0.05 to slow it ll down.

As you see G0 and G1 just goto the same co ordinate ?

I can manually make my own backlash code but of course its better to see whats wrong ?

Peter

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{FeedRate:%.0f}

G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{BacklashFeedRate:%.0f}

My code

2018-07-13 10:20:17 ReferenceHead DEBUG: H1.moveToSafeZ(0.75)

2018-07-13 10:20:17 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.75)

2018-07-13 10:20:17 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.75)

2018-07-13 10:20:17 ReferenceActuator DEBUG: A1.moveToSafeZ(0.75)

2018-07-13 10:20:17 ReferenceCamera DEBUG: moveTo((81.742165, 113.854060, NaN, 90.000000 mm), 0.75)

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(G0 X82.6985 Y113.8541   F150, 5000)...

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(COM3 G0 X82.6985 Y113.8541   F150, 5000) => [{r:{gc:"G0 X82.6985 Y113.8541   F150"},f:[2,0,29]}]

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(150, 5000)...

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(COM3 150, 5000) => [{r:{gc:"150"},f:[2,101,4]}]

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(G1 X82.6985 Y113.8541   F8, 5000)...

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(COM3 G1 X82.6985 Y113.8541   F8, 5000) => [{r:{gc:"G1 X82.6985 Y113.8541   F8"},f:[2,0,27]}]

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(null, 250)...

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(COM3 null, 250) => [{sr:{line:0,posx:84.539,posy:114.830,posz:0.000,posa:0.000,feed:150.00,vel:3200.92,unit:1,coor:1,dist:0,admo:1,frmo:1,momo:0,stat:5}}]

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(null, 250)...

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(COM3 null, 250) => [{qr:32,qi:0,qo:1}]

2018-07-13 10:20:17 GcodeDriver DEBUG: sendCommand(null, 250)...

2018-07-13 10:20:18 GcodeDriver DEBUG: sendCommand(COM3 null, 250) => [{sr:{line:0,posx:82.699,posy:113.854,posz:0.000,posa:0.000,feed:8.00,vel:0.00,unit:1,coor:1,dist:0,admo:1,frmo:1,momo:1,stat:1}}]

2018-07-13 10:20:18 ReferenceCamera DEBUG: moveTo((81.742165, 113.854060, 0.000000, 90.000000 mm), 0.75)

[Jason von Nieda]

I think this may be related? https://github.com/openpnp/openpnp/pull/745

I haven't had time yet to really dig into that PR, or this issue, but if you can let me know if that sounds related that will be helpful.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cafa85c5-03d4-455c-9ff5-800fb80f0d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Chaisty]

Hi Jason

Apologies it was my testing.

It does what it should on both positive and negative approaches.

Peter

[Peter Chaisty]

Hi Jason

I spent a while testing the backlash compensation .

It does work properly, no issues with approaching from either direction as far as i could see.

I had inconsistent results with my Liteplacer I think what would help the most would be to not stop but to decelerate as it approaches the target point.

I don't think GCode supports that.

There is a lot of mass being flung around .

I might have a play with this and see if it helps by slowing it down before it reaches the target so the head has less momentum.

I'm getting about 0.3mm repeatability in both axis using just the camera.

Peter

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/4sDYGnbCC1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ba02a5f5-fd23-4b2d-9996-2bbf64cc710d%40googlegroups.com.

[Mark]

> I'm getting about 0.3mm repeatability in both axis using just the camera.

 

Do you really mean repeatability? Then something is seriously wrong.

 

Are your belts taut enough but not overstretched?

 

I personally found guidance on the web to be very “subjective” in nature. Just an example:

https://www.liteplacer.com/phpBB/viewtopic.php?f=3&t=470

 

Personally  I found it takes some courage to stretch the belts taut enough. These GT2 6mm belts seem so feeble for the weight they have to accelerate.

https://youtu.be/poLwQDpfeJ8

 

 

_Mark

[Marek T.]

Try M204 with acceleration parameters to send from the Openpnp console.
In Smoothieboard it works.

[Marek T.]

ie M204 S2000. It works to reset if remember well. Buy if you find proper acceleration you can fix it in Smoothie config (if you have Smothie, but I think other controllers have similiar).

[Peter Chaisty]

Thanks Mark 

Yes moving between the two fiducials

Back and forth. 

I'm not happy. 

I'll check the belt tension tomorrow and see if it helps.

It's running on the tinyg but I do have a smoothie board.

Peter

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/4sDYGnbCC1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/002901d41b45%24f8a65250%24e9f2f6f0%24%40makr.zone.

[Marek T.]

Maybe it depends of the belt weight and teeth profiles. But I had made many experienced while my servos tuning also with different belts tensioning - and it didn't produce some visible backlash for me till it was not really very loose.

Tinyg probably also should react for it. Just try, it will work or not, for sure won't realize other function just acceleration change or nothing.

[Peter Chaisty]

HI all I did a lot of testing over the weekend.

1/ The Tiny G actually uses Jerk compensation as a improved version of acceleration.

https://github.com/synthetos/TinyG/wiki/TinyG-Tuning.

This value was turned down to 1500 for 

2/ I tightened the both Y belts and that helped a little.

3/ Tightening the X is very difficult but I re-did the belt as tight as I could by hand then adding shimming the end plate that hold the stepper away from the extrusion to give another mm or so of tightening.

4/ I increased the current on the Tiny G for x and Y.

5/ Backlash compensation helped a little but Its a little hit and miss. I'm not sure if it helps or not.

With all the changes the best accuracy / repeat ability I can get is around 0.1mm of error in X and 0.3mm in Y.

I have achieved better than this at times but then after a few cycles moving between Fiducials the error has crept in again.

This is ok for 0805 and normal smd but I am not going to be placing a 0.5mm pitch QFP .

I get the feeling I am pushing the limit accuracy of the mechanics and repeatability.

I know one step is 0.1mm and it needs micro-stepping to go better than this. I have it set to 8x which I am aware is not linear once in the micro stepping domain.

I am seriously considering changing the X and Y for Hiwins and ball screws with greater reduction gearing so that 1 step is maybe 0.05mm and runing without or maybe with only 2 or 4 microsteps.

I know it will be slower but I want accuracy y every time even if throwing away speed.

On the positive side. I'm loving Open PNP sw and the new cameras that Juku ( Liteplacer)  supplied as an update kit are a massive improvement.

The Nozzles are great on the Liteplacer.

Peter

[Marek T.]

0.1-0.3mm accuracy is hard to accept. Note the nozzle tips runouts will sumarize with it and you may have hard play while picking up even 0603.

Machine for 0805 only is like Chinese toy from 10 years ago.

Maybe you should try to limit the current of motors not to increase it, to force less rapid motors behaviour. I don't tell it's perfect solution in stepper case because have no experiences with them but at DC servos it changes.

Just try to be sure it's giving nothing maybe but you will know :-).

What in case when you stand with camera over the center of the fiducial and start making short jumps ~10mm up-down, left-right or along the smal squares 10x10mm. Do you ever comeback to the ideal center or you loose an accuracy for some 0.01-0.05 mm?

[Peter Chaisty]

Hi

One thing I noticed was the camera and or gantry was moving / flexing.

I tightened everything I could on the camera and attempted to tighten the eccentric wheels .

I disabled backlash and I tried moving 100mm steps in various x and Y

It is possible to get back onto the Fiducial pretty accurately by approaching on the Y axis from below.

So using move camera to in the job menu  I can get back to my first Fiducial at 9,9 without any problems using backlash compensation.

Going to my diagonal one at  87,106  its about +0.35 in Y which leads me to think maybe my Y axis is off and I should check calibration again.

and 0.05 in X which i can live with.

Peter

[Marek T.]

I had crazy situation some time ago that the lens was wrong tightened in its holder, and changed position in accordance to the sensor - just 0.01-0.04 only.

I was sure it's problem of motors, belts, axis, even wrong fixed camera - everything but not the lens :-).

That's why asked if you always can back to the idealy same center of some point like fidu center even making small jumps forward and back, or arround, I couldn't.

[Peter Chaisty]

Hi

I found Y was off maybe 0.2mm in 300mm.

Not much but an error I which I have compensated for  anyway.

I'm getting X going off now so for the time being I think I will admit defeat for a while.

I'm going to look into a more rigid frame with larger extrusion anf the possibility of Linear rails and ball screws .

I'll key the Z axis but remount it on something more rigid.

I must admit I don't like the backlash. 

I'll look at consolidating my machine file to share here as its a bare bones file that doesn't have the auto change nozzles setup yet.

So its pretty safe to run and any other liteplacer with the new cameras.

Peter

[Peter Chaisty]

Update 

some good news

I've been chasing around trying to verify the things I was using as calibration standards are correct.

With backlash etc on I cant measure any error in 300mm on X at least.

I did that with 300mm calipers and using calibrations standards to check.

Next I have to do Y and measure the squareness again.

Some light at the end of the tunnel though.

Peter

 

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/4sDYGnbCC1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e954ce38-885e-45cc-bf01-921eedcb5fcb%40googlegroups.com.

[Marek T.]

Is this not the train? ;)

Good luck!

[Peter Chaisty]

Thanks Mark

I think I may have found something.

I went through and rechecked x,y accuracy using backlash code .

Then I recalculated squareness .

So I have repeat ability as far as I have tested but....

My 2 Fiducials of 4 I am using .

I still got a +0.3 error on Y when I return to it in the job position camera tab.

However I tried rotating the board slightly to see if it was using the two fiducials for squareness.

It seemed to give a massive error when I return.

The almost square error this time is worse normally X is ok.

Its like its not using the Fiducials to workout the angle of the board ?

Peter

On Sat, 14 Jul 2018, 08:40 Mark, <ma...@makr.zone> wrote:

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/4sDYGnbCC1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/002901d41b45%24f8a65250%24e9f2f6f0%24%40makr.zone.

[Peter Chaisty]

So

Investigating more

I have repeat-ability now but its not capturing the more extreme fiducial and using it to align the board rotation / offset angle ?

Peter

[Peter Chaisty]

Hi

I thought I had a problem with the fiducial vector alignment code but I was actually pressing the load board 0,0 from the camera after Fiducial alignment.

That appears to clear the Fiducial alignment vector.

So the correct procedure is as per the video on youube

1/ set a rough board 0,0 capture the cmera location to board home

2/ Fiducial alignment

3/ Dont press capture the new more accurate board 0,0 from camera.  Doh !

Peter

[jt whissel]

Are you still using my TinyG updated firmware? If so having any issues with it? I am still working on the kinks. 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruRhDcSi9Q4hQ1Sf-TgsHz5yv62P2J3JwfCj84TYKMda5g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

From,
Jt Whissel

[Peter Chaisty]

Hi

Yes and very pleased with it .

Have you found any issues / made any improvements ?

Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAP31JPje406SyKJtboTnumds1uocA%2BrDC3UN4tCHZbTSbRDu-A%40mail.gmail.com.

[jt whissel]

I was having issues with G1 and fixed that. I get occasional lockups. However, I can not pinpoint if its openpnp, windows usb issues or tinyg. Have you experienced this issue? 

Issue: When you send commands in openpnp you get no response from TinyG. 

To fix this issue I have to fully close openpnp and reopen it. It makes me think its a problem with openpnp or windows usb drivers (using windows 7) 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruQ%2BziMqOegMTgf1magrtxfNbNZaSTpMgLNV-Rx6W-cv4w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

From,
Jt Whissel

[Peter Chaisty]

Hi

I had to extend the command timeout a lot as I slowed my machine down.

I also extended the connection timeout as that takes a very long time sometimes. 

If I do get a timeout and it's always my fault then I have to exit openpnp and restart. It won't  reconnect without a restart.

I don't consider that too much of an issue.

Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAP31JPioo4O%3Dmbjdws6vcb-_K5Dwu%3DxqJ0Gc03Va_W7Y37zgAg%40mail.gmail.com.

[SMdude]

If something happens and I have to exit openpnp without first disconnecting from smoothie, I cannot reconnect unless I go to device manager and disable and re enable smoothie or restart the system. Disabling and re enabling normally works.

[D.Mouradov]

On Friday, July 13, 2018 at 11:59:25 AM UTC+2, Peter Chaisty wrote:

Hi

Moving on with the saga of my liteplacer setup.

I have confirmed by simulating the backlash functionality that I need backlash compensation.

I have set the backlash settings to an extreme value but it doesn't appear to do what I expect.

I set extreme values for backlash offset (-5) so that I would see it move the offset

then the feedrate factor to 0.05 to slow it ll down.

Peter

Hi  all, i have exactly the same problem !  i need compensate 0.1mm backlash on X  . 

But even when changing (Backlash Offset X unit) value to 0.5 and even 2,  Nothing happens , it still remains 0.1mm backlash 

Sorry for my English

GcodeDriver

Enter code her<command type="MOVE_TO_COMMAND">

        <text><![CDATA[G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:E%.4f} F{FeedRate:%.0f} ; Send standard Gcode move]]></text>

<text><![CDATA[G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{BacklashFeedRate:%.0f} ; Send standard Gcode move]]></text>

        <text><![CDATA[M400 ; Wait for moves to complete before returning]]></text>

         </command>e...

Tell me what could be the problem  Thankss !!!

I use the latest version

[Jason von Nieda]

When you say nothing happens, do you mean OpenPnP doesn't perform the backlash move at all, or that it does perform the move but the end result still shows backlash?

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ccd4f940-a693-41c4-9b67-2d6a308762b8%40googlegroups.com.

[D.Mouradov]

HI Jason

Yes doesn't perform the backlash move at all

[D.Mouradov]

Hi Jason  

I did the test I moved head three times left 1mm  three times to the right 1mm

as seen backlash compensation does not work

latest OpenPnP version  updated before the test

2019-02-24 17:50:36.087 ReferenceNozzle DEBUG: N1.moveTo((164.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:36.088 GcodeDriver DEBUG: sendCommand(G0 X202.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:36.091 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X202.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:36.091 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:36.155 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

2019-02-24 17:50:36.719 ReferenceNozzle DEBUG: N1.moveTo((163.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:36.721 GcodeDriver DEBUG: sendCommand(G0 X201.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:36.742 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X201.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:36.743 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:36.806 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

2019-02-24 17:50:37.407 ReferenceNozzle DEBUG: N1.moveTo((162.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:37.408 GcodeDriver DEBUG: sendCommand(G0 X200.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:37.416 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X200.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:37.417 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:37.502 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

2019-02-24 17:50:41.056 ReferenceNozzle DEBUG: N1.moveTo((163.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:41.058 GcodeDriver DEBUG: sendCommand(G0 X201.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:41.061 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X201.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:41.062 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:41.125 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

2019-02-24 17:50:45.087 ReferenceNozzle DEBUG: N1.moveTo((164.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:45.088 GcodeDriver DEBUG: sendCommand(G0 X202.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:45.089 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X202.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:45.089 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:45.153 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

2019-02-24 17:50:45.791 ReferenceNozzle DEBUG: N1.moveTo((165.040000, -328.400000, 0.100000, 0.000000 mm), 0.7000000000000001)

2019-02-24 17:50:45.792 GcodeDriver DEBUG: sendCommand(G0 X203.2700    F10500 ; Send standard Gcode move, 5000)...

2019-02-24 17:50:45.793 GcodeDriver DEBUG: sendCommand(serial://COM7 G0 X203.2700    F10500 ; Send standard Gcode move, 5000) => [ok]

2019-02-24 17:50:45.794 GcodeDriver DEBUG: sendCommand(M400 ; Wait for moves to complete before returning, 5000)...

2019-02-24 17:50:45.858 GcodeDriver DEBUG: sendCommand(serial://COM7 M400 ; Wait for moves to complete before returning, 5000) => [ok]

On Sunday, February 24, 2019 at 3:34:20 AM UTC+1, Jason von Nieda wrote:

[Jason von Nieda]

Please send me your machine.xml.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b5cadf10-829a-4146-9f3b-e9294a2fcf40%40googlegroups.com.

[D.Mouradov]

Thanks for the quick reply.

[D.Mouradov]

in wiki 

To enable backlash compensation, there are two steps:

1. In the GcodeDriver configuration, set the backlash offset X and Y to a small value that you think is greater than your backlash. Starting with -0.4mm is a good choice. Also set the backlash feed rate factor to 0.1. The max feed rate is multiplied by this value for the backlash move, so using 0.1 will move the head at 10% of it's normal speed for the final position approach.
2. In the GcodeDriver Gcode configuration, change your move to command to look something like:

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{FeedRate:%.0f}
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{BacklashFeedRate:%.0f}

I've changed move to command in  GcodeDriver.xml I needed to change in machine.xml to ?

Thankss 

[Jason von Nieda]

I'm not sure what you mean by GcodeDriver.xml - there is no such file. But yes, you have to change in machine.xml, or more specifically, you change it in the OpenPnP GUI.

Go to Machine Setup -> Driver -> GcodeDriver -> Gcode Tab and select MOVE_TO_COMMAND. You'll see that your MOVE_TO_COMMAND does not include the backlash command. Add that and I think it will work fine.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3805d291-2c9c-404a-a979-b1e9180601d9%40googlegroups.com.

[D.Mouradov]

Thanks Jason 

strange I can not understand where this file came from :)

Now everything is clear sorry for your lost time