K-ROSET Lite Tool Setup and TCP/IP Simulation Limits

A K-ROSET Lite tool problem and a TCP connection problem have different deciding conditions: Lite limits how models can be placed, while a TCP test depends on the endpoint, port, listener state, and controller simulation configuration. Lite still permits TCP/IP programming, but a tool imported through the project tree may not behave like a freely positioned tool model. A reported D/D+ simulation also accepted unexplained connections; the same behavior did not appear with an E configuration and a ZX165U, so isolate that simulator condition before treating it as a PLC fault.

K-ROSET Lite tool and TCP boundaries

For a tool that will not add or position correctly, first check whether the operation is a world-model import or a Tool Arrow import. Lite permits one model in the world environment only when no other model has already been imported there; that model can be moved freely. It permits multiple models on the Tool Arrow, but those models cannot be moved freely. The tool coordinate can still be set through the controller terminal.

For TCP/IP, separate application communications from the terminal editor connection. Port 9105 reaches the K-ROSET terminal editor; it is not the port for a custom TCP test program. A TCP test on that port can show a login: prompt instead of exchanging application messages. Select an application port for the test and make the client target the port on which the server is listening.

These are independent limits. A license restriction on model import does not by itself explain a socket error, and a successful socket handshake does not show that the robot motion task can execute the intended command.

Tool-tree failures and the values to inspect

When the selected tool does not appear where expected, record the import path, selected file, model placement, and Tool Arrow coordinates before changing the TCP program. The reported example used an RS030N robot and the library tool Hand_G5BM21000B; that identifies the attempted setup, not a guarantee that the same tool operation is available in every Lite project.

There is an import-format ambiguity in the reported instructions: they mention a tool file in .krprj files, and separately describe exporting CAD geometry, such as a SolidWorks tool, as .stl before adding it. Treat these as distinct import paths until the K-ROSET import dialog and the Handling Project Manual identify the expected file type for the operation you selected. Sample tools are located under Kawasaki\K-ROSET\Hisui\KHIlibraries\Tools; the Handling Project Manual points to a tool example on page 21.

Lite model rules and tool-arrow coordinates

A Tool Arrow model is a visual object; the controller's tool data defines the tool coordinate used by robot motion. In Lite, the imported model origin snaps to the Tool Arrow origin, and the model cannot be freely repositioned like the single movable world model. If the physical tool tip is offset from the model origin, changing the model placement is not a substitute for setting the controller's tool coordinate.

One reported workaround sets the Tool Arrow TCP from the terminal rather than the K-ROSET Project Tree. Its example targets (0,0,128.6,0,0,0). That value is specific to the example geometry and desired TCP; use the measured or documented offset for the tool being simulated, not the example number. Verify the controller's coordinate convention and the intended tool orientation before using the result for robot motion.

Lite also separates project capability from controller behavior. The reported project could be used to learn robot programming despite restrictions on tool and model handling. A licensed version or trial may remove some restrictions, but a trial is a licensing question rather than a TCP configuration fix. License availability can change; obtain current terms from Kawasaki or its distributor.

TCP endpoint roles and diagnostic values

Draw the connection as client to listening server before entering commands. For a client test, Hercules can act as the server and listen while the K-ROSET program connects. For a server test, K-ROSET executes a program that listens and accepts while Hercules runs as the TCP client. Both sides must use the same application port. The client also needs the server address appropriate to the simulator topology.

A connected socket is only a transport path. It does not define the application message. The PLC and robot program must agree on the ASCII strings or fields to exchange and on how each message ends or is delimited. In K-ROSET, Hercules can exercise that logic, but it does not replace writing and executing a robot program that sends or receives the messages.

Tool-arrow TCP correction through the controller

Use the terminal workaround when Lite accepts a Tool Arrow model but the desired TCP position cannot be represented by moving that model. The synchronization direction matters: copy project settings to the controller before issuing the tool command, then copy the controller settings back into K-ROSET so the project reflects the changed tool data.

1. Create the project and add the required robot.
2. Synchronize K-ROSET to Controller with controller settings selected.
3. Open the Terminal Window and enter the tool commands. The reported example is:

   QTOOL OFF
   TOOL NULL+TRANS(0,0,128.6,0,0,0)

4. Synchronize Controller to K-ROSET with controller settings selected.
5. Save the project, close it, and reopen it to check that the coordinate persists.

The example positions the Tool Arrow at the specified coordinate; it does not configure a freely movable model. If a tool change is part of the workflow, synchronize Controller to K-ROSET again after adjusting the tool in the terminal. Keep the tool definition, visual model, and project copy aligned so the displayed geometry does not imply a TCP that the controller is not using.

TCP client tests against Hercules

Use Hercules as a listening server when K-ROSET runs the client program. This is the simpler path for checking a client connection because the server's listening state is visible in Hercules. A client may bind or allocate a socket before a peer is ready, so a lack of connection is not proof that the program never created a socket.

1. Choose an application port that is not the K-ROSET terminal editor port.
2. Set Hercules to server mode on that port and start listening before K-ROSET attempts to connect.
3. In the K-ROSET client program, use the server address and the same port. The reported command form is TCP_CONNECT; use the Kawasaki manual for the exact argument types and syntax for the installed controller configuration.
4. Check the connection result and socket ID before entering the receive or send path. Use TCP STATUS when you need to refresh the reported state.
5. Send a known ASCII test message from Hercules, then check that the K-ROSET receive code reads and decodes it. Test the response direction separately if the application requires robot-to-PLC data.
6. On normal exit and error exit, close the socket. After an aborted program, run the project's socket-cleanup routine or otherwise close the old socket before trying to create another one.

