Posts by kwakisaki

Try doing the teaching in reverse - ie as if you are dropping it off.
Dependent on your equipment, that may be easier to align up.

I couldn't comment on compatibility of that 1GB board as I have no record of it to view.
Kawasaki produced an endless amounts of different 1GB part numbers for C controller.
Most variants were different due to the following:
- 1GB was available with 2 CPU's (6axis) or 3 CPU's (7 axis).
- 1GM ID board (which selected variant of arm that 1GB would connect to).

Back in the day, you could order:
- 1GB and 1GM combination matched to your controller = one single part number for both.
- 1GB 6 or 7 axis board on it's own = one single part number on it's own.
- 1GM ID board specific to your arm = one single part number on it's own.

When you receive the 1GB board, ensure you transfer the 1GM from your old board to your replacement 1GB including dipswitch/jumper configurations and I suspect it should be compatible.

Batteries are good now then.....excellent.

So, with actual encoder end swapped, the motion exerted on JT3 is registering as JT4 values.
Proves the hardware (JT3 encoder).
The reason I mentioned to this, if something has been spiked, you could be looking at a faulty encoder AND 1GB board.

Now you can rule the physical encoder out and due to your pursuance of the continuity checks (old school.....I love it and should ALWAYS remain as a troubleshooting tool and not just random swapping of parts) from what you have written, does point to the 1GB board.

The only other final check is from:
1FG => 1GB board for continuity (you will probably require 2 people and extended DVM leads) for JT3 encoder signals.

Have you got the troubleshooting manual?
- If you have you will find the robot side connector and pinout that connects to the 1FG board.
- If you have you will find the controller side connector and 1GB connection details.

So in terms of transparency, you can eliminate the complete umbilical, umbilical connections, internal controller harness between 1FG and 1GB board.
If they check out, then 1GB it is..........

Encoder read errors will never clear as it is a closed loop system, encoders are constantly read after power up and if any cannot be read, errors will be generated and remain.
I hope you have not been 'hot swapping' as this can spike the encoders and permanently damage them and possibly damage the 1GB board too.

Have you actually measured the supply to the encoder at JT3 end?
Have you swapped JT3 encoder harness at the encoder end and carried out a brake release and moved JT3 arm and seen the encoder/position values change on the axis data you have swapped to?

Quote from abraham1234

But if you feel uncomfortable when reply such stupid question, you dont need to do that.

That is not a derogatory remark directed at you and in no way did I insinuate or state your post was stupid or silly.
Please re-read it, I have provided an example exactly as you requested.
Nothing is stupid or silly when you are learning and looking for answers.
The stupid or silly thing is not to ask in the first place.

KISS is a term used across many industries and in life actually where situations could be over complicated as opposed to keeping it simple.

When new to something then Keep It Simple Stupid is recommended as a thought process.
Keeping it simple, logical and sequential is a great way of learning especially with programming.
Kawasaki AS language is extremely flexible and powerful and many solutions exist per problem.

If I was programming your application, I would be using a more complex solution using a whole host of AS commands, local variables and other AS functions that are available based around the application because I know AS and I can but this doesn't help others especially from a newbie perspective.

So when I provide examples, I make them as simple and logical as possible not only for the creator of the thread but for visitors to assist in people's development not for the purpose of labelling people, but for the purpose of training and assisting others in their journey in areas I can.

Do a google search for the Keep It Simple Stupid term and you will see the meaning behind it.

Quote from DoesItExist

it's interesting to have separate batteries per 3 encoders

Other OEM's do something similar but choose to use completely separate cells instead of an assembly. Which introduces possibilities of single cell changes at infrequent times.
Kawasaki choose separate cells, but assemble them in a pack, so they are ALL replaced at the same time when ANY battery alarm is triggered from the servo board CPU's to ensure regular maintenance for all encoders and reduces the downtime.

Quote from DoesItExist

The cells themselves seem to be obselete and quite hard to find...

They are not obsolete, they are used on current models.
Any Kawasaki distributor should have them readily available as they are a service consumable.
I know Kawasaki in the UK and Germany always carry stock.
You can find them on Ebay (search kawasaki robot battery):

