User Configurable Packets

SynqNet networks support configurable data packets. This feature makes it possible to fine tune the network traffic for optimum performance. Most applications will NOT need to configure the network packets.

During network initialization, the MPI/Controller discovers each node and reads its Node Type, Option, and FPGA DeviceVendor identifiers. The SqNodeLib library uses the node identifiers to determine an index into the resource tables. The resource tables are an array of structures containing the feature count for each node hardware and FPGA. If the SqNodeLib cannot find an exact match for the node identifiers, then it will take an educated guess and set the SqNodeInfo.id.exactMatch to 0 (FALSE). Based on the resource table, the packet data is automatically configured to match the features each node supports. Thus, features that are not supported by specific nodes have already been eliminated from the data packets.

For systems that have a large number of nodes or need to run at high sample rates, reducing the packet size can improve the control latency. If your application requires packet optimization, begin by examining the SynqNet Timing Calculations. This can be done through the MPI by using the mpiSynqNetTiming(...) method. The timing calculations are based on several variables, so make sure you have all your nodes connected and all of your controller configurations set. Then, save a copy of the timing calculations. This will provide a baseline, so you can compare the timing after packet optimization.

Using the SynqNet Config methods and Packet Cfg structures you can optimize the packets by removing unused features:
          mpiSynqNetPacketConfigGet(...)
          mpiSynqNetPacketConfigSet(...)
          MPISynqNetPacketCfg{...}

ALWAYS make the mpiSynqNetConfigGet/Set(...) calls BEFORE mpiMotorConfigGet/Set(...), mpiMotorEventConfigGet/Set(...), mpiFilterConfigGet/Set(...), mpiAxisConfigGet/Set(...), mpiCaptureConfigGet/Set(...), and mpiCompareConfigGet/Set(...). The controller memory has several internal pointers that directly address the packet data. mpiSynqNetConfigSet(...) will shutdown the network, initialize the network with the new packet data, and recalculate the internal pointers. Calls to configure the motor, filter, axis, capture, and compare objects may use these pointers. The network packets is the interface between the MPI/Controller and the node hardware. If you try to configure the motor, filter, and axis objects BEFORE configuring the packets, you might run into some trouble.

For example, if you configure a capture to trigger on a motor's dedicated home input and then use packet configuration to remove the capture data from the packets, the capture object will still have pointers to the old packet addresses. The capture object will not work properly. This type of problem can have much worse consequences if the previously configured object writes to an old packet address.

If you do not know what object configurations have been made, reset the controller. A controller reset will clear the controller's memory, initialize the network, and calculate the internal pointers. Then make your packet configurations and object configurations.

It's a good idea to make one packet configuration change at a time. Then test your application. It may not be obvious if your application uses a particular feature. It's much easier to make one change and determine the results then to make lots of changes and try to figure out which change caused problems.

After you have optimized your packet configuration and configured your objects, then read the SynqNet Timing Calculations again. Compare the baseline timing to the optimized packets timing. From the comparison, you can determine how much packet optimization improves your system. Then, you'll probably want to re-tune your servo loops to get the best performance.