Slow response time of smFastUpdateCycle ()

Lionel_Lee · 9 October 2018 11:37

Hi all,

I am trying to perform a real-time velocity control using a IONI drive. In order to send commands to IONI in a high updating rate (>2KHz), the real-time PC is communicating with IONI via RS485 with a baud rate of 4Mbps.

According to the document, by using smFastUpdateCycle to set/read the velocity/position, I should be able to set at least 20000 velocity set points per second. But it seems that the smFastUpdateCycle function takes more time than expected to set and read the data, around 160 microsecond on average instead of 50 microsecond as suggested in the document.

Has anyone also tried to use smFastUpdateCycle for realtime control under high updating rate but having the same issue? or perhaps there is some setting I have to set up for such a high speed communication?

Thanks in advance
Lionel

Mika · 9 October 2018 12:29

Hi Leonel,

First thing to check is that you indeed increased the baudrate of the simplemotion bus to something higher than the default value. See:

github.com

GraniteDevices/SimpleMotionV2Examples/blob/develop/RealtimeControlExample/communicationthread.cpp

#include "communicationthread.h"
#include <math.h>

CommunicationThread::CommunicationThread(QObject *parent): QThread(parent)
{
    targetAddress=1;
    useHighBaudRate=false;
    updateFrequency=50;
    trackingErrorLimit=12000;
    proportionalGain=10;
    positionSetpoint=0;
    trackingErrorFault=false;
    running=false;
    clearDriveErrorsFlag=false;
    prevDriveFaultStopState=false;
    prevServoRearyState=false;
    busHandle=-1;
}

CommunicationThread::~CommunicationThread()

This file has been truncated. show original

Tero · 9 October 2018 19:59

Also which device you use for RS485? To reach very high update rates, you need to use very low latency hardware, such as powerful microcontroller and fast code on it to spend minimum amount of time processing data outside update cycle function. With some modern ARM Cortex MCU’s it’s pretty easy to achieve 10kHz, and with optimum code, 20 kHz.

With USB on PC you can typically get only 500-1000Hz.

Lionel_Lee · 11 October 2018 12:04

I followed the example and set the baudrate of the board using the API call smSetParameter(bushandle, 0, SMP_BUS_SPEED, someBaudrate );

The real-time PC’s baudrate setting is modified using the API call provided by the RS485 PCIe cards’ supplier.

By changing the baud rate from the default (460800) to 4M, the performance is indeed improved (600us per smFastUpdateCycle call to 160 us per call), only not as good as it is expected to be.

Lionel_Lee · 11 October 2018 12:12

We ran our real-time software (on preempt rt kernel) on a Aaeon motherboard (EMB-QM87A) and used a RS485 PCIe card (Axxon LF1089KB) to communicate with the IONI.

Tero · 11 October 2018 15:57

Thanks for details! Sounds like there might be still longer delay in PC or it’s serial port. Do you have logic analyzer or oscilloscope in hand to verify?

Here is sample measurement with logic analyzer on TX/RX lines for a SimpleMotion drive.

This is not the actual Fast update communication, but you’ll get the idea. All empty space in diagrams are waste and reduces update rate. The first image illustrates the time how long it takes IONI to start responding after outbound message has been completely delivered. In Fast update commands this delay is always less than 50 µs.

The second images shows the time how long it takes from PC to start transmitting the next command to the SM bus. This is typically the main factor of limited update rate.

Tero · 11 October 2018 16:42

Here is real Fast update command data with 3 MBPS:

And here you’ll see the response delay that PC has with USB connection (above image, just zoomed out so well’ll see total of 3 fast update calls):

In this case we get only some 400Hz rate.