When you have downloaded the desired version of Experior, run the .exe.    Before you install, please take the time to read the license agreement. When you have read it, choose I agree to continue: Experior is as default installed as ‘C:\Xcelgo\Xcelgo Experior 7’. If you want a custom installation directory click the Options button. Otherwise click the Install button. The program will now install. If a User Account Control window appears click YES to allow the .exe to install Experior in the defined install directory.   Once the installation is complete, click CLOSE to finish. Using a web license To use Experior with a web license you must place the license key file in the Experior installation folder. As default this is: C:\Xcelgo\Xcelgo Experior 7   The License key file name has the following signature: license.(LicenseID).(LicenseType).key   Minimum PC Requirements CPU – Quad Core CPU with 8MB Cache and DDR3 Graphics card – Nvidia Gt 710 2GDH3 or equivalent Memory – 8GB Ram Disk Space – 900MB Operating System – Windows 10 Recommended PC Requirements CPU – Hexa Core CPU with 12MB Cache and DDR4 Graphics Card – Nvidia Gtx 1070 8GB or equivalent Memory – 16GB Ram Disk Space – 900 MB Operating System – Windows 10/11  

Prerequisites As a prerequisite for creating an OPC UA connection, an OPC UA server must be configured on your controller and must be started.   For a description of the procedure required for starting the emulation of Schneider Electric controllers from EcoStruxure Machine Expert, refer to the How to Emulate User Guide in the EcoStruxure Machine Expert online help. For information about starting an OPC UA server on a PacDrive LMC controller, refer to the OPC UA Server Configuration in the LMC Device Objects and Parameters part of the EcoStruxure Machine Expert online help. For information about starting an OPC UA server on a Modicon M262 Logic/Motion Controller, refer to the OPC UA Server Configuration in the M262 Logic/Motion Controller - Programming Guide in the EcoStruxure Machine Expert online help.   Creating an OPC UA Connection To create an OPC UA connection, proceed as follows: Step Action 1 In the Connections view, right-click inside the table and run the command OPC UA Client from the contextual menu. Result: A new row is added to the table with Protocol = OPC UA. 2 Select this row and configure the connection in the Properties view. 3 In the Communication section, edit the OPC Server Address parameter to enter the IP address and the port of the controller you want to connect to. Use the following format as an example, using the default port 4840: opc.tcp://127.0.0.0:4840 4 In the Connections view, right-click the row you created for the OPC UA connection and run the Connect command from the contextual menu. 5 Enter the Username and Password in the OPC UA Credentials dialog box. NOTE: If anonymous login is allowed by the OPC UA server, select the check box "Anonymous login" in the "Properties view"  to avoid this dialog box for future logins. Result: The message Untrusted Certificate is displayed. 6 Verify that you are about to connect to the correct URL and you trust the certificate. Click Yes to proceed or No to cancel. Result: After the connection to the controller is established, you can see Status = Connected displayed in the row of the selected connection. The available tags are read from the OPC UA server, as indicated in the Logs view by the messages Started reading tags and Finished reading tags. The controller variables can be selected within Experior 7.   OPC UA-Specific Settings in the Properties View The following settings of the Properties view are specific to OPC UA connections: Parameter Description Communication Auto Re-Connect Select this option to perform automatic reconnection attempts when the OPC UA connection is interrupted. Auto Re-Connect Delay Enter a delay for starting the first reconnection attempt after the connection has been interrupted and between the individual reconnection attempts. Default value: 5000 ms Infinite Re-Connect attempts Select this option for an unlimited number of reconnection attempts. The waiting time between each attempt is defined by the Auto Re-Connect Delay parameter. Auto Re-Connect Max. attempts Enter a maximum number of reconnection attempts. The waiting time between each attempt is defined by the Auto Re-Connect Delay parameter. Default value: 5 Anonymous Login If anonymous login is allowed in the OPC UA server (for details, refer to the description of the Disable anonymous login parameter in the OPC UA Server Configuration in the M262 Logic/Motion Controller - Programming Guide in the EcoStruxure Machine Expert online help) select this check box to avoid entering credentials. Communication Interval Enter the minimum delay (in ms) that must elapse between the OPC UA client data requests sent to the OPC UA server. Default value: 16 ms NOTE: Consider the impact this polling frequency can have on the performance of the OPC UA server when reducing the value. If you transfer a large amount of data using an OPC UA connection, consider increasing the polling frequency to avoid slowing down the performance of the OPC UA server. OPC Server Address Enter the IP address and the port of the controller you want to connect to. Use the following format as an example, using the default port 4840: opc.tcp://127.0.0.0:4840 Use Publish-Subscribe Select this check box to activate the publish/subscribe data exchange between the OPC UA client and server.

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.

