Posts by kwakisaki

    I'm stuck with a quite curios problem and I was not able to find a solution for it yet.


    Suppose the main program is executing a motion command (JMOVE or LMOVE for example), and the E-Stop is triggered. This last motion is resumed when the emergency is cleared and the motor power (and cycle) are turned on.

    You have a short memory my friend.

    This is precisely what myself and dm.bogachev were eluding to in your previous thread regarding this 'automated' emergency stop continuance(s).


    This is not a curious problem, this is exactly what happens.

    That is why It is not a recommended practice to implement.


    On an external immediate interruption many conditions should be considered before continuing.


    The 2 minimum conditions as a priority to be considered are (IMHO):

    1. The robot may continue to execute the current motion segment.

    2. The robot may have processed the next motion segment and execute that new motion segment.


    The fail safe method is to:

    - Switch to Teach mode.

    - Use Check/Go.

    - Complete current motion segment step or change step and complete the next motion segment.

    - Switch to Repeat and then motor power, cycle start from there.


    From a programmatical perspective, the only true method is to :

    - Grab current program.

    - Grab current step in execution.

    - Grab current position.

    - Grab other variables or signal states that are relevant that require dealing with.

    - Clear the current program stack.

    - Check and confirm the current position is the same position it was at at the time of interruption.

    - Set/reset whatever variables or signals were at the time of the external interruption.

    - Re-prime the program to the motion segment step or non motion step it was executing.


    I would read explicitly what the BREAK command does as I don't think you've quite got it.

    BREAK has no skip functionality at all.


    You may wish to also look into the following commands:

    SYSDATA

    DEST

    TASK

    WHICHTASK

    dm.bogachev you read my mind my friend and beat me to it with that information........... :top:

    AS language reference manual mention that :

    ''To record a macro, choose from the menu bar [FILE (F)]  [MACRO (M)] and enter the file name to save that macro. To run a macro, use the SEND''

    AFAIK what is stated in the manual is very vague and is not necessarily correct.

    The SEND command in AS relates to Serial data transmission and requires the correct syntax.

    I also think you have to be connected to the controller via serial for this to work.

    I am just speculating here as it's something I've never actually attempted to do.


    Kawasaki would be better to contact over this for clarification.

    KRTerm is a mature product and no longer being developed.

    I'd be surprised if you could get an answer from them.


    The [File] option can be used to:

    - directly execute a specified macro file.

    - directly send a binary file to the controller (never tried this).


    The M icon/button in the tool bar can be used to directly execute a specified macro file.

    From an initial look at some of your images, it looks like an ex jag system (Interbus was their standard with those controllers and spot welding guns).


    Pictures of the left side of the controller will prove this.


    OK, so some additional things for you to provide some further information on:

    - Try and identify where the 3 cables going from the Interbus board are connected to.

    - It is likely one of them is going to a green device and the others are going to a weld timer.

    Welcome to the forum............. :beerchug:

    With little to no experience, you are going to have a hard time trying to resolve this.

    Interbus is a fieldbus network that will consist of at least 2 devices.


    hello, im a student at vox. and this is my end term problem

    End of term problem.........?

    Is this something a tutor has caused as part of a troubleshooting exercise?


    From experience, Interbus is very robust and somewhat bullet proof.

    The error is relating to connection issues, no parameters in the Interbus card, loss of network as it cannot read associated nodes that sit in it's configuration, or possibly the settings in the Kawasaki have been changed.


    Any failure, of cable disconnection, loss of parameters or node failure will kill the network.

    If you have some spare parts then great, if you haven't then the only thing that can be done is:

    - Check cables are securely connected.

    - So disconnect them and reconnect them, don't just assume by wiggling them, they are connected.

    - You can attempt the master card to re-read the network and self configure itself.


    Be worth posting some pictures of the controller inside of the Interbus board and letting us know just what nodes exist on the network (topology) and whether they are displaying faults too.


    Also describe what it was doing prior to the fault:

    - Did it fail during use.

    - Did it fail after any maintenance on the line.

    - Did it fail after someone has been playing around with settings on the Kawasaki.

    - Did it fail after troubleshooting other problems.

    - Did it fail after a power off period.


    Lack of details means it could take a long time, especially if your not conversant with fieldbus networks and specifically Interbus parameters and settings and no spare parts available.

    So del/r will delete all reals?

    No.

    Read my post, I cannot type it any clearer than I have.

    it because i have to remove alot of reals, and have done it in a program but all the reals that already are in the robot will stay there even after uploading a new real file

    Makes no difference the reason.

    Loading data does not replace existing data, it adds to it and will overwrite any data that is the same.


    If you read the manual, to remove programs and all associated variables that are not shared globally with other programs, then you can clean systems up easier.

    But people fail to read the manual.


    /P/L/R/S/INT are all individual switches relating to specific data.


    DEL monkey will delete the program monkey and ALL associated variables for that program that are not globally linked to any other program.


    If you want to clear out ALL user data.

    That is programs and variables you can use the SYSINIT/U command.

    This will initialize the user data area (wipe it) and retain all system settings etc.

    I saw that KRterm can use macro but I don't know how to write macro instructions.

    The HELP in KRTerm contains macro commands and syntax.

    And is there a command that can be entered directly on KRterm to open the .uas file?

    I doubt it, never tried it, and can't see the point of it really.............


    MacroDlg.INI file is the file that is required to allocate .uas files to buttons on the macro page.

    1. Setup the MacroDlg.INI to display the macro button page.

    2. Allocate a button to a .uas file you wish to create.

    3. Create the .uas file.

    4. Open KRTerm and the Macro page should be displayed with your allocated button(s).

    5. Press the button to execute the macro.


    Attached is a small video demonstrating this.

    Note, any file saves made will be saved by default to the root directory of the KRTerm application.

    A sysinit will do far more than just the real data, so be warned............ :justice:


    As long as any of the real data is not referenced by any programs, they are free to be deleted/removed.

    Otherwise they will remain and you will receive message(s) to the fact.


    DEL/R *


    This also applies to other switches to like locations /L* and strings /S* etc.....

    Allow me to provide a clearer explanation of my situation. The challenge I face is that glitches often occur in my absence, leaving me uncertain about the events. The issue stems from operators restarting the machine, and the explanations provided are consistently imprecise.

    I harbor suspicions that the root cause may be an alarm signal sent by the PLC overseeing the work area, causing a halt in the robot's operations.

    It seems what you are asking is an external influence to the robot, so you will need to code in a data capture event to react to a PLC alarm signal.


    If no robot error is being produced, then no information will be captured in any of the logs except in the operation logs (what is being done at the time stoppage to restart it).


    So you must have a 'reaction' written in the robot code to 'do something' based on the alarm signal from the PLC in order to capture information you require.


    So you need to improve this area of code and use commands to capture specifics from the robot like:

    - Program(s).

    - Step No.

    - Positional Data.


    Check out SYSDATA and DEST and HERE commands and construct some code and use inside a PC Task and start generating your own logs and also include the monitoring of SYSTEM SWITCH status such as RGSO, CS, REPEAT, TEACH_LOCK as well as the PLC alarm signal(s).


    For instance, using the above commands in a PC Task you can grab:

    - Captured current program in execution.

    - Current step in execution.

    - Current position of robot.

    - Current target position of the robot.

    To be more precise, a real error does not occur, but the robot stops because something happens that causes it to stop.

    You will have to explain this scenario to me as it does not make sense........ :hmmm:

    If the robot execution is interrupted due to an external influence then surely that is externally related, not your code.

    To interrupt robot execution, you are either:

    - Telling it to stop.....WAIT, HOLD, PAUSE, ABORT, SAFETY etc.

    - Robot error is occurring causing it to stop.

    The robot model is FS030L-A001.

    In which case all you really have are error logs and operational logs:

    SAVE/ELOG

    SAVE/OPLOG

    So with the SAVE commands I am able to see the robot's logs, in particular what steps the program took?

    Yes, the error logs contain alot more information than you see from the teach pendant.

    Although pre F and E controller, there is less information.

    In the manual I see "SAVE OPLOG file name". Where is the file saved and how do I access it? If I connect to the robot via ethernet using KRterm, can I save it to the desktop, for example? What format is it saved in?

    These are fundamental things you should already know if you are dealing with Kawasaki Systems.

    If you don't know how to use KRterm or KCWin applications, then go here and download them, I have included a simple connection guide which includes a simple save command.

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


    a. Install KRTerm.

    b. Connect to robot.

    c. Go online.

    d. Type in SAVE monkey and press enter.

    e. Type in SAVE/ELOG monkey and press enter.

    f. Type in SAVE/OPLOG monkey and press enter.


    ALL file saves by default are saved to the root directory of where the exe of the application is saved.

    In the above case you will then have:

    - monkey.el (error log)

    - monkey.ol (operations log)

    - monkey.as (full controller file save (without logs).


    ANY file saved from Kawasaki can be viewed and edited via any standard text editor.

    You can even load files in with a .txt file extension as long as you stipulate it.

    Same questions for USB_SAVE_OPLOG. How do I select the usb driver?

    That makes no sense at all............. :hmmm:

    No controller connecting to an F Series arm has USB capabilities in either hardware or software AFAIK.


    Only E and F controller and future generations (including generation 2 teach pendant) have USB capabilities AFAIK.

    the reconstruction of what really happened is always approximate and difficult to interpret.

    Get them into the habit of creating file saves when an error occurs (hard to enforce, but worth asking).


    On later revision E controller and all F controller you have additional save commands:

    SAVE/ALLLOG - Saves ALL log data.

    SAVE/FULL - Saves ALL data that can be saved.

    SAVE/ELOG - Saves error log.

    SAVE/OPLOG - Save operation log.


    Don't get too used to KIDE, study the AS manual for SAVE commands available.


    I've been working with Kawasaki for over 15 years and all I ever need for debugging or troubleshooting robot errors (not processes in the application) are error logs and operation logs.

    Arc On symbol must be displayed otherwise welding not possible:


    For your information, welding is possible in Teach mode. However, in repeat mode, welding is not possible

    So this means electrical interface between robot and power source is functioning.

    the FA10N F series cannot be set by item, and you have no choice but to set welding-related items all at once

    Please provide evidence of this, video clip etc.


    Provide a backup,

    I'm 100% sure that robot will perform welding with disabled torch interference signal

    dm.bogachev 100% correct..... :top:

    You will need to contact your local Kawasaki distributor in order to obtain the correct firmware files for duaro and equivalent robot teacher application files to install on your tablet.


    That section of the video is showing the importance of matching tablet robot teacher application version to duaro firmware version.


    That document will likely be outdated now and different revisions will likely to be available not only in live scenario, but also in later revisions of KRoset.


    Incompatibility will create connection issues AFAIK as it is part of the initial handshake check.

    According to specs sheets I have for FS06L, if you have a European D40 controller (as attached).

    With a requirement of 5.9KVA with a source of between 380vac and 440vac.


    Some things need to be considered:

    1. KVA requirement, can this be provided by a lower three phase source.


    2. The primary of the mains transformer supplies the following secondary supplies:

    a. 26vac to supply brakes.

    b. 210vac - 230vac to supply AVR (Low voltage power supply.

    c. 210vac - 230vac to supply Single phase outlet (if required).

    d. 210vac - 230vac three phase to supply the power electronics (MC Unit and Power block source).


    No idea if this can be done as I have never cut and shut any controllers outside of the supplied conditions, so good luck if you can manage it.

    The code is just a bit difficult for me to read because I'm not familiar with some of the tools, such as the SFLP command.


    But it's true, AS language is powerful, precisely because it's easier to reach your goal with the individual tools than with conventional programming languages. But you have to know when to use the right tools.

    You know what I'm going to say already - as I stated it in my last:

    many solutions exist so it is definitely worthwhile grabbing a beer, crunching the manual and if you have it (KRoset), start key bashing and just see what you can achieve.

    Your comment below I hear ALL the time:

    I'm also not always sure whether I've chosen the easiest way or whether the code could be written even shorter.

    This shouldn't be a factor.

    - The right way is when your program works to the specifications required 100% of the time.

    - The wrong way is when your program doesn't work at all or only works a % of the time.


    So I'll ask two very simple questions:


    1. What do you mean when you say easiest?

    2. What would you accomplish by making code shorter?


    Ever heard of KISS.

    Adopt this direction from the start and you'll never fail.

    Try to run before you can walk will result in you falling over time and time again.

    It's a bit intermediate to understand but this code works better than the code from dm.bogachev above!

    Nothing intermediate at all, that's AS language right there in the same language dm.bogachev is using.

    May be you are referring to structure and commands, ease of reading, ease of execution etc.


    It is just an example remember, if it was something I was going to deploy onto a system, it would be written very differently.


    That's what makes AS sooo powerful and flexible, there is no 'text book' method or document on how you program an application.

    You have a book of commands (just like a toolbox full of tools), sometimes we use an alternative tool instead of using the correct tool to accomplish the same thing.


    This is why it is better to be 100% transparent about your application when it comes to Kawasaki and using Robot Forum, many examples, many solutions exist so it is definitely worthwhile grabbing a beer, crunching the manual and if you have it (KRoset), start key bashing and just see what you can achieve.


    I'm sure you'll be pleasantly surprised.

    Thanks again! (Please let me know if I’m asking too many questions here)

    No problem at all..... :top:

    What is the difference between block command circular 1 and circular 2?

    Circular1 is deemed the mid-point of the circular trajectory and circular2 is the end of the trajectory.


    You can have multiple circular1 motions (under the WC instruction) as you can handle, but the final 'closure' to this is done by circular2.

    You cannot have just circular1 as it needs to calculate the radius.


    Below is a snapshot of the AS equivalent from the manual, as this also includes a small example and diagram.

    *** Note standard AS circular interpolation (not AS Arc circular motion) is C1MOVE (circular1) and C2MOVE (circular2).



    How precisely does the mid point of the circle need to be defined?

    Depends on if you require a circle or not.

    Is it better to define several points along the circle using weld c?

    If you are not intending on a circle, then possibly (depends on what you are welding) but you will need to use circular1 instructions until you intend to terminate the trajectory.

    You will need to take into account the final circular1 motion though.

    Is it possible to define an arc of weld, or will circular block command try to complete interpolate the circle?

    Not too sure what you mean by this.

    Joint interpolation welding is possible (not recommended as the trajectory is less controlled).

    On a rotary axis parallel to the travel of the weld, I m guessing I can simply pose above the weld and spin the rotary axis, and define linear weld, is this correct?

    Possibly, depends on whether you are looking at coordinated motion (which will require a paid for option) and also if the rotary axis is controlled via the Kawasaki.

    You have the option of stationary welding too.

    Is there any setup animation software available that is comparable with this machine, and to practice block programming on? I’ve seen videos showing a animated e controller operations, seems like a good way to learn, and possibly program.

    KROSET is Kawasaki OLP simulator application which still support the legacy D controllers (not earlier).

    This can be downloaded from their download portal, but you would need to sign up in order to obtain it or contact your local Kawasaki distributor.


    KROSET is one application and running it without a license is referred to as Lite mode.

    Lite mode functionality is heavily restricted as opposed to a licensed version.

    USB Hasp Licences are available to purchase.


    You have a real time viewer, animated arm, virtual pendant and programming interface.

    So you could certainly use it as a self training tool just in Lite mode without requiring the full functionality.


    If you check out my YouTube channel (in my signature), I have many demonstrations of KROSET available including some arc welding stuff, but most of it is only achievable using a licensed version.