When an Experior model is saved, data added to an Attributes object is saved together with the rest of the model data.   Example The TestObject is an example of an object that is going to be saved: (Note: The object has to be serializable)   [Serializable] public class TestObject { public TestObject() { private string text; public string Text { get { return text; } set { text = value; } } private int count; public int Count { get { return count; } set { count = value; } } } }   Now create an instance of the TestObject class. TestObject test = new TestObject(); test.Count = 100; test.Text = "Hello";   And an instance of the Attribute class and then add the instance of the TestObject. The name Test1 is used to identify the object when the model is reloaded or whenever you want to get hold of the object. Core.Environment.Scene.Attributes attributes = new Core.Environment.Scene.Attributes(); attributes.Add("Test1", test);   The test object can at any time be removed by disposing the attribute object or by calling the static method Remove. attributes.Dispose(); or Core.Environment.Scene.Attributes.Remove(this.Name);

Hyper-menus feature in Experior employs the mini-markup/text-markup language to decorate help dialogs.   Mini-markup must be well formed. That means that all tags must be properly closed and all attributes must have values enclosed in double quotes. For example this is how line-break tag would look like: <br/>   Markup Reference   <b> – The B element indicates that text is rendered as bold text.   No attributes are available for this tag.   Example: <b>Bold Text</b> <i> – The I element indicates that text is rendered as italic text. No attributes are available for this tag.   Example: <i>Italic Text</i> <u> – The U element indicate that text is rendered as underlined text. No attributes are available for this tag.   Example: <u>Underlined Text</u> <s> – The S element indicates that text is rendered as StrikeOut Text No attributes are available for this tag.   Example: <s>StrikeOut Text</s> or <strike>StrikeOut Text</strike> <font> – The font element indicates the size change, font face or text color. Attributes: size Indicates absolute or relative font size. For example size=”+1″ will increase the size of the text font by one point. size=”-2″ will decrease the size of the text font by two points. size=”12″ will set explicit text font size to 12 points. face Indicates the font name. For example face=”Arial” will set the font to Arial. color Indicates the text color. Named colors from Color class can be set or color using RGB format: #RRGGBB where RR indicates hexadecimal value of Red component, GG indicates hexadecimal value of Green component and BB indicate hexadecimal value of Blue component. For example color=”Red” will set text color to red.   Example: <font color=”Red” size=”-1″>Red smaller text</font> <h1> … <h6> Indicates block heading text. No attributes are available for this tag.   Example: <h1>Level One Heading</h1> <h3>Level 3 heading</h3> <a> Indicates an anchor – a hypertext link. Attributes: href – string which indicates hypertext reference. Attribute value is available in event arguments of MarkupLinkClick and can be used to provide more information about the link. name – string which indicates name of the link. Attribute value is available in event arguments of MarkupLinkClick and can be used to provide more information about the link.   Example:<a href=”MyLink”>My Link Text</a> <br/> – Indicates line break. No attributes are available for this tag.   Example: First Line<br/>Second Line <div> – Indicates generic block level container element. Attributes: align – Indicates the container content alignment. left, right or center are allowed values for this attribute. width – Indicate the container width in pixels. height – Indicate the container height in pixels. bgcolor – Indicate the container background color, for example: bgcolor=”#FF0000″ or bgcolor=”Red”. padding – Indicates the padding around the element in pixels. Format for the value is: left, right, top, bottom. For example: <div padding=”1,1,4,4″”> produces 1 pixel padding on left and right side of container and 4 pixels padding on top and bottom. All values must be specified. valign – Indicates the vertical alignment for the content blocks inside of container. Default value is top. Acceptable values are: top, middle, bottom   Example: <div align=”center” width=”120″>Block container element content center aligned with width of 120 pixels</div> <span> – Indicates the in-line block level container element. The tag does not cause the line break. You can use it to create tabular layouts. Attributes: align – Indicates the container content alignment. left, right or center are allowed values for this attribute. width – Indicate the container width in pixels. padding – Indicates the padding around the element in pixels. Format for the value is: left, right, top, bottom. For example: <span padding=”1,1,4,4″”> produces 1 pixel padding on left and right side of container and 4 pixels padding on top and bottom. All values must be specified.   Example: <span align=”right” width=”100″>In-line container element content right aligned with width of 100 pixels</span> <p> – The P element defines a paragraph. Attributes: align – Indicates the paragraph content alignment. left, right or center are allowed values for this attribute. width – Indicate the paragraph width in pixels. padding – Indicates the padding around the element in pixels. Format for the value is: left, right, top, bottom. For example: <p padding=”1,1,4,4″”> produces 1 pixel padding on left and right side of container and 4 pixels padding on top and bottom. All values must be specified.   Example: <p align=”right” width=”200″>Paragraph element content right aligned with width of 200 pixels</p> <expand/> – Indicates the position for the expand sign of the button inside of the markup text. This tag allows you to place the drop-down sign which indicates that button has drop-down anywhere inside of the markup text to reduce the space used by a button. Attributes: direction – Optional attribute that indicates the direction the expand sign points to. Possible values: left, right, top, bottom, popup   Example: Page<br/>Borders<expand/> <img> – The img tag defines an image. Attributes: src – Specifies the image source resource name or embedded resource name. width – Indicates the fixed image width in pixels. If this attribute is specified height attribute must be specified as well. height – Indicates the fixed image height in pixels. If this attribute is specified width attribute must be specified as well.   Supported entity characters: &lt; – less than < &gt; – greater than > &nbsp; – hard space &- ampersand &

