Posts by kwakisaki

If you allocate in the Kawasaki the first fieldbus bit 0 to:

1 - output

1001 - input

Then simply put:

SIGNAL 1 (in Kawasaki AS language) will turn on fieldbus bit 0.

DI000 in Mazak should then turn on.

BUT you need to consider the other signals in the Mazak address, it may also require other signals in the address to be set to 0 or 1.

So you may need to send multiple signals using Kawasaki either by:

1. SIGNAL 1,-2,3,4,5

2. Using BITS command by sending a 16 bit or 32 bit group of signals to the complete Mazak address.

(Both commands are available in the Kawasaki AS language manual for referencing).

ie the complete address may be required to send the full signal (packet) to.

BITS command will send a set BCD value to the allocated group of signals:

BITS(1,8) = 100

The value of 100 will be sent out using 8 signals starting at signal 1 using binary notation below.

(MSB) 0110100 (LSB)

Each address you are talking about contains 16 or 32 bits (16 or 32 signals).

The Kawasaki does not access the Mazak address directly.

It will access the specific IO of that address.

Example Mazak address R16384 contains 32 signals starting with DI000 - upto DI031.

DI000 => DI031ONLY sit in that address, nowhere else.

So when you allocate the Mazak fieldbus for R16384:

- DI000 will be fieldbus input bit 0

- DI031 will be fieldbus input bit 31

When you allocate the Kawasaki:

- 1st output will be fieldbus output bit 0 (which will talk directly to DI000)

- Last output will be fieldbus output bit 31 (which will talk directly to DI031).

This is assuming your allocating is correctly configured and byte ordering is correct.

R163842 etc..............are these data addresses?

If so, what sort of data do these contain real numbers/ integers/strings

Are they just 1 and 0.

Are they a specific Input.

Your values as you stated:

R16xxxx appears as inputs - That input would need to point to Kawasaki output xxx

R18xxxx appears as outputs - That output would need to point to Kawasaki input 1xxx

Cutting speeds, accel, decel and no. of points along cut path, what variances have you tried, any increase/decrease in deviation based on this?

CP switch on?

Code being used?

TCP setup?

Joint angles or transform data?

Robot mounted on ceiling, is ceiling posture set for installation (default is usually floor)?