My FS02 robot at home, I have added a battery carriage externally and use 2x Li-on 18650 rechargeable cells which I replace/recharge/replace when required so that I don't have to buy batteries anymore.
The robot has not been used in 6 months and the batteries are still good.

Up to you regarding 1GB.
Current monitoring for the joints is directly from inside the power block and sent to the 1GB board.
Like I said, swap JT5 and JT6 motor and encoder connections, re-zero and see if the fault moves when you get the encoder JT3 situation sorted.

FYI - Encoder low battery voltage warnings:
- Servo A warnings relate to major joints 1,2,3.
- Servo B warnings relate to minor joints 4,5,6.

KISSING it......Keep It Simple Stupid
Simply put your dump instructions into a subroutine and CALL it after the label.
Then you have your dump subroutine that can be called by other programs.

.PROGRAM main();
HOME;
CALL pick;
CALL place;
HOME;
.END

.PROGRAM place();
ONI/LVL -1009 GOTO eof;
;
JAPPRO place, 100;
LMOVE place;
OPENI;
BREAK;
IGNORE 1009;
LDEPART 100;
RETURN;
;
eof:
CALL dump;
RETURN;
;
.END

.PROGRAM dump();
JAPPRO dump, 100;
LMOVE dump;
OPENI;
LDEPART 100;
RETURN;
;
.END

Change the encoder battery.
I noticed in your earlier post about 'recharging'.
There is no recharge circuit and the batteries do not recharge, they are exhaustible.

This may rectify it and better to rule that in or out as it is the cheapest route too.

The 1FG gets source voltage from the controller and converts to 5V for encoder power and that board suffers from aging and could also be attributable to the encoder errors.

It is strange that she was working (albeit for JT5 error) before moving her and I really cannot see the 1GB board failing like that (a possibility of course, but in the realms of probability not really).

ONI or ON starts the monitoring of the condition and is cancelled when the condition occurs or IGNORE is used to cancel the monitoring.
So there is no need to 'look' for the signal again when ONI or ON has been executed.

It depends on how you look at it.
An example below (it is just an example, not something to copy and paste).
The place routine has 2 parts to it controlled by the RETURN instruction.
By default it will always place and RETURN or if interrupted, dump and RETURN.

.PROGRAM main();
HOME;
CALL pick;
CALL place;
HOME;
.END

.PROGRAM place();
ONI/LVL -1009 GOTO eof;
;
JAPPRO place, 100;
LMOVE place;
OPENI;
BREAK;
IGNORE 1009;
LDEPART 100;
RETURN;
;
eof:
JAPPRO dump, 100;
LMOVE dump;
OPENI;
LDEPART 100;
RETURN;
;
.END

Quote from abraham1234

- The robot executes some movement commands, whenever it receives a PLC signal, it will CALL a subroutine

- The robot stops at the last command of the subroutine and does not return to the previous program

Too generalised, you need to be more specific:
- Application.
- PLC interface to Robot type.
- Using PC tasks and Program Task or just Program Task.
- Why does it need to stop at end of subroutine, just return to main routine and scan for new task.

Usually you use a main task and scan for new task, execute task and return to main and scan for new task.

Alternative is you create asynchronous PC Task for communication to PLC and based on PLC signals and prime main task, motors on and cycle start, execute main task using repeat once.

Check CN2 on 1GB board, all encoder signals come from X3 direct and also check inside X3 connector on controller and umbilical connection for damage pins/sockets.

Quote from DoesItExist

I'm also convinced the issue with the encoder is no on the robot harness/encoder side as I swaped the encoders 3 and 4 on the 1FG board (on the robot side directly after the connectors) and still had the errors on jt3...

I would agree as that pretty much proves robot side harnessing without the error swapping over.
Down to your X3/X3A umbilical/Connectors (pins/sockets) or controller side on the 1GB board or connections to it.

Regarding JT5 error:
You may have tight gearing on JT5 and she may just require 'exercising' considering her age so can you jog JT5 in teach mode at all across all or any speed ranges.

If not you can also do something similar at the motor end for by swapping JT5 and JT6 motor and encoder connections and just test to see if the fault moves (same motors).
You may need to re-zero JT5 and JT6 but if it is mechanical, then she may need some dinero's and tlc.

