Posts by paranoidandroid

System Job ended up fixing it, good recommendation. Much nicer than having to recode the PLC to support explicit messaging. Thanks for the input TSGIR

Hey RF Nerds,

I've been in chats w/ Motoman about trying to get better synchronous data transfer to/from the DX200 robot controller and my PLC (Siemens S7-1500 in this case). They have two manuals available, one for AB / Ethernet/IP and one for Siemens / PROFINET (I'll attach both below).

My program structure:

- MASTER.JBI, called by the PLC at program init. Runs DATAXFER.JBI once at job init to synchronize data w/ the PLC (bits/bytes happen synchronously, have to turn these into ints/doubles/reals for the robot with some math)

- Job calls are issued by a switch-case in MASTER.JBI given a program number and a permissive bit from the PLC

- Data is re-sync'ed with DATAXFER.JBI each time something changes (counters, positions, offsets, etc).

The issue:

- DATAXFER.JBI takes ~1 second to run, which adds up over time when running many different job calls. Would like to find a way to synchronously update variables on the DX200 controller side the same way that bits/bytes are updated on the CP1616 card.

Allegedly there's a way to do this with explicit message communication, but Yaskawa's documentation isn't great for Siemens support (more geared towards AB).

Anyone have any experience setting this up, or had success in getting messages to write to variables directly on the DX200 controller? Any advice would be greatly appreciated.

Cheers,

-PA

Made some minor edits to this, was having an issue getting the output VARNAME.DAT file to compile on MotoSim. Should work now.

Great. Got off the phone w/ Motoman as well, and they reiterated the same.

So!

Re: Fabian's warning, use this code at your own risk. I'm not responsible if you clobber your controllers, so please do be sure you know what you're doing before you start pushing files around.

Some preliminary info:

- You'll need both the xlrd and the pandas libraries for this code to work. I've been doing development in the Anaconda IDE, but whatever interface you choose to use should work. Tutorials on how to install those libraries are available on the internet.

- So far, this runs on the DX200 controllers I've worked on. No idea if it will work with others, but would be great to hear some feedback.

- I'm happy to work w/ collaborators (just reach out to me on GitHub). I have main restricted to pull requests only.

- Right now, I only have code working for VARNAME.DAT, with things in work for IONAME.DAT and EXIONAME.DAT. If you have suggestions, ping me here or on GitHub.

GitHub - alfacharliekilo/Yaskawa-Motoman: Code repository for Yaskawa Motoman projects

Code repository for Yaskawa Motoman projects. Contribute to alfacharliekilo/Yaskawa-Motoman development by creating an account on GitHub.

github.com

Happy parsing...

Thanks, seems like I had some duplicate P-VAR names hiding, regex to the rescue!

To the mods: is there any issue sharing in-house developed (i.e. NOT Yaskawa IP) utilities for *.DAT file parsing? I've got a GitHub repo I'd like to share that parses VARNAME.DAT (soon to follow w/ others) based on the Motoman CDS sheets. Provided there's no issue here, I'll provide a GitHub link.

Hey Yaskawa RF,

I've been tinkering with a DX200 controller for a bit now, and am starting to build some tools to make the process of building IO and VARNAME.DAT files a little simpler. Been manually manipulating these files in NP++, and have found a couple of the following:

1. The files MUST be terminated with both a carriage return followed by line feed (\r \n) for the Motoman compiler to work correctly.

2. Make sure you're mapping correctly. I've mainly been doing this with the CDS sheet that Yaskawa provides during onsite commissioning (excel spreadsheet).

Anyway, has anyone run into a "ERROR 0722: It is already registered for Variable name" before? I've been trying to troubleshoot why VARNAME.DAT won't read back into the controller, keeps tripping this error code when trying to load into the robot. It might be a parameter setting (mapping variable registers to variable names, I need to look up which one this is, will edit w/ that info.)

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?

Can you elaborate? I've gone thru all the menus for the CP1616 card in maintenance, can't find an option to statically assign IP for the card. I can for the controller, but not the same issue.

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.

Quote

S2C430: RELATIVE JOB OPERATION METHOD

This parameter specifies how to operate a relative job. A method to

convert a relative job into a standard job (pulse), and a conversion method

to calculate the aimed position (pulse position) when a relative job is

operated can be specified.