Due to our move from a self hosted webpage to the following community structure, the API documentation is now available as static html files you need to download attached file, unzip and then open any one of the html files in the folder.

The control panel allows you to insert controls for communicating with the PLC. By right clicking on an empty square of the control panel you will open a control menu, from which you can choose different types of controls:   The only difference between the first six controls is variation in design. The buttons work when you press them while the lamps light up when a specific PLC signal is sent. The knob button allows you to switch between many different values, which you can choose in the properties window. The gauge will show values sent from the PLC. ‘Switches’ allows you to choose between two state and three state switches:     When you have chosen a control, you can see its properties in the ‘Properties’ window. You will also be able to change its name and color here as well as changing different other values for the control:   If you right click the button you can either delete it or copy it to get another button with the exact same attributes.   If you right click on the ‘controls’ tabs at the top of the control panel you will see a menu allowing you to make changes to the tab:     RIGHT: Allows you to move the controls tab right to change the order of the tabs. NEW CONTROL PANEL: Create a new control panel DELETE (Tab name): Delete the tab with the corresponding name DELETE ALL: Delete every controls tab UNDOCK: Move the controls tab around to another position in the Experior window ALIGNMENT: Choose where in the control panel the controls tabs are situated  

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.

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.

With a developer license for Experior 7 it is possible to create custom catalogs, controllers, plugins and more in your Experior model. We have three different templates packaged in a .vsix (Visual Studio Integration Extension) file that you can download and run, as long as you have Experior 7 and Visual Studio installed. This .vsix is attached in this article in a zip file - Simply download and extract to run the installer.   To avoid confusion, we recommend removing the old Catalog, Controller and Plugin templates before installing the new ones. Removing old templates   To remove the old Visual Studio templates:   Close Visual Studio   Navigate to the C# visual studio template folder. The standard path for this is: C:\Users\ your username \Documents\Visual Studio 20XX\Templates\ProjectTemplates\(Visual) C#   Delete the zip files named: “Experior-7.0-Catalog-Template.zip”, “Experior-7.0-Plugin-Template.zip” and “Experior-7.0-Controller-Template.zip”.   If you get an error dialog saying: “This extension is already installed to all applicable products” You can navigate to: c:\users\[username]\AppData\Local\Microsoft\VisualStudio\17.0[hashid]\Extensions\   If any of the folders here contain Experior template files. Delete the folder. Then try running the VSIX installer again.   Output path   By default, the output path of the templates is set to the default installation location of the Experior executable.   This is defined by the environment variable: “EXPERIOR7_BIN” which is created when you install Experior 7 - by default: (C:\Xcelgo\Xcelgo Experior 7).   This means that when you build your project, the project output (*.dll) is created in that folder.   Make sure “Copy local” is set to “false” for Experior specific dll’s.   You can change this output path through the project properties. But in order for Experior to load it, you need to provide an External Libraries location.   This can be done in several ways: – Through the catalog selector’s External Libraries dropdown when Experior is started with “-config” – Through using a Startup Configuration file when Experior is started with “-startupconfiguration <file>” – Through an External Libraries path when Experior is started with “-libs <path>”   You can also manually drag and drop the dll from the folder you build to, into the Experior installation folder.   Warning:  When using an External Library folder, any dll that is present in both the External Library folder and the Experior installation folder causes errors.  

