Overview This document explains how to enable OpenID Connect (OIDC) authentication for Experior and the Experior Remote Viewer. Once configured, users can authenticate via an external Identity Provider (IdP) instead of using local credentials. This setup supports standard OIDC-compatible identity providers (e.g., Azure AD, Keycloak, Auth0, Okta, or similar platforms).   Prerequisites Before starting, ensure the following: Experior is installed and runnable Experior Remote Viewer is available Access to an Identity Provider (IdP) that supports OpenID Connect Ability to register a client/application in the IdP   1. Experior Configuration Runtime Requirements Experior must be started using one of the following modes: -graphicsserver -headless These modes enable the web interface and API required for authentication.   Web API Configuration Update the WebApiSettings.json file to include identity provider settings. Option A – Direct OIDC Configuration Provide explicit configuration values: 1 "IdentityProvider": { 2 "Authority": "https://<idp-domain>/", 3 "Issuer": "https://<idp-domain>/", 4 "Audience": "account", 5 "ClientId": "experior-remote-viewer", 6 "UserIdField": "", 7 "RedirectUri": "http://127.0.0.1:8080/callback", 8 "EndSessionRedirectUri": "http://localhost:8080/", 9 "AuthorizationScope": "openid", 10 "Prompt": "login" 11 }   Option B – Dynamic Configuration via External API Alternatively, configuration can be retrieved from an external service: 1 "ExternalApi": { 2 "BaseUrl": "http://localhost:5050/api", 3 "IdpEndpoint": "/idp" 4 }, 5 "IdentityProvider": { 6 "Authority": "", 7 "Issuer": "", 8 "Audience": "", 9 "ClientId": "", 10 "UserIdField": "", 11 "RedirectUri": "", 12 "EndSessionRedirectUri": "", 13 "AuthorizationScope": "", 14 "Prompt": "login" 15 } In this scenario, Experior will query the external API to retrieve the required IdP configuration. Other Relevant Settings Ensure the following sections are configured as needed: WebUi.Enabled = true CorsConfiguration.AllowAll = true (or restrict appropriately for production) CertificateConfiguration.AllowInsecureCertificate should be false in production   2. Identity Provider Setup Your Identity Provider must be configured with a client application for Experior Remote Viewer. Required Configuration Create a client with the following characteristics: Client ID: experior-remote-viewer (or match your configuration) Protocol: OpenID Connect Redirect URI: Must match RedirectUri in WebApiSettings.json Scopes: At minimum openid Optional but recommended: Enable refresh tokens Configure logout redirect URI Add additional scopes such as profile or email Supported Identity Providers Any OIDC-compliant provider can be used, for example: Azure Active Directory Keycloak Auth0 Okta   3. Remote Viewer Setup The Remote Viewer uses the configured Identity Provider via Experior's API. Ensure: Remote Viewer can reach the Experior Web API Redirect URI configured in the IdP matches the viewer callback endpoint Network configuration allows communication between viewer, Experior, and the IdP   4. Login Flow The authentication flow works as follows: User opens the Remote Viewer User is redirected to the Identity Provider login page User authenticates with the IdP IdP redirects back to the Remote Viewer using the configured callback URL Experior validates the token Access is granted   5. Best Practices Always use HTTPS in production environments Do not allow insecure certificates outside of development Restrict CORS settings to known origins Keep client secrets and configuration secure Align redirect URIs exactly between configuration and IdP   Summary By configuring Experior with an OpenID Connect-compatible Identity Provider, you enable secure, centralized authentication for both Experior and the Remote Viewer. This allows integration with enterprise identity systems and improves security and user management.

This article describes the navigation around the scene inside Remote Viewer on a PC. Two objects are relevant for navigating the scene: Camera: virtual camera that displays the Experior scene streamed to the Remote Viewer. Projection: perspective Field of View Axis: vertical Field of View: 50 degrees Clipping Planes: near 0.3m, far 1000m Physical Camera: false Camera target: movable object which the camera is always pointing at. To visualise the Camera target, go to Settings inside Remote Viewer, and set Show camera target to true.   Rotation To rotate the camera around the camera target, click the left mouse button and drag the mouse.   Translation To pan / move / translate the camera target horisontally, click the right mouse button and drag the mouse. The camera will always move with it. Note: when the camera is too close to the camera target, the translation might appear slow. Maker sure the camera target is visible, and in the correct position. Zoom To move the camera towards/away from the camera target, use the mouse wheel.   Fly camera The camera can be "flown" in a similar way like a First-person view (FPV) drone: To go forward (in the direction of the camera), use the W button / up arrow key. To go left, use: A / left arrow key To go right, use: D / right arrow key To go back, use: S / down arrow key To speed up, use left shift.   Reset camera To reset camera, use the Reset camera button in the scene, or go to Settings, and click Reset camera The camera can be reset into: Default position Position that shows all objects in the scene. To achieve this, go to Settings, and set Reset camera to scene bounds to true