To create a list that contains all derived types just call: Experior.Core.Assemblies.Assembly.DerivedItems<TDerived>   The example below shows how to create a list of all Feeders in the current model: var feeders = Experior.Core.Assemblies.Assembly.DerivedItems<Experior.Catalog.Logistic.Feeder>();

IEntity is an interface for a model entity that is typically shown in the Solution Explorer and has a Name, EntityId and properties to enable/disable itself and indicate whether it is selected and whether it can be deleted.   It also contains a getter property to indicate the parent of the entity.   Typical classes that implement the IEntity interface are: Experior.Core.Assemblies.Assembly, Experior.Core.Motors.Electric, Experior.Core.Communication.PLC.Input, Experior.Core.Communication.PLC.Output.

Assemblies are model entities that are chosen from a catalog and are dragged onto the working area.   All assemblies derive from the class Experior.Core.Assemblies.Assembly which itself implements the IEntity interface.   The constructor of an Assembly always contains an object deriving from the AssemblyInfo class as an argument, Assembly(AssemblyInfo info).   This is used to support the mechanism for saving/loading a model. When saving a model all AssemblyInfo objects are serialized into an Assemblies.XML file and zipped into the Experior model file.   When loading the model Experior unzips the Experior model file and deserializes the Assemblies.XML file. For each deserialised AssemblyInfo object the appropriate constructor is called.   When dragging the assembly from a catalog to the working area the methods of the catalog are used to create an appropriate AssemblyInfo object and then pass this object into the constructor of the matching Assembly class.   Note: After an assembly is created by dragging it onto the working area its Inserted method is called. This is not the case when the assembly is created by loading the model.   Main methods/properties of the Experior.Core.Assemblies.Assembly class:   Configuration related methods/properties   Add(IEntity entity): This will make the current assembly the Parent entity of the given IEntity. It will also add the given entity to its list of entities (See property Entities)   Remove(IEntity entity): This method will remove the given entity from the list of entities of this assembly and will set the Parent property of the entity back to null.    bool Configured: This getter property indicates whether the current assembly is configured (this will be the case when RigidParts or subassemblies have been added to the current assembly)   bool Embedded: This getter/setter property indicates whether this assembly is embedded into another entity or not. When the Embedded property is true the assembly will not be serialized separately when saving the model, instead it will be serialized inside the xml tags of the parent assembly.    List<Experior.Core.IEntity> Entities: This getter property returns the list of entities that were added to the current assembly.   IEntity Parent: This getter property returns the parent entity of the current assembly. If the assembly is not added to another entity then the Parent property remains null.   User interface related methods/properties   MouseDown(): This method is called when the current assembly is selected and the user presses the mouse button.   MouseUp(): This method is called when the current assembly is selected and the user releases the mouse button.   KeyDown(System.Windows.Forms.KeyEventArgs e): This method is called when the current assembly is selected and the user presses a keyboard key. The pressed key can be derived from the given KeyEventArgs e.   KeyUp(System.Windows.Forms.KeyEventArgs e): This method is called when the current assembly is selected and the user releases a pressed a keyboard key. The released key can be derived from the given KeyEventArgs e.   Example: public override void KeyDown(System.Windows.Forms.KeyEventArgs e) { // change viewpoint when 5 is pressed in the numpad if (e.KeyCode == System.Windows.Forms.Keys.NumPad5) { Experior.Core.Environment.Scene.Camera.JumpTo(this.ViewPoint); Vector3 target = this.CalculateTarget(); Experior.Core.Environment.Scene.Camera.Target = target; float calculatedRadius = Trigonometry.Length(this.ViewPoint, target); Experior.Core.Environment.Scene.Camera.Radius = calculatedRadius - 0.15f; } }   bool Selectable: This getter/setter property allows to control whether the current assembly can be selected (e.g. by clicking on it).   bool Selected: This getter property returns true if the current assembly is selected.   Motor related methods/properties   InsertMotor(Electric motor): This method is called when the user inserts a motor to the current assembly using the context menu (right clicking on the selected assembly)   InsertMotor(Electric motor, string category): This method is called when the user inserts a motor to the current assembly by selecting the category in the context menu. E.g. below shown context menu will result in a call of InsertMotor with a newly created vector motor and category UP/DOWN.   RemoveMotor(Electric motor): This method is called to remove the previously inserted motor from the assembly   RemoveMotor(Experior.Core.Parts.Arrow arrow): This method is called to remove the previously inserted motor from the assembly by clicking on the associated motor arrow. Below you see some examples of usage of the Motor related methods:   Typically the usage of motors in assemblies involves:   In the constructor of the assembly specify what types of motors can be added through the context menu. E.g: Menu.Motors.Types.Clear(); Menu.Motors.Add(typeof(Surface)); Menu.Motors.Add(typeof(Vector), "UP/DOWN"); Menu.Motors.Add(typeof(Vector), "LEFT/RIGHT");   In the constructor of the assembly insert the motors that were previously saved in the Info object: InsertMotor(Experior.Core.Motors.Motor.Get(info.motorsurfacename)); InsertMotor(Experior.Core.Motors.Motor.Get(info.updownmotorvectorname),"UP/DOWN"); InsertMotor(Experior.Core.Motors.Motor.Get(info.leftrightmotorvectorname),"LEFT/RIGHT");   Override the InsertMotor methods to internally keep track of the motors that are inserted (e.g. put them in the proper local fields, maybe create a motor arrow, take into account name changes of the motors,…). Below you find an example: public override void InsertMotor(Electric motor) { if (motor == null) return; if (motor is Surface) { base.InsertMotor(motor); surfacemotor = motor; motor.NameChanged += new Motor.NameChangedEvent(SurfaceMotorNameChanged); if (belt != null)belt.SurfaceMotor = motor; } } public override void InsertMotor(Electric motor, string category) { if (motor == null) return; if (motor is Surface) { InsertMotor(motor); } else if (motor is Vector) { if (category == "UP/DOWN") { if (updownmotorvector!= null) RemoveUpDownVectorMotor(); Info.updownmotorvectorname= motor.info.name; updownmotorvector= (Vector)motor; updownmotorvector.NameChanged += new Electric.NameChangedEvent(motorvector_MotorNameChanged); CreateMotorArrow(updownmotorvector); Add(updownmotorvector); } else if (category == "LEFT/RIGHT") { if (leftrightmotorvector!= null) RemoveLeftRightVectorMotor(); Info.leftrightmotorvectorname= motor.info.name; leftrightmotorvector= (Vector)motor; leftrightmotorvector.NameChanged += new Electric.NameChangedEvent(leftrightmotorvector_MotorNameChanged); CreateMotorArrow(leftrightmotorvector); Add(leftrightmotorvector); } } else base.InsertMotor(motor, category); }   In case you want to allow the user to change the inserted motor through the property window than you have to add the needed property and annotate them with the proper attributes. When you use a string property to set/get a motor you need to specify the proper System.ComponentModel.TypeConverterAttribute (for a Vector motor this is Experior.Core.Motors.Vector.Converter, for a surface motor this is Experior.Core.Motors.Surface.Converter). To change the motor in the setter of the property you first verify whether a motor exists for the given name and then you call the appropriate InsertMotor method as you can see in below example: /// <summary> /// Gets or sets the vector motor used for UP/DOWN movement. /// </summary> /// The vector motor. [TypeConverter(typeof(Vector.Converter))] [PropertyAttributesProvider("DynamicPropertyVectorMotor")] [DisplayName("UpDownVectorMotor"),CategoryAttribute("Motor"),DescriptionAttribute("Vector motor for UP/DOWN movement")] public virtual string UpDownMotor { get { if (((MyAssemblyInfo)Info).updownmotorvectorname== null) return string.Empty; return ((MyAssemblyInfo)Info).updownmotorvectorname.ToString(); } set { if (Experior.Core.Motors.Motor.Items.ContainsKey(value)) InsertMotor(Experior.Core.Motors.Motor.Items[value], "UP/DOWN"); } }   Miscellaneous methods/properties   LocalRotation(Vector3 localRotationPoint, float DeltaYaw, float DeltaPitch, float S): Will rotate the current assembly around the given localRotationPoint with the given angles. This will only work if the assembly had been added to a parent assembly. This method will only change the LocalPosition of the assembly with respect to the parent assembly, while keeping the LocalYaw, LocalRoll and LocalPitch constant.   InsertActionPoint(ActionPoint ap): This method is called when the user inserts an action point to the current assembly by clicking on the “Insert ActionPoint”  of its context menu:     Above choice for inserting action points ion the context menu was created by: Menu.ActionPoints.Add(typeof(Core.Routes.ActionPoint)); Menu.ActionPoints.Add(typeof(Core.Routes.Sensor));   bool InvokeRequired: Some methods in Experior are bound to a specific thread (e.g. main engine thread) and are not thread safe. Therefore, if you are calling an method from a different thread, you must use one of the Experior’s invoke methods (Experior.Core.Environment.Invoke) to marshal the call to the proper thread. This InvokeRequired property can be used to determine if you must call an invoke method, which can be useful if you do not know about the different threads. See also here.   InvokeRefresh(): This will schedule the engine to call the Refresh method of the current assembly   Refresh(): This method is called to update the internals of the assembly when some of its properties have changed. It can be used to delete/create subparts   Inserted(): This method is called by Experior after the user has dragged the current assembly from the catalog onto the workarea. It is not called when the assembly is placed on the workarea by loading an Experior model.   Render(): This method is called by Experior each time the current assembly is rendered (amount of times is determined by the FPS setting). The base Render methods makes sure that it also calls the Render method of all parts and assemblies that were added to the current assembly.   Reset(): This method is called when the user resets the model (e.g. using Ctrl-R). You can e.g. override this method to reset a linked motor or a custom counter: public override void Reset() { if (motorvector != null) motorvector.Reset(); loadcount=0; base.Reset(); }   Step(float deltatime): This method is called in PhysX mode each time the physics engine advances the time. The delta time is passed as an argument in the method. In discrete mode the Step method of an assembly is not automatically called when time advances but if needed the assembly can subscribe to it: Experior.Core.Environment.Scene.Step += new Experior.Core.Environment.Scene.StepEvent(Step);   The Step method is typically used to set states, move parts and or subassemblies. Example where a scanning sensor is moved up and down and sends a signal if gets beyond a given height: public override void Step(float deltatime) { base.Step(deltatime); if (movescansensor) { if (vectormotor != null &amp;&amp; vectormotor.Running) { // change the relative position of the scan sensor according to the speed en specified direction of the vector motor scansensor.LocalPosition += vectormotor.CurrentSpeed * deltatime * vectormotor.VectorDirection; if (scansensor.LocalPosition.Y &gt; SlowZoneHeight) { ((TestAssemblyInfo)Info).plcSlowZone.On(); vectormotor.AlternativeSpeed(); } if (scansensor.LocalPosition.Y &gt; MaxLimitHeight) { vectormotor.Backward(); } else if (scansensor.LocalPosition.Y &lt; MinLimitHeight) { vectormotor.Forward(); vectormotor.Stop(); } } } }   Grouping related methods/properties   UnGroup(): This will Ungroup the current assembly with all other assemblies it is grouped with. UnGroup(Experior.Core.Assemblies.Assembly assembly): This will ungroup the given assembly from the current assembly. The call is ignored if the given assembly was not grouped to the current one. AssemblyDictionary<string, Assemblies.Assembly> Grouped: This returns a dictionary containing all the assemblies the current assembly is grouped with. The Key being used in the dictionary is the name of the grouped assembly, while the Value is the grouped assembly itself. You can use this dictionary to iterate over all assemblies that are grouped with the current one. foreach (KeyValuePair kvp in this.Grouped) { Experior.Core.Environment.Log.Write("Assembly " + this.Name + " is grouped with assembly " + kvp.Key ); }   string Category: This getter property returns the category to which the current assembly belongs and which is used to classify the assembly in the tree of the Solution Explorer. Color Color: This getter/setter property controls the current color of the assembly.   SolutionExplorer related methods/properties   bool Deletable: This getter property controls whether the current assembly can be deleted  void Dispose(): This method is called when the current assembly is deleted. It is usually overriden to unsubscibe from events that the assembly had subscribed to.  bool Enabled: This getter/setter property controls whether the current assembly is enabled (value equals true) or disabled (false). In case the assembly is disabled it is not taken into account by the discrete event engine bool ListSolutionExplorer: This getter/setter property controls whether the current assembly should be listed in the Solution Explorer. bool Locked: This getter/setter property allows to lock/unlock the current assembly. When the assembly is locked it will change color to Colors.LOCKEDCOLOR (Yellow by default). bool Movable: This getter/setter property controls whether the assembly can be moved or not. bool Warning: This getter property returns true if the assembly should be shown with a warning icon superposed on the normal icon in the Solution Explorer. If you want to specify yourself when this should be the case then override the property. See example below: public override bool Warning { get { if (((TestAssemblyInfo)Info).plcSlowZone.Warning)return true; return false; } }   Positioning related methods/properties   Matrix Orientation: This property returns or sets the global orientation of the current assembly as defined in the Microsoft.DirectX.Matrix structure. Vector3 Position: This property returns or sets the global 3 dimensional coordinates of the center of the assembly Vector3 LocalPosition: This property returns or sets the relative 3 dimensional coordinates of the center of the assembly with respect to its parent object float LocalYaw: This getter/setter property reflects the rotation angle (in radians) of the current assembly around the Y-axis of its parent object. float LocalPitch: This getter/setter property reflects the rotation angle (in radians) of the current assembly around the X-axis of its parent object. float LocalRoll: This getter/setter property reflects the rotation angle (in radians) of the current assembly around the Z-axis of its parent object. Matrix LocalOrientation: This property returns or sets the relative orientation of the current assemblywith respect to its parent object as defined in the Microsoft.DirectX.Matrix structure float Yaw: This getter/setter property reflects the rotation angle (in radians) of the current assembly around the global Y-axis. float Pitch: This getter/setter property reflects the rotation angle (in radians) of the current assemblyaround the global X-axis. float Roll: This getter/setter property reflects the rotation angle (in radians) of the current assembly around the global Z-axis   Examples of these can be found in Assembly Configuration.    

If a public class that extends the Core.Motor.Electric class exists in a catalog or plug-in then Experior will pick it up and make it visible from the Assembly context menu.   This means that you can put your own motor onto a conveyor or use it anywhere else.   To control the type that has to be listed in the context menu you can use the Menu.Motors.Add method.   The standard motors in Experior (Surface, Vector, Eccentric and Rotation) are only listed in the context menu if you explicit asks for it by calling:   Menu.Motors.Add(typeof(Core.Motors.Surface));   Menu.Motors.Add(typeof(Core.Motors.Vector));   Menu.Motors.Add(typeof(Core.Motors.Eccentric));   Menu.Motors.Add(typeof(Core.Motors.Rotation));   If your motor is derived from the Core.Motors.Surface class then by adding Menu.Motors.Add(typeof(Core.Motors.Surface)) all surface motors and all derived motor type will listed in the context menu.   If your assembly accepts all motors then just put in: Menu.Motors.Add(typeof(Core.Motors.Electric));   But remember this not includes the standard motors (Surface, Vector, Eccentric and Rotation).   In the example we have two motors that are derived directly from Core.Motors.Electric. To list the standard surface motor and at the same time accept motors derived from Core.Motors.Electric the two line below has to be added to your assembly: Menu.Motors.Add(typeof(Core.Motors.Surface)); Menu.Motors.Add(typeof(Core.Motors.Electric));   When the user then creates a new motor by clicking on the New menu item the InsertMotor method is called on the selected assembly. The only argument in the InsertMotor method is an instance of the motor just created.   Note: It makes no sense to have the motors listed in the context menu unless InsertMotor is overridden (Experior will not list the motors unless the assembly is overriding the InsertMotor method).  

The Experior.Core.Motors.Motor class is used in Experior to model motors. The motors are used to initiate movements of loads, parts or assemblies. The main class deriving from Experior.Core.Motors.Motor is the class Experior.Core.Motors.Electric. The Experior.Core.Motors.Electric class is the main motor used in in discrete mode.   Motors that interact with the PLC are typically of the class Experior.Core.Motors.ElectricExtended which derives from the Electric motor class   There are several classes deriving from the ElectricExtended class.   Experior.Core.Motors.Surface: This class represents a surface motor that is used to move a load and this motor is typically added to a ConveyorBelt part. Experior.Core.Motors.Vector: This represents a Vector motor used to move a part/assembly in a certain direction determined by the VectorDirection property. Experior.Core.Motors.Rotation: This represents a Rotation motor used to rotate an assembly/part in the horizontal plane. Experior.Core.Motors.EccentricLinear: This represents an eccentric motor where the attached parts/assembly will move linearly up/down Experior.Core.Motors.EccentricRotation: This represents an eccentric motor where the attached parts/assembly will rotate up/down   Main methods/properties of an ElectricMotor:   Backward(): This will put the motor in Backward mode. This method does not start the motor if it wasn’t running yet. It only sets the current running direction. If the motor was in Forward mode before the call of this method then the DirectionChanged event is triggered. Forward(): This will put the motor in Forward mode. This method does not start the motor if it wasn’t running yet. It only sets the current running direction. If the motor was in Backward mode before the call of this method then the DirectionChanged event is triggered. Start(): This will start an idle motor. It does not change the direction. Stop(): This method will stop a running motor. SwitchDirection(): This method will change the direction of the motor. If it was forward the new direction will become backward, and if it was backward the new direction will become forward. event MotorEvent DirectionChanged: This event is triggered when the direction of the motor is changed (from forward to backward or vice versa). The delegate contains the motor as only argument. event MotorEvent Started: This event is triggered when the motor is started. The delegate contains the motor as only argument event MotorEvent Stopped: This event is triggered when a running motor is stopped. The delegate contains the motor as only argument. bool Running: This getter property returns true if the motor is started and running, false otherwise. float Speed: This property returns/sets the  nominal speed of the motor. float CurrentSpeed: This getter property returns the current speed of the motor. Note that this can be different from the nominal speed in case the motor is accelerating/decelerating , when frequency encoder is used, when alternate speed is used. Directions Direction: This getter returns the current direction of the motor. Possible values are Experior.Core.Motors.Motor.Directions.Backward and Experior.Core.Motors.Motor.Directions.Forward. Reset(): This method resets the motor. bool Enabled: This getter/setter property controls whether the current motor is enabled (value equals true) or disabled (false). In case the motor is disabled it can’t be started.

Action   Use the static Action method to execute anonymous methods after a specified delay.   Example Executes the Log.Write method after 2 seconds. Experior.Core.Timer.Action(() > Experior.Core.Environment.Log.Write(“Hello World”), 2);   Timer   Experior.Core.Timer is a Timer that expires after a given time. The Experior.Core.Timer is similar to the .Net System.Timers.Timer class but adds Experior specific functionality. The Experior.Core.Timer will pause when the Experior model is paused and will also automatically resume when the Experior model is resumed. In addition it takes into account the Simulated time instead of the world time. So if Experior runs x times faster than the world time than the timer will expire after the given TimeOut divided by x.   The Experior.Core.Timer can be used in PhysX and discrete mode. Note however that is more accurate in discrete mode. (This is because in PhysX mode the time progresses in steps where the delta time is determined by the PhysX engine)   Properties   double TimeRemaining: This property returns the remaining time in seconds of Simulated time before the timer will expire. double PercentageRemaining: This property returns the percentage (between 0 and 100) of the remaining time in seconds of Simulated time before the timer will expire.   float Timeout: This property returns the total time in seconds of Simulated time between starting and expiring of the timer. bool Running: This property returns true when the timer is started.   bool AutoReset: This property is true when the timer will automatically start again after expiring. When it is false the timer requires a Reset() and Start() to start running again.   Methods void Start(): This method will start the timer. void Stop(): This method will stop the timer. void Reset(): This method will reset the timer. After this the TimeRemaining will equal the TimeOut again. It does not automatically start the timer. void Dispose(): This method will dispose of the timer. Static method If you want to execute a method after a given delay you can use the static Action method as shown here. In that case the action is only executed once (no AutoReset).   Example Below you find an example where two timers are created. The logtimer changes and prints every second the status of the pickuptimer. using System; using System.Collections.Generic; using System.Linq; using System.Text; using Experior.Core.Assemblies; namespace Experior.Catalog.Assemblies { public class ExampleTimer:Assembly { public ExampleTimer(AssemblyInfo info):base(info) { CreateTimers(); } private int counter = 0; private Experior.Core.Timer pickuptimer; public void CreateTimers() { // create a timer that will expire after 10.5 seconds of Simulated Time pickuptimer = new Core.Timer(10.5f); pickuptimer.AutoReset = false; pickuptimer.Elapsed += new Core.Timer.ElapsedEvent(pickuptimer_Elapsed); Experior.Core.Timer logtimer = new Core.Timer(1.0f); logtimer.AutoReset = true; logtimer.Elapsed += new Core.Timer.ElapsedEvent(logtimer_Elapsed); logtimer.Start(); pickuptimer.Start(); } void logtimer_Elapsed(Core.Timer sender) { counter++; Experior.Core.Environment.Log.Write("LogTimer has elapsed " + counter + " times at simulated time " + Experior.Core.Environment.Time.Simulated + " at elapsed time "+ Experior.Core.Environment.Time.Elapsed); if (pickuptimer != null) { Experior.Core.Environment.Log.Write("RemainingTime of pickuptimer " + pickuptimer.TimeRemaining + " percentage remaining" + pickuptimer.PercentageRemaining); if (counter == 1) { pickuptimer.Stop(); // change timeout to 20 seconds pickuptimer.Timeout = 20f; Experior.Core.Environment.Log.Write("Setting timeout of pickuptimer " + pickuptimer.Timeout); Experior.Core.Environment.Log.Write("RemainingTime of pickuptimer after setting timeout" + pickuptimer.TimeRemaining + " percentage remaining" + pickuptimer.PercentageRemaining); } else if (counter == 2) { Experior.Core.Environment.Log.Write("Starting of pickuptimer "); pickuptimer.Start(); } else if (counter == 3) { Experior.Core.Environment.Log.Write("Resetting of pickuptimer"); pickuptimer.Reset(); } else if (counter == 4) { Experior.Core.Environment.Log.Write("Starting of pickuptimer"); pickuptimer.Start(); } } if (counter == 30) { Experior.Core.Environment.Log.Write("LogTimer will stop"); sender.AutoReset = false; sender.Elapsed -= new Core.Timer.ElapsedEvent(logtimer_Elapsed); sender.Dispose(); } } void pickuptimer_Elapsed(Core.Timer sender) { Experior.Core.Environment.Log.Write("PickupTimer has elapsed"); pickuptimer.Dispose(); pickuptimer = null; } public override string Category { get { return "ExampleTimer"; } } public override System.Drawing.Image Image { get { return Common.Icons.Get("Cube"); } } } }

The Accessories Catalog is accessible in both Physics and Discrete Events Mode.     Its purpose is to allow users to import custom items for use within models, but with only very basic properties as opposed to coding a custom catalog item for example.   To import an item, right click within the catalog and select Import.   The supported file formats for import are shown in the drop box in the bottom right of the import file dialog.     One thing to bear in mind when importing CAD files is that the dimension units will differ between it and Experior.   That is to say the CAD drawing will generally be measured in metres while Experior components are measured in millimetres.   This could lead to the item, when dragged into the model, being to large for the floor and needing re-sizing for it to be visible on the model.  

Introduced in Experior build 47248 the measure feature can be used to calculate the distance between 2 objects.   The Measuring feature can be found under the Tools menu in the Options section.   To activate click on the measuring tape icon so that goes from being black and white to color.   Now click on the component you want to measure from so that the measuring line appears.   Then click on the second component and the distance between the 2 is shown below the line in between the 2 objects.

The messages/telegrams are typically written as part of the PLC/Controller code or a custom dll file that gets added into the Experior model.   Within the dll code the different types of telegrams are generally coded as case statements, the case being the identifier used within the Validation file in Experior.   Adding Validation in Experior   To add a message/telegram for validation in Experior the following must be done: Open the model, if the model is locked, you must unlock it before proceeding You can tell if the model is locked by the padlock icon on the very top toolbar being closed   Unlock the model by clicking the icon, it now changes to that of an open padlock   In the Solution Explorer pane right click on MVT and select New   A new validation template is created. It can be re-named by double clicking it and typing in a new name Right click on the newly created file Select Edit, the validation template opens   If you wish to add a new message validation check, click the green + at the top of the screen.   A new block with a length of 3 appears, initially defined as ASCII (by the A in the center of it).   To re-size the new block just added, select it so the border becomes blue and then click and hold down on the right hand edge The cursor should change to look something like ←|→, then simply drag to the left or right until the size is as required Now double click on the selected block to bring up the properties Under the Format tab of the properties are options for modifying format of the particular telegram/message section   Under the Padding tab select the value according to how the telegram is setup   To add another block on the same line, ensure the first one is deselected (black border) and right click and select Add The 3rd block, generally, contains the message/telegram identifier Add the block as normal and re-size if necessary Then right click on it and select Identifier   Now double click to open the properties for that block and there is now an Identification tab available Click it and then enter the 3 character code identifier for the message/telegram   Now the block has a red outline with the 3 character code below it   Now just add the rest of the blocks as required so the validation fits the telegram it refers to            

When running Experior in Discrete Events Mode and, for instance, testing communications between controllers and warehouse management systems, it is possible to record a telegram sequence.   In some setups it can be very difficult to reproduce a specific error/exception when a WMS/MFC is controlling the model. This is because it demands that the high-level controller has to have the ability to go back to a well known state and then be deterministic when the test is repeated.   All incoming messages (on high-level connections like STX/ETX) are recorded if the feature is turned on.   All messages are recorded with a time stamp, a telegram sequence can then be replayed, once the recorder has stopped   When the Replay is started, it is controlled by the model timer, and then the different connections receives messages in the same way and at the same time as when the WMS/MFC was on-line (note: the Replay can only be started if the elapsed model time is 0).   The last menu item in the communication context menu is for saving a recorded telegram sequence. The telegrams are listed chronological in a text file.  

It may become necessary at a point during development to merge two models. This section provides a brief walk-through and example of how to do this.   Open the model you want to merge into   With the model open click the Merge button under the File menu     Select the model you want to merge into the currently open model and click OPEN When the message appears asking if a new section should be created for the merged assemblies   click YES The merged assembly now appears in the build area   In the Solution Explorer select Merged1.   In the properties the rotation, size and position of the merged assembly can be altered   Control Panels merged into an existing model can have the same name as one of the Control Panels (a tab page) that already exists   Before starting the merge process Experior will now verify if the model that is being merged contains one or more connections that already exists in the current model. The user is then asked if the merge process should be terminated

A collection of assemblies (or a group of assemblies) can be saved in “My Catalog” to enhance re-usability.    In the picture above a photo eye and a conveyor are grouped together and saved in “My Catalog“.   Organizing the “My Catalog” To organize “My Catalog” items please switch to the tree view mode. To change the name or if you want to delete it then right click on the assembly and use the context menu.   To organize the assemblies sub folders can be created (sub folders can be renamed or deleted in the same manner).   Just drag the assemblies between the sub folders or back to the “My Catalog” parent folder.   Note: The items in the “My Catalog” folder just reflect the folder structure in the MyCatalog folder of the working directory of Experior.   This means that you can share the saved collection or group of assemblies just by copying the files!  

Scripting allows you to make demonstration models that can run without being connected to a PLC.   The model below has been set up with a script that allows the motor to start when a load activates the first sensor and a new load to be released when the load activates the second sensor.   Open Experior in Physics Mode Place two basic conveyors on the 3D scene and add a motor to the conveyors For the second conveyor instead of adding a new motor select MOTOR1 from the context menu Place a photoeye from the sensor catalog at the red end of the 1st conveyor and one in the middle of the 2nd conveyor Pick a feeder from the basic catalog and place it above the photoeye in the 1st conveyor’s red end   Switch to the scripting tab and enter the code as shown below public void On(object trigger, string symbol) { if (symbol == "SENSOR1") { Motor.Start("MOTOR1"); } if (symbol == "SENSOR2") { Assembly.Activate("FEEDER1"); } }     Press F5 to compile the script Switch back to the model Press P to activate run mode Release the first load by double clicking on the feeder The motor starts and when the first load activates the sensor When the load activates the second sensor a new load will be released   Target Methods   In addition to the default target methods, you can add the methods listed in the tables below from the context menu which is accessed by right clicking in the scripting area.     Motor Started: Use if you want to be informed when a motor starts. Input Changed: Use if you want to be informed when a defined PLC output changes value. Value Changed: Use if you want to be notified when a defined PLC output changes status (only relevant in connection with I/O registers). Position Changed: Use if you want to be informed when an assembly changes position. Message Received: Use if you want to subscribe to telegrams which are received at the connection in question (can only be used with STX/ETX and RFC1006 connections). Telegram Received: Use if you want to subscribe to telegram received events. Step:  Called at every frame update. Activation Assembly specific method, only used for certain customized assemblies.   Script Methods   From the script environment you can access all public classes, methods and properties in all the different plugins and catalogs that are linked to Experior.   There are some static classes that makes it easy to make a script. This is not an object oriented approach but for some situations this is okay.  

The example below illustrates how to control a grouped assembly with a simple script.   Open Experior in Physics Mode Build a model using two conveyors, one photoeye sensor and a pusher   The pusher is located in the Advanced Catalog The pusher should be added to the side of the first conveyor so it is adjacent to where the second conveyor intersects on the other side Under the Edit menu click Select All                 Now right click on the selected assemblies and select Group   Select SENSOR1 in the Solution Explorer   In the Properties under Scripts -> Event open the editor for the Entering event   Complete the line by selecting “PUSHER1”   Press F5 so the script compiles Close the script editor Right click on the grouped assembly and choose “Save in My Catalog“   Now when a load activates the sensor it triggers the Entering event which activates the pusher

Normally Loads are created by a Feeder.   A Feeder can be added by either: Right clicking on the track/conveyor and selecting Insert Feeder from the context menu Dragging and placing a feeder from the Basic catalog. This is only possible in Physics mode   The only difference between the two types of feeders is that the feeder from the catalog can be re-sized and re-orientated and be freely moved about the model.   All other configurable properties are identical between the two.   The feeder can be used to feed loads into the system in two ways: Set up the feeder properties for Automatic Feeding Use the Feed property under PLC Outputs to setup a output symbolic to trigger the feeding of a load by, for example, a button push   The type of load being generated by the feeder can also be changed and configured.   In the Feeder properties under the Load category you can use the Type field drop down to select the load type.   The other properties in this section can be used to change the loads dimensions & orientation, its density and rigidity, the loads center of mass and its color.    

Action Points are the nodes in the route graph. You can give a load a destination and based on the route graph the shortest path is calculated.   When a load arrives at an Action Point the load can stop and pass that event onto a controller/script.   To add an Action Point, right click on the component on which you want the Action Point and select Insert Action Point. Then click Action Point. The Action Point is represented by an X, initially in the center of the track.   You can move the Action Point along the route (by moving the mouse).   The Action Point can be released from the route by holding down the ESC key (release the ESC key again to drop the Action Point on a different route).   While moving the Action Point along the route, you can hold down the CTRL key to move the action point a step of 100 mm.   The properties for the Action Point are defined as follows:   Identification Name – Customizable name Type – Catalog reference   Operation Enabled – Set to determine whether Action Point is enabled or not Collision Mode – Should the load arrive at the leading, center or trailing edge of the Action Point Highlight – The load gets the same color as the Action Point (only usable if the Stop Mode is set to anything other than “None”) Stop Mode – Defines the behavior when the load arrives. Choose from None, Stop, Capacity, Interval or StopMotor: None – The load just passes the by Stop – The load stops when it arrives Capacity – Defines how many loads that may leave the action point per minute Interval – The loads stop for a period of time (can be controlled by a normal distribution) StopMotor – The motor that controls the routes is stopped (all loads on the route are stopped) Capacity – Loads/Min. Disabled if the value set to zero (only usable if Stop Mode set to “Capacity”) Distribution (only usable if Stop Mode set to “Interval”) Mean (µ) – Set the mean value Std. Deviation (σ) – Set the value for the standard deviation Base – Select the base units. Choose from Neutral, Millisecond, Second, Minute or Hour Default Destination – If a load without a destination is arriving at the Action Point, its next destination is defined by this property.   Position Distance – The distance for the start of the track to the position of the Action Point   Scripts Events – The events “Arriving” and “Leaving” can be handled by a script (this is an alternative to the script or controller)   Statistics Enabled – If this is enabled every load that arrives is counted and is visible in the report   Visualisation Colour – Select the colour of the Action Point Visible – Select whether the Action Point is visible or not

In Physics Mode motors can be added to tracks.   To add a motor to a track you, select the track and right click.   Select a motor from the context menu.   When a motor has been added to a track, it will be listed in the motor menu as Motor1 and so forth according to the order in which they are added.   The numbering runs across the different types of motors.   A motor can be used on an unlimited number of tracks.   After a motor has been added to a track, it will become available to other tracks through their context menu and properties window in the motor menu drop down list.                     A motor is visualized by an arrow that points in the traveling direction.   The arrow is red when the motor is stopped and green when the motor is running.   The default motor direction is from the track’s red fix point to its blue fix point.   To start/stop a motor for standalone test purposes, either right click on the arrow and select start, double click the arrow or select it and press the plus (+) key.   Selecting the motor and pressing the minus (-) key will change the direction of the motor.   When the same motor has been used on several tracks, start, stop and change of direction will apply to all identical motors.   There are several different types of motor available for use: Surface Motor – A surface motor moves loads. Vector Motor – A vector motor lets the track ascend and descend. The direction angle for a vector motor can be defined in the properties. In the operation menu you set the x-y-z coordinates in the direction property. Rotation Motor – A rotation motor lets the track rotate horizontally. After a rotation motor has been added, you will find a rotation property in the motor menu in the properties window for the track, where from you can select the rotation motor’s position on the track. Eccentric Motor – An eccentric motor lets the conveyor move from a fixed angle. After an eccentric motor has been added, you can set its fixed angle, in the properties window for a conveyor, to be at the start, end or center of the conveyor. Vertically fixed angle lets the full length of the conveyor ascend/descend. In the properties window for the eccentric motor you can set a limit value (mm) for the +Y direction and the -Y direction, and disable/enable automatic stop.   Modes All motor types have four different operation modes. Operation modes are accessible through a motor’s properties window. When Experior is connected to a PLC, you can set up the motor modes according to the tables below.   The following tables shows the four different Experior motor modes that can be used for interpreting the PLC’s motor inputs and outputs (note that the modes works differently when the Frequency Converter is enabled).   Without frequency converter   Normal Forward = 1, Backward = 0 -> forward direction Forward = 1, Backward = 1 -> forward direction Forward = 0, Backward = 1 -> backward direction Forward = 0, Backward = 0 ->  stop Stop Forward = 1, Backward = 0 -> forward direction Forward = 1, Backward = 1 -> stop Forward = 0, Backward = 1 -> backward direction Forward = 0, Backward = 0 -> stop Two Modes Forward Speed1 = 1 -> motor runs forward at speed1 Forward Speed2 = 1 -> motor runs forward at speed2 Backward Speed1 = 1 -> motor runs backward at speed1 Backward Speed2 = 1 -> motor runs backward at speed2 Forward/Backward Start = 1, Forward = 0, Backward = 0 -> stop Start = 1, Forward = 1, Backward = 0 -> forward direction Start = 1, Forward = 1, Backward = 1 -> ignore Start = 1, Forward = 0, Backward = 1 -> backward direction Start = 0, Forward = 0, Backward = 0 -> stop Start = 0, Forward = 1, Backward = 0 -> stop Start = 0, Forward = 1, Backward = 1 -> stop Start = 0, Forward = 0, Backward = 1 -> stop   With frequency converter Normal Start = 1, Reverse = 0 -> run forward Start = 1, Reverse = 1 -> stop Start = 0, Reverse = 1 -> run backward Start = 0, Reverse = 0 -> stop Two Modes Forward Speed1 = 1 -> motor runs forward at speed1 Forward Speed2 = 1 -> motor runs forward at speed2 Backward Speed1 = 1 -> motor runs backward at speed1 Backward Speed2 = 1 -> motor runs backward at speed2 Forward/Backward Forward = 0, Backward = 0 -> stop Forward = 1, Backward = 0 -> forward direction Forward = 0, Backward = 1 -> backward direction   (note: the direction can’t be changed before the motor is stopped – the feedback signals can tell when the motor is stopped)  

Tracks are usable in both Physics and Discrete Event Mode.   In Discrete Event Mode the tracks are the base components for doing discrete simulation.   The idea is to route loads around in a network for routes.   By connecting routes (snapping tracks together) the route graph is calculated based on the nodes (action points) in the network.   Tracks, by default, run from the red point to the blue point, so when attaching additional tracks, opposite coloured points must be snapped together to ensure the model flows correctly.   To join the tracks together, move them together so the the blue and red connection points merge, while holding down CTRL, so the two components will snap together.   To merge tracks drag one track over the other until both highlight, then hold the CTRL key to snap them together.