SRVO-068 Continued...

    Yes, I see what you mean about the speed differences.

    I'd be inclined to state that is just the 'processing of the data' for the purpose of displaying the values and not a reflection on the 'real time' speed of data exchange between pulsecoder and controller, otherwise there would be a huge following error (difference between commanded value and actual value) within the motion processing which to me would result in error after error after error.


    It could well be, both robots are actually processing a different amount of data at the time of displaying these values.

    Motion instructions are always the priority as far as the controller is concerned, anything squirted out to the teach pendant for display purposes sit at the end of the priority list of processing as far as I'm aware.


    But still, interesting when you see them side be side.

    I wonder if you just set them both to single display for the positional data, you would see some improvements or not?


    The error you are getting is a distinctive 'break' in communication from pulsecoder to controller according to the error listing though.

    I still find it odd that our "problem robot" is the only one i've seen so far of the several others I checked that has this "delay" issue on all 7 axes. The two pendants in the video are the same robot performing the same job (mirrored) so I wonder what extra data this one is using compared to the others? Like you said according to the manual it's an obvious break in communication between controller and encoder it just stood out to me today while going over things. And the fact that it doesn't return to 0.000 like the other robot(s) we have performing the same job. My thought was maybe this slow transference of positional data is why it's not reaching it's 0 also.


    The DTERR we just had happened in a different area than the last four i've documented. So far J3, J4, and J5 are the only three consistencies i've noticed. J4 and J5 are probably the least relevant as the cable bundle doesn't travel down to those axes. But J3 however is right around where everything is ran through and a highly probable pinch point so I will start there on the next DTERR. I won't rule anything out entirely just yet but to me J3 is just the best first choice.


    Something else i've noticed is that when the POSN button is pressed and displaying positional data on this robot (while sitting still at HOME) some of the numbers will jump back and forth rapidly unlike the other robot. Also when calibrating sometimes instead of displaying all 0.000 the first set of numbers which is for G2 J1 will read 0.006 instead. Am I looking too far into useless information?

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    Edited 2 times, last by SHIFT_Lock ().

    Thumbs Up 1

    It is very possible you could be looking at 'anything' that seems strange now.

    The fact you have 2 (or more) robots doing the same job, suggests they should all be the same and yes, technically you would expect that, but there could be whole host of reasons, memory differences, memory available differences, firmware differences and things like that.

    I'm not saying this is not related or irrelevant, it could well be.....


    But that would be a nightmare to resolve and from my experience, the technology is already proven and developed and I would of expected that if it were a problem to be resolved during development.

    Maybe worthwhile just having a look at the firmware levels between the robots just in case they are different, as you maybe using a firmware that could have a known 'bug' regarding that which could be related to your issue and it's now showing herself.....


    I'd pursue this 'common' posture element to a conclusion though, before venturing down another route, or I think you'll be back to swapping items ad hoc again.....and in the UK, we call this situation 'chasing your arse'...

    I checked out what I believe to be the payload settings (i've never had to mess with this personally so it's new to me) under $PLST_GRP[1] and 2 going through each one and the four robots I compared it with all match. Group 2 is actually all 0.000 across the board on every one of them. I'm not sure where to find the aux axis inertia but that does bring up a good point. The robot has been constantly displaying:


    Code
    CNTR-009 Warn-Cont Vel too high(G:%d^2)
