One issue that arises with this workflow is that Ignition does not always immediately detect file changes made outside the Designer. After checking out a branch, merging changes, or pulling updates, the gateway will still need a manual file scan from the Gateway before the latest project or configuration files are reflected.

To make development workflows smoother for our projects at DMC, we created a script that uses the Ignition 8.3 Gateway API endpoints to trigger project and configuration file scans. By integrating this script into Git hooks, file scans can run automatically after branch checkouts or merges, eliminating the need to manually navigate to the Gateway webpage and trigger them each time (fig1 and fig2). Additionally, developers can manually run the script from Bash or the command line to trigger file scans on demand.

In this blog, we have provided a sample script and .env file, and we will walk you through the steps to set this up.

Why This Step Matters

There are a variety of reasons why automating this step is both important and beneficial. This automation reduces friction in the development workflow, reducing some of the common sources of errors and delays while improving team-wide consistency and clarity. By using Git hooks to automate file syncing in Ignition, developers avoid repeated trips to the Gateway UI and reduce mental load.

By adding automated file scans into the development workflow, teams can make Ignition 8.3 development feel more like regular software development, where Git-based practices like branching, merging, and pull requests fit naturally into SCADA projects.

Set Up Gateway API Key

In order to access the API endpoint, we need to set up an API key in the Gateway. Follow Ignition’s manual for this.

By default, Ignition requires API keys to be used over secure HTTPS connections. Since this script commonly runs against local development Gateways using standard HTTP, the Require secure connections for API Keys setting must be disabled for the requests to succeed.

Make sure to copy the ENTIRE api key. We will add it to the .env file in the next section.

Repo and Environment Variables Set Up

Copy the example script (included in the section below) into your desired location in your repo. For example, in this repo, we have put it at the following location and called it gateway_scan.py.

Path: ignition-docker-8-3\scripts\gateway_scan

Next, add the following variables to your .env file:

GATEWAY_IP= (your gateway’s IP address)
HTTP_PORT = (your gateway’s port)
GATEWAY_API_TOKEN=(your generated API token for the gateway)

The example script looks for these variables; if they are already in your .env and are named differently, open the example script and do a find-and-replace to update the variable names.

Git Hook Set Up

Git hooks let us automatically run scripts when certain Git actions occur. For this workflow, we typically set up Git hooks to run the gateway_scan.py script after branch checkouts and merges.

This means that when a developer switches branches, pulls changes, or merges updates, the Gateway file scan can run automatically without having to open the Gateway webpage and manually trigger it.

To set this up, create two files in the .git/hooks folder:

.git/hooks/post-checkout
.git/hooks/post-merge

Paste the following code into both files:

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

The post-checkout hook runs after switching branches. The post-merge hook runs after a merge, which also commonly happens when pulling new changes from the remote repository.

The first command moves the terminal to the root of the Git repository. This helps ensure the script runs from the correct location, even if Git triggers the hook from within the repository.

The second command runs the Gateway scan script:

py scripts/gateway_scan/gateway_scan.py

Developers can also run this command manually from Bash or the command line whenever they want to trigger a Gateway file scan on demand.

If the repository contains multiple gateways you want to automatically file scan for, add a separate set of environment variables for each gateway in the .env file, create an API key for each gateway, and then update the gateway_scan.py script following the comments, so the script knows which gateways to scan.

Example Script & env. File

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f""

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f"http://{ip}:{port}/data/api/v1/scan/{action}"

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

Conclusion

Automating file syncs in Ignition 8.3 is a simple configuration change that can deliver meaningful improvements to your development workflow. By reducing manual steps and ensuring the Gateway always reflects the latest project state, teams can work more efficiently and with greater confidence. For engineers using Git to manage their Ignition projects, this approach unlocks the full benefits of modern version control while keeping SCADA development reliable and consistent.

The post Triggering Gateway File Syncs for Ignition 8.3 Using Git Hooks appeared first on DMC, Inc..

In a recent Ignition 8.3 project, we had two gateways in a single Git repository that needed to share library elements. While 8.3 enables a more Git-centric workflow, it does not provide a built-in mechanism to keep shared resources synchronized across multiple gateways. Without an automatic way to manage this, shared libraries can quickly drift and become difficult to maintain.

We addressed this by creating symbolic links from each gateway’s library folders to a shared “source of truth” directory. A symbolic link (symlink) is a special file that points to another file or folder—like a shortcut at the filesystem level. When you access it, the system transparently redirects you to the target location. This approach allows both gateways to reference the same underlying files while still fitting cleanly into a Git-based workflow, making it a simple, low-friction way to keep shared resources consistent.

This blog walks through how to set up shared libraries between two Ignition gateways in a single Git repository using symlinks on Windows, helping you avoid duplication and keep shared code synchronized in one place.

With this setup, any time a symlinked file is modified in a Designer and saved, it’s immediately overwritten in the shared “source of truth” location. After changes are made and tested in one gateway project’s Designer, the files can be committed and pushed to the repo as usual.

We’ll walk through setting up a shared script library folder as an example. You can use the same pattern to share views, styles, and additional files as needed for your project.

What are Symbolic Links?

A symbolic link, often referred to as a symlink, is a reference point in a filesystem that points one file or folder to another location. Instead of duplicating the files, a symlink acts as a pointer. When an application accesses the symlinked path, the operating system (OS) redirects it to the target destination.

In Ignition 8.3, a symlinked folder behaves exactly like a project directory. Associated scripts, views, and resources load as one would expect; however, the actual files live somewhere else in the filesystem.

Sample Repository Structure

Here is a visual representation of what the structure would look like after the symlinks are set up. The file structure for gateway1 and gateway2 down to script-python is default to ignition. You will have to create the “shared” folder location and structure manually in your repo, and you can organize it anyway you want.

