Home
This documentation describes a set of function blocks built around shared objects.
In Sysmac Studio, an object is a global structure used by several FBs. It contains the command data, status data, messages, and hardware exchange data required by the object. This approach is close to a class concept: the structure is the object instance, and the FBs are the methods used to configure or operate it.
This architecture helps keep the PLC program modular. A configuration FB links the object to the hardware, while operation FBs work on the same object instance to execute commands or display states. The same object can therefore be used in ladder, ST, HMI logic, or other FBs without duplicating internal logic.
The project is not distributed as a Sysmac Studio library. The objects are copied directly into the target project. This keeps the function blocks editable, makes debugging easier, and allows project-specific modifications when required.
| Object | Description |
|---|---|
| PNEUMATIC | Controls pneumatic cylinders and valves. |
| FLASHLAMP | Controls stack lights and visual effects. |
| DOOR | Controls door locking, unlocking, and door states. |
| STATE | Provides state control function blocks. |
| BUZZER | Controls buzzer effects and priorities. |
| VIBRATOR | Controls vibrating bowl or rail devices. |
Open the project containing the required objects.
Right-click one FB from the object to import.
Select Select and Copy Multiple Items:
Select all FBs required by the object.
In Reference, select:
Include POU, global variable, and data type
Click Copy:
In the target project, right-click POUs.
Select Paste Multiple Items:
The selected FBs are added to the target project with the required data types and dependencies. If all dependencies are selected, the project compiles without errors.
The imported elements remain fully editable inside the target project.
Before using an object, an instance must be created inside the Global Variables table.
An object instance is the memory area shared by all FBs working on the same equipment.
For example:
- One FB configures the hardware
- Another FB moves a cylinder
- Another FB checks alarms
- Another FB displays states on the HMI
All these FBs exchange information through the same object instance.
Without an instance, the FBs cannot share states, commands, messages, or hardware information.
Each line creates one object instance.
Example:
We will examine each column of the Global Variables table.
The instance name must clearly describe the equipment function.
The name should not follow the electrical schematic naming.
Prefer:
HMI_LampSet
Pneu_Blower
Sensor_Selector_Left
Avoid:
HM-HL1
M09
B2B21
The objective is to simplify:
- Reading
- Debugging
- Search
- Auto-completion
- Maintenance
Keeping the object type at the beginning of the name is recommended.
Examples:
Pneu_Blower
Sensor_Selector_Left
FlashLamp_MainTower
If many objects are used, adding the station or machine area improves readability.
Examples:
Pneu_Sta3_Blower
Sensor_Loading_Left
FlashLamp_Packout_Main
This simplifies object filtering with auto-completion.
The data type defines the object type.
The object path always starts with:
OBJ\
The object to instantiate is always:
BASE
Example:
OBJ\PNEUMATIC\BASE
OBJ\SENSOR\BASE
OBJ\FLASHLAMP\BASE
The complete path must be uppercase.
If part of the path is lowercase, a child structure was probably selected by mistake.
Correct:
OBJ\PNEUMATIC\BASE
Incorrect:
OBJ\PNEUMATIC\Config
Objects should normally not use Retain.
The runtime states of the objects should restart from a clean state after boot.
Incorrect retain usage may create:
- Invalid runtime states
- Incorrect alarms
- Invalid commands
- Unexpected machine behavior
Important
Some objects may require retention. These cases are documented individually inside the related object documentation.
The comment field can contain:
- Equipment role
- Machine function
- Additional information
- Electrical reference
The electrical reference should be placed at the end of the comment.
Example:
Vacuum to take pin from vibrator (Q21)
This keeps the instance name readable while preserving the electrical mapping information.
Namespaces are used to organize FBs inside Sysmac Studio.
Each object has its own namespace:
OBJ\PNEUMATIC
OBJ\FLASHLAMP
OBJ\DOOR
OBJ\STATE
The namespace system improves:
- Auto-completion
- Code readability
- FB organization
- Programming speed
It also avoids having hundreds of FBs permanently visible inside the completion system.
In a normal program, the auto-completion does not directly propose the FBs of the object.
The FB still exists, but Sysmac Studio does not automatically expose it inside the completion list.
It is possible to manually access the FB by writing the complete namespace path.
Example:
\OBJ\PNEUMATIC\
The auto-completion then proposes the FBs inside the object namespace.
Example:
\OBJ\PNEUMATIC\Pneu_Config_Cylinder_SimpleActing
This method works correctly, but the code becomes visually heavy and more difficult to read.
Namespaces can be included directly inside the program configuration.
Open:
- Program variables
- Namespace section
Then add the required namespaces.
Example:
OBJ\PNEUMATIC
OBJ\FLASHLAMP
OBJ\STATE
Once the namespace is included:
- FBs appear directly in auto-completion
- The namespace path is no longer required
- The completion list becomes cleaner and faster to use
The instantiated FB now uses a short readable type name.
Internally, Sysmac Studio still keeps the absolute path association automatically.
The recommended workflow is:
- Create the program
- Add all required namespaces
- Start programming
This provides:
- Cleaner auto-completion
- Better FB filtering
- Faster development
- Better readability
- Easier maintenance