"periodic" jitter when using buffered Motion

argon
simplemotion

#1

Hi Granite Devices Community,

I am currently working on a two-axis machine for our gunsmithing company that should be used to rifle barrels.

Here is a short version of the problem:

When using buffered motion (also when using the example project from github) i get a short jitter on every axis. Except that jittering, the axis run very smooth.
The jittering ocours roughly every 2-3 secons on each axis (even when using just one axis), but not at the sime time. It seems like the point of time where the jitter ocours on each axis drift relatively to each other.
For me it looks like the drives are loosing some points or the clock sync or something similar.

Does anyone of you have an idea what the reason could be or at least where to start looking for it?


Here are more details of the system:

2 Komotek Servo motors (one KANZ-01BF1N2 100W, one KANZ-06BF1N2 600W) with 10K encoders, connected to argon drives
The servo tuning might not be perfect (but reasonably well!) at the moment, but as the problem occours more or less predictable I don’t see the reason there.
Everything is installed acording to the wiki and with high quality components (SMV2 Breakout board with E-Stop, SMV2-USB Dongle, high quality LAPP resolver and motor cables, electrical controll cabinet according to industry standards)
The Controller is a Windows10 Machine.
The lattency setting for the FTDI COM port is set to 1ms. (I tried different settings of various parameters in the advanced settings dialog, do they make any differnce btw?)

As the problem occours even with the buffered-motion example, I don’t think it makes sense to go into detail about the controller I want to use in the production system. In short it is a c# application (95% finished) in which i have wrapped the simplemotionv2.dll. If I get the system going I would be happy to share the servo drive part with you, I have written some classes that wrapp the simplemotion side quite nicely (getting bus and drive status in dedicated class, threaded application with motion instructions that can easily be used in the main application,…)


Thank you guys,
I hope you can help me get this going…

Andreas


#2

Hi!

I think I know what it is about. This is probably quite old issue and addressed in IONI firmwares later than 1.6 (however I recommend latest FW to be sure). The jitter should be eliminated when you enable linear interpolation in buffered mode.

To activate that, you need to write BUFFERED_INTERPOLATION_MODE_LINEAR into SMP_BUFFERED MODE parameter on each drive.

/* SMP_BUFFERED_MODE defines the behavior in buffered motion commands:
 * bits 0-3 (LSB): setpoint interpolation mode.
 * bits 4-31: reserved for future use.
 *
 * Setpoint interpolation modes:
 * 0: apply nearest setpoint (default). If there are non-setpoint commands between setpoint commands,
 *    these are executed in order with setpoint commands. Non-setpoint commands are executed without time delay to allow setpoint
 *    commands to be executed at constant frequency.
 * 1: linear interpolation between setpoints. If there are non-setpoint commands between setpoint commands,
 *    these are executed one setpoit command in advance compared to a setpoint commands. This is a result from look-ahead buffering.
 *    Non-setpoint commands are executed without time delay to allow setpoint commands to be executed at constant frequency.
 *
 * Note: this is present only in SM protocol version 27 and later.
 */
#define SMP_BUFFERED_MODE 16
	#define BUFFERED_INTERPOLATION_MODE_MASK 0x0F
	#define BUFFERED_INTERPOLATION_MODE_NEAREST 0
	#define BUFFERED_INTERPOLATION_MODE_LINEAR 1

It seems that it’s not being used in the example program, we’ll change that.

Let me know if this helps!


#3

One more note: drives buffered mode works by synchronizing clocks over SM bus. It takes about 30 secs of buffered mode operation to completely synchronize & stabilize clocks between axis. So if you need extreme accuracy, let the buffered mode run for 30 secs (i.e. drive static setpoint to all axis during this “boot” time) before performing the precision moves.

If you stop buffered motion and continue it later, the syncing happens much faster (normally instantly).


#4

Hi Tero,

Thank you for your prompt reply!

I am using Argon drives, so as far as I know (an found in the Argon firmware SourceCode) there is no “SMP_BUFFERED_MODE” in the Argon firmware.

I have allready let the drives run way longer than 30 seconds (more like an hour) and the behaviour does not change.

Are there any other reasons for the jitter you could think of?

By the way:
Interestingly I noticed another Issue (not a problem for me, but could lead you to an idea):
I do get more packets back (summed up over the time of some commands) when using BufferedFillAndReceive than i sent, (i.e. newAxis->numberOfPendingReadPackets becomes negative), is this normal behaviour?

Thank you, Andreas


#5

Thanks for details!

Unfortunately the linear mode is not implemented in Argon, and implementation of it can’t be pulled of very easily. To workaround I suggest:

  • Check whether motors would be suitable for IONI drives. If they are, we can do swap of the drives and refund the difference. Conversion should be quite easy as same encoder connector and mostly same settings work 1:1.
  • Use some other metod of controlling drives. I.e. use of some external step/dir generating hardware could resolve the jitter issue. (Google for SmoothStepper product and some CNC applications that support it)

#6

Hmm, not sure about that. Would need more info & investigation to comment on that.

Perhaps it could be explained by the fact that pending read packets are delayed in buffered motion? See https://granitedevices.com/wiki/Buffered_motion_stream_in_SimpleMotion_V2