repo/
└── gateways/
   ├── shared/
   │   └── script-python/
   │       └── library/ (real files live here for this example)
   │
   ├── gateway1/
   │   └── projects/
   │       └── project1/
   │           └── ignition/
   │               └── script-python/
   │                   └── library/ -> symlink to ../../../../../shared/script-python/library
   │
   └── gateway2/
       └── projects/
           └── project2/
               └── ignition/
                   └── script-python/
                       └── library/ -> symlink to ../../../../../shared/script-python/library

Setup Steps for Windows

Before creating any symbolic links, complete the following one-time setup steps. Every developer working with this repository must perform these steps on their local machine. Skipping them can result in broken links when the repo is cloned or checked out.

Prerequisites

1. Enable Git symlink support

By default, Git on Windows may treat symlinks as plain text files. This setting ensures symlinks are created and checked out correctly.

Run the following command in Git Bash:

git config --global core.symlinks true

git config --global core.symlinks true

2. Enable Windows Developer Mode

Developer Mode allows non-admin users to create symbolic links without permission-related issues.

Settings > Privacy & Security > For Developers > Developer Mode

Turn Developer Mode on.

3. Restart your computer

Restarting your computer ensures Developer Mode is fully applied before creating symlinks.

Initial Creation of Symbolic Links

Follow the steps below to set up the initial symlinks for the script-python library folder in our example. The same approach can be used for other shared resources.

Gateway 1:

1. Open Command Prompt as an Administrator

2. Navigate to the target directory for your symbolic links

Move to the directory where the symlink will live in Gateway 1: cd gateways\gateway1\projects\project1\ignition\script-python

3. Move any existing library files:

If you already have files in the library folder and/or the library folder exists, move the entire library folder to the shared directory at gateways/shared/script-python. If not, skip this step.

If you leave the library folder here: \gateways\gateway1\projects\project1\ignition\script-python. The following error will occur because Windows cannot create a link where a directory already exists:

4. Create the symbolic link

Run the command below to create the symlink linked to the actual files in the shared location:

mklink /D library ……….\shared\script-python\library

5. Verify the symlink was created successfully

Verify the link has been created by running the command dir at the symlink location in the command prompt. If the symlink was created correctly, then you should see it in your output.

In addition, you can visually verify that the folder was created correctly in File Explorer by looking for the arrow icon in the bottom left. When you double-click into this symlinked folder, it will take you to the location it is linked to.

Gateway 2

Repeat the same steps for Gateway 2, adjusting the path as needed:

cd gateways\gateway2\projects\project2\ignition\script-python

Create the symlink pointing to the same library location.

Once both gateways are linked, the shared library folder is ready for use. Any changes made through one gateway’s Ignition Designer will be written directly to the shared directory and can be committed to Git as usual.

Ignition Designer/Gateway Refresh and Test

After creating the symbolic links, the final step is to confirm that Ignition detects and uses the shared files properly. Because Ignition doesn’t automatically reload filesystem changes, users must manually initiate file and project scans to update each gateway.

1. Close all open Ignition Designer sessions

Closing active sessions of Designer resolves any potential validation interference caused by cached projects.

2. Trigger file and project scans on both Gateways

On each gateway, run the following:

• Platform → Overview → Scan File System
• Platform → System → Projects → Scan Projects

3. Open Ignition Designer for Gateway 1

• Create a new script or modify an existing script in the share library.
• Save the changes.

4. Refresh Gateway 2

• From the Gateway 2 web UI, trigger both the file system scan and project scan again.

5. Open Ignition Developer for Gateway 2

• Open Ignition Developer for the second Gateway and verify that the adjustments are present.

Now the library symlinks are set up and ready for use. If the changes appear as expected, the symbolic link configuration is working correctly, and both gateways are pulling from the same shared source of truth. Once validated, follow your project’s specific git workflow to push these changes to your repository.

Final Thoughts and Best Practices

It’s important to keep in mind that whenever a file in the gateway filesystem is changed, the gateway doesn’t automatically update to reflect those changes. You will need to perform two file scans for the latest changes to be reflected. The screenshots below show where to trigger these scans.

At some point during testing, you may need to view/test a library file in both gateways. In this scenario, it is important to regularly perform the above file and project scans, as changes are being made and saved. Below is an example of a possible order of operations:

1. Make changes to library file in Gateway 1 project designer.
2. Save changes to library file in Gateway 1 project designer.
3. Open Gateway 2 webpage UI.
4. Press Scan File System on both Platform > Overview page and Platform > System > Projects page for Gateway 2.
5. Open a fresh designer session of Gateway 2’s project to view latest changes.

Keep in mind that if changes are made in both gateways to the same library object, the last place it was saved will be the effective, latest state of the file. In the above example, if a change is made in Gateway 2’s project designer session and saved there, Gateway 1 would have stale library files internally, requiring file scans to refresh them.

To avoid accidentally overwriting changes, the best practice is to separate work into separate commits and modify a given shared file from only one gateway at a time.

Finally, make sure the other developers run through the setup steps on their machines to avoid accidentally breaking any symbolic links during initial setup.

The post Setting Up Symbolic Links for Shared Project Libraries Across Ignition 8.3 Gateways appeared first on DMC, Inc..

1. How to set up retained memory for local labels, global labels with no device assignment, and global labels with device assignment 

2. Adjusting the allotted device memory if you run out of a certain type of device memory 

3. Minimizing program memory 

Retained Memory

It is straightforward to set non-device assigned labels such as local labels within a program or a global label that doesn’t have a device assignment to retain memory. Locate the label and within the class drop down select ‘VAR_RETAIN’ or ‘VAR_GLOBAL_RETAIN’ as shown below for the two types of labels.  