The reported K-ROSET tests used 127.0.0.1 for local testing. That address is useful when both endpoints run on the same PC, but it is not the address of a PLC on another computer. For a remote PLC test, use the server's reachable address and check host firewall rules for both K-ROSET and Hercules. A successful local loopback test validates the program exchange on that PC; it does not validate the plant network path.

TCP server tests and socket ownership

Use this direction when K-ROSET must listen for the PLC, or when Hercules is standing in for the PLC client. Start the K-ROSET server program and make it listen before Hercules connects. The accepted connection belongs to that server task until the program closes it; subsequent client attempts can fail if an earlier test left the socket open after an abort.

1. Configure the K-ROSET program to open the server socket and listen on the chosen application port using the syntax in the Kawasaki TCP/IP manual.
2. Configure Hercules as a TCP client for the same server address and port, then connect only after the K-ROSET listener is running.
3. Check the accepted socket ID and peer information before receiving data. Read the received string and compare it to a known test message.
4. Close the accepted connection and listening socket according to the program's design before a new test. Add cleanup to error paths so a fault does not leave a socket owned by an abandoned task.

A reported Hercules connection to 127.0.0.1 on 9105 displayed login: because that port reaches the terminal editor. The terminal login response is not a TCP application exchange. Move the application test to a separate port; do not treat the terminal prompt as a successful PLC message test.

PC-task routing for robot motion

Kawasaki program execution separates motion instructions from process-control logic. A PC program can handle TCP messages and make decisions, but it cannot execute a motion instruction directly. The same restriction applies to a called subroutine that contains a motion instruction. The reported error for that case was E1095, “Cannot execute motion instruction in PC program.”

Keep motion in the main motion program and use the PC task to request an allowed main-program operation. The reported monitor-command forms include PRIME at the command prompt and MC PRIME inside a PC program; other described PC-task requests include MC EXECUTE, MC CONTINUE, MC HOLD, MC KILL, and MC ABORT. The prefix is the distinction between issuing a monitor command at the terminal and invoking the command from PC logic. Confirm supported forms in the AS Manual for the target controller.

For message handling, compare received ASCII command strings against a defined set of permitted actions. The reported examples used IF logic, and the user also tested CASE logic; both can select a motion request. Use $DECODE when a received string contains fields that must be parsed into variables. Do not treat arbitrary received text as a motion command: map only expected messages to a bounded motion program and preserve the machine's safety and interlock design.

Motor power is a separate condition from TCP connectivity. The terminal command examples use ZPOWER ON and ZPOWER OFF, with MC ZPOWER ON or MC ZPOWER OFF from a PC program. A test can prove message reception while motion remains unavailable because the robot is not enabled or because the main program was not primed or executed. Keep those states separate during diagnosis.

Also distinguish a monitor command from a program instruction. SETHOME typed alone at the terminal can display home values and prompt for input; used as an instruction inside a program, it does not open that interactive terminal prompt. The same distinction applies to commands such as POINT and HERE. A missing prompt inside a running program is therefore not evidence that TCP data was lost.

TCP state and motion verification in K-ROSET

Verify one layer at a time. First establish that the expected endpoint is listening. Next confirm the K-ROSET connection result and nonzero usable socket ID, then send one known message and confirm the received bytes or decoded value. Only after those steps pass should the PC task request motion. This sequence separates network failure from message parsing and robot execution.

• Listener check: Confirm Hercules is in the intended server/client role and is actively listening when the other endpoint connects.
• Endpoint check: Compare the destination address and port in the program with the Hercules configuration. A matching number alone is insufficient if the program points to the wrong host.
• Socket check: Inspect the connection result, socket ID, and refreshed TCP STATUS. If a program aborts, close the old socket before retesting.
• Payload check: Send a known ASCII value and confirm the program receives the same content before adding command decoding.
• Motion check: Confirm that the PC task routes to a main motion program and that the requested operation is permitted by the controller's state. A TCP receive does not prove that motion executed.
• Persistence check: For a tool coordinate, save and reopen the project after synchronizing Controller to K-ROSET.

When a workstation simulates both endpoints, 127.0.0.1 keeps the test local. When TwinCAT or a PLC runs on a separate system, switch to the correct reachable address and test through the same network path used by that endpoint. Allow the required applications through the PC firewall. If a test works locally but fails remotely, investigate addressing, routing, firewall policy, and the listening interface before changing robot motion logic.

Recurring K-ROSET TCP and licensing failures

The unexplained periodic accept behavior was reproduced with a D/D+ controller configuration in K-ROSET and did not appear in the reported E configuration with a ZX165U. That observation does not identify a Windows service or prove a license cause. If the accept record lacks the expected socket ID or peer address, preserve the log and repeat with a controlled configuration rather than treating each accept as a valid Hercules session. The controller configuration and the displayed socket details are the deciding evidence.

The Lite restrictions reported for tool/model operations should not be used to explain that socket anomaly. Likewise, the TCP/IP code's ability to run in Lite does not imply that every simulated controller profile accurately reproduces a live controller's network behavior. Use K-ROSET to test message sequencing, parsing, and program flow, then separately validate the final endpoint and controller behavior on the intended hardware.

Frequently asked K-ROSET Lite questions