Posts by kwakisaki

What you are asking is pretty general I'm afraid and requires a little more context as I'm reading it.

Without seeing your main routine and the area you are looking at injecting the code and what you mean exactly be stopping the robot:

- Ending cycle and parking the robot and turning off cycle start and re-priming of a program

- Ending cycle and parking the robot and just waiting to start again with a part present sensor.

- Conditionally pausing the robot until a another action takes place.

- Halting the robot.

- Repeating a main program or subroutine using repeat continuous, repeat once system switch.

Any chance you can elaborate a little further?

Quote from Krash

IF part ==12 GOTO 200

This is the correct syntax.

I prefer bracing the evaluation condition(s) in parentheses:

IF (part==12) GOTO 200

Also I try to avoid jumping to labels where possible and have a more determined evaluation like:

IF (part==12) THEN

CALL xxxx

END

IF (part==12) THEN

CALL xxxx

ELSE

xxxx

END

You also have the WHILE/DO/END or the DO/UNTIL

See attached files to learn from.

Quote from dm.bogachev

If someone else will be interested about this, it does not work

Very good to know and a shame it didn't work.

Many thanks for letting us know, I shall place that in my little black book.......

I can't be sure if you can purchase a HMS board for Kawasaki directly from HMS, I've never tried.

It doesn't surprise me to hear the part no is invalid though, as several items in the Kawasaki cupboard are manufactured by other OEM's under license agreements in order to steer the source of supply to a single source and create something proprietary.

Your revision of the HMS board seems very old to me.

4 years ago, they were using a version about 5.05 or something similar.

Check your conversation and try that using the RT Standard and see if anything changes.

The led's are saying the Kawasaki is 'knocking on the door' of the PLC and no-one is home.

Led 2 is reporting the IO Controller (Siemens PLC) is not in operation.

So it appears to be reflecting what your PLC is saying.

As there are only 3 main things to make sure are configured in Profinet and yours looks matched on Kawasaki and the PLC from what I can see:

- Device Name.

- IP Address.

- Signal allocation.

I forgot to add, Kawasaki did release an additional option called 'Signal Output Within Path Function'.

You will need to contact your local Kawasaki distributor in order to obtain it (they may charge you).

May be something to consider if it appears more in line with what you need.

I have never used it, but attached is the manual and reads like it does what is intended for signal synchronization during motion segments.

Still not sure about why you require the /I3 format, but if it's working for you.

DEXT directly accesses pose/posture locations and grabs the required element and turns it into a real values (including decimals).

You haven't included your CALL to the subroutine and the parameters, so your issue probably lies in that area.

You need to use the & in your CALL to parse in pose and postures.

Why not look into the DECOMPOSE command and also consider creating your string on one line.

The following just shows something quick for joint 1 and joint 2 so that its displayed here on 1 step.

You can also add all your other joints to the same step and notice the inclusion of the separators ","

That's the thing really with 2nd user systems.

If you are going to re-purpose it into a similar application, then there could be some use of the existing programs etc to learn from or even modify for use.

Personally, like with the cut wiring, I would get it back to a complete clean system:

- All external field wiring removed.

- All user data removed (backed up to stored file on a PCMCIA card or PC before being removed).

This way you're not fire fighting with previous programs etc on your way to re-purposing it.

I'm assuming this is an arc welding application your referring to, as the FS10E were a very common model for D controllers for arc welding.

If it is then you will probably already have the relevant hardware and software installed and configured for arc welding.

So removing the old field wiring and just removing the user data would give you a clean medium to build on without removing any of the important configuration data.

I would recommend you look into going online with a PC at some point, to obtain file saves and loading data to the controller, some applications can found here and I recommend KRTerm to start out with:

Kawasaki Online Terminal Editors - Manuals, Software and Tools for Kawasaki Robots - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

You can also obtain a PCMCIA card and use the teach pendant, save and load that way to if the PCMCIA card reader is installed (it usually was standard for Dxx controllers).

If you are looking at wiping it, it would be better to create a backup first and if you are unsure about how to do this, then let us know.

Let us know if you need anything further........Enjoy............