Introduction The current implementation of the Physics Engine in Experior 7 presents difficulties in accurately simulating the dynamics of loads under certain scenarios commonly found in conveying system applications. This may partially or entirely alter the results of simulation and emulation models, requiring workarounds to overcome these issues.   To address these challenges, a new implementation called Advanced Dynamics has been developed to provide a generic solution that covers a broad spectrum of complex dynamics scenarios presented in case conveying and pallet conveying systems, with respect to the motion of loads produced by forces exerted by conveyors. However, it is not within the scope of this new implementation to provide a solution that represents a 1:1 version of real physics (e.g., material deformation), considering the computational limitations of real-time simulations.   Development The following section describes the main points that have been reworked to significantly impact the overall physics engine.   Load transition Problem The displacement of the load is affected, either partially or totally, by the collision between the load and the belt that occurs during the transition in merge and divert sections. Flawless transitions depend on the geometry and dimensions of the load. Load orientation (Yaw) is affected during the transition, regardless of whether the configuration is straight-straight or straight-curve sections. Merge configuration old    Orthogonal configuration old   Cylinder transition old   Small Box transition old   Curve-Straight configuration old   Solution Whenever there is a collision between dynamic actors (i.e. loads) and static actors (i.e. belts), PhysX generates contact points that the contact solver uses to determine the velocity and position of the load. However, before the contact solver is applied, the properties of these contact points, such as the vector orientation, are modified to ensure a smooth transition, regardless of the geometry or dimensions of the load. The primary purpose of contact modification is to enable seamless transitions between conveyors, without requiring the use of ramps.   Orthogonal Configuration    Parallel Configuration   Inline-Decline   Contact Points Problem   Loads can exhibit unrealistic behaviors in certain scenarios where they come into contact with more than one surface simultaneously. This is because only the greatest velocity is applied. The current implementation lacks the capability to retrieve information about the contact points generated by the surfaces and the load.   Parallel Configuration old   Orthogonal Configuration old   Solution   PhysX filter allows retrieval of information related to contact points generated by collisions between dynamic and static actors. This makes possible to develop proper mathematics which considers the distance between the load’s center of mass and the position of each contact point to apply forces and torques correctly.   Parallel Configuration New    Orthogonal Configuration New   Friction Specifically, this refers to the friction force a conveyor surface applies to a load. Experior 7 calculates this friction force when the speed of the surface motor on a belt is different from zero. When the speed of the surface is zero, the PhysX engine from Nvidia will take over these calculations. Note: Patch and Two directional refer to the two friction modes from Nvidia PhysX supported in Experior 7. This only affects the friction force when it is being handled by the PhysX engine (i.e.: surface speed is zero). The key differences are: Two-directional combines the load and the surface friction coefficients for the force calculations, whereas Patch gives priority to the surface friction coefficients. According to the Nvidia PhysX documentation, Patch mode has better performance. Two-directional mode is more realistic, especially with static friction, as patch mode has unrealistically strong static friction. This behavior is most noticeable when a load is touching surfaces with non-zero velocity and zero velocity simultaneously. In Experior 7, the friction mode can be set through the command line arguments (patch is the default value). Experior 6 only supports the Two-directional mode.   Problem   The friction force calculations made by Experior 7 and the PhysX engine are inconsistent. An acceleration-deacceleration test showed this, where a load starts from rest on a conveyor. Afterward, the motor is turned on with a speed of 1.5 m/s and then is turned off (motor acceleration and deceleration are disabled). The following images show the load speed plotted against time. As the same physical phenomenon (dynamic and static friction) is responsible for the acceleration and deceleration of the load, we would expect the plotted curves to have a symmetrical behaviour. However, It is noticeable that the load behaves differently when accelerating and decelerating. This shows the inconsistencies between the force calculated by Experior 7 and the PhysX engine.   Solution   According to the Nvidia PhysX documentation, the friction force is calculated using the Coulomb friction model. To make the calculations from Experior 7 more consistent, we are now calculating friction force based on the Coulomb friction model. The following images show the results of the acceleration-deceleration test with the new friction calculations. Due to the symmetry in the curves, we can see that the friction force of the conveyors is now consistent when the motors are on and off.   Load Trajectory Problem   When the surface in contact uses sticky friction, Experior directly defines the load’s LinearVelocity property. However, this approach is inconsistent with PhysX, which computes all the forces exerted on a dynamic actor to determine its velocity and position. Furthermore, when the friction is not sticky, forces and torques are applied without regard of the surface’s orientation.   Incline-Decline old   Curve configuration old   Solution   Forces and torques are calculated based on the alignment of the surface and the information extracted from the contact points. During transitions from straight to curve and from curve to straight, forces and torques are applied independently to each surface. This is determined by the position of the center of the load. Remove the ramps from the conveyors. Incline-Decline new   Curve Configuration new   Stacks Problem The current physics engine configuration does not allow for stable stacking or displacement due to the default collision detection system (Permanent Contact Manifold). PCM is a distance-based collision detection system that can generate fewer contacts, potentially reducing the stability of tall stacks when simulating with insufficient solver iterations. Stacks old   Solver iterations refer to the minimum number of position and velocity iterations used by the contact solver behind the scenes to determine the velocity and position of a load.    Solution The physics engine configuration now includes a new feature called “Average Point”. This feature generates additional contacts per manifold to represent the average point in a manifold. It can stabilize a stacking effect when only a small number of solver iterations are used. The following videos demonstrate the difference when increasing the number of solver iterations from P:4,V:1 to P:20,V:5. Stacks 4 1 new   Stacks 20 5 new   Thanks to the new implementation, stacking and destacking processes no longer require additional functionalities or logic to achieve the correct behavior of the stack (e.g., the use of Group() and Ungroup() from the Load class). However, limitations from PhysX are still present when using a stack with a significant number of loads. The next two videos demonstrate the stacking and destacking processes, where the sensor between the forks only attaches to the load making contact.   Stacking new   Destacking new     Sleep Threshold Problem The PhysX solver continues to execute even when the load is not moving, resulting in unnecessary consumption of computational resources. In the video, it is evident that the arrow of each load which represents the linear velocity, keeps moving around continuously, even though the loads are completely static. Sleep Old   Solution Each dynamic actor contains a property called SleepThreshold, which sets the mass-normalized kinetic energy threshold below which an actor may go to sleep. Once an actor goes to sleep, PhysX will not report or notify it.   If a load on top of a conveyor is in a sleeping state, it will automatically awaken once the motor starts (CurrentSpeed != 0f). This is due to the notification from the motor to the PhysX engine through the method BeginStart(). However, it will take one more frame for the physics engine to move the load. It’s important to note that any motor developed using inheritance from the Electric class must use the method BeginStart when starting the motor.   Sleep new   Sleep Conveyor new   Risks / Side Effects To address the issues that were disclosed, it was necessary to implement new functionalities, which may have some unintended consequences. The following section outlines the potential risks associated with each of the proposed solutions. Performance     Performance decreased 18% Processor: i7-9750H CPU 2.60 GHz Ram: 16 GB Nvidia GeForce RTX 2070   A test was conducted to compare the performance of Advanced Dynamics with the current implementation, Classic Dynamics, which was considered a benchmark due to its efficiency. As shown in the image, Classic Dynamics is capable of handling 850 loads without exceeding the 16 millisecond threshold (the threshold is determined by the cycle task frequency of 60Hz), whereas Advanced Dynamics surpasses it. Based on the results of this specific test, Experior’s performance decreases by approximately 18%. It is important to note that performance can vary due to hardware specifications, as well as the size of the model and assemblies contained within it.   Precision to represent reality In some specific cases, uncertainties about the real-life dynamics of the load may arise due to the broad spectrum of complex scenarios and the lack of physical facilities to test them. Therefore, we are open to discussing and improving based on your feedback.   Although the mathematics defining the dynamics of the load and configuration of the PhysX engine have been reworked, computational limitations still persist due to the contact solver capacity. This is particularly evident when implementing tall stacks (more than 15 loads) or handling loads with very small dimensions. This limitations are expected to improve after updating the PhysX engine version in the near future. Dynamic 1    Dynamic 2   False Expectations Users should not expect to obtain the same results when using Advanced Dynamics as when using Classic Dynamics with regards to load dynamics, particularly when modifying the friction coefficients. The old implementation was developed in a specific way to overcome problems resulting from the lack of information and default configuration of PhysX, such as very high and low coefficient values. As shown in the following video, using the smooth friction type from Classic Dynamics will not produce the same results in Advanced Dynamics.   Expectations   Implementation To fully take advantage of the advanced dynamics, it is strongly suggested to remove the ramps of the belts used in your catalog. A new query property Experior.Core.Environment.Engine.AdvanceDynamics has been introduced, so that developers can handle the proper removal of ramps based on the physics engine dynamics. Users have the option to select the Physics engine dynamics type through the CLA (Command Line Argument) -physicsenginedynamics “advanced”. By default, Experior 7 will use “classic”. This parameter can be set from the cmd or the shortcut configuration as the following images show.     MinPositionIterations and MinVelocityIterations properties have been added to the class Load.  Global SleepThreshold property set automatically to 5e-5 if advanced dynamics is used. Nevertheless, the property SleepThreshold is available from the class Load. Visualization of contact points are displayed in debug visualization mode when using advanced dynamics. New friction coefficient values have been defined. Experior will automatically set the appropriate friction coefficient based on the selected physics engine dynamics. The following image displays the friction coefficient values defined for advanced dynamics mode.

Minimum PC Requirements:   CPU – Intel Core i7-37xx Quad, 2.5GHz or AMD equivalent   Graphics card – DirectX 9.0c compatible Nvidia Cuda compatible graphics card, minimum 2048MB (GTX 6xx, Quadro) (NVIDIA CUDA is used by the graphics card to accelerate the physics calculations. “Rigid” bodies are not supported at this time, but having a CUDA enabled graphics card is recommended. CUDA is a very common technology and supported by the majority of NVIDIA graphics cards, however, if the device being used is not CUDA compatible it’s ok as there is little to no difference compared to other graphics cards.) https://www.nvidia.co.uk/object/what_is_cuda_new_uk.html   Memory – 8GB RAM (32 bit: 3GB RAM)   Disk space – 900MB   Operating System – Windows 7/8/10/11 (32 or 64 bit) Administrative user rights on PC/operation system is preferred. The user should be familiar with normal PC and Windows functionality