0 : Previous step with priority (B-axis moving distance minimized.)

1 : Form with priority

2 : Previous step with priority (R-axis moving distance minimized.)

Display More

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.

'*************ACTION*************
MOVJ C00000 VJ=10.00 PL=2
'~~~~~ APPROACH ~~~~~
'Run approach location math
GETS PX[30] $PX001
CNVRT PX030 PX030 UF#(3) TL#(1)
GETE D030 P030 (1)
GETE D031 P030 (2)
GETE D032 P030 (3)
' Set X Location
SET D[30]  EXPRESS D[52] + ( I[69] - 1 ) * D[55]
' Set Y Location
SET D[31]  EXPRESS D[53] + I[70] * D[56]
' Set Z Location with Offset
SET D[32]  EXPRESS D[54] + I[72] * 10 + I[71] * D[57] + 300000 + D[24] / 4
' Reassign to position variable
SETE P030 (1) D[30]
SETE P030 (2) D[31]
SETE P030 (3) D[32]
SETE P030 (4) -1800000
SETE P030 (5) 0
SETE P030 (6) 900000
'Move to approach location
MOVJ P[30] VJ=25.00
'~~~~~ PLACE Mag ~~~~~~
'Run Place location math
SET D[32]  EXPRESS D[54] + I[72] * 10 + I[71] * D[57] + D[24] / 4
SETE P030 (3) D[32]
'Move to place location
MOVL P030 V=250.0

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!

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

massula, Just using the WoV project it was shipped with. InitialProject, 0.0.0.

panic mode That fix worked, thank you!

Hey all,

KSS:8.5.8

Robot: Virtual robot, OfficePc

Newly acquired, think maybe we're missing a setting in the WoV configuration to virtualize the robot. System's looking for actual RDC connections and all.

Anyone know which configuration has to change to make this a "dummy" robot?

Thanks,

-PA

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)

<?xml version="1.0"?>
<KRmsgNetSaveConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Channels>
    <Channel>
      <Name>MsgRequest</Name>
      <IPAdress>127.0.0.1</IPAdress>
      <PortID>65002</PortID>
      <MsgFormat>%HostName% %MessageTime:MM/dd/yyyy% - %ModuleName% - %MessageNo% - %MessageType% </MsgFormat>
      <ConnectionType>Tcp</ConnectionType>
      <CurrentFilter>
        <FilterKeys>Info</FilterKeys>
        <FilterKeys>Dialog</FilterKeys>
        <FilterKeys>Event</FilterKeys>
        <FilterKeys>Quitt</FilterKeys>
        <FilterKeys>State</FilterKeys>
        <FilterKeys>Wait</FilterKeys>
        <FilterKeys>Config</FilterKeys>
      </CurrentFilter>
      <CustomFilter>
        <UserMsg />
        <TechnologyMsg />
        <SystemMsg />
      </CustomFilter>
      <RequestSocket IsActive="true">
        <PortID />
      </RequestSocket>
    </Channel>
  </Channels>
</KRmsgNetSaveConfiguration>

<!--
Placeholder
Description

%HostName%
Configured network name

%Robname%
Configured robot name

%MessageTime%
Standard message time in the format: yyyy-MM-dd_ hh:mm:ss
Example: Display of the message time formatted 
as year, month and day:%MessageTime:yyyy-MM-dd%

%ModuleName%
Module name of the message

%MessageNo%
Message number

%LocaleMessage%
Localized message
Contains the message text in the language set 
on the robot controller as well as the parameters 
belonging to the message.
The parameter designates
 the specific value, 
e.g. +/- for the direction of rotation, A1 ... A6 for 
the robot axis.

%MessageType%
Message type

%EventType%
Message status
Add: The message is active from the time it is 
sent to the external system.
Removed: The message was active and was 
removed before the external system request-
ed the active messages.
Confirmed: The status “Add” was confirmed 
while the external system was requesting the 
active messages.

%MessageKey%
Message key without parameters

%LocaleMessageKey%
Message text in the language set on the robot 
controller, without parameters

%Parameter%
All parameters
By default, the parameters are separated by 
semicolons. If a different separator is to appear 
between the parameters, it must be included in 
the placeholder.
Example for formatting of the separator: 
%Parameter:$%, if “$” is to be the separator.
-->

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.