It takes a couple of extra steps to set a device assigned global label to retain. After you have decided on which device you want to use to assign to your label, you can assign the device to the label as normal, then select ‘VAR_GLOBAL_RETAIN.’

In the example below, I have assigned a trend array to a device section starting at D12000 up to D12399.  

Next, the D memory registers D12000-D12399 must be designated as retain memory in the ‘Device/Label Memory Area Detailed Setting’ area. To navigate here using the navigation tree, double-click on ‘Parameter’ -> ‘CPU Parameter’ -> ‘Memory/Device Setting’ -> ‘Device/Label Memory Area Setting’ -> ‘<Detailed Settings>.’ 

This will display the window shown below.

From here, double-click on any of the cells circled in the screenshot above. This will open the Latch Range Setting, where we will set what memory registers should be retained or latched.  

Here, we can see that I have a couple of ranges set for both M and D registers including the range D12000-D12999 to include the trend array from our example. After you have set the ranges you need for your project, press ‘OK’ and then you are done.  

Note, if you assign global labels that are not set to retain registers you defined in the Latch Range Setting or vice versa, you will receive a compile error reminding you to correct this.

Adjusting Device Memory Allotment Size

Depending on the size of your PLC memory and the size of your project, there are times when you might run out of a particular device type. In this situation, if you are unable to upgrade your PLC memory, you can attempt to reallocate your device types if there are some device memory types that you are not using.  

To do this, navigate to the Device/Label Memory Area Setting Detail Settings screen as mentioned in the section above. Starting in the navigation tree, double-click on ‘Parameter’ -> ‘CPU Parameter’ -> ‘Memory/Device Setting’ -> ‘Device/Label Memory Area Setting’ -> ‘<Detailed Settings>.’ 

Under the Device/Points column is where you can see the amount of points allocated to a given device. For example, for the D device, there are 20k points allocated which means the range of usable D devices spans from D0 – D20000. You can modify these allocations as needed as long as the total adds up to the ‘Total Device’ at the bottom as that is the limit of the PLC. After you are done, click on the ‘Check’ button at the bottom to verify that your new allocations are ok.  

Minimizing Program Memory

The screenshot above was from a previous Mitsubishi GxWorks3 PLC project where we almost ran out of program memory. Since upgrading the PLC memory was not an option, we had to consider other ways to save memory.  

For this project, we were programming from scratch and adhering to DMC’s best practices by using named Global Labels and UDTs for maximum code clarity and ease of maintenance. However, we discovered that moving data directly between UDTs using its symbolic name used a lot of program memory compared to directly manipulating the data using its device memory address. In the screenshots below you can see the massive difference in program steps used between using the symbolic name vs. the direct device address in rung 17.  

Due to the project hardware constraints, we had to sacrifice some code readability to fit the entire program within the allotted memory available. We used the instructions, BMOV (Transferring 16 – bit block data) and BLKMOV (Transferring n-bit data) on some of the bigger data transfers to help us achieve this. In the end, we were able to fit our program onto the PLC.  

I hope that you find these tips for setting up retained memory, adjusting the allotted device memory, and minimizing program memory helpful when working with GxWorks3. 

The post Memory Manipulation Tips For Mitsubishi PLCs using GxWorks3  appeared first on DMC, Inc..

If your current automation project requires the use of the Yamaha RCX-Studio 2020 software for the RCX3 Series controllers, this guide is designed to minimize your ramp-up time. This blog assumes you have a general understanding of robot programming and Robot-PLC integration knowledge. It is not designed to be a comprehensive guide on robot programming or to go through every single feature of Yamaha robots. We will cover the essential topics: connecting to the controller, defining IO, defining/teaching points, building a basic routine, and jogging so you can quickly move to development and commissioning your robot program.  

Important

RCX-Studio 2020 is free to download. However, to create, save, archive, and deploy custom programs to a controller, you will need a USB license dongle directly plugged into your PC.  

This link from Yamaha’s website includes the download link for RCX-Studio and information on the USB license dongle.

Starting a Project (File Structure Overview)

This is the initial screen upon opening up the software.  

The files under the folder ‘Controller’ are unarchived robot files. When opened, these can be used directly to go online with the robot controller and jog and monitor the robot. The files under the folder ‘File’ with the .all extension are archived files and are generally used for source control. These files require a USB license key to open and edit. You can’t go online with the robot controller and jog/monitor the robot with an .all file but you can view the program contents.  

Starting With No Reference File/Backing up From Controller

If starting from scratch, create a new Controller file by double-clicking on ‘New Controller.’ The following window will appear. 

Give your new controller a name. Then, you can select between starting in offline mode or online mode. To work offline with no existing robot program, you can either select a robot model number to add or start with a file with no existing robot if you just want to work on development and do not have an exact model number yet.  

To start in online mode, you need to be physically connected to a controller either by Ethernet cable or RS232 cable. You will need either the IP address or the RS232C connection information for the controller. You can pull all the data currently on the controller with this method.   

Working With a .All File

To convert an archived .all file to a regular robot program file, click on ‘Tool’ in the tool ribbon, then in the drop-down menu, click on ‘Data Transfer…’ 

Next, in the source file section of the window, select ‘File’ and browse for the location of your .all file. Then, make sure all the data is checked in the ‘Transfer Data’ area, and make sure the boxes directly below are all unchecked.  

Specifically, if you are looking to download the file back onto the existing robot after making programming changes, DO NOT SKIP the ‘Robot Specific Parameters’ as these include encoder hardware information and other hardware setup information important to the specific robot, which are set up at the factory. In almost all cases, you would want to transfer all the data. Otherwise, there is a risk of OVERWRITING this data on the controller when you download your updated program file to the controller if you didn’t originally transfer it to the controller file.  

