Need some explanation about Coord[x].LinToPvtError

[wilco7]

My machine setup is a CNC Milling machine with CK3E Motion controller and the machine will mainly run with CAM generated NC codes with high-block rate.

 

I'm currently testing several features that the controller provides for more accurate machined results, and I faced a somewhat mysterious error code "Coord[x].LinToPvtError" while I'm testing "SegLinToPvt" mode. I've searched through manuals and forums but there was not so much about this error except just simple information like "Error in automatic linear-to-PVT-mode conversion".

To be more precise, I've successfully milled several models with the feature turned on without any problem, but one specific NC code started causing this problem and motion always halts at the very same code line, but I can't find any problematic moves from there.

 

Can anyone tell me what situation can cause this kind of error? I want to know specific rules and conditions that this kind of error can occur if it's available, or if the error could be popping up somewhat randomly, I should turn it off permanently and forget about this feature, since my customers cannot reach to this kind of motion parameters, the machine should work well per se.

 

My current settings below, and please let me know if more information is needed.

- FW version: 2.7.0.0

- servo frequency = 2KHz

- coord[x].segmovetime = 1

- coord[x].lhdistance = 1024

- lookahead buffer 10240

- coord[x].seglintopvt = 1

- coord[x].pvateanble = 1 and 0 (both not works)

- Compensation tables and trajectory pre-filters are in use

 

Code snippet from problematic NC codes below (comments at the line where the error occurs)

"""

G0 Z43.1
G0 Z53.1
G53 G0 G90 Z0
G54 G0 G90 A0 B0
G43 H1 Z65
F1200
G0 Z65.0
G0 Y10.0
G0 X-55.0
G0 B0.0 A0.000
G0 Y0.0 X0.0
G0 B-15.56 A-16.143
G0 Y-4.358 X35.464
G0 Y-4.358 X35.464 Z65.0
G0 Y-4.358 X35.464 Z65.0
G0 Y-4.358 X35.464 Z65.0
G0 Y-4.358 X35.464 Z65.0
G0 Y-3.961 X35.862 Z65.0
G0 Y-2.072 X37.754 Z58.473
G0 Y-2.072 X37.754 Z58.473
G0 Y-2.072 X37.754 Z14.609
G1 Y-2.072 X37.754 Z14.609      ;;Coord[x].LinToPvtError = 1
Y-2.26 X37.602 Z14.609
Y-2.227 X37.562 Z14.597
Y-2.184 X37.534 Z14.584
Y-2.136 X37.515 Z14.572
Y-2.085 X37.507 Z14.559
Y-2.033 X37.51 Z14.547
Y-1.983 X37.524 Z14.534
Y-1.937 X37.547 Z14.522
Y-1.896 X37.579 Z14.509
Y-1.896 X37.579 Z14.509
Y-1.864 X37.619 Z14.509
Y-1.841 X37.666 Z14.509
Y-1.827 X37.716 Z14.509
Y-1.826 X37.767 Z14.509
Y-1.834 X37.818 Z14.509
Y-1.852 X37.866 Z14.509
Y-1.88 X37.91 Z14.509
Y-1.917 X37.946 Z14.509
Y-1.96 X37.974 Z14.509
Y-2.008 X37.992 Z14.509
Y-2.059 X38.0 Z14.509
Y-2.11 X37.997 Z14.509
Y-2.16 X37.985 Z14.509
Y-2.206 X37.961 Z14.509
Y-2.245 X37.928 Z14.509
Y-2.278 X37.888 Z14.509
Y-2.301 X37.842 Z14.509
Y-2.314 X37.792 Z14.509
Y-2.317 X37.741 Z14.509
Y-2.31 X37.69 Z14.509
Y-2.292 X37.642 Z14.509
Y-2.263 X37.599 Z14.509
Y-2.227 X37.562 Z14.509
...

"""

 

Edited March 5 by wilco7
fw version added

[MoMo]

According to my experience, if there are two lines of programs at the same position, the above error will occur.

You can add line labels to the program so that you can know the approximate location of the error in the program.

Edited March 5 by MoMo

[wilco7]

Thanks for the info MoMo

 

1 hour ago, MoMo said:

You can add line labels to the program so that you can know the approximate location of the error in the program.

Yes, I already know the code line number where the error occurred, and I have added a comment on that line above.

 

1 hour ago, MoMo said:

if there are two lines of programs at the same position

Do you mean the duplicated code blocks like a bunch of "G0 Y-4.358 X35.464 Z65.0" starting from the 14th line in the snippet above? If it is, It might be the case since the line number -at the end of duplicated move codes- where the error occurred was exactly the same every time, but actually I can't confirm the actual conversion error was occurred right there since I don't even know whether Look-Ahead feature is got involved or not on SegLinToPvt conversion because of lack of the documentation about that feature. Nevertheless, I think It could be a good clue on finding differences between working and not working codes.

[steve.milici]

If it were just a linear move without SegLinToPvt conversion turned on PMAC would execute a “zero distance” move. This is not possible in PVT. The “internal” PVT calculations to the exact same point generate this error instead of a possible “runaway” condition from calculation error.

[wilco7]

On 3/8/2024 at 3:41 AM, steve.milici said:

If it were just a linear move without SegLinToPvt conversion turned on PMAC would execute a “zero distance” move. This is not possible in PVT. The “internal” PVT calculations to the exact same point generate this error instead of a possible “runaway” condition from calculation error.

So, you mean MoMo was right. Because the "two lines of programs at the same position" is actually meaning a 'zero distance move'. Thank you for confirmation.

And it would be way better if this condition was written in the manual, since SegLinToPvt is automatic conversion and this means non-problematic move command in linear mode could become problematic move command 'automatically'