Posts by ericwiz7923

    For Sale a Kawasaki RD080N and aE32F B004 Controller. Located in North West Ohio. Shoot me a offer, I’m willing to negotiate. More pictures upon request. Comes with Teach Pendant, Servo/encoder cables that connect the robot and the cabinet, whole control cabinet (cpu,power sequence board, and 1UR board installed).

    Solution in simple - if you want to move robot from K-Roset buttons turn the robot to repeat mode. In repeat mode you won't get safety speed exceeded errors.

    I've never tried that, after I test it out I'll report back. Thanks for the suggestion

    If you are using F Controller, you have a selectable stop category between 0 and 1 available under Aux Func 0535 and additional information for this is offered in the relative external IO manual for F Controller.

    Do you have a copy of the External IO manual for the F controller? I haven't received this unit yet so I'm sure I have the info coming but I'd like to get a head start on researching this. I think, if I understand you correctly, that in a F controller you can actually set the stop type for the external hold? Will it still perform/be rated as mentioned in the previous few posts?

    Maybe spending some time on having a good autorecovery procedure is worth investigating and implementing. Basically what i'm saying is i would be looking into the root cause as to why the the crashes are occuring, but it doesn't hurt to put extra safeguards in place for the human factor too.


    And say for the 10% of the time it can't automatically be recovered due to being outside of certain limits or thresholds then they can still go back to the original method of manually recovering in teach mode.


    Either way i'm just speculating since i don't know your situation, but from my experience we don't allow operators to move robots, only trained maintenance staff and even then it's pretty rare that they would even have to drive the robot in teach in the first place.

    I agree 100%. Autorecovery is on my "to-do list". I see the Cubic-S as just another layer of safe guards. I unfortunately can't make policy decisions as far as who operates the robot, but I agree restricting access to trained users is always the best practice.


    Depending where you are in the world there are different standards but specifically i'm referring to the following:


    Stop Category 0
    : Stopping by immediate removal of power to the machine actuators (i.e. an uncontrolled stop – stopping of machine motion by removing electrical power to the machine actuators)Stop Category 1: A controlled stop (stopping of machine motion with electrical power to the machine actuators maintained during the stopping process) with power available to the machine actuators to achieve the stop and then removal of power when the stop is achieved Stop Category 2: A controlled stop with power left available to the machine actuatorsSo in the case of a kawasaki robot if you don't have Cubic S or any other fancy Safety PLC if you break the safety circuit the robot comes to a violent stop due to the servo motors power and brakes 24 volts being removed and stopping the robot in a fairly short distance this is Category 0 stop.Category 1 is giving the robot a set amount of time approx 500ms to start deccelerate before the safety circuit is opened thus achieving a more gentle stop but with a larger stopping distance. Sometimes due to the distance from light curtain and a robot you will not be allowed to use a Category 1 stop. Catagory 2 is pressing the hold button on the teach pendant or the robot going outside of the XYZ moving limits. The robot comes to a controlled stop and the power is left on ready to continue. The safety circuit is not opened. Clearly category 2 is not used for when humans are in the enclosed space with a robot for obvious reasons.

    So obviously an Estop event or loosing the Safety Circuit input would be an example of a Stop Category 0. Then I'm assuming a External Hold would be a Stop Category 2. What would be a trigger for a Stop Category 1? Looking at the 1Tr board connections nothing jumps out to me with that capability.

    I don't know how much experience or robot knowledge you have. If your robot crashes are due to the robot being driven in teach, then you could use XYZ moving area to try and limit this in conjunction with changing the collision/shock detection settings for teach mode to be much more sensitive.

    Right now our cells with shock sensors have those tied into the safety gate connections on the X8 connections, what would be a better place for those connections? We have the collision detection option but it was never implemented by the OEM. That along with the auto recovery is one of my long term projects. As far as my experience level I have about five years as a Controls Engineer at a Tier 1 Supplier to the Auto Industry (fanuc,Rockwell PLC's and HMI's). This was a production support role with minor projects sprinkled in. The Rs03N training cell will be the first integration project I've ever attempted. My role now is as my new companies primary robotics engineer. So I still do production support but the electricians are meant to be the first line of defense, with my primary focus being on training, continuous improvements, problem solving. All my Kawasaki experience has been gathered over the last year at my new employer. I did attend a AS Language course back in March which helped kick my skills up a couple nothches.

    We are replacing two of our production robots here in the next few months. One due to its D controller approaching end of life and another because the operators have essentially beat the thing to a pulp. Regular crashes due to operator error. That's more or less how I was able to present this as a justifiable expense, that yes there are improvements needed to the cell but with "untrained" operators being the primary users of the robot then we are just going to be repeating the same mistakes over again unless we overhaul our training program. I've already begun doing so with our skilled tradesmen, now I need to with our operators and with the number of people that needed formal training it jut made sense to buy our own trainer. On the Robot they've repeatedly crashed we are getting Cubic-S installed now. With the purchase of 3 robots and cubic-s package I couldn't swing another couple grand feature for the training cell unfortunately. I might try pushing for the upgrade here later in the year though. I agree my motion space margins are tight, if not bordering on problematic. I think my next step is to finalize my EOAT design so that I can really know what I "need".


    As this will be the first Robot system I've integrated myself sorry if I have a few dumb questions, for instance when you say category zero stop are you referring to rating from RIA TR R15.306-2016? Or is this a Kawasaki term I am unfamiliar with?


    I did noticed on my K-Roset Simulation that when the Robot exited out of the Moving Area XYZ Limit that it coasted for a bit before stopping but I didn't know it could to that extent. A bigger enclosure or Cubic-S sounds like the only option.


    Believe me I think there will be some robotic assembled grilled cheese sandwiches made for lunch as the cells christening project :weissbier:

    Status update. I've been working on the basic layout currently. I'm looking at a 5ftx5ftx32" (or 1524 mm by 1524 mm by 820 mm for you metric folk) enclosure/mounting platform. The robot area will be encased in a plexiglass enclosure with gate monitoring. The tooling I'm estimating the size at 100mm by 100mm by 100mm (the small cube featured in ENV in KHIlibraries). This is a over estimate on the tooling total size but until I have something actually concrete designed this should suffice to design my enclosure. I'll obviously need to add collision detection to this unit. Also I'm experimenting with the Moving Area XYZ Limits to hopefully prevent a collision into the enclosure. I've been instructed to try and keep the foot print no bigger then 5ft which gets problematic for the reach. I used The RS003N Installation and connection menu to plot the motion range. Still have to play with the XYZ Limit some more. Does anyone have tips for implementing? The controller manual is a little clinical in its description.

    Are you talking about the following situation?


    yes. I've received those errors along with the robot not really moving. It would twitch and then you would not be able to move it at all. Motor Power would be on, now errors would be active. the virtual robot would no longer move with either the virtual tp or teach panel then, hence the "crashed" description.

    Just a little follow up on this issue. I found that with a project using a rs003n, and a e-controller that the issues also appears in reverse. I am able to jog via the virtual teach pendant but cant use the k-roset teach panel. If I try and use the teach panel then the project freezes/crashes. There is no solution that I've found, just identifying another bug.

    Fortunately for me we only do material handling so I will definitely be focusing that aspect of programing. We are preparing for our first Cubic-S cell soon (next month), unfortunately I wasn't able to get this feature for the training cell. I completely agree that matching our current equipment's safety equipment is a desirable goal, one I've begun to flesh out with our available schematics and the External IO manual. I am instantly envious of your Arduino conveyor! I could have a lot of fun with that. The gripper system is one question I'm still pondering, how to source one or to design one from scratch (another new experience for me). For software we thankfully have all the necessary AB software (we alo have K-Roset!) to develop and even train for PLC and HMI specific tasks, my boss in I are envisioning a complete trainer specifically so our technicians can really get practical experience. Those IO modules look like they will make interfacing super easy, thats the kind of suggestions I was hoping to get from you guys!


    I've developed some basic labs already to perform on our production equipment/K-Roset. With the added reasouce of the Trainer cell I will be expanding my content ten fold. One nice thing I'll be able to do is to teach myself block step programing, right now all of our robots are running 100% AS programs.

    No just a XGPIO board. If there is anything going between the robot and the HMI (offsets for pick and place points) it will use the plc as the middle man. That's how all of our equipment is configured so I'm of the mind that I'll set ours up the same way so that its more relevant to what our skilled tradesmen will see.

    So my company has decided to purchase a training robot, an RS003 with a F style controller, and as the person who will be leading the training of our skilled tradesmen and operators I've been tasked with developing a training cell from the ground up. We also have the ability to integrate a AB ControlLogix PLC and a Panelview Plus HMI. If you guys were developing a training cell what other features would you integrate into the process or those that have experience integrating cells what is one thing you wish you would have considered when starting out on your first integration project. We will have the Ethernet IP software option but have decided to not get the internal double acting SMC solenoids. We are going to go another route with our pneumatic control.

    Kawasaki also has these safety features (dual channel redundancy of course):

    - External Emergency Stop

    - Safety Fence (Monitored in repeat mode only to remove motor power).

    - External trigger (External Deadmans - without it, motor power cannot be achieved in teach mode).

    - Reduced speed in teach mode limited to 250mm/s (optional fast check - Which I read somewhere for the US is not allowed - is this true).

    After reviewing my schematics and consulting the External IO Manual for my controller model all I can say is the way the safety circuit is designed is quite, interesting. They have the collision sensor wired into X8 connector for the safety gate connections and the real crux is they have two pairs of NC contacts, from a safety relay wired to the X7 connector for the external Estop monitoring. Our safety system is controlled by one of these, there is a mechanical switch that the key goes into on the HMI that enables MCR power. To gain access to the cell you remove the key from the mecahnical switch and insert it to a locking mechanism on the cells access gate. You can remove the key from the switch with out dropping out the safety circuit and you cant remove the key from the gate unless its being locked closed, if the safety circuit isn't active it triggers an estop for the robot. I've explained to my superiors already that to allow jogging with the gate open the OEM will probably have to completely retrofit this circuit. We've outlined what we'd like to see operation-wise, now just playing the waiting game and see how they respond.


    As far as speed being reduced in teach mode to 250mm/s in the US, I'd largely agree with that. Fanuc has/had the T2 option for faster manual jogging, and in my experience when we received new equipment that they did not continue on with that feature. A previous employer had a number of older cells that were probably grand fathered in. I'm unaware of anything like the t2 feature for our Kawasaki's.

    Thank you for the feed back SkyeFire and HawkME. I have allocated copy of RIA15.06 and will be educating myself on the actual standard. Great example by mentioning Fanucs separate safety circuits, I have a little experience with Fanucs but have been diving in the deep end of the pool of Kawasaki Robots for the last few months. Ill be reviewing my external signals manual to see if I can find anything comparable.

    I am currently trying to work with a integrator on modifying my cells safety circuit. This integrator is the OEM of the equipment and they originally designed the cell to not allow manual jogging of the robot unless the safety circuit (estops ok, all gates closed and locked ect) is in the correct state. This renders the ability to teach the robot impossible unless I either lock myself in a cell (no, just no), jog the robot from outside the perimeter fence and have the safety gates closed (not possible for fine adjustments), or if I bypass the safety system by electrical and mechanical means (not ideal at all). The integrator is telling me per code that no one can have access to the cell enclosure when the robot has motion power, manual jogging or otherwise. I haven't been able to find the actual RIA standard on this. Does any one have any suggestions on how to find this info? I have already submitted a question to the RIA help Q/A.

    1.Signals 1-1000 are outputs, 1001-2000 are inputs, 2001- up are "Internal bits" the way I think of them are like b3 bits in a rs500 program. I might have the ranges off by one, feel free to correct me anyone.


    2. You can assign a signal value when you create a interface panel icon. Menu->Aux Function->#5 Advanced Settings->#9 Interface Panel

    Thank you for clarifying my terminology. I found the root cause. 100% my error. lower case L's and ones are pretty much identical on the teach pendant. Shame on me and my ancestors.:pouting_face:

    Has anyone had the "DO Jmove ....." ever not work for them in repeat mode? I have my speed at 20%, I've tried check once and check continuous. Im not sure what else could be holding this up? I have no program running currently. If I re-issue the same command again it will say program running.

Advertising from our partners