The web license file (with the extension: .key) have to be located in the Experior installation folder (which is usually C:\Xcelgo\Xcelgo Experior…).   When Experior is started, it contacts the Xcelgo web license server to investigate whether the license is valid and whether a license seat is available. If the investigation is successful, a seat checkout is performed and the usage of Experior is granted.    When Experior is closed: Depending on the customer and license setup, Experior might give the user the option to contact the Xcelgo web license server for a check in of the license seat – or to keep it reserved for the user for later use. If checking in the license seat, the seat is available for checkout for other users with access to the same license.   The communication between Experior and the Xcelgo web license server is a bit different depending on the Experior version:   • Experior 5.x, Experior 6.0 and Experior 6.1 (prior to and including release Experior 6.1.19245) need access to port 8080 at ‘license.xcelgo.com’. They use a proprietary protocol for the license server communication.   • Experior 6.1 (from and including release Experior 6.1.19246) as well as Experior 7 need access to port 443 at ‘https://licenseapi.xcelgo.com’ for license server communication. They use a TCP protocol for the license server communication.   So: in order to check out or check in an Experior web license seat, access to and communication with the Xcelgo web license server is required. If this access is unavailable due to personal or company network restrictions and the access cannot be provided, then it is recommended to use a USB dongle licence instead.

Introduction The kinematization solution aims to simplify the process of creating mechanisms using primitive geometries or convex geometries generated from 3D CAD models, without requiring the user to have a background in C#. It also enables the user to define the motion of each component.   All the new functionalities are available from the ribbon in the tab named Kinematization.   CAD Import You can import 3D CAD models by clicking on the CAD/Convex button. This will open a dialog window where you can select the CAD file to import. Currently, the supported formats are Collada (.dae), Standard Triangle Language (.stl), STEP (.stp, .step), CATIA (.CATPart, .CATProduct), and SolidWorks (.sldprt, .sldasm): Some remarks to be made about the import feature are: Imported CAD files will be serialized within the model. Every Assembly created through the CAD import is of type BodyAssembly. The performance can be affected by either a large number of geometries or the complexity given the mesh density.   When importing a Collada file, an additional window will appear, giving the user the option to split the 3D model into multiple parts. This allows the user to recreate the hierarchy specified in the file, resulting in the creation of multiple BodyAssembly objects in the scene.    gif also available as attached video "URrobotImportExample1"   Hierarchy Modification   Creation or modification of hierarchies can be performed using the following buttons:   Attach: This method creates a parent-child relationship between the selected assemblies. The first assembly selected will be defined as the parent. Detach: This method breaks the parent-child relationship. The selected assembly will be detached from its parent.   You can create a new empty Assembly by clicking on the Create button. This option allows you to create a blank Assembly that can serve as a container for building a new hierarchy.  gif also available as attached video "AttachDetach.mp4"   Convex Collider Geometry   In a scene, the parts are composed of two main elements: visual mesh and collider geometry. The visual mesh is what the user sees all the time, while the collider geometry is used by the PhysX engine to detect collisions and apply forces.   The BodyAssembly class has been modified to offer a more precise convex collider geometry that closely matches the visual mesh. This not only improves the fidelity of the collision detection but also speeds up the creation process.   Convex collider geometries are created through a process called Cooking. This process has been modified to make a second attempt if the PhysX engine fails during the Cooking process due to the complexity of the geometry or a large number of vertices provided. On the second attempt, the vertices will be quantized using K-means clustering, which reduces the number of vertices by creating an approximation of the original model. If the PhysX engine fails again during the second attempt, a box collider geometry will be created.   Body Assembly The BodyAssembly class has been specifically developed to work with the Kinematization solution. The following points describe the key characteristics and behaviors provided by the class.   It provides polymorphism, allowing you to change its geometry to a primitive shape (box, cylinder, and sphere) or a convex shape (CAD file models). The behavior of the Body can vary depending on the selected dynamics Bodiless: It is kinematic and has no collider Rigid: It is kinematic and has a collider Physics: It is dynamic, and its position and velocity are determined by the forces acting on it.   Minimum position and velocity iterations improves the results of the PhysX engine solver for the current Body, when using physics joints. Collision allows you to enable or disable collision with other BodyAssembly objects in the scene, without destroying the collider.   Gravity allows you to enable or disable the effect of gravity on the current Body   Weight defines the density of the Body considering its volume   Motion Body Assembly has been designed to be compatible with Kinematic Axis Assembly and Physics Joints. On the other hand, you can perform combination between Kinematic Axis and Physics Joints to create mechanisms.   gif also available as attached video "SliderCrank.mp4" Kinematic Axis It allows for the movement of single or multiple assemblies that have been attached to it. It supports the attachment of Kinematic Axis assemblies to create serial or parallel kinematic chains. It supports the attachment of Body Assembly objects which belong to a structure composed by joints and which Dynamics type is Rigid. It provides only one degree of freedom. To simplify the motion assignment process, the user can select an assembly either from the scene or Solution Explorer and click on “Kinematic Axis”. This action will create a Kinematic Axis in the scene as the parent of the selected assembly, maintaining the same position and orientation. The same results can be achieved by selecting multiple assemblies before creating the Kinematic Axis. If no assembly is selected, a single Kinematic Axis will be added to the scene.   The motion of the Kinematic Axis can be defined based on the drive type. By default, you have the option to use Position, Velocity, or Forward and Backward drives. If you need to use a custom drive, select the option Custom. Any class that inherits from the Electric or Positioner class will be added and displayed in the Custom Drive property. Simple Motion Serial Kinematic Chain Kinematic Axis and Physics Joints   Passive Physics Joints A physics joint requires two BodyAssembly objects, and it defines the way bodies move relative to one another. The provided physics joint is of type D6 which is a highly configurable joint. It allows for the specification of individual degrees of freedom to either move freely or be locked.   Joints can only be created through the Joint Editor Window, and are compatible only with BodyAssembly types. On the other hand, bodies cannot be Bodiless since the PhysX engine requires the collider geometries of the bodies.   The Joint Editor Window allows the user to perform a quick configuration of the joint by enabling/disabling the degree of freedom. However, to get access to the full configuration of the joint, select the Physics Joint object in the Joint Editor Window, and the properties will be displayed in the Properties Window.   The joint position and orientation are relative to the BodyAssembly, which has been set as the origin. The child position and orientation are relative to the joint origin. Besides, it is possible to change the geometry type even if the BodyAssembly is already connected to a physics joint. Experior automatically will reconstruct the joints connected to the body.   No collision is presented between the BodyAssembly objects that are linked through the same physics joint. However, collision is present with external BodyAssembly objects or any other Assembly in the scene which has rigid parts.    Attachment of Assembly objects to BodyAssembly which already belong to a physics joint, is allowed. Nevertheless, the objects attached will not impact nor modify the motion of the joint since attached objects mimic the change of position and orientation. Active Physics Joints Example Physics Joints Pose Physics Joint Reconstruction Physics Joint with Attachment   URDF Import When importing the Universal Robot Format (URDF) file, multiple Body and Kinematic Axis assemblies will be created based on the information specified in the file. Joints specified by URDF are constructed using Kinematic Axis assemblies. Unlike CAD import, URDF import allows to have BodyAssembly objects with custom colliders, regardless of the visual mesh geometry. This is possible if the collider information is provided by the URDF file.   NOTE: URDF import supports the same CAD formats mentioned for CAD import (.dae and .stl) To maintain the specified hierarchy in the file, parent, joints, and child relations are kept. When using Kinematic Axis assemblies as joints, the configuration applied to them based on the content of the file includes three aspects: Type, Axis, and Limits.   Physics Joints Tips / Suggestions The following tips and suggestions are provided to improve the response of the PhysX engine and to have a more stable mechanism composed by passive physics joints. Mass ratios above 10 are to be avoided, as the solver is not designed for high rigidity systems. The bodies with higher mass will dominate the movement. Setting the mass of the parts to the real value might not be the best way to set the parameter, depending on the mass ratios. Setting a realistic center of masses can be useful to providing higher stability to a mechanism, as it will greatly influence how the joint affects the angular movement of the body. The higher the solver iterations, the more “rigid” the joint will be (less flexible). Position iterations will mainly provide the accuracy of slow-moving mechanisms. Velocity iterations will improve the accuracy of high-speed movement. Law of diminishing return applies for the last two points. In some scenarios, gravity and collision could be disabled to improve the accuracy of the simulation, in the case that these interactions are not required for the specific simulation that is being done. Wrong Parameters     Parametrized   More demos can be find attached as Deltapicker-demo.mp4 and T-robot-demo.mp4

