I have no clue how to reach A3 if I need to get the tool pointed back at JT2 in the -y direction
Posts by ericwiz7923
-
-
Are these the poses your describing?
-
I'll have to go back and verify my TCP, that is a good point I hadn't thought of. Otherwise it sounds like I'm doing something pretty similar. Thanks for the feed back!
-
Currently working on improving a couple things on our training cell (see this link to see the training cell) and I was pondering what everyone does when creating work spaces from scratch for a new application. Generally on our production equipment we don't modify the work spaces, although I have added a few basic ones sporadically. When I did create new or modify existing ones I more or less just jogged the robot around to get a approximate value for my cube. Not necessarily the most efficient way to do this. Does anyone have tips/tricks for setting up new work spaces? I have use of AutoCad and K-Roset and have been playing around with doing a rough layout in AutoCad and then creating a obstacle in K-Roset to sort of plot the Work Space in advance. Still feels like I'm doing a lot of guessing/eyeballing values. Any thoughts or suggestions would be appreciated.
-
I'm not a fan of remote access to industrial robots, I think it's a non requirement (personally).
Exposing an Industrial Robot to remote connectivity over local carries a shit load of risks IMHO.
If I'd ever own a company that uses industrial robots, none of my robots would be remotely accessible.
I understand the convenience, but I'd rather know when I'm asleep, no-one is ping bashing my kit with port numbers and intrusion attempts just for the fun of it or maliciously.
If only locally controlled, then I can control the management of my robot fleet more securely.
I don't necessarily disagree. OT Network Security is one of those things I'm trying to learn a lot more about, and just not connecting it to the Network is the simplest solution when there are security doubts.
-
I believe the English manual came out with the v1.0 of KIDE, you can prompt the English of the manual from within the software. I found this in the documents folder within the C:/drive location.
-
Interesting, I'm based in the UK and have never come across this, so thanks for sharing...........
It looks like Kawasaki Japan has not developed this, but Kawasaki USA (Kawasaki Inc) instead.
Kawasaki USA and Kawasaki Germany appear to developing 'side application tools' as opposed to Kawasaki Japan ('Mothership') developing them and marketing them under the 'Kawasaki Global Banner'.
Kawasaki Germany developed something called KIDE which may be very similar to KSCADA.
However, it is clear KSCADA has originated from the USA branch, so they would be ones to contact referencing any trial availability.
Its sort of frustrating the disconnect between the different branches of the company. Last year I was at AS Language training and the staff at the Wixom office (KawasakiUSA) had no clue about K-IDE (yes I am aware this is a Beta test of the software). A little cohesion and we could have a very capable product. Right now I use K-Roset, KTools, K-IDE, KTerm, and CS-Configurator. I made a point in my post-training questionnaire to suggest pooling resources and have a complete software package.
-
KSCADA seems to be to Kawasaki what PC FILE SERVICE is to FANUC, which is what I would need to schedule backups for several robots and manage them. Couldn't find anything but KSCADA.
Have you considered writing a FTP Script to automatically do backups? I had a co-worker create that for our Fanuc's at a previous employer.
-
Would you use them again, recommend them, experienced any negatives?
IMHO I think they turn a poorly designed XGPIO interface on the F Controller into more usable and reliable solution.
Overall I still think the initial XPGIO design from Kawasaki appears 'weak' for an industrial robot controller, seems more synonymous for a laboratory type of environment.
I would 100%. They were very easy to work with/order from and their products are well made. When paired with the Kawasaki manuals the nomenclature was easy to understand and create schematics for.
Thanks for the warm welcome!
I did not have power supplied to the COM pin. Now it works great. I really appreciate the help.
I also appreciate the XGPIO connection solution recommendation. I am really considering it. Soldering onto the provided XGPIO plug has been tedious, and I am afraid of getting too much heat into the small pins and damaging the plug.
Your a better man then I am. I took one look at that 50 pin hirose connector with those pins designed for 22/24 AWG and punted the idea of making my own.
-
I bought the Graviton solution a few months ago and it has worked very well for my application.
-
I did not want to come out and say this as it steers away from your topic, but this is kind of my point.
Kawasaki Systems certainly allow them to be very bespoke indeed, and as an end user, should problems occur, then the supporting OEM documentation or training you have received may not support your cells and you are totally reliant on the integrator should you experience errors, faults or strange occurrences.
To be clear, I am not making any kind of statement towards your integrator in saying what they have delivered and setup is wrong.
The point I am making is that where possible, always follow fundamentals as the OEM documentation will be relative to them.
If these fundamentals are not followed, there must be a reason why.
For instance, an integrator may re-zero JT4 (on a 6 axis robot) 180 degrees from mechanical zero to accommodate a service pack/harness installed.
As an end user, unless you are aware of this and you needed to re-zero JT4 (ie motor failure/change), then it is very likely you will use OEM procedures and the result could tear the harness afterwards.
If you come across a cell that doesn't follow fundamentals, then be aware/in agreement of them before hand between integrator and client and have it documented/pencilled into any in house training you are likely to offer so you can fully support it.
Yes, Lemster68 has also suggested payload.....
Kawasaki uses AS Weight command or Tool coordinate aux function to apply payload, COG and moment of inertia values that will certainly allow for a more optimized system.
I agree 100%, hence the desire to develop a company spec.
-
Interesting topic and something I could spend hours on for sure based on my experience with end users and integrators.
But to some things up generally:
- Fundamental product knowledge is key - even if you are an operator.
- How this fundamental knowledge is then applied.
- Anything programmed can be changed unless access is prevented.
- Just because it works, does not mean the pixies are not queuing up waiting for some fun.
I completely concur with ShAdOwDrAgOnS
Base and Tool go hand in hand as they are the 2 fundamental coordinate systems used.
Whether you use BLOCK or AS, Base and Tool are fundamental to the robot and intended application.
They need to be considered for ANY intended application and applied accordingly.
Fundamental to ANY Robot is:
- Correct zeroing.
- Correct working envelope parameters (hard stops, limit switches and joint limits).
- Correct EOAT values (Tool)
- Correct internal working areas of the envelope (Base).
Not setting these or applying them incorrectly is going to lead to a charity event for the pixies.
You now have the added bonus of Cubic S to 'Police' the settings and stop the robot in the event of 'external influences', but Cubic S can only police the fundamental settings, if these are incorrect, the policing of them will also be incorrect.
All OEM's provide training for their products, anyone dealing with robots should at least attend some fundamental product training.
In house training often circumvents fundamentals for application training.
I understand completely. I based most of my listed specs off of our existing equipment for modularity so that it will be easier for my technicians to repair in the future (ie. controller model, AS Program exclusivity, Cubic-s version). As far as the use of base and tool coordinates (or lack there off) and the AS Programing exclusivity, that was how the equipment was originally designed and sold by the integrator. Our applications do not change tool or base values. One part of your comment that just hit me like a bolt of lightening though, that may make my revised spec, is your comment on correct eroing and correct working envelopes. That would most certainly save a lot of heart burn down the road. All great information everyone!
-
We also don't mess with the base coordinates. We also have a null tool coordinate on all four of our Kawasaki cells, I have thought about messing with that. What I did ended putting down for my Kawasaki Specs was I specified that all programing had to be AS programing to mirror our other equipment, we specified the same controller model that we have for our other cells (E32F) so that we have consistency in our spare part inventory, we specified a 1TW board over a 1UR board to mirror our other lines, and specified the general industries spec of cubic-s.
-
I do not have a whole lot to offer up. But you mentioned material handling, so one thing comes to my mind. That the bolts holding the end effectors onto the robot are safety lock wired such that they cannot back out from vibration and such. I went to one installation that had been running and a maintenance person needed help to position the robots so that they could check/tighten any loose bolts. I was like, "what? Who does not lock wire their bolts?" Well they didn't specify it, and I suppose others don't either. Big hazard to have an end effector come loose at high speeds.
That’s a good suggestion. Never seen a Tool go flying, lots of parts though lol. Best one was I told a rookie tech not to blindly run the robot homing program because the clamps holding that large metal car part would open sending the part flying in the process. He looked me square in the eye said “No it won’t” then proceeded to yeet that part out of the cell.
-
What is the sort of information everyone likes to bake into their equipment standards for new Kawasaki robotic systems, specifically for material handling? I've seen everything spelled out down to program names and functions/ip addresses/IO mapping/communication types to the opposite end of the spectrum where maybe one would ask for a specific controller/robot model and that's it. Also those with integration experience what is something you like/dislike to see when reviewing the customers request for new projects?
-
For those with experience designing a EOAT, what software do you like to use? Right now I am just a programmer with a electrical background but I am interested in broadening my skills. I work in a pretty niche industry so alot of our components needs to be custom designed. I feel like if I can approach a oem with a basic concept, it will decrease the development time of new lines/ideas
-
roho76 Are you located in the U.S. ? I'm in the battery industry myself so I was curious what equipment/ plant your working in.
-
If they say CS Configurator was never in KROSET, show them the following screenshot which was taken from KROSET Instruction Manual prior to them releasing Cubic S.
This would be the most significant improvement Kawasaki would make by placing CS Configurator Application into KROSET.
You will know what I mean when you go on the training.....but you will enjoy it for sure.....
Lol I'll be sure to mention this and also add this comment to my post training survey. I also have a K-Roset license so if I had the CS-Configurator built in that would help get me up to speed a lot faster. Also thanks for clarifying my previous questions.
-
- RS050N Robot
-
That should be a non-factor.
-
No problem, it may seem very long process, but you are dealing with 'Kawasaki Safety Module' which has many versions and incorrect advice from me could result in permanent emergency stop conditions until resolved.
So I need lots of information, thank you for your patience........
But simply your problem:
- Because a backup was reloaded and Controller was mis-matched with Cubic S.
- So all is needed is to use CS Configurator to update Cubic S Module with replacement data to match.
FYI:
Your version of Cubic S and Controller should have the USB writing option enabled.
This would allow to connect USB port of Controller to USB port of Cubic S.
This feature allows to update Cubic S Module without CS Configurator knowledge and is easier process.
Please ask KRI about enabling this option and demonstrating function.
A couple side bar questions, all related to Cubic-S. The usb port your referring to would be the one under the accessory port? I'm guessing this is why we are supposed to have the cubic-s module connected to the 1VA board via a usb-c cable? Is there any harm in not having the Cubic-S module connected to the 1VA board via the usb cable?
Also have you attended a formal Cubic-S training before? I ask as I am attending a Cubic-S training at the end of the month, and if you have then I was curious if in your experience was there anything you wish you could have learned in the classroom that you had to learn independently in the field. Any portion to be sure I grasp fully before I leave the training?