Yes, if you ask Kawasaki and probably pay for the option.

Cubic S is a dedicated Kawasaki programmable safety device, you may be held accountable should any damage or harm occur without the appropriate training so I would suggest if you haven't received any formal training, to arrange for this as the forum is no fast track or substitute for training.

It has been sometime since I personally was involved with Cubic S and things may have changed regarding tools and tool shape points but I'll provide information as far as I know currently.

BLOCK and AS tool change is handled differently in Cubic S and I don't think they can be mixed.

QTOOL is the system switch which differs between BLOCK and AS tools in standard controllers.
- ON is for BLOCK tool in aux function 0304 and selected by way of tool no. in the BLOCK step.
- OFF is for AS tools by use of TOOL command.

TOOLSHAPE points in standard controllers are monitored points for speed monitoring and in Cubic S systems are monitored points for speed and interferences.

CBS_AUXTOOL1 is the system switch in Cubic S controllers which selects either:
- Tool and it's associated tool shape points from TOOL1 in aux function 0304 for BLOCK if ON.
- Commanded tool and commanded tool shape points for AS if OFF.

If CBS_TOOLCHG is OFF the controller will always send tool no 1 to Cubic S.
If CBS_TOOLCHG is ON the controller will send the selected tool no. to Cubic S.

TOOLID:
- If not used then tool no 1 is always monitored.
- If used, both tool shapes and tool numbers are monitored and if the motion distance is greater than the distance in Tool discrepancy, then an error occurs.
- I think if the setting is left at 0, no monitoring for mismatch occurs (which would carry a risk).

Both CBS_AUXTOOL1 and CBS_TOOLCHG system switches cannot be changed programmatically without requiring Cubic S to be updated by way of power cycling.

In BLOCK you have by way of fixed setting Tool No and the associated tool shape point assigned to it via aux function 0304.

In AS you have by way of command varying tool centre points and pre-defined tool shape points assigned as tool shape no's.

Like I mentioned, it's been sometime since I used Cubic S so things may have changed.

Back in the day, if you were physically changing tools with varying tool centre points and were not using CBS_TOOLCHG and TOOLID for checking, then you would create a set of tool shape points to encompass the volumetric area of the largest tool and set that and then freely use TOOL command to change the tool centre points without error if using AS.

From what you are describing, you are physically tool changing and within that physical tool, have various tool centre points which may or may not require different tool shape points too.
I don't think this can be achieved as the physical tool (TOOLID signals) need to be checked against the commanded tool and if you selected a different commanded tool centre point would produce a mismatch.

I would contact your local Kawasaki distributor and see if anything has changed which would allow for your configuration, otherwise I would recommend to not use CBS_TOOLCHG and TOOLID (which could carry a risk dependent on your application) and use AS as an alternative.

Would be nice if someone else has looked into this and can further add to this discussion as if it is not possible, this would be something to Kawasaki to look into developing further.

Reading the AS Language manual funnily enough yields that kind of information.

The meaning of your command as you have written means it will not work and will likely produce an illegal signal number error when executed.

You created this thread as you are looking for help with this error and you also posted in a different thread asking for help about the same error = duplicate post....

Doanthanhan do not duplicate posts.

Yes, it demonstrates clearly how it is created and highlights the .END and carriage return directly afterwards at the beginning of the video.
Terminating the .PROGRAM with .END and terminating the .END line with the carriage return.

If you are going to reference videos you are watching in the future, please link to those videos as obviously we have no idea what you are referring to without actual content.

It will be because you are creating your programs offline and not doing it correctly.
More than likely it is because of either:
1. You are not including .END at the end of your program.
2. Not putting a carriage return after the last line entry (not terminating the line) before saving.

.PROGRAM monkey();Testing
.END
 <=== cursor needs to flash here before saving

If you use the terminal editor in KRoset, you will never encounter this issue.
Make a program using the terminal editor in KRoset and then SAVE it to your PG folder.
Open that file in a text editor and see just how it is formatted then when you create a program offline again, follow the same format and you should be golden for future programs offline.