Posts by paranoidandroid

    Following up. I understand what your feedback is now Robodoc. Just got finished working with Motoman technical support.


    For clarity, this is from their troubleshooting:


    Problem


    Some customers report that the IP address is lost at power cycle or some other conditions. When looking at the card in TIA Portal or other Siemens software the IP address will show as 0.0.0.0.


    Resolution


    Our suggestion to save the IP Address as follows:


    1.       Start the YRC1000 or DX200 in “Maintenance Mode”


    2.       Once fully booted set the IP address again from the Siemens software.


    3.       This will put the CP1616 board into a mode which it can save the setting properly.


    4.       No settings within the robot controller itself need to be set or changed.


    5.       Cycle power to the robot controller.


    One additional countermeasure - if you have the TIA-project for the CP1616 you can execute the “factory reset” first and load the TIA-project again.


    Happy programming...

    -PA

    Following up on this thread.


    Seeing a similar issue, but not during normal operation. This only happens when I disconnect the programming pendant (using the disconnect option with long-pressing the simple menu button).


    Any thoughts on what might be happening here?

    Hey Motoman RF,


    Is anyone dealt with the issue of the CP1616 dropping the static IP address if the controller is shut off? I can go and re-assign with PRONETA or TIA Portal after the fact and re-establish connection but this would prove problematic if we lose power at the plant and have to re-assign IPs to EVERY robot controller after.


    Suggestions? Haven't been able to find anything in the PROFINET documentation from Motoman just yet.


    Thanks,

    -PA

    Hey RF,


    Anyone run into issues with the DX200's functional safety board when it comes to the FSBOUT signals? I have alarms 4772 (for outputs 1 and 2), 4768 (for output 2), and 4923 (for output 1) faulting on startup.


    I've tried clearing alarms (4772 persists), resetting in maintenance mode, and loading a previous backup. None of these seem to clear the issue. Is it possible the CN220 card is hosed?


    Any recommendations from folks that have dealt with this before would be appreciated. I'll follow up as I get details from Motoman.


    -PA

    After doing some more manual reading, turns out modifying S2C430 solves my problem.



    Setting the parameter to 2 makes it work in my case. Woo. ;)

    Following up on this, tracking a similar issue on a DX200 controller, MH50-II robot.


    Running a palletizing operation with a pounce point above the pallet, locations are calculated based on counter integers provided by the PLC.


    When working with KUKA, I used to manage this problem by just using a MOVL move instead of a MOVJ (KUKA disregards the "status" and "turn" i.e. robot orientation for MOVL moves). It doesn't appear that it works the same way with Motoman. On this edge case, the robot tries to reorient because the location at C0 has a T orientation <180 degrees. The placement point has a T orientation > 180 degrees.


    Providing a snippet of code below. Am I able to accomplish this with the code I have, or so I need to use a SFTON / SFTOF command? For reference, the D[ ] variables are positions provided by the PLC, I[ ] variables are counters provided by the PLC. D[30] - D[32] are placeholder variables so I can move things into my position buffer P[30]. I know the orientations for X, Y, and Z are correct as I'm able to get 99% of my pallet stacked with this code. Just a weird edge case I'm trying to account for.


    Helpful, thank you.


    As a rule of thumb, what do you use to get jobs (or other parameters) between a controller and simulation/offline? The onsite Yaskawa application tech suggested just using USB on the pendant. 90s much? ;(


    I'm coming from the KUKA world (I never thought I'd say I missed Workvisual, but here I am...), and I'm used to being able to push/pull over ethernet without an issue.

    Seems like I'm having a similar problem (MotoSim EG-VRC 2018). I tried to save via Job Pad and push to a live controller via Ethernet. MotoSim crashed and now I can't move jobs between my live and simulated controller. Great software! :S


    What's the best way to recover? I have a CMOS.bin I can pull from the live DX200 controller (there's no CMOS.bin I can see from the MotoSim backups), but I need the user frames, tool interference, etc from the simulation.

    Hello RF Yaskawans...


    Robot: MH-50

    Controller: DX200

    FieldBus: Siemens Profinet

    Safety Fieldbus: DX200 FSU interface (no safe ethernet)


    Traditionally trained KUKA robot integrator/programmer, making the hop over and getting some experience integrating PLCs with Yaskawa's DX200 robot controller and a Siemens S7-1500 PLC. Planning on using the FSU board on the DX200 for safety monitoring (e-stops, doors), along with some axis monitoring due to the tight space we've got the robot installed. Pretty standard fare for a robot integration project.


    So, the question is related to job selection with Yaskawa robots. I've familiarized myself with the INFORM language (similar to KRL, since they both operate w/ a VxWorks RTOS), but I'm not quite certain how the PLC interface is expected to work with these robots, and have yet to find good documentation that talks about the process.


    For example, with KUKA, this is mainly accomplished with the CELL.SRC file along with a submit interpreter (cyclic background program) that acts as a listener for the PLC. Once jobs get dispatched from the PLC, they get passed into the CELL.src file and triggers a SWITCH-CASE, ultimately controlling the job selection. I'm looking at around 50 to 100 jobs for this particular application, so I need to get a firm understanding on how INFORM / Yaskawa robots manage these signals. I'm more asking how the Yaskawa manages the cyclic scanning of incoming bits from the PLC, less so HOW those bits are mapped.


    After configuring the PLC / mapping your I/Os (setup two DINTs for my 64 PLC-to-Robot input/output booleans, along with a handful of other ints for robot tools, bases, and program numbers), my limited understanding is:


    1. Change the robot over to "Remote" mode

    2. Start the "scanning" program and scan for program numbers. Accept a program number once dispatched by the PLC

    3. Select the correct program based on a SWITCH-CASE, execute subroutine (is it a JUMP case with Yaskawa?)

    4. Execute, and report program status (zones clear, gripper states, etc) via ProfiNET.


    Found this RF link, would love some more information in parallel to this. Potentially from Yaskawa's page, not sure what this would be under.


    Switch case instruction


    Thanks in advance,


    -paranoidandroid

    KSS: 8.5.8

    Robot: Various


    Referring to this old thread that massula started about 5 years back, curious if there's been any follow up? (Source: KRC4 system messages manual)

    Working on passing messages over TCP with the KRmsgNET TP. The following is a snippet from KRmsgNETSettings.xml, along with a comment for what the XML allows as far as customization. As you can tell, there's no option for message "severity" or importance. Best I see is %MessageType, which is not very granular.


    Alternatively, there's the MBX_REC command. Documentation on this is... limited. Any pointers on what this function does, beyond the function definition EXTFCTP INT MBX_REC(INT MBX_ID :IN,STOPMESS MESS :OUT) from $OPERATE.DAT and $OPERATE_2.DAT? (source: KRC4 list of functions and subprograms)


    Wasn't able to find this specific XML, but I see what you're recommending.


    I did try playing around with C:\KRC\SmartHMI\Config\Authorization.xml, which gives the same user mode levels from 5 to 30. However, this didn't quite do as expected. Modified both "#ExpertProgrammer" and "#Administrator" values between 20 and 30, all it really seemed to do was make these options disappear from the user menu...


    However, I found another interesting workaround.


    From C:\KRC\UTIL\RuntimeTests, there is a DLL and config file that will allow a logging function to pop up on the SmartHMI.


    Copy/paste these files into both C:\KRC\SmartHMI and C:\KRC\SmartHM\Config, and you'll force the HMI to display a logging function on the bottom of the HMI. Will require a reboot w/ file reload, which you can force if you "Restore" a previous KUKA project. Just make sure you back up / image before doing so.


    From there, you'll be able to get into the desktop and use Start > Administrative Tools > Computer Management to reset the password.

    Hey Robot-Forum users,


    KSS 8.5.8

    KRC4 Compact controller

    DVI Monitor + USB Keyboard


    Appears one of our techs locked out Admin credentials on the KUKA HMI and promptly forgot the password. Nice. :rolleyes:


    W/ KSS 8.5, minimizing HMI comes with Admin credentials, no longer in expert. I have access to expert, but I don't have access to Admin. My plan, if I can successfully minimize the HMI or prevent the HMI from coming up, is to regedit the password back to default.


    Reading on a few other threads, it appears there's a key sequence you can use on boot to prevent the HMI from opening. I'm referrring to:

    smartHMI interface

    [SOLVED] KUKA KRC2 Windows fail


    I've given these a go, with no joy:

    - CTRL

    - SHIFT

    - CTRL+ESC


    Any clever ideas?

    Following up. You're correct, Panic Mode. Bizarre behavior w/ the hot fix KSS, but more likely an issue that made it in from 8.5.6. I believe KUKA is aware of the problem now, so hopefully it will stay fixed with iterations from 8.5.8 and beyond.


    For posterity, here's the khash I used (same username and pw you provided).

    So I reached out to KUKA directly on this issue, wanted to follow up on couple of things:


    1. I'd originally tested this on KSS 8.5.7 HF1, which it turns out has a lot to do with the problems I've been tracking. It will successfully mount the local drive (in this instance, a directory on the shared D:/ drive). After mounting, if you try to run the "krl_fopen" command on HF1, it will fail. I attempted this same code with KSS 8.5.8 with no issues (unmount and mount D:/, make a new directory on the mounted drive, fopen, fprintf, etc). So it appears the KSS has something to do with this bug. My recommendation to anyone running into this issue w/ HF1 is to upgrade your software to the next stable version.


    2. The documentation per KUKA on the khash.exe is correct (based on a reliable POC at KUKA Robotics in Detroit). I think this got a little confused, and I wanted to be clear. I'm able to successfully unmount / mount D:/ with the following on KSS 8.5.8:

    Code
    CWRITE($FCT_CALL,STAT,MODE,"krl_unmount","/MountDrive")
    CWRITE($FCT_CALL,STAT,MODE,"krl_mount","/MountDrive","//192.168.0.1/d","kukauser","0E76390E88C27932C9816D326AF12CEA2B")

    Note that "kukauser" is case sensitive. Hashed password is "68kuka1secpw59"


    Everything else that followed worked successfully after the drive mount, including using:

    - krl_fopen

    - krl_mkdir

    - krl_fprintf

    Panic Mode,


    Thanks for looking into it.


    Still running into the frustrating result of getting a STAT.RET1 = #CMD_ABORT and MSG_NO = -32 (Mount point not found.) Code below...



    Truncated the rest of the code, as STAT.RET1 returns #CMD_ABORT at this point.

    Including a snippet of code for drive mounting the local D:/, per PanicMode. Unfortunately I'm receiving a STATE.RET1 = #CMD_ABORT on this (MSG_NO -2, Operation failed: mount point not (or no longer) available.).


    I don't see any indication for why this would happen. I've tried the following iterations for mounting address:

    - //192.168.0.1/Log

    - //192.168.0.1/d/Log

    - //192.168.0.1/d

    - //192.168.0.1/


    I receive a MSG_NO: -2 in each of those cases.

    Hey all,


    KSS 8.5.7 HF1. Tested this both on a compact controller for an Agilus, and on a full size controller for a KR16.


    Running into a similar issue as lomaxe with krl_fopen. I'm presently trying to write to the D:/ drive (for logs), after ensuring sharing privileges have been activated. Ultimately, I'm trying to get CWRITE commands to create, and write to a file inside of the D:/ drive under a specified directory. At present, I'm not using the krl_mount command to mount the D:/ drive as lomaxe did. From what I can tell from this thread, it doesn't appear to matter as they ran into the same issue I'm seeing. I'm going to attempt to mount the D:/ drive using the local IP per Panic_Mode (credentials "KukaUser" and the "68kuka1secpw59" password hash), but at present I'm not sure this will change the end result.


    Things that we've checked:

    - External PC connected via KLI, able to ping the IP address of the KRC controller (172.31.1.147, for reference)

    - External PC can access, and write, to D:/. Meaning create directories and files, along with deletion.

    - Error value for the STATE_T structure comes out to -2, indicating "Operation failed, e.g. because the file was opened outside a KRL program or the mode is “r”, “r+”, “rb” or “rb+”, but the file does not exist.". I've ensured that my code uses the append command ("a") with krl_fopen.


    Any recommendation / direction / feedback would be greatly appreciated.


    Some portion of my code shown below: