rtcp problems with 5 axes working continuously

[daxo]

Hello, everyone.
for the first time I have to deal with 5 axes working issues continuously.
the particular that I have to realize is similar to a "helix" wrapped on a tree for an angle of 120°. the " propellers" that make up the particular are three and repeat with a constant angular step.
I have made the calculation of the tool path by caia v5-r20sp3.
from the simulator included in the cam package turns out everything ok.
I have performed the output of the processing strategies in apt furnace and I have provided to generate iso files through appropriate post processors.
verifying the cn file on board machine carrying out the milling cycles to "empty"
I have found an analytical in the movements, quickly, of connection between the past.
Now I'll explain.
the tool change the processing is positioned correctly in z;
activates rtcp by g43.4 wheel and board correctly; approach as expected; perform the first work pass and disengage correctly. Now the unexpected happens. the tool should, after having disengaged, reposition to the point of departure increasing of one step the pass through rotation of the axis c in anticlockwise direction to a safety distance :finger:.
In reality the tool after dising performs a rotation of the axis c and in simultaneous also a slight slash of the axis b in clockwise simultaneous abatement with the axis z and therefore "crossing" the piece
Obviously I would have destroyed the piece and at least broken the tool. I have examined the files iso to an expert who asserts that they are correct and that the problem and in some machine parameter.
the working center used is a die seiki nmv3000dcg with control msx7111iv (basis fanuc31i if not mistaken) with bascula (b) second axis y and rotating table (c) second axis z.

Is someone able to give me suggestions on which parameter(s) should I intervene? or if there are special strategies to be adopted in the output phase of iso files?

I have already tried to make output with only g1 within the iso files.
I have already tried to enable the function of inserting interpolated movements between the connecting passes .
everything was useless:frown:.

thanks in advance all those who want to give me suggestions with the occasion I offer cordial greetings

Bye-bye

 

[Wizard69]

try to post the iso code by highlighting the blocks in which this pass crosses the piece, possibly even an image of the work piece and the calculated path.

 

[Wizard69]

It is also important to know the structure of rotational axes of the rotary table machine (c) on a rotating table (a), oscillating head (b) and rotating table (c).
However it is probably a post processor problem.

 

[daxo]

Hello wizard69

as required place:
- particular explanatory image to be realized
- cinematic image working center
- cn file

inside the iso file the incriminated blocks are bounded by comments (swine) ...... (play).

thanks for the collaboration

 

[Wizard69]

the problem I imagine is present at the moment when routes performed the movement g0 x-90.0234 y9.5403 z-14.6315 b-103.6016 c-9.5284 that I have to make in a single movement the passage from the distrust of the first pass to the attack of the second pass crosses the piece.

I don't have all the elements to determine the cause, but if the cam shows you a fast movement that follows the circular shape of the piece this should be represented by various "point-point" movements (with all x,y,z,b and c axes that describe this trajectory) and such movements must be reported on the apt that is converted by the post processor.

so if, simulating the path of the cam, the movement is a single block (but I would like to exclude it) the post processor unfortunately can not make us much.
if the movement consists of several blocks, it is necessary to check whether the apt contains them and consequently the responsibility is of the post processor.

however, beyond the responsibility, the solutions to work the piece are (in order of practicality):
1) recalculate the processing by making (if technologically possible) past bidirectional
2) You should change "hand" the above block of the iso file in this way:
g0 x63.8928 y-66.151 z.0116 (block of detachment)
G0 z50
g0 x-90.0234 y9.5403 b-103.6016 c-95284
g0 z-14.6315

Of course, if you have to make the change by hand of the iso file, I suggest you check it on the machine with your hand on the potentiometers and you should repeat it for all the chips. . .

 

[daxo]

Hello wizard69

the problem is the following block:
g0 x-90.0255 y9.9813 z-14.8719 b-103.6091 c-9.5149

on the internal simulator the passage at this point is highlighted as a "recline" section.
In machine such shift should be translated according to a combined movement of axles and the axis c should rotate counterclockwise.
In fact, the shift is translated according to a combined movement of axes with axis b and hourly rotation axis c clockwise. such movement involves the collision of the tool with the piece.

