Hallo, 

ggf. handelt es sich hier um ein Missverständnis.

Die optisch sichtbare Oberfläche ist eine reine "Animation" auf Basis der Textur und deren Skalierung. Die Bewegung des Fördergutes ist rein physikalisch.

Zuerstmal haben die beiden Dinge nichts miteinander zu tun und es lässt sich nicht automatisch verbinden weil grundsätzlich die Textur sehr individuell sein. Damit die "Animation" nun identisch zur Fördergeschwindigkeit ist (was zuerstmal reine Optik ist) muss in der Transportsurface der Texturescale passend eingestellt werden. 

Der Wert ist abhängig von der Größe des Meshes sowie der Größe und Skalierung der Textur (d.h. den Einstellungen im Renderer des Materials).

Beantwortet das die Frage?

Gruß

Thomas

Hallo,

ich habe in meinem Test aktuell erstmal nichts gesehen. Können Sie ein Video zusenden indem das Verhalten zu sehen ist.

Es wäre auch gut, wenn die entsprechenden Parameter im Inspector zu sehen sind.

zur "Smooth Acceleration": hier wird einfach die Beschleunigung anders berechnet, um eine sinoide Beschleunigung zu haben. 

An sich muss der beschriebene Effekt an dem SetDirty liegen. Bitte probiere mal EditorUtility.SetDirty(component);

Hi,

do I understand it correctly - you want to have values (PLCInputs) which should be written by Unity to the PLC. Before writing them and on startup, Unity should read the values (like PLCOutputs) and use this values for writing. Am I right?

If I am right I even don't know if that makes sense. PLCInputs are always written to the PLC (and old values on the PLC will be overwritten). PLCOutputs are always read from the PLC. 

Thanks

Thomas

Hi, I never  tried Roboguide and EthernetIP. Are you sure that roboguide is able to communicate over EthernetIP. We don't have RoboGuide - so we realy don't know what do do in your case. Sorry.

The issue is solved and will be released today in realvirtual.io Professional 2021.10.

Ich würde es nicht komplizierter als nötig machen und zuerst mal einfach beginnen. Ggf. auch auf das Align zuerstmal verzichten. In der Box ein Sensor macht keinen Sinn. Es heißt auch "Pick based on Sensor" und nicht "Place based on Sensor". Das Ablegen muss im allgemeinen irgendeine Steuerung veranlassen. Also die Robotersteuerung wenn sie am Ende des Pfades ist oder ein Script in Unity das den Roboter steuert. Vielleicht wird er ja auch nicht abgelegt weil er gleich wieder gegriffen wird. Bei einer derartigen Anwendung sind normalerweise Signale in "SignalPick" und "SignalPlace" die ein Script oder die Robotersteuerung steuert. Ich sehe hier keine Signalverknüpfung - d.h. ich vermute dass das Ablegen in der Grip Componente nicht gestartet wird. Im allgemeinen Demomodell ist ein Bespiel Assets/game4automation/Scenes/DemoGame4Automation.unity und es gibt einige Beispiele in Assets/game4automation/Scenes/DemoGripping.unity. Einfach genau so nachbauen, dann funktioniert es auch sicher.