The RigidPart class serves as the base class definition for Part models in Experior to build on top of. RigidPart further splits into Static (See article “Static : RigidPart”) for scenery/Assembly models and Dynamic (See article “Dynamic : RigidPart” ) related to Loads, both which derive from RigidPart. Static models refer to models that describe the environment in an Experior model. Dynamic refers to load models that needs to be moved by the Experior model.   Most importantly, models deriving from Static are not affected by gravity, whereas models deriving from Dynamic are affected by gravity force. Additionally, Dynamic models have inertial physics, meaning mass as well as linear/angular movement in accordance with NVIDIA’s PhysX engine implementations (PhysX Documentation).   The figure below illustrates the class overview, with visuals examples of imported models deriving from both classes. Experior's RigidPart base class, which Dynamic and Static classes derives from. Dynamic is the base class for handling Load models. Static is the base class for handling 3D models related to Parts.   Methods and Properties   The RigidPart class does not implement physics related properties and methods as it did in earlier Experior versions. Those definitions have been moved to Static and Dynamic, where those classes implement how they interact with the engine in different ways. Only exception is the Friction coefficient property.   Therefore, RigidPart takes care of defining the following, many of which are open for extension:   Name and Identification Transformations Positioning – Global and Local Local Rotation Local Orientation Coloring – Base color, Selected color Visibility in the scene Disposal handling Selection/Deselection Enabling/Disabling Parenting objects Interaction Mouse click handling Mouse dragging handling Keyboard hotkey click handling Friction coefficient – sets friction force of a Part, defining how easily objects “glides” across its surface.

This article outlines how to import and read Excel files contents using a custom plugin.   1. First, create a new project using the Plugin template available HERE. If you already have a plugin project, skip this step.   2. It is necessary to install two NuGet packages. Therefore, in the solution explorer of visual studio, use right click on the Dependencies section, and select the option Manage NuGet Packages. Browse and install the following NuGet packages     3. Opening and reading a file with the recently added library can be performed as follows:   /// <summary> /// Class <c>Excel</c> provides methods to read the content of an Excel file. /// </summary> internal static class Reader { /// <summary> /// Opens and reads the content of an Excel file /// </summary> /// <param name="filePath"></param> /// <returns>A collection of Content type which contains the content of each Sheet</returns> public static List<Content> Open(string filePath) { try { using (var stream = File.Open(filePath, FileMode.Open, FileAccess.Read)) { // Auto-detect format, supports: // - Binary Excel files (2.0-2003 format; *.xls) // - OpenXml Excel files (2007 format; *.xlsx, *.xlsb) DataSet result; using (var reader = ExcelReaderFactory.CreateReader(stream)) { result = reader.AsDataSet(); } var content = new List<Content>(); foreach (var table in result.Tables) { var tableInfo = new List<List<string>>(); if (!(table is DataTable sheet)) { continue; } for (var i = 0; i <= sheet.Rows.Count - 1; i++) { var rowInfo = new List<string>(); for (var j = 0; j <= sheet.Columns.Count - 1; j++) { var value = sheet.Rows[i][j] == null ? string.Empty : sheet.Rows[i][j]; rowInfo.Add(value.ToString()); } tableInfo.Add(rowInfo); } content.Add(new Content(sheet.TableName, tableInfo)); } return content; } } catch (Exception e) { Log.Write($"An error has occured during the reading process of the Excel file {filePath}. Please, see Debug.log"); Log.Debug.Write(e); return null; } }   The Excel file’s content is returned through the variable “content,” which provides a list of items. Each item corresponds to a sheet and its content/data. Notably, the content read from the Excel file is of type string. Developers must perform any necessary type conversions for specific data types.   You can download the attached plugin project, which contains a blue print to implement Excel reading files logic.

Load type "Default" representing an xcelgo logo box (1m, 1m, 1m)   Loads in Experior means models that represent items to be transported by material handling equipment such as conveyors, lifts or cranes.   The Load class takes care of definitions for both the Physics Engine and Discrete Events Engine, where there are important differences to take note of. In Physics mode, a Load is considered a dynamic object (Kinematic = false). This implies that the Load’s position and orientation is determined by the underlying NVIDIA PhysX engine, which experior’s physics engine is built on. The PhysX engine applies forces/torques on the Load to achieve positioning/rotation/orientations.   In Discrete Events Mode, the physics engine is not used (Kinematic = true). Here it is instead important to note that, unless a given Load is made undeletable, the Load will always be on a Route or an Action Point. When a Load is no longer on either of these, it is deleted from the environment by the underlying engine. In Discrete Events mode, Loads are not saved when an Experior Model is saved either, which they are in physics mode.   Built in Load types in Experior are implemented by a Load type class that inherits from Dynamic, which defines the physics actor implemented by a given Load type. Some of the physics related concepts implemented in Dynamic are also defined in the Load class, hence why their documentation will overlap.   Concepts Implemented in the Load Class A comprehensively detailed view of available methods and properties implemented can be found in the API Load Class documentation.   Generally Shared Implementation   Concepts that apply to all Loads, regardless of engine Experior is running in. Load Identification – Such as “Barcode” strings. Transformations Positioning (x = Length, y = Height, z = Width) Orientation Rotation (Yaw, Pitch, Roll) Load Coloring For selected/unselected state and highlighting when an action point is reached for instance. Selectable – Whether the Load is selectable by mouse clicks. Deletable Disposal Handling Visibility Grouping Defines whether a given Load is part of a group of Loads. Note: In Discrete Events mode, grouping/ungrouping Loads happen instantaneously, whereas the Physics engine requires finishing its current cycle of applying forces to Loads before grouping/ungrouping can occur. Attachment Whether the Load is attached to another RigidPart and therefore follows that RigidPart’s movement. Report Boolean to decide if the Load should be counted in the Statistics counter/window in Experior. Parenting Takes care of correctly setting parent/child hierarchies when multiple Loads are part of a grouping or attached to other RigidParts. User Data Users can add customized data to a Load, which for instance could represent data from a WMS such as PurchaseOrder, Customer Source, Destination, DueDate..etc. and attach it to the Load. Mouse/Keyboard Interaction methods open for extension Keyboard: KeyUp() and KeyDown() methods. Mouse: DoubleClick() method. Kinematic A Kinematic = true actor will act as if it has infinite mass, which means it can push regular non-kinematic dynamic actors away, but cannot be pushed back itself. Secondly, if movement is intended for the Part, the programmer must define the actor’s movement each time step, which can be useful if it is desirable that the object should follow a specific pre-defined path.  (Physics) Kinematic = false. (Discrete Events) Kinematic = true.    Physics Related Implementation   Friction coefficient – sets friction force of a Load, defining how easily it “glides” across a surface. Rigid – Matters in defining how the actor behaves when collisions occur. Also defines how precise the collision should be (as in how closely collision detection point matches point on the mesh) – this is also a question of performance, where rigid body shape complexity increases performance cost. Rigid body shape – has the following options: None Box (Default) Rounded Dice Sphere Convex Linear/Angular Dampening Linear/Angular Velocity Center of Mass Position When the physics engine applies a force to a Load to make it move, the force is applied into its center of mass. By default, a Load’s density is equally distributed over the whole volume of the Load and hence the center of mass of the Load is also its geometrical center. By providing the CenterOfMassOffsetLocalPosition, it is possible to move this center of mass and potentially place the center of mass lower than the geometrical center to, decrease the collapsing of a Load. Note: The value provided to this property is an absolute value. The CenterOfMassOffsetLocalPosition property provided in the property window of a feeder is a normalised value, where 0:0:0 is center of the Load and 0:1:0 would be at the top-center position.  Collision Detection (true/false) Default: true Density – used in calculating Load’s weight, which in Experior is Density * Volume. AddForce()/AddTorque() Sleep/Wake – Physics concept of enable/disable. Setting a Load as “Sleeping”, means it will no longer responds to physical forces applied to it, until it is enabled/woken up again.   Discrete Events Related Implementation   Loads move through an Experior model differently in Discrete Events mode compared to Physics, as described in the articles regarding differences between discrete events and physics and Action Points. The Load class contains implementations for handling moving Loads to another Action Point or Route, defining what should happen in the event of a Load reaching an Action Point, advancing simulated time and returning information regarding the events that occur for the Loads such as total distance traveled.   Examples of concepts implemented: Stopping/Releasing Loads on Action Points, meaning stopping and moving Loads when its a given Load’s time to step forward in time. Moving Loads directly to a specified Action Point Switching Loads to another Route or Action point with a variety of overloaded methods that handle different parameters, such as distance from start of the route, rotation and more. Distance (or “space”) a given load occupies on a route Getting the next event time, used by the Discrete Events engine to correctly determine the order in which to process the incoming events. RouteOffset can be set on a load, to offset it from the center line on a conveyor.  

