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.

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

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.

TECH TIP  😺🖥   Someone asked; “Is it possible to get the logs generated by Experior inside my VM or docker container, stored somewhere in a common accessible location – and can you perhaps make them easily searchable/filtered etc. ? ”.   Ok…first question; Getting hold of the logs ?;   Experior already provides an easy way to get a hold of the logs (or rather receive the logs as they are generated) via the API. Simply create an Experior plugin where you implement interface ‘Experior.Interfaces.ILogTarget’ and subscribe in to our Experior.Core.Environment.Log.Subscribe(ILogTarget) and you have a class that will receive all logs from Experior. public class InfluxDBLogTarget : Experior.Interfaces.ILogTarget { public string LoggerId { get; } = "MyId"; public string LoggerLocation { get; } = "MyLocation"; public bool Enabled { get; set; } public bool Active { get; } public void Open() { Experior.Core.Environment.Log.Subscribe(this); } public void Close() { Experior.Core.Environment.Log.Unsubscribe(this); } public void Log(ILog log) { //todo - log to destination } public void Log(List<ILog> logs) { //todo - log to destination } public void ClearLog() { //todo - clear destination if supported } public void Dispose() { Close(); } }   So far so good…   Destination ?: You have a ton of options here, since Experior doesn’t restrict you using any of the thousands of 3rd party software, nugets, libraries or custom code (build from scratch in F# if that’s your preferred flavor). For this example we decided to try out the interesting InfluxDb (https://www.influxdata.com/).   InfluxDb is a high-performance time series database, that comes with several ways of ingesting data (getting data into it).   After a few minutes of google time, InfluxDb was installed on our windows box using docker (www.docker.com).   For getting data into the Influx database, there seems to be a couple of ways to go about this. Direct web API, C# client, or using a Telegraf plugin.   We love nugets and luckily there’s a nuget for it (InfluxDb.Client – https://www.nuget.org/packages/InfluxDB.Client/). Add the nuget to the project and copy the example code and you are off.   Result; So after a couple of hours, filling out the methods of our ILogTarget implementation, we end up with an Experior plugin (in this case I named it ‘InfluxDbLogTargetPlugin’) that is able to receive all Experior logs, and relay them to a running InfluxDb server. I added some extra options to convert logs into ‘syslog’ format etc. – just for the fun of it – it was that simple.   Seems to be working great, but I need play around with doing a proper logview dashboard (below is just raw-data viewing using the built-in InfluxDb UI). Sounds like the older 1.8 version had a syslog logviewer built in, but it was removed from the 2.0 version.   Or perhabs Grafana has a better one. Grafana is another interresting visualization tool that can easily be used in conjuction with InfluxDb.   Thoughts have already started on doing a plugin that provides means for logging simulation/emulation data to InfluxDb and using one of the visualization packets on top of it – that could also be cool 👾   Happy logging 😺🏍   ‍  

Static allows a higher complexity level for 3D models, meaning it loads all materials on an object and recreates it as it was created in the 3D design software.   This is particularly relevant for Parts in Experior – such as conveyor belts, machinery, sensors and custom graphical objects – which are usually more complex than a single box-shaped Load variation. It should be noted that some models – such as a Conveyor belt – is actually a collection of different simpler model shapes stitched together rather than one mesh.   Models deriving from Static relates to models that either applies forces to other 3D model objects (conveyors), or models that are static in the scenery. A conveyor applies forces to Loads for instance, whereas a model of a stacked shelf, or a man, can be placed for illustrative purposes or achieving completeness of the Experior 3D model compared to the real world. Most importantly, Static models are not affected by a gravity force.   Static RigidPart models are typically added to Assemblies like conveyors, sensors, gates, sorters for example.   Methods and Properties Static implements physics related properties and methods, as well as overriding some of the basic definitions from RigidPart. Note: We are working on creating a complete list which can be found in the API static Documentation   The following physics related concepts are implemented: CreateActor() NVIDIA Physics core concept, defining an actor that behaves based on physics. A Static Part is added as an actor. A new actor is created each time (in an UpdateActor() method) a property value that affects its functional configuration is changed, such as size or rigid shape. This method is called from a model class which derives from Static. Kinematic related methods 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. Static Parts are instantiated as Kinematic = true, which provides a need for defining methods that handles transformations (TransformActor()). 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 Friction (override) & new methods Enable/Disable() Friction methods can be called to set a Part’s friction coefficient on with its coefficient value or disable entirely. (Physics Engine) For instance, Conveyor belts can have motors attached, where it can be useful to entirely disable friction when a motor is started and instead handle a Load’s movement along the Conveyor in a consistent linear manner. Similarly, when the motor stops, friction is enabled once again to stop the Load’s movement along the Conveyor. Collide() Boolean used to update simulation parameters if the Static Part collided with a Load Part   General related concepts that are implemented: Attach()/UnAttach() Methods related to attaching loads to a Static model, such as a robot picker with a magnet. Takes care of positioning/orientation of the attached loads. Lock/Unlock – Lock/Unlock the Part’s position in Experior. (Bool) Rigid – Get/Set whether the Static Part is a Rigid, which it does not necessarily have to be. If the 3D model imported is for illustration purposes, it does not need to behave with physics related functionality.   Adding a Static Model Part to an Assembly The following code example demonstrates a code excerpt on how a Static model Part is added to an Assembly in Experior, based on the Curve Assembly found in the Conveyor Catalog and corresponding CurveConveyorBelt Part to add.    Note: This excerpt is only a fraction of the full Curve Assembly implementation and should be considered as such, meaning the code snippets will not fully produce the illustrated example.   using Experior.Core.Parts; // Needed for ConveyorCurveBelt reference using Experior.Core.Mathematics; // Needed for Trigonometry reference using Experior.Interfaces; // Needed for Coefficient reference using Experior.Core.Assemblies; // Needed for Assembly reference public class Curve : Assembly { private ConveyorCurveBelt curveBelt; public Curve(CurveInfo info) : base(info) { if(info.friction == null) { info.friction = new Experior.Core.Parts.Friction(); info.friction.Coefficient = Coefficients.Sticky; } curveBelt = new ConveyorCurveBelt(true); curveBelt.Radius = info.radius; curveBelt.Width = info.width; curveBelt.Angle = Trigonometry.Rad2Angle(info.angle); curveBelt.Friction = info.friction; curveBelt.Rigid = true; curveBelt.Color = info.surfacecolor; Add(curveBelt); } }     A simpler example taken from the DeveloperSamples catalog, shows the most basic method of adding a new RigidPart Box to an Assembly, as demonstrated below.    Sample2 Assembly placed in Experior, containing part1 (Blue Box) and part2 (Red Box).   using Experiore.Core.Assemblies; // Needed for Assembly / AssemblyInfo reference using Experior.Core.Parts; // needed for RigidPart/Box reference using System.Windows.Media; // Needed for Colors reference using System.Numerics; // Needed for Vector3 reference public class Sample2 : Assembly { private RigidPart part1, part2; // Constructor public Sample2(AssemblyInfo info) : base(info) { // Add a new RigidPart Box // Color = Blue // Dimensions = (x - length: 0.5m, y - height: 0.5m, z - width: 0.5m) // Local position = (x: 0, y: 2, z: 0) part1 = Add(new Box(Colors.Blue, 0.5f, 0.5f, 0.5f), new Vector3(0, 2, 0)); part2 = Add(new Box(Colors.Red, 0.5f, 0.5f, 0.5f), new Vector3(0, 0, 0)); } }

Dynamic is primarily used as the base class for Loads in Experior. Since there is potential for a lot more active Loads than Parts/Machinery in an Experior model, Dynamic implements simplified models, cutting 3D model complexity for performance gains.   A Dynamic load 3D model is collapsed into a streamlined format that strips away some of the functionality seen in Static. For instance, Loads only applies one material color to the entire 3D model instead of iterating through all materials. Visual complexity could be achieved by applying a texture to the model.   Models deriving from Dynamic relates to models (Loads) that act on physics forces applied by other 3D objects (conveyors for instance). Loads are meant to be moved by the NVIDIA PhysX engine, to transport them along conveyor paths in an Experior model. Most importantly, Dynamic models are affected by a gravity force to drive their transportation through an Experior model. In Experior’s Discrete Events mode, Dynamic can be attached to a Load, which will not be affected by physics forces.   Methods and Properties Dynamic implements physics related properties and methods, as well as overriding some of the basic definitions from RigidPart. Note: We are working on creating a complete list which can be found in the API documentation.   The following physics related concepts are implemented: CreateActor() NVIDIA Physics core concept, defining an actor that behaves based on physics. A Dynamic Part is added as an actor. Also implements ReCreateActor(), which calls this method each time a property value affecting its size or rigid shape is modified, setting the newly created actor’s global position/orientation to the previous actor’s values. Kinematic (true/false) 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. 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 Center Of Mass Offset Local Position, 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 Center Of Mass Offset Local Position 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. Add Force()/Torque() 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.   Adding a Dynamic based Load Custom Load classes in Experior derive from the Load base class in the Experior.Core.Loads namespace, where the custom Load class implements a Part that derives from Dynamic. Let’s look at an example that demonstrates how a EuroPallet load type could be implemented in Experior.   The EuroPallet class defines a EuroPallet constructor which takes a PalletInfo object as an argument, which further derives from LoadInfo class, where info.<insertfield> fields are defined. Inside the constructor, a new Part is created and positioned/oriented correctly alongside updating the info object with the correct information, which ensures the model can be re-created when loaded from a save file.   public class EuroPallet : Load { public EuroPallet(PalletInfo info) : base(info) { Part = new PalletPart(info.randomcolor ? Colors.GetRandomColor() : Info.color, // Part color 1.2f, 0.144f, 0.8f, // Part size (Length, Height, Width) info.density, // Part density EmbeddedResources.EmbeddedResourceLoader.Get("EUROpallet.dae"), // Get embedded 3D model resource info.rigid, // Define Rigid shape this); // ILoad parent Part.Position = Info.position; Part.Orientation = Info.rotation; info.height = ((PalletPart)Part).Height; info.length = ((PalletPart)Part).Length; info.width = ((PalletPart)Part).Width; info.color = Part.Color; } }   The PalletPart class, which derives from Dynamic, gets the correct mesh from an embedded resource by importing it, scales the mesh to input size and sets a centerofmass point value. The latter value matters for physics forces, which are applied to an objects center of mass point. internal class PalletPart : Dynamic { private EmbeddedResource resource; private int textureId = -1; [Browsable(false)] public override int TextureId =>; textureId; public PalletPart(Color color, // Part color float length, // Part length float height, // Part height float width, // Part width float density, // Part density EmbeddedResource resource, // Embedded resource file reference Rigids rigid, // Rigid shape ILoad parent) // ILoad parent : base(parent) { try { this.density = density; this.resource = resource; // Import Embedded resource mesh, its meshdata color and ID reference to mesh texture Importer.GetMesh(resource, out meshData, out this.color, out textureId); // At the time of writing, Experior handles Load coloring with 2 special cases by: // * transparent = random color // * black = mesh color // This if clause means if (input) color != black, set mesh color (this.color) to input color // if (input) color is black, it uses outed mesh color (this.color) as load color // Color handling is to be refactored in a future Experior major version. if (color != System.Windows.Media.Colors.Black) { this.color = color; } this.rigid = rigid; scale = new Vector3(1, 1, 1); Vector3 size = MeshData.BoundingBox.Size; // Calculate proper scalar based on mesh bounding box size if (length > 0 && height > 0 && width > 0) { scale = new Vector3(length / size.X, height / size.Y, width / size.Z); } // Define center of mass point centerofmass = new Vector3(0, -Height / 2.5f, 0); Observers.MeshObjectObserver.Added(this); } catch (Exception se) { Log.Write(se, 0933886); } } }   A CreateEuroPallet() method could then finally be defined as: public static Load CreateEuroPallet(string barcode, float density, Color color, Rigids rigid) { var info = new PalletInfo { barcode = barcode, rigid = rigid, density = density, color = color }; var load = new EuroPallet(info); // Position the load at half the load's height. (Positions the load from its centerpoint). load.Position = new Vector3(0, load.Height / 2, 0); // Add to collection of loads added to the scene. items.Add(load); return load; }   In Experior, the CreateEuroPallet() method is called when the “Feeder” assembly in the Conveyor catalog “feeds” a new load, either from a double-click event on the 3D cube model or pressing the spacebar when it is selected.   Feeder Assembly as it is placed in Experior, not selected.   Feeder and the EuroPallet load type created (random colour applied). 

To provide diagnostic, debug or logging messages Experior provides several mechanisms.   Logging The Experior.Core.Environment.Log class provides the following static methods to write messages to the Log window:   public static void Write(Exception exception); public static void Write(string message); public static void Write(Exception se, int id); public static void Write(string message, bool underline); public static void Write(string message, Color color); public static void Write(string message, LogFilter filter); public static void Write(string message, string hightlight); public static void Write(string message, bool underline, LogFilter filter); public static void Write(string message, Color color, LogFilter filter); public static void Write(string message, string hightlight, Color color); public static void Write(string message, string hightlight, LogFilter filter); public static void Write(string message, Color color, bool underline, LogFilter filter); public static void Write(string message, string hightlight, Color color, bool underline); public static void Write(string message, string hightlight, Color color, LogFilter filter); public static void Write(string message, string hightlight, Color color, bool underline, LogFilter filter);   The meaning of the arguments is straightforward;   The message is the string that will be logged to the log window (and/or file depending on the properties set by the user in Experior). The highlight is part of the message that will be shown in bold. The color is the color in which the message will be shown. Underline, this boolean indicates whether or not the message will be underlined. The filter corresponds with the chosen filter by the user in the properties of the Log;   To illustrate, the following code:   Experior.Core.Environment.Log.Write("Created sensorpart assembly", "sensorpart", CadetBlue, true, Communication ); Experior.Core.Environment.Log.Write("Created sensorpart assembly", "sensorpart", Red, false, Action);   Will be shown as follows (when no filter is applied);   Debug log   Similar to the regular logging there is also the possibility to only log your message in case the debugging option is set in Experior.   In this case the Experior.Core.Environment.Log.Debug class is used with the public static void Write(string message) method.   Example: Experior.Core.Environment.Log.Debug.Write("This is an example debug message");   Diagnostic info Experior also provides the possibility to print diagnostic messages to other areas than the logging window.   Therefore the class Experior.Core.Environment.Diagnostic contains the following static methods:   public static void Message(string message); public static void Message(string message, Color color); public static void Message(string sender, string message); public static void Message(string message, Color color, Environment.DiagnosticAction action); public static void Message(string sender, string message, Color color); public static void Message(string message, Color color, Environment.DiagnosticAction action, Environment.Signs sign); public static void Message(string sender, string message, Color color, Environment.DiagnosticAction action);   By default the messages are shown in the status area underneath the working area.   The arguments are:   Message: The information that will be shown. Sender: This string appended with a : will be shown before the message. It is mainly used to provide the origin of the message e.g. the Assembly name. Environment.DiagnosticAction: This is an enum with the following possible values; ALARM in this case the message will also be shown in the alarm window of experior TEMPORARY in this case the message will only be shown for couple of seconds TEMPORARYANDLOG in this case the message will only be shown for couple of seconds but it will also be printed to the log window (where it will remain) STICKY in this case the message will remain visible in the status area until a new message is requested or until the message is removed or the Clear() method is called of the Diagnostic class REMOVE way to remove a STICKY diagnostic message NONE Environment.Signs: This is an enum to indicate what icon should be attached to the message in the status area.

The Experior Translate has challenges when coming to performance issues, but it is difficult to fix the challenges without affecting existing solutions using it.   Here is what we decided to do:   The existing property ‘Animate’ has been renamed to ‘AutoUpdatePositions’ (Animate still exist but marked obsolete). Reason for the name change is that not only animation is affected but also positions of Assemblies/Parts added to the translate timer, will not be updated until translation is done.   Code example: // Create a translate timer as per usual: Core.Timer.Translate _translateTimer = new Core.Timer.Translate(); // Configure _translateTimer private void ConfigureTranslateTimer() { _translateTimer.AutoUpdatePositions = false; }   A new method ‘UpdatePositions’ has been added. This allows users to manually update positions of Assemblies/Parts added to the translate timer when AutoUpdatePosition is false.   This solves the problem we used to have with slow simulations when the translate timer is used and with a few extra steps (for the user), there are almost no loss of precision or functionality. If ‘AutoUpdatePositions’ is set to false, simulations using translate timers will run a lot faster. This has 3 side effects:   1.The translation is no longer animated. However, if users implement a real time timer that calls UpdatePositions every 1/30 sec. then animation is back to normal, and the simulation still runs a lot faster.   Code example: // Setup a real time timer somewhere (e.g. in a Controller): System.Timers.Timer updateTimer = new System.Timers.Timer(1/30.0); updateTimer.AutoReset = true; updateTimer.Elapsed += UpdateTimer_Elapsed; // Call UpdatePosition on Elapesed private void UpdateTimer_Elapsed(object sender, ElapsedEventArgs e) { _translateTimer.UpdatePositions(); }   2. Positions are not updated until translation is done. However, if users call UpdatePositions just before asking for a position of any Assembly/Part added to the timer, the return value should be as precise as if AutoUpdatePositions were true.   Code example: // Lets say we need a position of an assembly while it is being translated by _translateTimer _translateTimer.UpdatePositions(); var position = MyAssembly.Position;   3. OnPositionChanged events are not raised on every timestep when AutoUpdatePositions is false, only when UpdatePositions is called by the user. This may have an impact in some project.   How it used to work in Experior 6 and why there is a difference in Experior 7:   In Experior 7 there has been focus on making simulations deterministic. That means a simulation should yield the same results when it is run multiple times and in different environments e.g. on another computer. To accomplish this we needed to separate the UI thread from the engine thread where simulation related calculations are done.   In Experior 6, the UI update rate (which was user adjustable) was directly responsible for initiating the update of assemblies. That means, if the framerate was set to 5, then positions of Assemblies/Parts added to a translate timer would be updated 5 times per real-time second, no matter the simulation time scale. This could in some cases yield different results whether the framerate was set to 5 or 60 and whether timescale was 1 or infinity. That also means if the framerate was set to 0, much fewer calculations were needed and hence the simulations were running very fast, although non deterministic.   In Experior 7, the engine thread is responsible for initiating update of assemblies. When the simulation target time scale is at infinity, the time steps are as large as it takes the computer to do all necessary calculations. If the time scale is 1 (real time), the engine step method inserts pauses in every step to accomplish the target time scale of 1 real-time second. That means the same amount of calculations is needed no matter time scale or framerate and hence the simulations are running slower.