Advertising

Posts by Witty

    Are you sure this error comes from the ethernet encoder? Or maybe something's wrong with the physical encoder? You could try switching the 2 physical encoders on slave robots and see if the error remains on the same robot - then you would really confirm that the problem is with the ethernet encoder.

    You need the Linetracking option installed on your robot for this kind of applications.


    The general idea is, that you have your main program, where robot does everything that's not tracking related and you have your tracking program, which at one point is being called from the main program.


    The tracking program only contains the motion commands, which are to be performed during tracking. In your case it can be a list of motions through your PRs. Tracking program has all its motions assigned to a tracking frame, which is just like a user frame, but this one moves together with a conveyor (you know the conveyor's speed thanks to an encoder). So you have all your motions programmed relative to a tracking frame.


    But how does the tracking program make sure, that it follows the kittens, and doesn't go a bit in front of them or behind them? That's what you need a trigger for. You need a sensor (or in more complex systems a vision system), which will detect a kitten. When the kitten is detected, the system knows, that the kitten reached the origin of tracking frame and from now on, the system can follow the kitten with the conveyor's encoder.


    The principle of operation of linetracking systems is very easy, but a bit tricky to explain in a post like that. If you have the linetracking manual available, it should explain it more clearly.

    Fanuc doesn't have a motion type equivalent to KUKA's Spline, unfortunately.


    Your idea of:

    Code
    1. :J P[1] 100% CNT0;
    2. :J P[2] 100% CNT0;
    3. :J P[3] 100% CNT0;


    will result in short stops at all the points because CNT0 behaves like FINE.

    Could it be, that the backup was taken in different robot position than the position of robot when it was restored?


    The encoder mismatch can happen when you restore AOA taken in one positon into robot, which is now in another position, not sure if it works the same way with Image backup.

    Regarding question 3:
    Take a look at the example string provided: '10.5''9.8''15.9'.

    Code
    1. READ file_var (xs::0::2, ys::0::2, angles::0::2)

    would cut this example string into substrings to xs, ys, angles with " being the separator. Unfortunately, I can recall, that you can't use " as separator in Cognex - correct my if I'm wrong. So what Cognex might actually send to you will be more like '10.5,9.8,15.9', and you will have to separate the numbers yourself.


    Regarding question 4:
    "The file_var will access which file or variable from the cognex?"
    The ones which you request with Get Value command. In this example code, there's:

    Code
    1. WRITE file_var ('gvc007',CHR(13),CHR(10))


    So from Fanuc you're sending a command to Cognex, saying: "Get me value of C7". And as an anwer, cognex will send you this value.
    In Cognex In-Sight Explorer you configure the output for the robot system to be available under "Job.Robot.FormatString", so the command to get your inspection results from Cognex would be:

    Code
    1. WRITE file_var ('gvJob.Robot.FormatString',CHR(13),CHR(10))


    Does that statement have merit?


    Sounds like some folk wisdom to me :uglyhammer2: Even if it's not "as important" (which I'm not sure of), I still see no reason for intentional use of wrong values (good luck explaining that to your boss).


    And yes, slightly wrong values are better than zeros.

    You won't get a direct, numerical answer to "how much does it affect longevity", but there's no good reason to intentionally use wrong payload settings (neither way too low nor too high). Actually, with any kind of motion-related errors, payload settings should be one of the first things you check, because wrong payload settings can really cause (often indirectly) multiple different errors.

    Try slowing down the conveyor just for test purposes - you will most likely be able to complete the cycle in T1 also.


    Anyways, if you're able to complete the cycle in Auto with given conveyor speed, for sure you will be able to do the same in T2.

    Thank you for the help provided so far. I managed to open trace .r64 files with Matlab as a workaround to my problems regarding WorkVisual or OfflineTraceTool.
    Hopefully my last doubt in this aspect is: do the channels "DriveMotorTorq_Act(1-6)" store the real-value torques of the motors in each axis? This seems obvious that they should (regarding the name of the channels), but my measurments show the torques are suspiciously low. I do realise the motors are followed by gearboxes, but I would appreciate if anyone stated if the values shown in attached picture are reliable. The robot is KR6 R900 sixx with a tool weight of no more than 1kg, performing a horizontal SPLINE movement in T1 mode.

    Unfortunately, that did not help. Creating the mentioned folders and moving my traces to them does not seem to help with anything. When I'm using the File -> Import/Export -> Import Trace Results to import my trace (tried both importing them from external location and from the Kuka Work Visual installation folder), I get the notification that it is uploaded successfully, but the "Trace Analysis (scope)" window looks as attached. I see my trace "witt_trace", but no channels are avaliable to be chosen.

    Hello, in the meantime I realized that WorkVisual can also be used to analyze the trace data. Unfortunately, neither OfflineTraceTool nor WorkVisual can open my traces. When loading them, OfflineTraceTool posts an error of not being able to find any traces in selected path and WorkVisual does find the trace, but no channels are avaliable to be shown. What I did to copy my tace data from the robot to PC was just a copy of the whole folder C:\KRC\ROBOTER\Trace to a USB pendrive. Are there other ways to export trace data?