After that, select a blank controller file that you want to put the data in or create a new controller file to store the data, then press ‘OK’.  

Program Overview

For the remainder of this guide, we will review programming and commissioning with the controller file interface. Here is a general overview of the important components of the controller file UI. 

Next, we will shift our focus to the ‘Window Tree’. Through the window tree, you can navigate to all the main functions needed for programming and commissioning the robot. We will go through a couple of important items here to get you started. 

Operation Folder

This folder includes the following items: Servo, Origin(All), Origin(Selected Robot), Jog, and Point Trace, which are all important for initial commissioning. 

Servo

Double-clicking on ‘Servo’ brings up the following window.  

Here you can manually turn on and off motor power and free servos for each individual axis. This can be useful if you need to turn off power to manually move the robot by hand during commissioning.  

Origin(All) and Origin(Selected Robot)

Sending a robot to origin will command the robot to move to the origin position of the encoder set at the factory and not a custom user “home” location. This does not need to be done regularly. It only needs to be done if the servos lose track of their current position.  

Typically, controllers will come with special batteries installed to ensure these positions are always remembered, even when the main power supply is off. Since these are factory settings, when there is a need to send the robot to origin, be aware of any objects surrounding the robot to prevent collisions, as it will move each axis directly to the origin location, disregarding any programmed moves.  

Jog

The jog window is key for teaching positions and commissioning. Here you can select between three jog modes in the ‘Unit’ drop-down: ‘pulse’, ‘mm,’ and ‘tool’, and the buttons will change accordingly to those options. The ‘mm’ setting is millimeters in Cartesian coordinates and is the simplest one to use for general jogging purposes. You can adjust the jogging speed in percentage units and the jogging distance with the ‘Inch Dist.’ field. After changing the value, press “set” to apply it. If it hasn’t been set, the value will be highlighted red.   

Point Trace

The point trace window is used for verifying motions between points that are safe and optimizing robot pathing. Here you can select the type of move (linear, arc, joint), the movement speed, and the point number you want to move to. You can also only move selected joints to a particular point. Press “Trace” to start moving to the current selected point.  

Program Folder

This is where your main robot program and subroutine/functions will live.

Double-click ‘New Program’ to create a new program. You can choose from starting with an empty file or one of the templates included. The paper icon with the ‘M’ indicates that it is your main program and will begin executing when you start the robot. To adjust the main program, right-click on the program you want to change to the main and click ‘Setting Main Program’. 

Below is the programming window for a given program. Here you can start, stop, and step through your program. You can also reset the program and have it execute again from the top. When online, clicking on the yellow ‘Exec Line’ button will toggle the view to follow which line is currently being executed.  

For specific programming syntax information, refer to the Programming Manual. The remaining items in the program folder are not essential to review in a quick start guide, so we will move on.  

Coordinate System Folder

This is where your point definitions are stored. Double-click on ‘Point’ to bring up the Point window.

In RCX-Studio, points can be referenced in the program as the point number, ex. P5, or their Name, ex. ‘NavHome’. Refer to the manual mentioned in the programming section for the exact syntax.

The Point window is also where you can teach and modify points manually. To teach a point, move the robot to the point you’d like to teach and then click on a point number where you would like to save the data and press ‘Teach(mm)’ to teach with Cartesian data or ‘Teach(pls)’ with encoder pulse data. You can manually modify any saved point by clicking on the cell with data you’d like to modify, changing the data, and then pressing ‘Enter’ on your keyboard. You can also add any additional helpful comments in the ‘Comment’ column.  

The remaining items in the Coordinate System folder are not essential to review in a quick start guide, so we will move on.   

Parameter Folder

The parameter folder holds robot-specific hardware settings and general settings related to the specific selected robot.  

These are the ‘Robot Specific Parameters’ mentioned earlier in the guide to not skip during the data transfer.  

In the Controller window, note that there are some execution and program settings that you can modify. Click on them to display their descriptions.  

You can view which option communication boards are installed in your controller to communicate with the PLC. Locate them in the Board Enable/Parameter windows under the Option drop-down. 

System Folder

The system folder includes a couple of troubleshooting items that are helpful during commissioning, including ‘Warning History’ and ‘Alarm History’. You can also click on ‘System Check’ to see if the overall system is ok.  

Monitor Folder

This folder is very important for commissioning, as it contains access to all monitoring windows for the robot’s current position and the controller IO. We will only focus on the main ones DI, DO, SI, SO, SIW, and SOW. We will also review a couple of significant IO points in this section.  

Current Position

Clicking on ‘Current Position’ will open the current position window, where you can view the robot’s current position in Cartesian coordinates and encoder pulse values.  

DI/DO

These windows show the current state and available digital inputs and outputs going to the controller. A bright green LED means it is on/true, and a dark green LED means it is off/false.

Within a program, you can reference these points using the system name (e.g., DO0(0)) or a user-given name if allowed.  

SI/SO

These are IO points coming over Ethernet or other communication protocols based on the optional communication boards installed in your controller. These are typically used to communicate with the PLC.  

Here is the default list of SI: 

The first 16 bits are reserved and have a dedicated purpose based on their comments. A couple of important ones include the following:  

• SI0(0) – E-Stop input for the robot, ON= E-Stop OK 
• SI0(1) – Command to turn on robot servos 
• SI0(6) – Stop robot program execution, OFF = Stop Active, ON = Stop Inactive 
• SI1(2) – Start automatic robot program execution 
• SI1(5) – Resets the robot program and forces it to execute from the first line (useful for recovery during handshakes) 
• SI1(6) – Robot controller alarm reset for any controller alarms 

