sorry we don't have a solution for the problem. Because of Unity is changing very fast we decided to relay on the Long Term Support releases which give long term support and better stability. So my advice is to use Unity 2018.4.8f1 and other 2018.4 Versions
there was a problem with the automatic settings of the defines.
Please check if the PLCOutput Script was added to your variable automatically:
If not please set in the defines manually "GAME4AUTOMATION" and reimport all OPCSignals.
Now it should work
I am wondering why the event doesn’t works with OPCUA in the Beta - I will check an make it work
I will send you the beta via mail download link.
At the end it was easier as expected and we had an error in the signal override stuff what caused some problems.
At the end now it should work like you expected at the beginning. You can register to Signal change events by:
var com = GetComponent<PLCInputBool>();
com.SignalChanged += SignalChangedRuntime;
public void SignalChangedRuntime(Signal signal)
Debug.Log("Signal Changed Runtime " + signal.ToString());
Or you can use as an alternative UnityEvents in the Inspector:
You can see how it can be used in the Script TestSignalChanged attached to CanConveyorSensor in the Demo model.
The signal changed events should now be also emitted if you use Simit as an Interface.
Please check if everything works if expected. We are going to release this officially next week.
... and please give Game4Automation a positive feedback in the Asset Store Reviews - this is really helpfull!
Simit would need to be in this case the OPCUA server. Game4Automation is only able to be the client. Are you using Simit for modelling the logic or is it more acting only as an interface. If it is just an interface you could connect to the OPCUA server in the PLC directly from Game4Automation.
Please send me your Game4Automation Invoice number (i would need this to check your license).
You will get the Beta this afternoon.
And yes - this solution works for all Signals - independent from the Interface type.
I think I found a flexible way. We could implement Unity Events on the Signals.
This seems to be a very flexible and transparent way for the user:
Could you please check this if this fits your needs. If everything works for your side we would release. I will send you a beta version today or on Monday. Does that fits for you?
1000 - 20.000 is a lot. I am expecting more the Interface itself to be a bottleneck. By design - because of the SHM interface - Unity needs to loop through all the variables each cycle and to update them. In relation to that, I think that the mentioned update method is not costing much additional resources. For providing the change event I would need to implement a setter for the Structs StatusBool, StatusInt.... And this setter will be called each cycle (because of the necessity to loop through all SHM Variables) and will do more or less the same as the proposed update method. So I don't see so far a big advantage in implementing this.
Are the variables changing very fast in your application? Did you consider using OPCUA because there the variables are watchable and you can implement an event which is called when they are updated. Or is it necessary to use Simit?
Customer support service by UserEcho