To support various Continous Integration (CI) setups, from Experior version 7.0.23105 onwards, you can now load unsigned catalogs and plug-ins – if using a Developer license.   The feature is two-folded. Part one is the skipping of signing the catalogs and plug-ins – this can be done in one of two ways.   Remove the Experior.Build UsingTask in the csproj – either by removing it entirely or adding a Conditional attribute. Or by configuring the Experior.Build by setting the new attribute ‘Skip=”true”‘.Example: <Experior.Build AssemblyFileLocation=”$(OutputPath)$(TargetFileName)” Debug=”true” Skip=”true”></Experior.Build> Now you are compiling/building the catalog or plug-in without signing it. Previously you would not be able to load the catalog or plug-in in Experior, but with the new version you are able to load them if you are using a valid Developer license.   A usescase could be to save time in CI pipelines. Visual Studio solutions with many plug-ins could use a substantial time just doing the signing process. These steps can now be avoided.   Note:   If you are using a non-developer license, catalog and plug-in checking is done as usual (catalogs and plug-ins must be signed) – meaning checksum and Key checking etc. will be performed as expected.   If you are using a Developer license and a valid ‘Tail’ / signing is found, then it also will be checked as usual. So the new feature is that Experior will allow catalogs and plug-ins without a tail.

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.

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 3964R-Protocol is a serial point-to-point protocol for communication between two programmable logic controllers (PLC). Can be set up to use an ethernet connection or a serial (RS-232/RS-422/RS-485).   TCP/IP Properties Identification Name – Customizable name Id – Customizable Id   Communication Port – Port used for communication between EcoStruxure Machine Expert Twin and “Device” Mode – Select “Server” or “Client” Auto Connect – Activate or Deactivate whether Experior should try to automatically connect to the “Device”   Serial Properties Line Signals DTR – Select if DTR (Data Terminal Ready) is to be used RTS – Select if RTS (Request To Send) is to be used Handshake – Choose from ‘XOnXOff’, ‘RequestToSend’ or ‘RequestToSendXOnXOff’ handshake protocols   Port Settings Port Name – Select the name of the port Baud Rate – Select the baud rate at which to connect Data Bits – Enter the number of data bits to be used Stop Bits – Choose from ‘One’, ‘Two’ or ‘OnePointFive’. Parity – Choose from ‘Odd’, ‘Even’, ‘Mark’ or ‘Space’   Identification Name – Customizable name Id – Customizable Id   Communication Auto Connect – Activate or Deactivate whether Experior should try to automatically connect to the “Device” Auto Connect Delay – If Auto connect is checked you can set a delay (in miliseconds) after which the connection will attempt a reconnection

There are two different ways to connect to a PLC depending on whether you use a tag based or an address based connection. If you wish to use a tag based connection you have to start by connecting to the PLC in the Connections window. If you want an address based connection you have to wait to connect to the PLC in the connections window until you have chosen the right settings for the object, you wish to connect.    It is possible to connect most assemblies and controls in the model to a PLC, such as connecting a lamp or a sensor. You have to choose which PLC you wish to connect to for each individual input and output, not just for the assembly as a whole.  If you only have one PLC in the connections window, the object will automatically choose this PLC. If you have more than one PLC  you can choose which PLC to connect to in the assembly’s properties window under ‘connection id’. Having the PLCs connected already only works if you want to use a tag based connection on the object. Then, when you have chosen which PLC to connect to, you can see a list of tags in the properties window. Choose the corresponding tag and the object will be connected to the PLC.   If you wish to use an address based connection you have to start by going to the properties window for the object you wish to connect. Here you should find the PLC input or PLC output category and press the toggle arrow on the side of the category:   Now you can go to the Address field and type in the address for your PLC. You can also choose the right source in the source field. Then you can go to the connections window and connect the PLC so the object will begin sending information to your PLC.