The remaining can be named and used for custom functionality.  

Here is the default list of SO: 

The first 16 bits are reserved and are used to report a status based on their comments. The remaining can be named and used for custom functionality.  

SIW/SOW

These are registers used to send words between the robot controller and the PLC. These cannot be renamed by the user. You can display their values in Hex or Dec with the radio buttons at the top. You can reference these IO in the robot program using their system name (e.g., SIW(0), SIW(4)). You can find more information on programming syntax in the programming manual linked above in the Programming Folder section.  

The post A Quick Start Guide to Robot Programming with RCX-Studio 2020 appeared first on DMC, Inc..

Siemens TIA Portal V18 and WinCC Unified offer effective solutions for setting up user logins, increasing the safety of your operations as a result. In this guide, we’ll walk you through the process of adding local users, runtime rights, and protecting your HMI features in a few simple steps.

Setting Up Users and Rights

The first step is to set up the user profiles for your project. You can set specific rules for password complexity under ‘Security settings’ > ‘Settings.’

Next, navigate to ‘Security settings’ and then to ‘Users and roles.’

In the ‘Users’ tab you can create a new local user profile. To do this, you will need to click on ‘<Add New User>’ and then ‘Add new local user.’ Next, you can enter in a ‘User name’ and ‘Password.’ Here you can also define a timeout, which will automatically log the user out after a certain amount of time. This is also where you will assign roles to each listed user, but we’ll return to this after setting up some roles.

Assigning Roles 

Next, let’s go over ‘Roles’ and ‘Rights.’ Each role is comprised of a set of selected rights. ‘Runtime rights’ are what we will reference while programming protected or user restricted features on the HMI.

To create and name your own custom rights, navigate to the ‘Roles’ tab and then to the ‘User-specific runtime rights.’ Here you can create new rights with custom names and descriptions.

As an example, I have created 4 levels of rights and users as shown above: ‘Admin,’ ‘Maintenance,’ ’Technician,’ and ‘Operator.’ Admin will have the highest level of rights, followed by Maintenance, then Technician, and finally Operator with the lowest level of rights.

To set up the roles for our example setup, return to the ‘Runtime rights’ tab, and then click on ‘Operator’ in the Roles window. This screen will show the HMIs and PLCs available in the project.

For this example, we will set up the runtime rights for the WinCC Unified SCADA device by clicking on the drop down, selecting the device, and then selecting the custom runtime right we created earlier: ‘Operator Rights.’ Since ‘Operator’ has the lowest level of rights, we will only check ‘Operator Rights’ for the ‘Operator’ role.

For the other 3 roles, we will assign the rights as shown below:

Technician – Operator Rights, Technician Rights

Maintenance – Operator Rights, Technician Rights, Maintenance Rights

Admin – Operator Rights, Technician Rights, Maintenance Rights, Admin Rights

When set up this way, a feature that needs to be protected by a user login can be sorted according to the permission hierarchy rules we defined earlier.

The ‘Admin’ user can access anything protected by one of our custom rights, but the ‘Operator’ user can only access those protected by ‘Operator Rights.’ There are many other system defined rights available in which you can also assign to your custom roles if needed.

Creating User-Restricted HMI Features

Next, we will go through how to reference these roles while programming protected features on the HMI. In the example below, we want to restrict the ability to interact with the I/O Field to the Admin user. Navigate to the ‘Security’ dropdown and select ‘Admin Rights’ for the Authorization field.

This will limit interaction with this IO Field to the Admin user only. If you wanted a different level of access, you could choose from any of the other rights available to tailor the access to your needs. This setting is available for most other objects available in WinCC Unified. For anything that you want to restrict with a user login, you can set an Authorization level here.

Downloading User information to HMI

After you’ve made user or role changes it is important to set the dropdown below to ‘Reset to start values.’ This ensures that your changes get updated in runtime.

That’s it! Your basic user login setup is complete. By following the steps outlined in this guide, you can establish user authentication mechanisms tailored to your equipment’s requirements.

The post Setting Up Basic User Profiles and Login for WinCC Unified Runtime appeared first on DMC, Inc..

Ignition offers native support for Mitsubishi devices through its new Mitsubishi TCP Driver, allowing direct communication between the PLC and the SCADA system. Ignition has a published guide for setting up connection from the Ignition side. 

In this blog we will focus on the configuration of a Mitsubishi PLC project in Gx Works3 to connect to an Ignition server as well as some basic troubleshooting tips. Additionally, we will go over the concept of a useful tool DMC developed DMC to quickly convert assigned labels within global label lists to Ignition addresses in a .csv file and that can be directly imported into the Ignition Gateway. 

Configuring a Mitsubishi PLC for Connecting With Ignition:

After you’ve added your PLC to a Gx Works3 project, navigate to the Module Parameter of your PLC. 

In the “Own Node Settings,” first make sure your PLC is on the same network as your Ignition Gateway, and then make the following changes:

1. Enable/Disable Online Change > Enable All (SLMP)
2. Communication Data Code > Binary

Then press “Apply” at the bottom right corner. 

Next, double click on the “<Detailed Settings>.”

A new window will pop-up labeled “Ethernet Configuration.” Navigate to the right of the window and click on “Ethernet Device (General).” Next, click and drag a “SLMP Connection Module” to the table portion of the window. A new SLMP Connection Module will be added. 

Set the Protocol to “TCP” and then set the Port Number to the same port number that was chosen in the Ignition Mitsubishi Driver. 

Press “Close with Reflecting the Setting” at tool bar located at the top of the window. Finally, write the new configuration changes to the PLC and do a power cycle.

Troubleshooting Connection Issues: 

