Editing Optimizing SimpleMotion V2 performance

This article lists the ways to optimize throughput and reduce latency of [[SimpleMotion V2]].
==Factors affecting to SMV2 speed==
The speed of SMV2 is limited by:
*Latency of RS485 communication device on the host side (i.e. [[SimpleMotion V2 USB adapter]]). This is the time delay of the communication device has during one write-read cycle, typically in range of milliseconds.
*Command execution time of SMV2 slave device (servo drive). This is the delay how soon slave sends the return data after it has received the command from the SMV2 host. On [[Argon]] this is typically around 1-2 ms for a single command and 0.4 ms on each additional command in the queue (see later sections for info about queued commands).
*Baud rate of RS485 bus. By default this is 460800 bits per second which is not typically the bottle neck. It is possible to change baud rate by one SMV2 command if necessary (TODO: how).
==Improving performance==
===RS485 adapter latency===
One major source of latency is the RS485 adapter. Two ways to improve this:
*If using [[SimpleMotion V2 USB adapter]] on Windows, go to Control panel->Device manager and find the USB Serial Port of the adapter. In the driver settings you will find the latency timer setting which defaults to 16 ms. Reduce this to 1 ms and click Ok.
*Another option is to use a PCI/PCI-E based RS485 adapter which may have near zero latency and also better real-time capabilities than USB devices.
===Optimizing code===
The easiest way to use SMV2 library is to use ''smSetParameter'' and ''smRead1Parameter'' commands. However these commands are not optimal as they set and read only one parameter at the time and all latencies are added to this single call.
====Queued calls====
The more optimal way is to use '''queued''' SM commands. Queued command is a list of commands that are transferred to a slave in single data transfer, executed as a batch in the slave and finally all return data is returned as list. In this case bus latencies occur only once per multiple commands.

Instead of doing this...
<pre>
smSetParameter( handle, deviceAddress, paramId1, paramVal1 );
smSetParameter( handle, deviceAddress, paramId2, paramVal1 );
smSetParameter( handle, deviceAddress, paramId3, paramVal1 );
smSetParameter( handle, deviceAddress, paramId4, paramVal1 );
</pre>
...one may do this:
<pre>
smint32 nul;
//append commands to queue
smAppendSetParamCommandToQueue( handle, paramId1, paramVal1 );
smAppendSetParamCommandToQueue( handle, paramId2, paramVal2 );
smAppendSetParamCommandToQueue( handle, paramId3, paramVal3 );
smAppendSetParamCommandToQueue( handle, paramId4, paramVal4 );

//execute commands over SM bus
smExecuteCommandQueue( handle,deviceAddress );

/*read return packet values. This is dummy as we don't need to read any parameters 
in this example now. However it's always required to read all return data from buffer 
before appending new commands. So each smAppendSetParamCommandToQueue will need 
one smGetQueuedSetParamReturnValue after smExecuteCommandQueue.*/
smGetQueuedSetParamReturnValue(  handle, &nul );
smGetQueuedSetParamReturnValue(  handle, &nul );
smGetQueuedSetParamReturnValue(  handle, &nul );
smGetQueuedSetParamReturnValue(  handle, &nul );
</pre>

In the above example, the ''smExecuteCommandQueue'' is the only line where RS485 is being used thus generating only one write-read latency. ''smAppendSetParamCommandToQueue'' and ''smGetQueuedSetParamReturnValue'' transfer data only inside SMV2 library buffers and are fast calls.

=====Queued size limit=====
One SMV2 command or return data packet can hold up to 120 bytes of payload data. This means that one should not add too many commands to the queue to avoid exceeding the 120 byte limit in outbound or inbound direction.

Single smAppendSetParamCommandToQueue commands consumes maximum of 6 bytes in outbound data and smGetQueuedSetParamReturnValue maximum of 4 bytes. So one can safely queue 20 set parameter commands in the one transfer.
====Low level queued commands====
{{info|This is work in progress chapter, don't use}}
This section shall describe how to further optimize communication by using lower level queued commands instead of smAppendSetParamCommandToQueue and smGetQueuedSetParamReturnValue which do some dummy assumptions (such as all parameters are written as 30 bit values and every time parameter address is set even if it's not changed from the previous set parameter command). Also reading variables while writing one is possible without separate command which reduces the amount of SM commands needed.

Following example will:
*Initialize read-out parameter address so that all further SM commands will return the desired parameter as return value
*Use custom parameter lengths to reduce amount of data transferred

<pre>
TODOTODOTODOTODO
</pre>

<pre>
//set address where values are written. Consumes 2 bytes of outbound payload
smAppendSMCommandToQueue( handle, SMPCMD_SETPARAMADDR, paramAddr1 );
//write parameter value. SMPCMD_16B consumes 2 bytes of outbound payload
smAppendSMCommandToQueue( handle, SMPCMD_16B, paramValue1);
//set address where values are written
smAppendSMCommandToQueue( handle, SMPCMD_SETPARAMADDR, paramAddr2 );
//write parameter value. SMPCMD_24B consumes 3 bytes of outbound payload
smAppendSMCommandToQueue( handle, SMPCMD_24B, paramValue2);
//set address where values are written
smAppendSMCommandToQueue( handle, SMPCMD_SETPARAMADDR, paramAddr3 );
//write parameter value. SMPCMD_32B consumes 4 bytes of outbound payload
smAppendSMCommandToQueue( handle, SMPCMD_32B, paramValue3);

//execute commands over SM bus
smExecuteCommandQueue( handle, nodeAddress );

//read value commands (one per each append command). Size of inbound payload depends on how large TODOTODO
smGetQueuedSMCommandReturnValue( handle,&ret );
smGetQueuedSMCommandReturnValue( handle,&ret );
smGetQueuedSMCommandReturnValue( handle,&ret );
smGetQueuedSMCommandReturnValue( handle,&ret );
smGetQueuedSMCommandReturnValue( handle,&ret );
smGetQueuedSMCommandReturnValue( handle,&ret );
</pre>