Glad to hear you've managed to get her moving, proves the main hardware is operational.

Always a good sign for a 2nd user system where the history is cloudy........

Kawasaki has many types of errors/warning, some prevent motion, some interrupt motion some are just visual warnings.

From what you've described about the errors and the previous application, they sound like process related errors.

As this is from a previous application, chances are it is bloated full of the previous process programs etc and it would be bad advice for me to tell you to to wipe the controller of all data.....not unless you want to, but are in a position where you can make a full backup first (this would be my advice).

Let me know if you can make a full backup of you want to go down that route.

However as an intermediate step.

If they are happening and you are still able to jog the robot, it is possible that a background task is running and could just be stopped (but it may start again on a power cycle).

So first thing to check:

- Have a look on the teach pendant screen very top for a window that is headed as PC.

- Is there any program(s) name here with an asterisk.

If any are there and have asterisks by them, they will also have a number in front of them too.

This is the PC Task area (background programs).

The asterisk indicates that particular PC Task(s) is running.

So I would turn them off by:

- Going to Aux 0810.

- Selecting PCABORT and entering the PC Program no to abort.

This will stop them and see if this stops them from appearing

If after a power cycle (I suspect they will) the programs start again, it is more than likely the AUTOSTART SYSTEM SWITCH(ES) are set.

If this is the case:

- Go to Aux 0502 (SYSTEM SWITCH)