The script window in Experior allows you to call the Experior API, within an instance of Experior.   It allows you to interact with Experior and e.g. stimulate the active model. An example usecase could be running a model without being connected to a physical PLC.   The shown model below has been set up through scripting, so that the first motor starts when a load activates the first sensor and a new load will be created when the load activates the second sensor. Gif is also attached as mp4 in this article.     The script window could contain following code: using System; using System.Numerics; using System.Windows.Media; using System.Linq; using Experior; using Experior.Core; using Experior.Interfaces; using Experior.Core.Loads; using Experior.Core.Routes; using Experior.Core.Communication.PLC; public partial class Main { public void On(object trigger, string symbol) { if (symbol == "SENSOR1") { Experior.Core.Motors.Motor.Get("MOTOR1").Start(); } if (symbol == "SENSOR2") { Experior.Core.Assemblies.Assembly.Get("FEEDER1").Activate(); } } public void Off(object trigger, string symbol) { } }   For pre-defined script helper methods, you can right-click within the script window to insert the following methods:   Initialize On (default inserted) Off (default inserted) Motor Started Motor Stopped Input Changed Output Changed Message Received Telegram Received Step Activation Arrived Enter (Action Point/Sensor) Leave (Action Point/Sensor) Elapsed Reset Pause Continue Dispose   Dispose:   When you press the “Compile” button in the top left of the script window the Dispose() method is called. You can use this method to unsubscribe from events and perform other clean-up actions.   Note: Since the Dispose() method is called before the compilation happens, it will not be the current version of the Dispose method as that one has not been compiled yet. It will be the Dispose method from the last time you compiled.   To make sure the Dispose method that is called matches the most recent implementation, it is best to compile every time you make changes to your Dispose method.   Initialize:   The Initialize method, runs as soon as compiling the script finishes.   On:   This method is called when:   Receiving input through a connection and the incoming data is of the type bool and its value is “True”. When a button is pressed in the “Control Panel” window. When a sensor is activated by a load.   Off: Same as On, but the value is “False”.   Motor Started: Is called when a motor is started.   Motor Stopped: Is called when a motor is stopped.   Input Changed: This is called when the input changes.   Output Changed: This is called when the output changes.   Message Received: Called when a message is received.   Telegram Received: Called when a telegram is received.   Step: Called at every frame update.   Activation: Called when an SRM is created.   Arrived: Called when a load arrives at a node.   Enter: Called when a load enters a sensor or actionpoint.   Leave: Called when a load leaves a sensor or actionpoint.   Elapsed: Called when a timer elapses.   Reset: Called when the scene is being reset.   Pause: Called when the scene or model gets paused.   Continue: Called when the scene or model gets unpaused.

On occasion, it can be useful to launch Experior with certain startup options to change the program’s functionality.   This article lists each command line argument, that you can use when launching Experior.   You can also view a list of these startup options by using the -help or -? command line argument when launching Experior.   Inputting the argument Command line (cmd) Open a command prompt (cmd.exe) Write path to your install directory, by default: “C:\Xcelgo\Xcelgo Experior 7\Experior.exe”  Append the argument and press enter (How it would look with default directory: “C:\Xcelgo\Xcelgo Experior 7\Experior.exe” -help)   Shortcut Right click the shortcut you use to launch Experior Click on Properties Go to the Shortcut tab In the field labelled Target:, append the text with your argument Click Apply and Ok Here is an example with the -help argument:     Visual Studio Right click the project that launches Experior Click on Properties Go to the Debug tab Go to Start options > Command line arguments Type in your argument Save (ctrl+s) Here is an example, once again using the -help argument:     Full list of startup options -help|-? Opens a command prompt with a list of all command line arguments available for the current Experior version.   -startupconfiguration <filepath> or new Specify a startup configuration file to use. You can read more about this here.   -config Displays the ‘Catalog Selector’ dialog during startup.   -headless Starts Experior in headless mode. NOTE: this will also enable webapi and graphicsserver   -webapi [off|filepath] Enable webapi or [off] to disable it or enable webapi and specify the webapi configuration file to use.   -graphicsserver [off] Enable graphics server or [off] to disable graphics server.   -model|-modelfile <filepath> Experior opens a model if the argument matches the name of an existing Experior model.   -phy|-physics Starts Experior in physics mode. (Only functional with the right privileges)   -variable Using variable time steps (physics mode). (Default: Experior is using fixed time step method)   frictiontype <Patch|OneDirectional|TwoDirectional> Starts the physics engine with the chosen friction type (only available in Physics mode). (Default: Experior is using Patch mode)   -physicsenginedynamics <Classic | Advanced> Enables advanced dynamics of loads which provides a more realistic motion of loads produced by conveyors and stacks stability (only available in Physics mode). (Default: Experior is using Classic dynamics)   -des|-event|-events Starts Experior in discrete Events mode. (Only functional with the right privileges)   -eng|-engineering Starts Experior in engineering mode. (Only functional with the right privileges)   -builder Starts Experior using ‘Builder’ profile. (Only functional with the right privileges)   -commissioner Starts Experior using ‘Commissioner’ profile. (Only functional with the right privileges)   -tester Starts Experior using ‘Tester’ profile. (Only functional with the right privileges)   -viewer Starts Experior using ‘Viewer’ profile.   -oem Start Experior in OEM licence mode. See OEM Setup (link)   -license <filepath|dongle[:id]>|offline[:id]> Specify either a specific license type to use (dongle, offline, or weblicensefile) or specific license (dongle:id). (example: -license C:\Experior\license.key) (example: -license dongle:xxxx)   -licenseusage <id> Set the licenseusage property for web license usage tracking.   -forcecheckin Check-in web license when Experior closes without asking user.   -libs <directory> Set an additional libraries directory. (example: -libs C:\Projects\Demo\)   -logfilemode <none|file|filedate|filemodelname> Set the log file mode. (example: -logfilemode file)   -log <filepath> Set a temporary log directory. (example: -log C:\Experior\Logs\)   -workdir <directory> Set working directory (permanently). NOTE: this argument will not work in combination with another argument. The application will not be started – only the directory will be set. (example: -workdir C:\Experior\)   -debug [none|debug|detailed] Enable debug level ‘Debug’ or optionally set debug level to specified level.   -reset Reset the Working directory and reset configuration files to default settings.   Automated Testing -continuous Keep discrete event engine running.   -autostart Run the model when it is loaded.   -stopafter <duration> Stop the model and close Experior after a period of time – ‘duration’ defines the time in seconds before the model stops and Experior starts closing.   -atstart <sym/name> Here you provide a symbol name or assembly name that should be activated when a model is started (after connections are established) so that this can initiate some action in the model.   -timescale <scale> Specify the time scale to use. (example: -timescale 2.5)   -seed <seed> The seed used by the random generator.   -eventfile <filepath> Loads an event file (*.events). (this is only possible when a model file is loaded at the same time)