In the tool bar at the top, navigate to “Diagnostics” > “Ethernet Diagnostics” to troubleshoot any connection issues. Here you can see any error codes or statuses. You need to be connected to the PLC to use this. 

Converting Gx Works3 Global Label Lists to Ignition Addresses: 

Quick reminder that, for your tags to be seen by your Ignition project, they need to have device assignments. Here is an example where the labels are assigned to D devices: 

For the Ignition side, you can find the formatting for these addresses in the “Determining Addresses” section in the Ignition document linked at the top of this blog.

If your project has a lot of tags, it can be worthwhile to create an automated script/program to convert the label list exports from Gx Works3 to Ignition addresses and compile them into one .csv file to import into the Mitsubishi driver on the Ignition gateway. This will be much faster than manually adding in one tag at a time. 

You can choose to use one .csv file to keep track of all your PLC tags or append new .csv files each time you add new tags. 

On a recent DMC project, we designed a Python tool to help us automate this task. Our Python tool would read the exported .xml files from Gx Works3, pull out the tag names, data types, and assigned device numbers, and then use that information to construct the Ignition addresses. 

Our tool was custom made for a particular project, but here is the overall workflow for our tool for guidance if you are looking to create your own:

1. Right click on HMI tag lists from Gx Works3 project and export as XML.

2 . Move them into the designated folder where our Python script is accessing unprocessed tag lists.

3. Run Python script.

4. Grab converted .csv file and import (without appending) into Mitsubishi Driver in Ignition gateway.

5. Repeat process if new tags/lists were added to the unprocessed tag folder.

In this project, we changed the mapping for our tags often during development due to changing scope/issues we were encountering. It was beneficial for us to re-run our Python conversion script on all the .xml HMI tag list files and import a new converted .csv file each time instead of appending an additional file. It was easier to keep track of changes and to update any tag mappings that might have changed as we just needed to export and overwrite the same tag list in the unprocessed tag list folder. 

The post Integrating Mitsubishi GX Works3 with Ignition Using the Ignition Mitsubishi TCP Driver appeared first on DMC, Inc..

If you’ve chosen GX Works3 as your development environment, you’re in for a treat. In this blog, we’ll guide you through the initial steps of starting a project in GX Works3, from installation to writing your first program, setting you on the path to automation success!

Table of Contents:

1. Installation
2. Importing CSP/CSPP Files for Devices
3. Creating a New Project
4. Navigating the Interface
5. Hardware Configuration
6. Writing Your First Program
7. Simulation and Debugging
8. Final Thoughts

1. Installation

Back to Table of Contents

System Requirements

Before installing GX Works3, make sure that your system meets the following requirements:

• Windows 7 or later
• At least 2 GB RAM
• 5 GB of free disk space

Before you can dive into creating a project, ensure that GX Works3 is installed on your system. Follow the installation wizard’s prompts and, once complete, launch the software.

2. Importing CSP/CSPP Files for Devices

Back to Table of Contents

CSP/CSPP files are the Mitsubishi equivalent of ‘EDS’ files (like in Rockwell). These files are usually provided on the device manufacturers website.

Open GX Works3. Do not open a project. If you have a project open, you must close it.

In the top menu bar, click “Tool,” then “Profile Management,” and then “Register.” Select the files you want to import and then “Register.”

3. Creating a New Project

Back to Table of Contents

Steps to Create a New Project

Click on “File” and then “New Project,” or on the icon circled below:

Choose the type and series of PLC you’re using. In our project we used an R08SF. Most of the programming will be done in ladder, so leave the Program Language as “Ladder.”

Name your project and select a storage location.

Click “Finish.”

Next, you will be prompted to set up a new user.

You will need to re-enter your chosen username and password every time you open the program and when you go online with the PLC to read or write for the first time in an online session, so choose your username and password wisely.

Note: You can go back to change this later if needed.

After this, you will be prompted to name your project. Then, your new project will open.

4. Navigating the Interface

Back to Table of Contents

Here are some important areas of the GX Works3 interface:

Navigation

This is where you’ll find all the elements related to your project such as programs, function blocks, devices, labels (AKA Tags), and parameters (for hardware configuration).

Workspace

This is where you’ll write and edit your code

Output Window

This window shows the output of compile-time or run-time actions. There are some other tabs here that are helpful for online debugging, but we will look at those later on.

5. Hardware Configuration

Back to Table of Contents

Adding Devices and Modules

To add devices and modules:

Right-click on the “Module Information” under Parameter in the Navigation.

Next, select “Add Module,” and choose the specific device or module you’re working with.

It is ok to leave “Start I/O No. Specification” as “Not Set” if you want GX Works3 to handle assigning these values automatically based on slot number.

If there are specific values you want a module to start at, you can choose ‘set’ and pick your Start I/O.

For this example project, we will choose a digital input card RX42C4 in slot 1 and a digital output card RY42PT1P in slot 2 to start.

In addition, the R08SFCPU requires an R6SFM, a safety function module, which we will put in slot 0 here.

PLC Configuration and Setup

IP Address

Double click on “Module Parameter” under R08SFCPU or your chosen PLC series. This will open the screen below:

Here you can set the IP Address information for your PLC. Press “Apply” on the bottom right side of the screen to save.

CPU Module Operation Setting at Error Detection

While debugging programs later, if any of your programs encounter an operation error (ex. array index out of bounds, invalid function input data when using direct addresses), the PLC will default to a “stop” error state: which requires a full reset of the PLC to clear (sometimes includes a power cycle if there is a safety module involved).

This can be very annoying when debugging and testing code; however, there is a setting that you can change that allows the PLC to continue running with the operation error allowing you to track down the error, make an adjustment, and continue testing.

Double click on CPU Parameter under R08SFCPU or your chosen PLC series. This will pull up the parameter window.