- Untick any switch that says AUTOSTART.PC (You will have AUTOSTART.PC => AUTOSTART5.PC

This will stop them from starting on power up.

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

@ is only a recognized number when used in conjunction with 32bit referenced commands such as BITS32 and UTIMER as far as I'm aware.

I am pretty sure (not 100%) that you cannot encode integer values into BCD directly using those commands as $ENCODE will not recognize 32bit references only real numbers as a compatible format.

I noticed also in your code, you are trying to use integers (@) and then encode them into decimals.

This again I do not think is possible as @ are considered whole numbers (no decimal places).

I think more code will be required for conversion and a special thanks to dm.bogachev for providing some conversion routines between reals and 32 bits here that maybe of some use from the following post:

Post

RE: using BITS32 to send joint positions over EtherCAT fieldbus

I have a code example for sending 32-bits numbers, but you should know that it will be correct only for the first 7 digits. (According to the manual)
robot-forum.com/attachment/37530/

(Code, 72 lines)

dm.bogachev

May 1st 2023

Be sure to give him a thumbs up if you are going to download it/use it......

However, it appears you are trying to read 16 bits, so it would be much simpler to follow this convention just by using real numbers (reals) instead.

.PROGRAM PackStatus (.packet_size)
; Fill the packet size
$packet_msg = $ENCODE (/I3, BITS(.packet_size, 16))
.END

However I am not too sure how you are trying to use the /I3 format and $ result in your example.....

Can you explain/share the format of string you are trying to construct if it's not IP protected info?

Many thanks for the images, that assists greatly.

The Simple Kawasaki topology is as follows:

- Controller CPU <==> 1TJ Fieldbus Motherboard <==> HMS Board <==> PLC.

- The controller CPU does not have ANY direct connection to the PLC/Field.

- The HMS board acts as the translator between Kawasaki and PLC/Field.

From your images I can see as a checklist:

- 1TJ Fieldbus Mother board.

- HMS Board installed onto 1TJ at CN1 position.

- Physical Interface is set for Slave ANYBUS connector CN1 (4).

- Total IO is 64 Signals.

- Local is allocated to 1-32 and 1001-1032.

- Slave is allocated to 33 - 64 and 1033 - 1064 (33 and 1033 are the 1st IO bits of the fieldbus signals).

- Please check Aux 0607 (EOAT extended IO) for accidental sharing of fieldbus IO if used or not.

- Slave port is set to LSB and BIG ENDIAN (this is usually correct for Siemens PLC).

- Network ports 1 and 2 are located on CPU board, not HMS board so not applicable for fieldbus.

- No need to set master port IP address as Kawasaki is slave.

- Slave port IP address is xxx.xxx.0.5 and effective address matches.

- This tells me you are statically using IP address and not provided by PLC.

- Gateway is set at 192.168.0.8 !!! are you going through switch/router and not direct to PLC?

- There is device name entered for profinet network device name.

- CC Link data has been set - no need for this as Profinet is being used not CC Link.

- The Kawasaki is not reporting ANY error conditions relating to the fieldbus hardware.

Your Kawasaki configuration tells me there is nothing immediately incorrect in Kawasaki from a hardware perspective as no error(s) being reported, except for HMS led indications.

You need to reference these led's with explanation in Kawasaki fieldbus manual and provide this detail as you have not described which led's are displaying what kind of status.

You did not mention any Red led's displayed, which leads me to say your issue lies outside of Kawasaki Controller.

So the things to look at:

- What exactly are the HMS led's telling you - link established, Connected to IO Controller etc.

- Profinet cable integrity.

- If using switch/router, connect Kawasaki HMS board direct to PLC and see if change occurs.

- Check GSDML file is correct for HMS Board (firmware revision used).

- Signal allocation for IO matches Kawasaki 4bytes in, 4 bytes out (consider process image too).

- Ethernet Node parameters match Kawasaki for IP and Device name - I think already correct.

Be interested to hear about your results.

We transfer and similar websites offer downloads and links for 7 days.

WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

The PLC is saying NO, but what is the Kawasaki saying?

Did Kawasaki supply the controller with the fieldbus board and profinet board already installed?

What module firmware version is your HMS interface board?

Did you obtain the GSDML file from Kawasaki?

What are the leds showing on the HMS board?

Have you followed the Kawasaki Fieldbus Manual correctly?

What is your configuration in the Kawasaki for profinet signal IO allocation?

Is it the same as the PLC?

Are the Profinet names the same and do not contain special characters and do not exceed 63 characters?

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

Please post in English and make sure post is able to be read and understood more clearly as it is not very clear even after translation.

If you provide screenshots and images via an external link, make sure it is freely available without requirements of having to sign in as this can be viewed as phishing.

May be use website that offers limited period downlink.

Others maybe happy to sign in or make account just to view your external link information, I will not unfortunately.

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

Most US spec systems require the trigger button (deadmans) to be held in first before motor power should be pressed.

But if the external safety chain is not connected, motor power will never come on anyway.

Personally when dealing with second user systems where the decommissioning team have been lazy and just cut all external field wiring ( ing hate that when they do that), then I remove it all back to bare controller.

In your case (D30).

You will need to study the external IO manual for the safety circuits (external emergency stop) and then insert jumpers into the correct terminal locations.

When correct, you should be able to energise the robot motors and be in a position to jog it around, assuming the zeroing data has not been lost and functionally the hardware is operating and not faulty.

The attached manual should assist in configuring the safety circuits.

Familiarize yourself with this manual and the components described etc (1KP board mainly).

Look at A-36, this shows the standard shipping jumper configurations for a standalone controller.

A-36 is the standard standalone controller 1KP jumpers which allow for motion to immediately be achieved not just in teach mode, but in repeat mode too.

Cautionary Notes:

- Make sure you are conversant with dual channel circuitry or get a qualified electrician to wire it.

- Check Teach pendant and Operator Panel emergency stops are working first.

- Check 1KP jumpers are correctly positioned (this is also in the attached manual).

- Teach mode (speeds up to 250mms) and repeat mode speeds (full speeds) can be achieved.

- Make sure the robot is securely mounted.

- Make sure there is some control measure for the working environment.

- Not only in teach mode (speeds up to 250mms), but repeat mode speeds (full speeds).

Personally, I never change the prefetches when using AS as in many cases you then have to manage it changing states regularly to avoid issues.

Example is when using MVWAIT and how it is explained in the manual.

So I try to manage the automatic function of them by use of AS commands if I can.

I also steer clear of signal setting as being used as positional references as you have to carefully manage (turn off and on) and also they can change state by many different influences such as an operator manually moving the robot to a different location and therefore the signal(s) are not relative now and could cause issues with auto recovery programs if you are using them as positional markers.

The WHILE loop can be executed at any point in time it is just an instruction and not necessarily reserved for motion segments.

It is very useful to loop a motion segment until the condition is met so that you could just 'walk' your robot to other Cartesians and manage signal states without having to bash the states of the system switches.

So during motion segments you can then also monitor and change signals etc within the routine.

SYSTEM SWITCHES can be used to automatically set conditions too, but they can have a negative effect on areas of the process too, so you need to manage them effectively the classic is RPS (that is another topic altogether).

The power and flexibility of AS allows instructions/functions to be used and hence has many iterations of possible instructions and function combinations that can be achieved effectively instead.

Check out the following AS Commands:

- WHILE/DO

- DISTANCE

- IF/END

Due to forward processing and speed command differences you will more than likely need a WHILE/DO condition after the motion segment or the motion segment to be wrapped inside a WHILE/DO condition; checking DISTANCE in order to trigger signals or process non motion commands between motion segments.

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

In future create a new thread and do not duplicate post and also provide full details of error.

- Full error code and description provided by the controller.

Moving Area limits are set up in Aux 0518 to create a cube area of operational area of the TCP.

If an error is displayed it is because TCP is out of prescribed area.

Just reset, go into teach mode and use joint interpolation to move TCP inside moving area limits.

This is explained in the Operations Manual you receive with the robot.

Quote from OpaBroesel

Get an ASCII backup from a time where program still ran, and then do a ASCII backup from now, where it causes that issue.

Install WinMerge or a comparable program and compare both, new with old code. Could give you a hint of where to apply changes

Couldn't have said it better.........

You should never adjust safety values to circumvent errors with DCS when troubleshooting.

DCS errors are there to protect whatever parameters have been set for the environment.

Those errors are telling you that something is potentially not safe and therefore get triggered.

This is only usually applicable on a mature system of course (ie a commissioned and operating cell).

If this occurs during commissioning/setup or/and you are proficient with DCS functions, parameters and procedures to adjust them then it can greatly assist in troubleshooting of course.

I have bear witness to a couple of instances where incorrect troubleshooting was applied by someone not proficient with DCS and was offered advice on the procedure of adjusting DCS parameters and they circumvented the error by adjusting DCS parameters to get the system operational again which resulted in a near miss towards an operator and a major collision costing £10,000 worth of damage to the EOAT.

I am only stating the above as this is a public forum and 'we' would like to make sure safe working practices are highlighted as a priority as Safety Monitoring Systems are there to reduce/eliminate and intervene where motion segments and processing exceed the Safety System parameters.

Quote from OpaBroesel

L P[1: "point-name"] 4000mm/sec FINE or CONT

where it was

L P[1: "point-name"] 300mm/sec FINE or CONT

Completely agree with OpaBroesel.

Please look into your motion segments where personnel may have added or modified instructions.

This may well be the source of the issue.

Especially if this problem repeatedly occurs at the same point for the motion segment in the program during automatic running.

A previous AOA and current AOA study of program data may yield these changes offline and direct you towards where the problem may have been introduced and therefore can simply be resolved.

It could be a PLC or HMI (external value) is being used dynamically to adjust motion segment speeds by way of IO or fieldbus etc, so if this has been integrated into the cell, then an investigation of this would be required as a possible cause too.

Of course the DCS parameters may also be an issue with an aging system (too sensitive), but from a troubleshooting perspective a first line of approach would be to look into the obvious first:

- Existing motion segments added/modified outside of the DCS set monitoring values.

- External influences such as PLC and HMI data changes, component failures.

Quote from ksj

I would like to get your help because of the unresolved part of robot programming by referring to the robot manual.

There is no unresolved part in the manual, the example shows a pick and place routine with the required programming method provided as the example (which is as basic as you need to get you away).

Clearly demonstrates the main motion routine and the vision TCP/IP routine for receiving of the coordinate data.

Except this is for single pick and place.

If you have multiple workpieces, then you just need to make sure your vision sends the coordinates of all workpieces per frame grab either as one string packet (if below 255 bytes) or as several packets.

Those coordinates are applied to the offset of the tracking conveyor position.

So pick workpiece(s) per frame grab should be easily achievable with simple modification of example program.

I don't know what your issue is......