When the Experior layout is set to default mode, you will find the connections and catalog window on the top left side of the screen. This window has a few different functions:   Catalog Connections   1. Catalog The catalog is where you can see the assemblies that are available to you. The catalogs function as a form of libraries where you can browse the different assemblies and other items. Which assemblies shows up depends on which catalogs you have loaded when you started Experior. In the very beginning you should see a window like this: If this window does not show up when you start the program, please read about the Experior startup options here.   This window is where you choose which catalogs will be loaded into the program. Make sure to at least include some of the catalogs, otherwise the catalog window will show up empty and you will have no assemblies to build your model from. Once you have chosen your catalogs they will show up in the catalogs window. To see what each catalog contains either double click on it or click the small arrow to the left of the catalogs name. This opens up any sub categories which you can in turn open up too, to see the individual assemblies. Once you have found the assembly you need, you can either click on it and then click on the model floor to insert it into the model or you can chose to drag it to where you want it placed and then click to place it. The catalogs window also has a few additional features. You can change the layout of the catalogs on the top left of the window: There are two different views to choose from depending on your preferences: Gallery view style:   Tree view style:      To the right of the catalog layout buttons in three view you have the option to zoom in and out on the content of your catalogs. Below that you have a search bar, where you can search for any specific assemblies in your catalogs. Above the zoom buttons is a small tack titled Auto Hide. Pressing this button will hide the catalog and connections window right below the Experior menu bar so it looks like this:     To reset the window to its original position either drag it back to where you want it and hover over that spot until you have the option to place it or go to the View tab in the menu bar and choose reset windows.   2. Connections   The connections tab is where you can connect to your PLCs or higher level systems. When you first open Experior the window will be empty. However, if you right click within the window a menu will show which allows you to create connections:   From this menu you can choose which kind of connection you wish to make. You can choose between low level (PLC connection) and high level. When you have chosen one or more PLC connections they show up in the connections window like this:    You then specify the IP address of the PLC in the properties window and right click on the connection in the connections window. Then a menu will show up which looks like this: CONNECT ALL: Connect all the PLCs at once (this only works providing you have entered an IP address for each connection) CONNECT: Connect this specific PLC ENABLE LOGGING: Log all the messages that the PLC sends and then shows them in the log window IMPORT: Import all addresses from the PLC in an Excel file EXPORT: Export the addresses as an Excel file ALARMS: Opens a new window that allows you to set alarms and which error messages they will display.  DELETE: Deletes the connection   Please note: The menu can have fewer options depending on the type of connection.   ALARMS WINDOW: The subscribe column lets you choose whether or not the alarm is activated. Address, bit and source shows the specific ‘address’ of the alarm. If you think of the address like an actual physical address, the ‘address’ column shows the road name, the ‘bit’ is the house number while the ‘source’ is the postcode.     If the connection to the PLC is address based you can only add alarms when the PLC is not connected. However, if the connection is tag based you can only add alarms when the PLC is connected. Read more about alarms here.   Besides being able to set the IP address in the properties window you also have the option to customize the connection here in other ways.  

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

Purpose of the article Recent Windows updates have introduced additional steps necessary for Experior to run optimally. In this article, we aim to share recommended settings that we advise customers to apply to their PCs to enhance performance. We are happy to extend the list with advice provided by you the customers, so feel free to get in contact with us and let us know how you setup your work stations.   Windows With recent updates to Windows, both we and our customers have noticed that the display settings in Windows can override those set in the Nvidia Control Panel (and possibly other graphics card providers as well). Therefore, it is crucial for Experior users to ensure that Experior is designated as a high-performance application in the Windows graphics settings. Here’s how to do it easily:   Open Graphics Settings: In the Windows search bar, type “graphics settings” and select the matching result.    Enable Hardware-Accelerated GPU Scheduling: In the graphics settings window, start by choosing “Default graphics settings” and ensure that “Hardware-accelerated GPU scheduling” is turned on. Add Experior as a High-Performance App: Back in the graphics settings window, you need to add Experior with custom options. Click the “Browse” button under the “Add an app” menu. This will open a file explorer window. Navigate to the Experior installation directory, which is as standard set at  C:\\Xcelgo\\Xcelgo Experior 7 . Select  Experior.exe  and click “Add.” It should now appear in the list below. Set Experior to High Performance: By default, the app will be set to “Let Windows decide.” Change this setting to “High performance” to ensure that Experior utilizes your high-performance GPU.   Nvidia Control Panel To ensure that Experior runs smoothly in Physics mode, it is still important to configure your Nvidia settings properly.   Open Nvidia Control Panel: Right-click on your desktop and select Nvidia Control Panel from the context menu. Manage 3D Settings: In the Nvidia Control Panel, click on Manage 3D settings from the left sidebar. Select the Preferred Graphics Processor: Under the Global Settings tab, find the option labeled Preferred graphics processor. From the dropdown menu, select High-performance Nvidia processor.  Set PhysX Configuration: Next, go to the Program Settings tab. In the Select a program to customize dropdown, find and select Experior (if it’s not listed, you can add it using the Add button). Below that, locate the PhysX settings section and choose your high-performance GPU from the dropdown menu.   Apply Changes: Once you’ve made these changes, click the Apply button at the bottom right corner of the window to save your settings. By following these steps, you can ensure that Experior utilizes the high-performance GPU for optimal performance   improvement tips for extended period model runs When running a simulation for an extended period of time, it is important to ensure that Windows runs stable. For this we suggest that you:   Disable hibernation Disable power optimizations (CPU throttling, screen off, hd off, USB power etc.) Disable windows update Don’t logoff/logon while running