Cause:  Continuous turn axis velocity is too high. cn_turn_no will not be valid because of high rotational speed.
Remedy:  Lower contaxisvel. This warning may be ignored if cn_turn_no is not used.

    This has been up on this robot for quite some time and A robot does not display this message. I found the cn_turn_no variable and it's a negative number whereas A robots is positive. But I have no clue where to check to lower the contaxisval.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    The easy way to check payload settings is menu>system>motion, but I guess the system variables would show the same info.


    Aux axis would have settings such as load inertia ratio, gear ratio, acceleration, max speed. These settings can be viewed and modified in a controlled start under the maintenance menu. Maybe can find them in the system variables also. Be careful not to change the settings unless you mean to. Wouldn't hurt to take an image backup first.


    Sounds like you need to check the speed. First make sure the programmed speed and override is the same on both robots. Then check the aux settings in the controlled start maintenance menu.


    To me that warning sounds like it's spinning too fast to keep track of the marker pulse???

    HawkME

    Interesting...………………….:icon_wink:

    So it's possible that this DTERR could be influenced if an additional load/force is applied to the axis during motion if configured incorrectly?

    Assuming these values were set/commissioned correctly in the first instance, would the exchange of any hardware such as:

    - Amplifier

    - Motor

    - Pulsecoder


    Require these settings to be recommissioned again even though the hardware is identical?

    I will have to do a controlled start on this robot first thing tomorrow to see about finding the AUX axis settings. As far as some variables I have found; to my knowledge the gear ratio is set to 0 across the board (I’ll find the variable tomorrow where I got this info), and the max speed is I believe 18,000 d/sec but we are set to 16,000 currently. I’ll have to find these variables again as it’s been a while since I’ve looked at them.


    As far as changing parts out I would think that none of those pieces actually retain any kind of data that would need reconfigured upon swapping. Although if anything would I’d say the amp maybe? But it was swapped from the A robot which is mirrored off this one so I would assume if there were any “settings” they’d already be good? I’m not sure though.


    Oddly enough we only had one of these DTERR alarms during production yesterday so I didn’t get much tinkering done as far as messing with the bundles ect. I spent more time skimming for payload and other variables.


    Also, I already have current AOA and image backups of these robots in case of any “oops” moments.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    I know with Kawasaki external axis hardware changing does not usually require any 'recommissioning' of values, only if the hardware was different like an over rated amplifier would require certain values to be recommissioned in, otherwise it's just a direct exchange.


    But it is very interesting what HawkME has mentioned as it's got my 'tingles' going and has thrown in another possible direction of investigation.


    AOA should be called OOPS in my opinion......

    Well as much as I hate to say it, I hope I have a few faults tomorrow (later today I guess) where I can start pulling on the bundle and see what happens. As well as check these setting mentioned above.


    I’ve learned from these forums that one little oops can cause hours of downtime and frustration. So I’ve went through every robot we have and made full backups stored on two separate USB’s and our network at work. :beerchug:

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    Thumbs Up 1

    Same reason of why we never modify a job when it comes to “testing”. We copy it, modify it, test it, and then implement it.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    For sure and also depends on the impact of what you are changing.

    Some people view changing like time delay values or touchup a location as something as a misdemeanour and no need to backup before hand...….

    For the time it takes to create an AOA, before and after, it's a no brainer for me.....


    Admittedly, I haven't had the pleasure of having to rely on a backup yet, but that doesn't stop me from doing it first.

    Regarding the position update speed on the teach pendant - Have you swapped pendants? It may be a stretch, but a difference in TP firmware might effect the position screen update rate. Is the controller software in both robots exactly the same?


    Regarding the DTERR alarm as it is currently - Are there any other alarms related to the SRVO-068 in the history before or when the alarm occurs? On which axes is the DTERR occurring?

    Ok, so I did a controlled start today and went to the maintenance menu to view the AUX axis settings and everything was identical. The gear ratio, the motor type, speed, ect ect. As far as the software and memory available and all things related everything is the same between the two robots as well. I did make one change to the "problem" robot though. I dropped the speed down from 18,000 to 16,000 to match the other robots and then COLD started the robot.


    As far as the processing speed of the pendant display I can try to swap the pendants tonight at their lunch break and see if the issue follows the pendant to the opposite robot. I was really hopeful that I was on to something here with maybe the CPU running slow and not sending/receiving data fast enough causing a communication type fault. I'll pocket that idea for now so i can focus on some more likely culprits. If it's just a separate pendant issue then i'm not concerned with it at the moment.


    This is the only active alarm of any importance besides the miscellaneous TP faults and the CNTR-009 I mentioned a few posts above. And this is a Group 2 Axis 1 servo set up as Continuous turn for a deburring process.


    I have also been monitoring the torque values recorded on these axes and comparing them. I'd like to see if I notice a spike of any kind during the fault.


    *EDIT* I did see a higher "Max Torque" on this axis than the other robot. At the time of the fault the torque recorded was 20.015 MAX and the Average was 17.153 whereas the other robot saw a max of around 3.6xx.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

    Edited 2 times, last by SHIFT_Lock ().

Advertising from our partners