OCP data access routines and System Composer's adapter

there doesn't appear to be any information within System Composer on how to map adapters/data-interfaces to either the Instrumentation Toolbox or OPC Toolbox data access routines. I see some questions about how to represent a 'bus', which helps a bit - and - I am trying to look for that last-mile portion.

[Sam Warner]

taking this question to support

[Sam Warner]

the reply I obtained from support was roughly the only mechanism to enable an adapter to describe a data-interface (and have it usable for actually simulating the true data flow through TCP/IP bus) are the one's attached in the Answers for UDP or TCP below.

Answer 1

[Sam Warner]

Undaunted by hurdles, I've altered the implementation to utilize TCP from UDP. The TCP offering, sadly, was not nearly as straightforward as UDP. Sadly, one can't use tcpip - it's marked for deprecation. Even sadder, one can't use the 'tcpserver' implementation offered within Matlab, either. Its one connection limit, followed by session specific data, means there's literally no way to write to one tcpserver and relay the data to a second to read out from, as the session that writes the data doesn't enable another session to read the information - even if the tcpserver could handle two connections. Worse - try finding a session layer router - preferably implemented to run on an OS.

Of course, OCP, or more likely MQTT, achieves the goal...I guess I am just providing alternatives for others along the way, as this seems one of the least documented paths.

So..... back to the TCP solution....

One needs to utilize a TCP server on the host OS of the simulation. I used netcat on macOS. Once that's out of the way, the rest is downhill. Steps are, (some on the host OS, some with the Simulink/Matlab evironment):

1. create a FIFO as a communication path between pipeline stages: "mkfifo data"
2. start a 'producer' server and send data to FIFO: ... "nc -v -k -l 1090 >data"
3. start a 'consumer' server and move data from FIFO to server.... "nc -v -k -l 1091 <data"
4. use the Instrument Toolbox "TCP Send", and have the producer send to the IP address/port combination
5. use the Instrument Toolbox "TCP Recieve", and have the consumer receives from the IP address/port combination

With those five wonderfully easy steps, one can utilize the Instrument Toolbox and craft up a distributed event simulation using Matlab/Simulink - yet - with downsides (which is why the OCP or MQTT options are the more desirable)

The issues I am still working out are:

a.) timing of data into and out of the FIFO, seems skewed to the producer

b.) time dialation to the consumer, as the FIFO provides zero time-tags to the data

[Sam Warner]

Wireshark showing the data's immediate exchange between producer & consumer.

[Sam Warner]

as long as the sample time for the transmit or reciever are >= 0.001125s the simulation of the infrastructure and the real-time characteristics of IO rate result in no skew, and there's no dialation on the consumer.

Answer 2

[Sam Warner]

I found out more, 'tcpserver' use has a few issues:

1. some "must compile" requirement despite all the models run mode set to "Normal"
2. the tcpserver, oddly, only supports a single connection, requiring a bit of extra modeling to route the data between workers.
3. the extra logic makes placing the entire code in a callback rather ugly for the long term

OPC Toolbox is solely available on Windows.

Reverted to UDP to see if there were any additional hurdles, and this worked by doing:

1. using the normal udpport in the "StartFcn" Callback of the Adapter
2. wiring in a bus between the producer, adapter, consumer; defining the interface, and routing the singal/bus to a terminator within the consumer.
3. using UDPsend, and UDPrecieve

Having the three steps enables the System Composer analysis tools to 'work' for a bus when the bus is a network adapter, and the simulations to work.

Next, I'll be replacing with an MQTT architecture, as UDPs sampling is causing a time-dialation & skid issue in real simulatin.