The Startup configuration file is used to launch experior with a set of predefined options.   In order to generate this file, you first start Experior with the command line argument -startupconfiguration new   This will create the file “StartupSettings.json” in the install directory folder, which as standard is set to: C:\Xcelgo\Xcelgo Experior 7   You can now navigate to the folder and edit this file with a text editor.   To make use of the settings, start experior with the command line argument -startupconfiguration (filepath)   Note: Remember to include the filename and extension in the filepath. Referencing the directory is not enough.   The command line arguments have a higher priority than the configuration file options. This means, that an option set in both the configuration file and the command line, will use the command line argument.   The options in the configuration file that are available as command line arguments are listed in the “Startup options” article.   The data is formatted in JSON and the file looks like this:   { "Config": false, "Headless": false, "DebugLevel": "None", "LogMode": "FileDate", "LogDir": null, "WorkDir": null, "SelectedEngine": "Events", "PhysicsFrictionType": null, "TimeScale": 1.0, "ContinuouslyRunning": false, "Seed": 0, "OEM": false, "WebApiEnabled": false, "GraphicsServerEnabled": true, "ModelToLoad": "C:\\Projects\\ExampleProject\\Models\\ExampleModel.Experior", "AutoStart": false, "StopAfterSec": 0, "AtStart": "", "EventFile": "", "LicenseSource": "", "LicenseUsage": "", "ImpersonateProfile": "None", "ForceCheckIn": false, "FingerprintReport": false, "SelectedCatalogs": [ "Experior.Catalog.Training.dll", "Experior.Catalog.ExampleCompany.Conveyors.dll", "Experior.Catalog.ExampleCompany.Feeders.dll", "Experior.Catalog.Xcelgo.GuidedPath.dll", "Experior.GuidedPath.Base.dll", "Experior.Catalog.Xcelgo.Buildings.dll" ], "SelectedExternalLibsPath": "", "ExternalLibsPaths": [], "BetaFeaturesEnabled": false, "ValidateSerialization": false, "LicenseServerFallback": false, "WebApiConfigurationFilePath": "" }   Config: Option type: boolean (true or false). Description: true will force a display of the ‘Catalog selector’ during startup, false will only display the dialog in case an input is needed. Default: false.   Headless: Option type: boolean (true or false). Description: true will start Experior in ‘headless’ mode (i.e. console mode with no UI other than console input/output), false will start Experior in UI/IDE mode. Default: false.   “DebugLevel”: Option type: string (“None”, “Debug” or “Detailed”). Description: Set the desired debug level. Default: “None”.   “LogMode”: Option type: string (“None”, “File”, “FileDate” or “FileModelName”). Description: Set the desired log file mode. Default: “None”.   “LogDir”: Option type: filepath string (null, empty or a valid directory path). Description: Set the desired log file directory path. Default: null (will result in debug.log in %localappdata%\Xcelgo\Experior\7\Work\Logs\debug.log).   “WorkDir”: Option type: filepath string (null, empty or a valid working directory path). Description: Set the desired work directory path. Default: null (will result in workdir being %localappdata%\Xcelgo\Experior\7\Work\).   “SelectedEngine”: Option type: string (“Physics”, “Events” or “Engineering”). Description: Set the desired engine type. (Only functional with the right license privileges). Default: “Physics” if several engines allowed otherwise the single allowed engine.   “PhysicsFrictionType”:  Option type: string (null, empty, “Patch”, “OneDirectional” or “TwoDirectional”). Description: Starts the physics engine with the chosen friction type (only available in Physics mode). Default: “Patch”.   “PhysicsEngineDynamics”:  Option type: string (null, empty, “Classic” or “Advanced”). Description: 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: “Classic”.   “TimeScale”:  Option type: floating point value (positive). Description: Specify the time scale to use. Default: 1.0. Example: 2.5   “ContinuouslyRunning”: Option type: boolean (true or false). Description: Prevents the model from stopping automatically when certain situations occur. (Example: In “Events” engine mode, the last load in the scene is deleted.) (Only applied in case of an applicable engine type) Default: false.   “Seed”:  Option type: integer. Description: The seed used by the random generator. Default: 0.   “OEM”:  Option type: boolean (true or false). Description: Start Experior in OEM licence mode. See OEM Setup (coming soon) Default: false.   “WebApiEnabled”:  Option type: boolean (true or false). Description: Enable or disable WEB API. Default: true if headless is true, otherwise false.   “GraphicsServerEnabled”: Option type: boolean (true or false). Description: Enable or disable Graphics Server. Default: true if headless is true, otherwise false.   “ModelToLoad”: Option type: filepath string (null, empty or valid filepath). Description: Set the desired model file to load after startup. (example: “C:\\Projects\\ExampleProject\\Models\\ExampleModel.Experior”) Default: null   “AutoStart”:  Option type: boolean (true or false). Description: Run the model when it is loaded. Default: false   “StopAfterSec”:  Option type: integer. Description: 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. Default: 0   “AtStart”:  Option type: string (null, empty or valid symbol or assembly name). Description: 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. Default: empty   “EventFile”:  Option type: filepath string (null, empty or valid filepath). Description: Loads an event file (*.events). (this is only possible when a model file is loaded at the same time) Default: empty   “LicenseSource”:  Option type: string (null, empty or valid filepath). Description: 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) Default: empty   “LicenseUsage”:  Option type: string (null, empty or any string with maximum length of 50 characters). Description: Set the licenseusage property for web license usage tracking. Default: empty   “ImpersonateProfile”: Option type: string (“None”, “Viewer”, “Tester”, “Commissioner” or “Builder”). Description: Start Experior at a lower license level than the one you have access to. (See: Types of Licenses ) Default: “None”   “ForceCheckIn”: Option type: boolean (true or false). Description: Check-in web license when Experior closes without asking user. Default: false   “FingerprintReport”: Option type: boolean (true or false). Description: For License debugging, appends a log file with a timestamp and license information. Default: false   “SelectedCatalogs”: Option type: array of strings (null, empty or an array of valid filenames). Description: A list of catalog dll filenames for catalogs that should be loaded when Experior starts. Default: empty   “SelectedExternalLibsPath”: Option type: directory path string (null, empty or a valid directory path). Description: A path to any libraries (dll’s) not within the Experior installation folder, that Experior should reference on startup. Any catalog dll’s contained within this folder will appear in the catalog selection window, when starting Experior. Default: empty   “ExternalLibsPaths”: Option type: array of directory path strings (null, empty or an array of valid directory paths). Description: Any other paths to catalog dll’s can be set here, these paths will be selectable in the dropdown of the catalog selector window, when starting Experior. Default: empty   “BetaFeaturesEnabled”: Option type: boolean (true or false). Description: Certain experimental features can be enabled with this set to true. Default: false   “ValidateSerialization”: Option type: boolean (true or false). Description: Validates loaded catalogs to make sure there are no issues with serialization (saving/loading). This is useful for debugging catalogs, as you dont need to load a model or create assemblies in the scene to trigger an error. Default: false   Example: If 2 catalogs have an assembly infoclass that uses the same xml typename, Experior won’t know which one to load.   “LicenseServerFallback”: Option type: boolean (true or false). Deprecated (no longer used) Default: false   “WebApiConfigurationFilePath”: Option type: filepath string (null, empty or a valid filepath). Description: The webapi configuration file. See: “Startup Options” article -webapi Default: empty (will result in default values)   “CoordinateSystem”: (optional) Option type:  string (“LeftHanded” or “RightHanded”). Description: Determines whether Experior should use a Righthanded or Lefthanded coordinate system. Default: “LeftHanded”

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)

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  

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.