how to solve the problem:
most likely it is just one or more parameters of the cn to change. I know for certain that on similar working centers of competing brands but who mount the same basic control (fanuc) the problem has been solved by changing this/s parameters. What are they? ? ?

I can not do bidirectional processing as the material I have to work is ti gr5 and therefore it is advisable to work in agreement to optimize cutting and tool life.

a hypothetical solution I would have found it and below I carry it

x16.4382 y-22.4031 z7.7043
g0 x45.641 y-49.3249 z2.9703

g0 x63.8928 y-66.151 z.0116 (--- release)
g49 (---disactivation rtcp)
g0 c-9.5284 (--- angle positioning on past
g43.4h#148 (--- reactivation rtcp)

g0 x-90.0234 y9.5403 z-14.6315 b-103.6016 c-9.5284
g0 x-66.0598 y5.5179 z-8.7523
g0 x-27.718 y-9177 z.6545
(sing)
g x-22.9253 y-1.7222 z1.8303 f250
x-23.0299 y-1.6715 z1.8114 b-103.5498 c-9.6216 f600
....

in this way the processed iso files would be fine.
I should in any case request the update of the post processor and define conditions when disabling and rehabilitating rtcp .

I hope I can solve the problem only by changing the parameters at the cn level.
tomorrow I will contact technical assistance fanuc and hope they can give me suggestions.

in any case I thank you for the suggestions and the time dedicated to my problem.

Bye-bye

 

[Wizard69]

regarding the control parameter that can transform the movement described by "linear" to "curviline" it is possible that there is but are not able to tell you (only the machine builder could do so).
However, take into account that this change is very delicate because, if you don't remember to turn it off, you risk damaging the piece in opposite conditions. . .
I therefore think much better to intervene on the post.
However, I am convinced that if the cam carries out that movement with a single block is a calculation problem, because if it were to be executed on a 5 axle machine, you would always unleash the piece without possibility to change any parameter of control.

 

[RS4]

Hello wizard69

as required place:
- particular explanatory image to be realized
- cinematic image working center
- cn file

inside the iso file the incriminated blocks are bounded by comments (swine) ...... (play).

thanks for the collaboration

Bye-bye

I saw the file , I want to see the file catia... .


I use catia for cn every day if for you it is not a problem you could post the cn cn file with machine and pptable

I can see if I can help you.

Hi.

♪

 

[daxo]

Hello

first of all thanks for the availability.
Unfortunately the catia native file cannot be disclosed as the company in which work has signed "disclosure fees" and therefore we cannot release data to third parties without approval of the final customer. we work in the same field and so you can understand me.

the pptable used is that customized by spacesystem.
the post processor has always been developed by a spacesystem technician.

today I have heard technical assistance fanuc and the first thing that suggested me was to advise me to change the post processor so that the linkage movements between the past happen with rtcp disabled.
It doesn't convince me completely even if tested and it seems to work.
in any case tomorrow to try to solve the problem I organized a meeting with technical expert nmv - (mori seiki), technician who developed post processor and technical expert module 5 axes advanced caia.

I'll let you know how things will evolve.

with the occasion I greet you

Bye-bye

 

[endrio1]

hi daxo I have a nmv8000 and I have already had these kinds of problems and unfortunately the fanuc is a little elastic for rtcp management.
so that when the function is active the tool always takes into account the position in the space in relation to the next movement.
the advice that I can give you is to release rtcp repositioning the axes b and c to "zero" (important) reactivate rtcp and restart.
I can also tell you that I was forced into the postprocessor to predict an extra length for the activation of the rtcp because in some cases you can have collisions not evidenced by the cinematic simulators.
I took almost a year to develop the post in all its variants as the issues are multiple (g43.4 g68.2.ecc.).
If I can help you somehow, it doesn't concern you.
Hi.

 

[endrio1]

However if it can console you doesn't even convince me that you have to disable rtcp because I don't always do it but only when I perform different operations between them since the post reads me the end of operation and then turns off rtcp but if this doesn't happen I have no problem running other jobs.
for me you only have some optimization issues in the next processing approach.

 

[daxo]

hi endrio1
today as anticipated in previous post I had joint meeting with technician mori seiki + expert post processor and expert cam catia.
result of the meeting:
- examined parameters cn 1008 and 1006 and are correct;
- examined cinematism with internal simulator catia and everything ok;
- tested cn files in the machine without equipment and particular presence, the connection movements between the past seem abnormal;
-proved to change the parameters of roll over (1006) worsening things;
- tried to transform g00 movements into g01 without any modification in the linkage movements between past;
- ritestato cn file in the car with movement in sbk. from a careful examination and reasoning on the operation of thertcp we come to conclude that the generated path is correct and most likely the connection path is strange but does not go to collide with the particular. we therefore decide to mount the friction and a crude in al, previously prepared, and to test the processing with minimal speed and hand on the potentiometers.

result: the path is correct and the ridges do not collide. the movement that in simulation is straight in reality turns into a series of "wave" movements that pass near the crude but do not collide.

You are perfectly right when you claim that the problem exists in the management of approaches/retractions. Unfortunately catia in this field seems to be a little limited. I'm going to have to run some tests and investigate the subject.
I confirm, moreover, that having also an external simulator is not said that you get an identical simulation to that actually realized on the working center (report when sieved by a simulation expert and that it uses/revenges a blasoned product ).
the technician mori seiki suggested me to model/import the equipment and tools inside the simulator implemented on board machine. keep the 3dceck function active to avoid such catastrophic collisions.
I'll have to study the manual and do some deep tests.

tomorrow I'm texting the full program. hand on potentiometers and cardio aspirins at hand.

another thing that the technician dies seiki did is the installation of the macro 9861. an optional macro mori seiki to manage in a way, much, easier rotations (g68.2).
actually is much easier to use and implement in the post-processor.

given your availability and using the same machine (to say the true nmv3000 respect nmv8000 is to be considered the younger sister) we remain in contact for a possible exchange of experiences. I am a neophyte for now. I hope to increase my experience and maybe be able to help you too.

with the occasion I thank you and greeting

Bye-bye

 

[endrio1]

I'm glad that your problem has been solved without major upheavals. As I imagined the problem of interpretation of the tool path that in rtcp is not always very clear and I can add without a doubt that no matter what simulator you have but to understand to the bottom of the behavior of the machine you have to see working. Sometimes I can assure you that to get the desired result you have to operate in the opposite way of what you would have thought.
as for the 3d ceck entertained as well if you have time I did it in a couple of cases and it works discreetly but it is a little complex to manage and anyway I recommend to import the models of the tools (stl file) previously made by cad because with the atomcomposition you no longer pass you also I have to inform you that at least until the last update of a couple of months ago still does not work the option of activation length from the correct mapps parameters
I can still tell you that the cinematic simulator has never happened to me in reporting collisions except on the first movement after the activation of the rctp on which you have to be careful.
the macro substitution of the g68.2 the year given also to me but I never used it because I don't like shortcuts and I preferred to lose some time to understand the logic of virtual corners and then the problem I passed to the technician of the post that worked on us a little bit and it has put everything in place (and that we pay them to do!!! ! ! )
I hope I haven't bored you too much, but there are so many things that I sometimes lose the sense of measure.
Bye.

 

[daxo]

today I finally completed the processing of the detail.
I must say that the result obtained is good:finger:.
machine movements are fluid and tools work properly.
I've only found a few shots on the c axis, with active g0.
replacing, within the cn files, g0 with g1f25000 movements became fluids with good acceleration ramps and deceleration.
The only problem encountered in some cases was the links between retraction and approach between the various working strategies.
trivially solved with the subdivision of the various strategies in multiple subprograms and using the "truck" to return to position of zero machine at the end/start of each of them.

Now I can assure you that I have taken the first step with the work in 5 axes continuously.

Thank you all for your help and advice

greetings daxo