Please stop multi posting (I've removed your previous post).

Motor shaft is part of the motor assembly, that information regarding motor disassembly will never be made available from Kawasaki as the motors are manufactured elsewhere and the manufacturers are very unlikely to publish that information either unless you are a repair agent.

Just my opinion though - New motor.

If you are talking about the removal of the motor from the robot, it is just 4 bolts (and you will probably require to use stand off bolts to raise the motor).

Would recommend some sort of sling to assist in physically pulling it out though, depends on your accessibility and risk assessment to prevent any injury though.

I think the gear is on a tapered shaft and will require gear pulling equipment to remove without damage.

I've never been in a position to test, or confirm full integration or not whether on software ethernet/ip or via 1TJ/Anybus ethernet/ip board interfacing.

I would be very much interested if and what information you receive from Kawasaki about this you could share though.

You need to determine if this is actually a robot issue or not, but things I would check are:

1. Payload is set correctly.

2. Is the arm at full stretch when cutting, try adjusting so that arm is more constrained.

3. How many positions are along each side - try a simple corner to corner cut (2 positions).

4. Laser focal point and settings correctly set.

Alexandru is exactly correct and probably a better example than I gave.

In Kawasaki the numbering convention for IO exchange:

Signal no. 1-960 = Outputs

Signal no. 1001-1960 = Inputs.

Kawasaki addresses inputs and outputs based on the numbering convention above.

- 102 would always be addressed as an output from the Kawasaki.

- 1102 would always be addressed as the input to the Kawasaki.

Knowing nothing about the Mazak.

it must also have some convention of addressing its outputs and inputs.

Complications can occur when byte swapping takes place which changes the order of signals:

Endianness - Wikipedia

Kawasaki has big and little endian and MSB and LSB swapping capabilities.

You would need to research the Mazak to see if this is the case also.

In order to change those fields directly as default, requires pressing A and the relative keypad button or just the keypad button for the intended parameter.

Denoted by the 'dual colour' of the keypad button.

However, I have sent you instructions for this via the conversation option in robot forum.

Well done indeed.

Even though the UNO outputs can deliver the required current for the SG90 servo's, I would recommend using an intermediate driver board just to protect the UNO outputs from overload and damage.

Especially if you are planning to implement co-ordinated joint motions.

Thanks for sharing.....

Ah, I know what your referring to.

Using BLOCK programming, when using left/right keys allows you to cursor left and right to select a specific field to set the parameter.

Check your conversation......upper right corner of the screen.....conv.JPG

I've sent you something.

Welcome to the forum..........

What do you mean 'teaching by cursor key' and what controller are you referring to?

Sounds like power block (IGBT Modules) issues or possibly the driver modules (1DD/1DT) to me.

Bugger to test out unless you have spares though.

Motor power will always go off as it is classed as a fatal error. and any power block related issues usually will not show their face until actual motor power is applied.

So you are unlikely to see it during startup, only when demanding motion.

Have you checked any of the documentation here specifically the AD Electrical Manual for further assistance and checks, it contains a lot of good detailed information that may help.

A and AD Controller Documents - Manuals, Software and Tools for Kawasaki Robots - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Sadly I have never used them and from all accounts, not all that popular either as integrators tend to stick with their own developed/integrated solutions.

I do believe in Kawasaki's wisdom that it is not just a software application that this consists of, I think arbitrary hardware is supplied with it also, including PC, Lighting Unit and Controller and License USB hardware dongle.

I believe the software has many different 'learning/training' tools though and would speculate (as with many Kawasaki products) a high degree of flexibility.

For this reason, I doubt it would be a cheap price tag either and therefore I would certainly contact your local distributor for more accurate information and it wouldn't surprise me if they offer demo units or at least be in a position to demonstrate the products full capabilities.

No problem, hope it helps you applying your modification....

You are not using QTOOL at all anyway, I was merely making a recommendation should you be using the aux func 0405 to make things a little easier.

If your tool direction or orientation is not changing and you a merely bringing the tcp closer to the centre of your flange and increasing the length of it, then yes, just by adjusting the Y and Z values should be applicable.

Dependent on how accurate your tcp is going to be used, then will depend on whether you should just alter the values or actually re-teach it in as these values are representing the new physical tcp for the robot.

Do not assume the 'fastest route' is going to be the best route.

You have several ways of defining tool values when using QTOOL OFF:

1. Locally setting tool values, does not store values as a location (not in a program).

- Typing in TOOL and pressing enter and then setting the values and pressing enter again.

2. Create a location and then recalling the values and applying it to the tool coordinate (used in program).

- POINT new_tool = TRANS(0,300,900,90,90,90)

- TOOL new_tool

3. Entering direct values (can be used in a program)

TOOL NULL+TRANS(0,300,900,90,90,90)

What is your use of 'arm' meaning here, as what you are saying doesn't quite make sense?

I am assuming you are talking about some part of the tool assembly but assumptions can often lead to incorrect advice.

What are your current OAT values you are using?

If it is a case of 90 degree difference only, then dependent on how it's mounted to the flange relative to the null tool coordinates, then it may be as simple as adjusting O and T values.

However, I would probably teach it in.

Have you read and tried the 'unknown tool method' available in the AS language Manual, I think somewhere in section 11, this is an alternative to auto tool teaching and uses the robots compound transformation calculation to return the tool values....only use 2 positions called the A&B method?

How are you intending to get the applicable XYZOAT values into the controller for the new tool?

Using Aux 0405 or using CAD data?

If you are using aux func 0405, I would recommend:

- Turn QTOOL ON

- Set the Tool1.

- Teach the TCP and store the values for Tool1

- Then create location using keyboard - POINT new_tool = TOOL

- Turn QTOOL OFF.

- Then use TOOL comand to set tool - TOOL new_tool

Using this method, if someone buggers with QTOOL, then by default you will also use the same tool values from aux 0304 (assuming no one changes the Tool no. using A and TOOL keypad button).

You could go over the top and set aux func 0304 tool1 to tool9 to the same values as your tool.

I don't usually do this, but when I started out, I applied this so to ensure my tool was always relative to my fitted tool (if never changed) and if someone wanted to use BLOCK with my current tool, they could freely turn QTOOL ON and not really have to remember to turn it OFF as I included QTOOL and TOOL as a programmed command in my startup sequences to ensure correct tool is used.

I have added some additional info to my previous post relating to the D controller, including a link to relevant post which you maybe interested in reading.

No.3.......try it out by toggling QTOOL ON/OFF.

EOAT is always a 'cloudy' area in the Kawasaki as there is much flexibility within the controller setup and configurations as opposed to being 'forced' to set something.

I really wish when using Kawasaki, this topic is firmly understood as it could lead to disastrous consequences if not fully understood.

This is no fault of your own, Kawasaki documentation and training do not sufficiently cover this either.

So in short order:

Kawasaki controllers have 2 programming conventions:

- BLOCK

- AS

Kawasaki controllers are usually supplied as default with a system switch turned on:

- QTOOL ON

Kawasaki controllers can operate quite successfully mixing BLOCK and AS conventions.

Now it you are using mixed conventions, QTOOL settings need to be controlled appropriately.

If you are only using one convention permanently, then QTOOL should be set to the applicable condition, either ON for BLOCK or OFF for AS.

The key points to remember here are:

1. QTOOL ON - Generally used for BLOCK programming conventions.

- Uses Aux Func 0304 Tool1 to Tool9

- Selecting a Tool no. (A and TOOL keypad button) when in tool interpolation uses Aux 0304 values.

- This Tool no. is stored within the BLOCK programming step when recording a position.

- If changing tools inside BLOCK is used, then you would simply select the required Tool no.

2. QTOOL OFF - Generally used for AS programming conventions

- Uses something known as Tool0 (but you never see/hear anyone speak about this).

- TOOL command is used to directly apply an XYZOAT value, or use a transform location to set Tool0.

- If changing tools inside AS, this requires TOOL command to be used.

3. Now the bonus round - You are using D Controller.

QTOOL ON will display Tx number T1-T9 in Tool interpolation icon (using Aux func 0304 Tool1-Tool9).

QTOOL OFF will display T0 in Tool interpolation icon (using AS TOOL command to use Tool0).

Check out the following thread, as this may be of interest:

Tool mode motion incorrect, need hints on diagnostics & correction - Kawasaki Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Also look at the video I posted in #8.

Quote from Jerryl859

The Qtool setting is also off, which I thought should be on. I have values for the old tool dimensions in x, y, z when I do a list/l command. The original tool was set up by an integrator.

This makes total sense and tells me you are using AS and not BLOCK and the above is correct.

1. All you would need to do is to setup another transform location in the location register and then use the TOOL command to set those values.

2. Or you could directly use the TOOL command to use entered XYZOAT values instead.

3. Aux Func 0304 values are not applicable.