There are two Connection types that utilize the CIP protocol. The Ethernet/IP – CIP connection and the Ethernet/IP – CIP Browsable. The former is made for performance and the latter is made for flexibility and is the subject of this article.   The connection is browsable, this means that it will scan for variables on the PLC and display them to the user. This contrasts with non-browsable connection that rely on the user to type in the correct address for each Input and Output.   Setting up the connection   First the connection needs to be created, then it must be configured. This includes settings the PLC type, the Rack Number, Slot number and the IP address of the PLC that the connection needs to communicate with:     Next step is to connect to the PLC. Right click the connection in the Connections window and click Connect:   The connection will request a variable list as soon as it connects with the PLC. Once the connection has the variable list it’s ready to be used. Please note that the variable list will only be available while the connection to the PLC is maintained.   Using the connection   The next step is to use the connection. This can be done by adding a button to the control panel. To do this select a square in the Control panel grid, right click and select a Button from the context menu:   Select the newly created button and expand the Pushed entry in the Properties window. Make sure that the connection ID property is the Browsable CIP Connection that was created earlier:   This will add the variable list. Locate a variable in that is of the BOOL type and check the checkbox. The Pushed Output of the button is now linked to the selected variable. If the button is pressed then the value of the variable in the PLC will be true, otherwise if will be false.   

The Transfer car is best described as a conveyor on a rail.   The conveyor can move along the rail, picking up and dropping off loads from and onto adjacent conveyors (stations).   Through the transfer car’s properties, you can assign any user created actionpoint as a pickup point or destination point.   When a load reaches a pickup point and it has its destination set to an actionpoint along the route of one of the destination stations.   The transfer car will move to the pickup point, transfer the load onto itself, move to the destination point and drop off the load.   Video demonstration (also attached)     In the video demonstration we have 3 actionpoints: AP1 - Middle of the first conveyor AP1 has its “Default Destination” property set to “AP3” AP2 - End of the second conveyor AP2 has its “Collision Mode” property set to “Leading” AP3 - Start of the third conveyor) AP3 has it set to “Center”

Experior can be used for a plethora of tasks and while it is designed for IT and/or PLC testing, the 3D graphics used in Experior make it an ideal tool for creating training or sales simulation too. Therefore, when you are creating a new model, it is important to choose the right level of details for the model. Should it be extremely detailed and look close to the real thing? Or should it have just a basic resemblance and instead focus on maximum effectivity? It depends on what the purpose of the model is.   IT & PLC tests If you want to use the model for testing, the focus should be on functionality. Basically, the less details the model has, the easier it will be for the program to run it, and the smoother the model will run in return. The more loads you want the model to run, the less details the program can render simultaneously. Of course, it should still be possible to see what each part of the model is supposed to represent in real life, but you probably do not need to be able to see every screw and button on every machine. If you need to lower the level of detail in a part of the model, take a look at our guide to how to do it HERE.    Simulation & Sales simulation For simulation the details are much more important to make the model look close to the real thing. Especially if you are running a sales-simulation you would want the customer to see, what they get as close to reality as possible. However, you probably do not need for the model to run as many loads simultaneously. Here you can focus on making the models look true to reality, even though the high level of details makes it harder for the computer to run as many loads, as you could with a lower detail level.   Examples Very detailed assemblies:   Decimated versions of the same assemblies  

Action Points is what triggers an event in a model built in Discrete Events mode. They are similar to sensors in Physics mode.   When you build a model in Discrete Events mode, you build it as a Path the loads will follow, which is a collection of Tracks. If you then want to have a certain event happen somewhere along the Path, you insert an Action Point on the desired Track. Adding an Action Point is done by right clicking on your Track, or Conveyor, and choosing ‘Insert Action Point’: The Action Point shows up as a small X in the middle of your Track. By clicking the Action Point, the properties window shows the available properties that can be changed. Behaviors related to the Action Point include: Changing the Action Point’s name. Behavior when a Load reaches the point (Stop Mode – dropdown menu). Default Destination – modifiable input string, which should be the Name of the destination Action Point. This property can be used to send a Load from a specific Action Point to another specified Action Point. Position on the Track/Route (Distance – which means millimeter away from the Track/Route’s start, as in the red arrow).  

The feeder and eater are two elements of a model that are closely connected. The feeder produces loads while the eater ‘eats’ the loads so they disappear from the model again. Read more about them beneath. Feeder As mentioned above, the feeder produces loads. Loads represent any product the model is designed to handle, for instance luggage, boxes or trays. If you double click a conveyor, it will produce a load. However, if you want to produce several loads, you will need to use a feeder. In the Physics mode, you can find the feeder in the Experior catalog under conveyors:   In the Discrete Events mode you can find the feeder in the demo catalog. From the catalog you can double click the feeder and place it in the scene. Alternately you can right click on a conveyor you wish to add the feeder to, and choose the ‘insert feeder’ option. Once you have added a feeder, it will start producing loads when you press play on the model. If you click on the feeder, you will be able to see its properties in the properties window. From here you can see, which type of load you are using as well as change load type under load>type. The default is a package but there are several options to choose from. A graphical overview of the all the available Load types – including the list shown in the image below: It is also possible to make your own loadtype by uploading your own file. You do this by selecting the loadtype called ‘file’. From here a menu will pop up, where you can upload your own. Besides showing the load type, the properties window for the feeder holds other information such as the loads size or any barcode connected to the loads. It is also possible to set a time interval for how often the feeder should produce a load. Alternately you can instruct the feeder to produce a new load when the previous load is a specified distance away from the feeder. Supported File Formats .x (Microsoft DirectX) .dae (COLLADA) .fbx (Autodesk FBX) .obj (Wavefront) .3ds (Autodesk 3D Studio) .ase (Autodesk 3D Studio ASCII) .stl (Stereolithography) .lwo (LightWave) .dxf (AutoCAD dxf) .glb 2.0 (binary) .gltf (embedded)  Eater  The eater only exists in Physics mode. You will find it under the sensor catalog>misc.>eater: When a load hits the eater, the load will get ‘eaten’ and disappear. In the properties window you can see the properties for your eater and change its size, visibility etc.  Linking a feeder and an eater It is possible to link an eater and a feeder to each other. For instance if you have build only parts of your model but still miss some functions, you can set it up so an eater eats the loads in one part of the model and then sends them directly to the feeder in another part of the model, making it possible to circumvent the part of the model, you have not yet build. If you wish to do this, you must go to the properties window of both the feeder and the eater in turn and enable the handover connection box: You also have to make sure that the port-numbers are a match and the computer does not already use this port – otherwise you will not be able to connect the two. When you have chosen matching port-numbers, that are not already in use, the feeder and eater will connect.   If you wish to connect a feeder and an eater that are not on the same device – for instance you have part of the model open on your computer, your colleague has another on his – it is possible to do so as well. You just need to make sure that the IP address in the properties for the eater matches the IP address of the device, the feeder is on. Then you can connect them.     

To learn more about the Experior User Interface please click an area of the picture you wish to know more about or select one of the categories below.     Menus Catalogs & Connections Model, Script & Routes Control Panel Logs, Loads, Inputs, Outputs, Alarms, Nodes, Schedule & Change History Statistics & Solution Explorer Properties

