Comments on: Argon firmware source code released!

By: Tero

Tero — Wed, 08 Jan 2014 00:35:52 +0000

I made some tips here. It may look bit mysterious before I have time to make some intro documentation of SM library :)

http://granitedevices.com/wiki/Optimizing_SimpleMotion_V2_performance

You may try reducing buffer size. I think 256 or 512 bytes could be optimum.

By: Bernhard Berger

Bernhard Berger — Tue, 07 Jan 2014 12:44:59 +0000

btw is there any sense in reducing the read/write packet size down from 4096?

By: Bernhard Berger

Bernhard Berger — Tue, 07 Jan 2014 12:22:44 +0000

Okay.. with reducing the FTDI latency I’ve gotten it down to <=4ms. That's at least a start.

Hopefully there are some tricks to get it down even further, <=1-2ms would be awesome. :D

By: Bernhard Berger

Bernhard Berger — Tue, 07 Jan 2014 11:35:56 +0000

Haha, yeah sorry about that.. But with fundamental things it’s often better to be documented too much than too little so other people can benefit from it..

By: Tero

Tero — Tue, 07 Jan 2014 11:13:12 +0000

Ticket system works, but you seem to find answer sooner than we see the question there :)

I’ll post shortly latency optimization techniques.

By: Bernhard Berger

Bernhard Berger — Tue, 07 Jan 2014 10:38:33 +0000

Ha! Just remebered that the FTDI default latency is 16ms after driver installation. Might be the reason for the big delay.. I’ll try it out and report back..

Btw. does your support ticket system work?

By: Bernhard Berger

Bernhard Berger — Mon, 06 Jan 2014 19:47:03 +0000

Hmm.. is there any way to speed up communication? No matter what I do, I can’t get the communication via SimpleMotion to work below 16ms.. For my servo wheel project to work recieving positioning and velocity data 16ms is way too slow, considering that I have to do calculations in between and then send the new setpoint value to the Argon.

Is there any way I can get that time down? I’d need it to be at LEAST down to 4ms, preferrably 2ms or even lower as the racing simulators output telemetry data respectively direct input commands at up to 400Hz. The slowest rate we have are at about 60Hz update rate, which I can’t even achieve with SMv2 communication, which makes using the drive stage for this project pretty much useless..

I really don’t want to use a microcontroller to send setpoint signals via PWM as this complicates the whole project and renders it (almost) useless..

What’s really bugging me is that the minimal time for communication seems to be 16ms, above that (using 4 parameters or more in a queue) it seems to scale accordingly (using 4 parameters takes about 20ms, using 6 parameters about 28ms).

Any ideas?

By: Tero

Tero — Sun, 29 Dec 2013 20:59:22 +0000

Yes, clean-up of variable naming is one of the next tasks among documentation and more example apps. Most of parameter names are adopted from VSD-E but their meaning has evolved.

Great to hear you got it working :)

By: Bernhard Berger

Bernhard Berger — Sat, 28 Dec 2013 17:15:28 +0000

Sorry, I’m a donkey.. I got carried away by the naming of the parameter.. maybe “ABSOLUTE_TARGET” and “INCREMENTAL_TARGET” or something more generic than ABSOLUTE_TARGET_POS would have been less confusing.. works like a charm btw. :D

By: Bernhard Berger

Bernhard Berger — Wed, 25 Dec 2013 21:19:56 +0000

So.. I actually need some help already doing some basic stuff..

I’ve dug through the simplemotion_defs.h file but I can’t find a parameter that lets me set a desired torque value. I’ve got 13 hits related to torque in that header file, but a bunch of them are for setting the limit in other modes and the other are marked as “readout”.

How do I actually set a desired torque in torque mode?

PS: again, great job on the V2 API, seems to cover about everything, just lacks some ‘Getting Started’ documentation ;)

PPS: happy holidays, sorry to bother you :)