In the “Setting Item List,” click on “RAS Setting,” and then navigate to the “Operation Error” line item in the window on the right.
 
The default setting is “Stop.” Click on the drop down and change it to “Continue” to prevent the PLC from stopping. Click “Apply” on the bottom right corner before exiting this tab.

There are a couple of other types of execution errors here that can also be set to “Continue” if desired. After testing and debugging, remember to switch these settings back to “stop.”

Timer Setup

Double click on CPU Parameter under R08SFCPU or your chosen PLC series. This will pull up the parameter window.

In the “Setting Item List,” click on the “Operation Related Setting.”

This will pull up the “Timer Limit Setting,” which controls the units that each of the three timer instructions: OUTL, OUTH, and OUTHS. 

Note: We typically set one of these to 1ms, so it is easier to keep track of how long timers are.

Labels, Data Types, and Memory Address Mapping

Labels are what you use for your program variables. They can be defined locally in a program or function and only accessible in that particular program or function, or they can be defined globally and accessed anywhere. 

They are equivalent to “tags” in a Rockwell PLC.

You can create multiple global label lists with different names, but there is no way to differentiate which global label list a global label is defined in. Each program/function can only have one local label list.

Here is a helpful table showing the available data types for labels:

In Gx Works3, you can choose to assign memory addresses to your labels explicitly or let Gx Works automatically assign them when converting your program.

Below are the commonly used memory addresses available in Gx Works3:

• X: Input
  • Inputs coming to the PLC through any devices or modules will be mapped to the X device addresses.
• Y: Outputs
  • Outputs being sent from the PLC to any devices will be mapped through the Y device addresses.
• M: Internal Relay
  • These are bits internal to the PLC. These are similar to memory bits in a Siemens PLC.
• D: Internal Word
  • These are words internal to the PLC.

Although you can reference device addresses directly in your program as normally open/closed contacts, outputs, etc., it is best practice to define helpfully named labels and use those in your program instead.

This makes it significantly easier to read and follow along whether you are revisiting your program at a later date or if another programmer is helping review your program.

One more thing to keep in mind is that, if you do wish to assign device addresses to any of your labels, you will need to keep track of how many registers each data type will take up.

For example, if you assign a float/real label a device address of D1000, since a float is 32 bits long, it will take up registers D1000 and D1001. Gx Works3 will not tell you explicitly that this is happening, so it is up to you to keep track and avoid unintentionally double assigning device addresses.

6. Writing Your First Program

Back to Table of Contents

Now that you’re familiar with the interface, it’s time to write some code.

First, we can start by adding a normal scan program.

Note: We also have the option of adding other types of programs, if desired, such as ‘Initial,’ ‘Fixed Scan,’ ‘Event,’ etc. Right clicking on any of the other options under the ‘Program’ tree will allow you to add new data to those types of programs.

In this blog we’ll cover the basics of ladder since that is the most frequently used.

Right-click on the “MAIN” under the “SCAN” dropdown in the Navigation and select “Add New Data.”

A “New Data” window will pop up. Here you can name your program and choose the language (ladder, ST, SFC, FBD/LD).

This will open the Local Label list and Program Body for the new program. You can define any program specific labels in the Local Label List before starting to write the program.

Alternatively, you can define your labels as your program as well. If you enter in label name that isn’t defined, it will open the dialogue window below, and you can choose to define it.

If you have an undefined tag, it will be gray instead of pink.

Next, to start writing your program, navigate to the “ProgramBody.” Make sure to set the drop down on the top left to “Write:”

The “Read” option will not allow editing, and you cannot copy lines of code in “Read” mode either. “Write Mntr” and “Read Mntr” are for monitoring the program while online with the PLC.

There are some display options that can be set to make the ladder editor easier to read. Click on “Tool” > “Options.”

Next, click on “Ladder Editor:”

Here are some settings that I think are helpful to have on; these will display any comments you add to labels or any comments you add to your ladder rungs.

One other setting that is useful to have on is the “Wrapping Ladder Display.” This will wrap a long label name and show the whole name.

To start writing logic, you can double click on a cell or select a cell and just start typing a label name or instruction. The drop down here shows the type of basic instruction you can assign to a cell.

Note: If you don’t choose anything, it will default to a normally open contact.

The easiest way to program is to type out the instruction and labels for each cell and then press enter.

Typically, the syntax is: Instruction Input1 Input2 …. Here is an example for a move instruction where an integer value 1 is moved into iCount. Here I typed: MOV K1 iCount.

Each instruction might have different inputs. If you need details, you can right click and select “Open Instruction Help.”

Here are some basic, commonly used shortcuts and instructions:

F5: NO
F6: NC
F7: OUT

Set: latch a Boolean

RST: unlatch a Boolean

Unlike Siemens and Rockwell, Gx Works3 requires different versions of instructions when using different data types. Here are some examples:

=, >=, <=, <>, Instructions for comparing 16-bit data.

+, -, *, /, Instructions for basic math with 16-bit data.

MOV, to transfer 16-bit data.

D=, D>=, D<=, D<>, Instructions for comparing 32-bit data.

D+, D-, D*, D/, Instructions for basic math with 32-bit data.

DMOV, to transfer 32-bit data.

E=, E>=, E<=, E<>, Instructions for comparing single precision real numbers

E+, E-, E*, E/, Instructions for basic math with single precision real numbers

EMOV, to transfer single precision real numbers.

ED=, ED>=, ED<=, ED<>, Instructions for comparing double precision real numbers

ED+, ED-, ED*, ED/, Instructions for basic math with double precision real numbers

EDMOV, to move double precision real numbers.

$+, to concatenate strings.

$MOV to transfer character strings.