It is possible to extend the functionality of Experior with custom communication protocols. This is done by creating your own plugin and extending Experior.Core.Communication.PLC.Connection.   In case your connection is TCP/IP based you can extend from Experior.Core.Communication.PLC.TCPIP.Connection.   Experior.Core.Communication.PLC.Connection In attached memcom communication plugin a custom connection is made that doesn’t use the network to communicate but instead uses a memory stream. This plugin can be used to quickly test your Input/Output driven components. You do this by connecting an input and an output through the same address of the memcom connection.   For example link the Pushed PLC Input symbol of a button to Byte 1 Bit 0 of the memcom connection and also connect the Lighting PLC output to Byte 1 Bit 0 of the memcom connection. When pressing the button the lamp will light up:   The custom connection uses a memory stream to achieve this because a memory stream has similar behavior as a regular network stream.   The source code contains some notes explaining how to achieve the same functionality without the memory stream (and just share the data buffer).   Whenever the user assigns an input/output from a component to a PLC connection then this input/output is assigned to a PLC Buffer (Experior.Core.Communication.PLC.Buffers.Input/Experior.Core.Communication.PLC.Buffers.Output). These buffers maintain an array of bytes and grows/shrinks whenever new inputs/outputs are added/removed.   So in the constructor of the connection we create the buffers and subscribe to the events that are triggered when their size should change or when new inputs/outputs are assigned to them.   It is possible to have multiple buffers in a connection. Therefore we distinguish between them in a connection using a unique key (string) the Source.   In the example plugin only 1 Input buffer and 1 Output buffer is used, each with a default Source name equal to “0”.   In the constructor we also restore the saved buffer in case it exists. public MemConnection(MemConnectionInfo info) : base(info) { input = new Core.Communication.PLC.Buffers.Input(); // first restore the saved outputbuffer if it exists if (info.outputs != null && info.outputs.Count > 0) { output = info.outputs[outslot]; } else output = new Core.Communication.PLC.Buffers.Output(); //give the input and output buffer a unique slot name input.Source = inpslot; output.Source = outslot; // subscribe to the different events to react upon data changes or to properly allocate the buffers output.BufferChanged += new Core.Communication.PLC.Buffers.Output.BufferChangedEvent(OutputDataUpdated); input.BufferChanged += new Core.Communication.PLC.Buffers.Input.BufferChangedEvent(InputDataUpdated); Experior.Core.Communication.PLC.Connection.Inputs.LengthChanged += new Inputs.LengthChangedEvent(Inputs_LengthChanged); Experior.Core.Communication.PLC.Connection.Outputs.LengthChanged += new Outputs.LengthChangedEvent(Outputs_LengthChanged); Experior.Core.Communication.PLC.Connection.Outputs.ConnectionedAssigned += new Outputs.OutputEvent(Outputs_ConnectionedAssigned); Experior.Core.Communication.PLC.Connection.Outputs.ConnectionedUnAssigned += new Outputs.OutputEvent(Outputs_ConnectionedUnAssigned); Experior.Core.Communication.PLC.Connection.Inputs.ConnectionedAssigned += new Inputs.InputEvent(Inputs_ConnectionedAssigned); Experior.Core.Communication.PLC.Connection.Inputs.ConnectionedUnAssigned += new Inputs.InputEvent(Inputs_ConnectionedUnAssigned); // add sources to the connection AddSource(input); AddSource(output); Experior.Core.Environment.Scene.Loaded += new Core.Environment.Scene.Event(Scene_Loaded); }   When the user assigns an Input/Output to the connection it triggers the Experior.Core.Communication.PLC.Connection.Inputs.ConnectionedAssigned and  Experior.Core.Communication.PLC.Connection.Outputs.ConnectionedAssigned events.   In the example we only use this to set the Source property of the Input/Output private void Inputs_ConnectionedAssigned(Input sender, Core.Communication.PLC.Connection connection) { if (this != connection) return; // here you can react upon the sender being added to this connection // in our case we just want to ensure the proper Source is set sender.Source = inpslot; }   Due to the nature of the example connection it is crucial that the Input and Output buffer have the same size so a big part of the source code is related to this.   When assigning Inputs/Outputs to a connection Experior verifies whether the buffer size should change and in those cases triggers the Experior.Core.Communication.PLC.Connection.Inputs.LengthChanged or Experior.Core.Communication.PLC.Connection.Outputs.LengthChanged events.   At all times you ask the minimum and maximum used byte of a input/output buffer by providing the connection and the Source of the buffer: int max = Experior.Core.Communication.PLC.Connection.Inputs.MaxSize(this, inpslot); int offset = Experior.Core.Communication.PLC.Connection.Inputs.MinSize(this, inpslot);   If the buffer is not large enough anymore you can allocate sufficient bytes: // allocate (max-offset) bytes for the input buffer starting from offset input.Allocate(max - offset, offset, Experior.Core.Communication.PLC.Buffers.Buffer.Units.SINT);   Note: Experior.Core.Communication.PLC.Buffers.Buffer.Units.INT is used to indicate that the given size should be measured in bytes. In case Experior.Core.Communication.PLC.Buffers.Buffer.Units.SINT is used the size will be measured in words of 16 bits.   After the allocation the input.Data property will be an array of bytes with the proper size. When the user tries to connect the connection the EstablishConnection() method is called. When he tries to disconnect the Disconnect() method is called. In our example we override both methods and set the proper state of the connection (Core.Communication.State). When establishing the connection we make sure that the Input/Output buffers are allocated with the same size. In case we use a memorystream we also start listening on the stream (similar as we would be on a networkstream).   When the states of the Input/Outputs are changed this is immediately reflected in changes of the corresponding Input/Output buffers of the associated connection and the BufferChanged events are triggered. In our example we write the changed buffer to the memorystream. A different thread reads the memory stream and when the byte array is received it calls the byte[] DataReceived(string source, byte[] data) method of the connection to indicate that the given source has received the given data. int l = memStream.Read(incoming, 0, incoming.Length); if (l > 0) { DataReceived(inpslot, incoming); }   This triggers the proper events on the changed Inputs/Outputs. In the example without the memorystream we simply share the Data of the buffer and directly call the DataReceived method.   Experior.Core.Communication.PLC.TCPIP.Connection This connection class inherits from Experior.Core.Communication.PLC.Connection and mainly adds some TCPIP specific properties like Port, IP address and distinction between server and client connection: string IP: This getter property is used to get / or set the IPv4 address used by this connection. For a server connection this is 127.0.0.1 (localhost).   int Port: This property is used to get or set the port number for the TCPIP connection.   bool Server: Getter property to indicate whether this connection is used as server or client.

Action Points are points on a Route where a load can stop and stay. They are used internally by Experior as vertices or nodes in the routing graph (where parts of the route between the action points are the edges).   They are implemented in Experior using the Experior.Core.Routes.ActionPoint class.   Main properties: string Name: Getter property for the name of this actionpoint. string APName: Gets or sets the name of this actionpoint. Route Parent: This getter property returns the route to which this actionpoint is added. Assembly:  This getter property returns the Assembly object to which this actionpoint belongs. Vector3 Position: This getter property returns the global position of this actionpoint. bool Routing: Gets or sets a value indicating whether this actionpoint should be included as node in the routing graph. bool Selectable: Gets or sets a value indicating whether this actionpoint is pickable by the user. bool Selected: Gets or sets a value indicating whether this actionpoint is selected. Experior.Core.Reports.Statistics.Statistic.Counter Statistic: This getter property returns the counter statistic linked to this actionpoint. ActionPoint.StoppingMode StopMode: This property gets or sets the stopping mode of this actionpoint. Possible values are: StoppingMode.None, StoppingMode.Stop, StoppingMode.Capacity, StoppingMode.StopMotor and only available in discrete event mode StoppingMode.Interval. ActionPoint.Edges Collision: This property gets/sets when an actionpoint triggers its Enter event. float Distance: This property gets/sets the distance of this actionpoint on its route measured from the start of the route. bool Active: This getter property returns whether this actionpoint is active (has load) or not. Load ActiveLoad: This getter property returns whether the current load on this actionpoint (or null in case the actionpoint is not active). string VirtualNode: This property gets/sets whether this actionpoint is a virtual node or not (default). This VirtualNode is used to join a group of nodes into one edge in the route graph. All actionpoints with the same VirtualNode value will behave as 1 node in the routing graph. static ReadOnlyDictionary<string, ActionPoint> Items: Static getter property that returns a read-only dictionary with all existing user actionpoints. Key in the dictionary is the name of the actionpoint while the value is the actual ActionPoint instance. Note: this dictionary only contains actionpoints that were added by the user, it does not contain the actionpoints that were created by code internally in assemblies. The developer should keep track of those.   Main events: event ActionPoint.EnterEvent Enter: This event is raised when a load enters this actionpoint. event ActionPoint.ReleasedEvent Released: This event is raised when a load leaves this actionpoint. It can be because the load was never stopped, or because the load is deleted or released or  switched to another ActionPoint or Route. event ActionPoint.MoveToEvent MoveTo: This event is raised when the MoveTo method is called on the load. event ActionPoint.RemovedEvent Removed: This event is raised when an actionpoint is deleted.   Example: public ActionPoint CreateActionPoint (int index) { ActionPoint ap = new ActionPoint(); ap.Edge = ActionPoint.Edges.Leading; ap.StopMode = ActionPoint.StoppingMode.Stop; ap.Name = index.ToString(); ap.Enter += new ActionPoint.EnterEvent(ap_Enter); ap.Released += new ActionPoint.ReleasedEvent(ap_Released); return ap; } void ap_Enter(ActionPoint ap, Load load) { // Example of gathering and logging some routing info // we will lo the previuous and next actionpoint and the distance to them float nextdistance; float prevdistance; ActionPoint next = Route.FindNextActionPoint(ap, out nextdistance); ActionPoint prev = Route.FindPreviousActionPoint(ap, out prevdistance); if (next != null) Experior.Core.Environment.Log.Write("Next ActionPoint of " + ap.Name + " is " + next.Name + " at distance " + nextdistance); else Experior.Core.Environment.Log.Write("No next ActionPoint found for " + ap.Name ); if (prev != null) Experior.Core.Environment.Log.Write("Previous ActionPoint of " + ap.Name + " is " + prev.Name + " at distance " + prevdistance); else Experior.Core.Environment.Log.Write("No previous ActionPoint found for " + ap.Name); // example of some diverting decision based on load info if (load.Identification == ap.Name) { //divert load to route Int16 idx=0; if (Int16.TryParse(ap.Name, out idx)) { load.Switch(divertroutes[idx].Route); load.Release(); } } else load.Release(); } void ap_Released(ActionPoint ap, Load load) { Experior.Core.Environment.Log.Write("ActionPoint " + ap.APName + " is released by load " + load.Identification); }   Main static methods static string GetValidName(string prefix): Actionpoints require a unique name. This method will create a unique name with the given prefix. static ActionPoint Get(string name): A factory method to create and return an actionpoint with the given name.If there was already an actionpoint with the given name then this existing one is returned. static ActionPoint Release(string name): This static method will release the actionpoint with the given name.

Routes are used in Experior to move loads following a track (linear, curve) without usage of the physics engine. Therefore routes are mainly used in discrete event mode. Routes are implemented in Experior using the abstract base class Experior.Core.Routes.Route. A straight route is implemented by the Experior.Core.Routes.Linear class, while a curved route is implemented by the Experior.Core.Routes.Curve class.   Routes may contain Action Points which typically represent destination points or decision points. By connecting routes Experior calculates the routing graph based on the nodes (action points) in the network. This routing graph can be used to calculate the shortest path to a new destination (Action Point ).   To incorporate routes in the working area and other components they are usually encapsulated in a TransportSection assembly. The TransportSection assemblies themselves are used as building blocks in the different Track assemblies.   A Route keeps track of the loads that are moving on it and of the Action Points it contains.   Note: In discrete event mode loads are always on a Route or on an Action Point. (Loads that are Deletable will be automatically deleted by Experior when they are not on a Route or Action Point).   Main properties: List ActionPoints: Getter property that returns all action points on this route.   LinkedList Loads: Getter property that returns all loads on this route.   Load First: Getter property returning the first load on this route.   Load Last: Getter property returning the last load on this route.   bool Bidirectional: Property that indicates whether Experior should consider this route as bidirectional or not when constructing the routing graph. Suppose the route between action points AP1 and AP2 is bidirectional than this means that the routing graph will have two edges between the vertices AP1 and AP2. In case the bidirectional property is false only 1 directed edge from AP1 to AP2 is available. Setting the bidirectional property has no impact on the actual movement of the loads: the developer still has to ensure that a load can move in opposite direction.   Motor Motor: Property that gets/sets the Motor used to control the movements of the loads on this Route. Changing the speed of the motor will change the speed by which loads move on its route and changing the speed sign will make the loads move in opposite direction.   Vector3 Start: Property that gets/sets the global position of the startpoint of the route.   Vector3 End: Property that gets/sets the global position of the endpoint of the route.   float Yaw: Getter property that returns the global Yaw of this route.   float Length: Property that gets/sets the total length of this route   bool Vertical: Property that gets or sets whether the route is vertical or not. This has an impact on how loads are positioned on the route.   bool Visible: Gets or sets a value indicating whether this Experior.Core.Routes.Route is visible.   float Yaw: Getter property that returns the global Yaw of this route   Main events: event Route.ArrivedEvent Arrived: This event is raised when a load arrives. This is not synchronized with the discrete event execution.   event Route.LoadAddedEvent LoadAdded: This event is raised when a load is added to the route.   event Route.LoadRemovedEvent LoadRemoved: This event is raised when a load is removed from the route.   static event Route.UpdatedEvent Updated: This event is raised when the routing graph is updated.   Main methods: void Add(Load load): This method will add the given load to the start of this Route.   void Add(Load load, float distance): This method will add the given load to this Route at the given distance from the start.   void Remove(Load load): This method will remove the given load from this Route.   ActionPoint InsertActionPoint(float distance): This method will create and return an actionpoint and position it at the given distance from the start of this route.   void RemoveActionPoint(ActionPoint ap): This method will remove the given actionpoint ap from this route.   void ClearLoads(): This method will remove all loads from this route.   Main static methods: static ActionPoint FindNextActionPoint(ActionPoint ap): Given an actionpoint ap this method will return the next axtionpoint on the route (returns null if no actionpoint is found).   static ActionPoint FindNextActionPoint(Route route): Given a Route route this static method will return the first actionpoint on that route.   static ActionPoint FindNextActionPoint(ActionPoint ap, out float distance): Given an actionpoint ap this static method will return the next actionpoint on the route (if any) and put the distance between the two actionpoints in the distance out parameter. static ActionPoint FindPreviousActionPoint(ActionPoint ap, out float distance): Given an actionpoint ap this static method will return the previous actionpoint on the route of ap and put the distance between the two actionpoints in the distance out parameter. If the route of ap does not have a previous actionpoint then the previous route is looked at to find the previous actionpoint.   static float ShortestDistanceToActionPoint(Load load, string destination): Given a load and the name of an actionpoint this static method will return shortest distance from the current position of the load to the actionpoint by following the shortest path on the linked routes. If no path can be found float.PositiveInfinity is returned and a warning is logged.   static float ShortestDistanceToActionPoint(string sourceAP, string destinationAP): Given the name of a source actionpoint  and the name of a destination actionpoint this static method will return shortest distance between the two actionpoints by following the shortest path on the linked routes. If no path can be found float.PositiveInfinity is returned and a warning is logged.   static void Update(): This static method will result in the updating of the routing graph. (This is also called when a user deletes or adds an actionpoint)   Example: float distance = Route.ShortestDistanceToActionPoint(load, "AP3"); if (float.IsInfinity(distance)) { Experior.Core.Environment.Log.Write("No path found from load " + load.Identification + " to actionpoint AP3"); } else { Experior.Core.Environment.Log.Write("Distance from load " + load.Identification + "to actionpoint AP3=" + distance); } distance = Route.ShortestDistanceToActionPoint("AP2", "AP3"); if (float.IsInfinity(distance)) { Experior.Core.Environment.Log.Write("No path found between AP2 and AP3"); } else { Experior.Core.Environment.Log.Write("Distance from AP2 to AP3=" + distance); }