Next, we will go over basic timers.

Earlier in this blog we set timer units in the CPU parameters. The instructions for each of the timers are OUT, OUTH, and OUTHS.

These timers will run based on what was set earlier. OUT is the instruction for a normal output coil, but, when the first input is a label of type “Timer” and the second input is a 16-bit unsigned integer, this instruction behaves as a timer. Here is an example of how this would look like:

This timer is enabled when Input1 goes high and starts counting to 100*10ms (default setting). When the time is reached, the label Timer1 can be used directly as a contact and will go high turning on Output1.

Finally, we will cover how to comment in Gx Works3.

The three icons below can be toggled on and off. When toggled on, double clicking on a rung or a cell will pull up a window where you can add a comment.
 
The leftmost icon allows you to comment on your labels (you can also do this in the label lists), the middle icon is for commenting an entire rung, and the last one will add a comment to an output.

Adding comments to entire rungs is the most useful.

If you check “Display in Navigation Window,” text you write here will become subtitles in the Navigation window: which can be helpful for organizing your code.

You can add multiple comments above a rung, like this:

7. Simulation and Debugging

Back to Table of Contents

This section will focus on how to simulate a PLC and go online to test your program.

We have created a basic sample program. Anything that hasn’t been compiled yet will show up as gray in the ladder editor and red in the Navigation window.

To check and compile code, click on “Convert,” then press the “Convert(B).”

Alternatively, you can click the convert button in the tool bar shown below.

If there are no errors in the code, after converting, the rungs in the ladder editor will turn white, and the titles in the Navigation will also turn white. If there are any errors, they will be displayed in the Output Window.

Next, click on the “Start Simulation” icon to start a PLC simulation. The button immediately to the right is “Stop Simulation” and will end the simulated PLC.

The first time you start a simulation, the program will automatically write to the simulation PLC. It will open the window below. which is the simulated PLC.

Now, you can switch to “Read Mntr” or “Write Mntr” to test your programs live.

If you make a change to your program, you will need to write these changes to the PLC. If you only changed your program, you could do an online change by pressing the icon below.

If you make a change to any Structured Data Types or Parameters, you will have to rebuild/recompile your project and then do a full download. To do a download, press the red arrow icon shown below. It will open a window where you can select exactly what you want to write to the PLC.

If you have multiple people working on the same PLC, anytime someone writes a change to the PLC, all other people will need to read from the PLC to obtain that change. It doesn’t automatically update. To read from the PLC, press the blue arrow button shown below. It will open a window where you can choose what you want to read.

Basic debugging and troubleshooting

The last part of this blog will go over some debugging and troubleshooting tools in Gx Works3.

After going online with the PLC and monitoring your selected program, the ladder editor will display the values in any referenced labels, and any contacts that are true will be colored blue.

In our sample program here, Input1 is true and iCount = 1.

There are two main ways to modify labels.

For a Boolean, you can right click on the label, go to “Debug,” then click on “Modify Value.” This will flip the value of the Boolean.

The other way to modify labels is to right click, go to “Register to Watch Window” and then add the label to a watch window of your choice. The selected watch window will open.

If no values are being displayed on the watch window, you can right-click on a label in the watch window and click “Start Watching.”

You can monitor and modify any label values in the watch window. After entering in the desired value, press “Enter” on your keyboard to confirm the value modification.

To cross reference a tag, right click on the tag and click on “Cross Reference.”

The cross-reference window will open and show all instances of the label.

One important thing to note is that no matter what value is present at a certain index in an array, the GX Works3 ladder editor will show that it is -1. To see its actual value, you can use a watch window.

In the example below, IntArray[Index] should equal 2, but the value shown in the ladder editor is -1.

The icons shown below near the top right corner show the statuses of the PLC.

If there are any errors, there will be a yellow exclamation mark present. To check on any PLC or module errors, clicking on the check mark will bring up the diagnostic window below.

One last useful tool for debugging is the Device/Buffer Memory Batch Monitor which can be accessed by pressing the icon below:

Here you can type a device name (ex. D10, or X100) or buffer memory unit and monitor the bits at those places in memory.

After you are done with simulating your program, make sure to stop the simulation before connecting to a real PLC.

To get connected with a real PLC, start off by pinging the PLC IP address using command prompt. After that is successful, press the icon shown below:

This will open the following window:

Double click on “Ethernet Board” to specify your adapter and hit OK.

Double click on “PLC Module.”

The first time you connect to the PLC, you will have to connect through the ethernet port directly on the PLC to write an IP address to the PLC. 

Choose “Ethernet Port Direct Connection.”

If you have connected to the PLC before, set the IP address already, and are now connected through an ethernet switch, click on “Connection via HUB” and enter in the IP address of the PLC. Next, press “OK.”

Next, click on “Connection Channel List.”

There are many different routes to connect to the PLC, the most common is “19 Ethernet Board Communication PLC Module Connection.”

If you have a different network topology, you may need to choose a different setting here. Selecting different options will change the graphic shown to help illustrate the topology. After choosing your setting, click “OK.”

Finally, we can test our connection to the PLC by clicking on “Connection Test.” A dialog box will show up to display whether the connection is successful or not.

If this is the first time you are connecting to a fresh PLC, make sure to write your entire project to the PLC to set the IP address of the PLC for future connections.

8. Final Thoughts

Back to Table of Contents

GX Works3 provides an integrated environment for developing and managing automation projects. While navigating and programming in GX Works3 may present challenges, mastering its key functionalities and insights can significantly alleviate the frustration, paving the way for a smoother and more efficient experience in harnessing its power for industrial automation.

Happy programming!

The post Starting a Project in GX Works3: A Beginner’s Guide appeared first on DMC, Inc..