4Dof-Controller code for arduino mega for AASD-15A and similar driver

I created a arduino sketch for generating those pulses needed to control servo drivers such as the AASD-15A used in the sfx100 project and the pt-actuators. The specific parameters are meant for the sfx100 actuator (ca. 110 mm stroke, aasd-driver, 90st motor) but it could easily be adapted to other configurations. There are currently no convenience/security functions. It currently only works with the arduino mega 2560 because I'm using hardware timer registers directly for better performance. For smoother movement I do interpolation, i.e. I distribute the pulses evenly across the sample interval. I use Pn098 = 10 (sfx100 system uses 20) and use it with FlyPt-Mover with these settings:

Feel free to use and modify (at your own risk of course)

I made the code available on github if you don't want to spend the coins:
https://github.com/cubexvr/servoController

Wow, interesting.

Would love to try it, but I suppose it doesn't work with Arduino Leonardo which is commonly used for OpenSFX projects?

Leonardo has a little bit different timers so it will not work out of the box. Adaption may be possible, I may have a look into it if a lot of people are interested. But arduino mega clones can be had for about 20€/$ and the pinout will most certainly be different

If you do it for Leonardo, would be good to match the pinout.

And yes, this is Open Source

I'm be trying this it for my 3x sfx actuators when I get em up and running in a month or so. Thanks a bunch! Those Thanos boards are expensive and I can't give up Mover at this point.

There is open hardware solution actually for SFX-100...
http://motionsim.blogspot.com/2019/12/open-hardware-4dof-servo-controller.html?m=1

Thanks, appreciate that. Unfortunately i have a longer stroke range (added 100mm to the length) and on first glance I can't change that on this shield. Perhaps versions for

Im on the Thanos waitlist though

You could actually change the Pn98 (Electronic Gear multiplier) from 20 to 40 for example to use it with 200mm stroke...

Shh... its a secret... lol

Right!

Yeah, but you loose half of the resolution by doing that. I'm using 10 so even better resolution, good for smooth movement. And this is open software, so by adapting the source you can change basically everything.

Sure, now you should add some automatic home calibration too, I didn't see that anywhere in the code...

As I said, no security/convenience functions yet, I personally don't need it, I care more about motion quality. If people want calibration (or an end stop switch) they can add it, source is free.

Gotta admit im a bit torn on what to do. Always want the best haha. The Thanos board will cost me a hefty 400 dollar with tax and all and if the Leonardo is generally enough for the SFX normally the Mega should be fine.

I got lots of switches and such lying around so im sure adding a endstop would be easy enough. Or some other solution but ill have to research that. Any hint on where to start for a purely programming solution?

I have a couple of questions.

What's the lowest latency you can get with this?
Do you have a picture of your wiring/pinouts?

Code:

// for sfx100 with pn98 = 10 (pulse multiplier)
const unsigned int minPos = 0;
const unsigned int centerPos = 11000;
const unsigned int maxPos = 22000;

I need to adjust so i get 150mm throw. Do i just do that in the Mover rig gain settings or do i need to modify the sketch? How does these values end up being 0 32 65?

In relation to that i have an issue too. I get a Gain(logististic/value;550;10);1) There's missing a 0 from your picture. It dont feel at all correct for me. Should it move that much with so little movement of the position test? If i keep the gain/log to 550 and just 1 on gains they move normally with no extra gain






If you wouldnt mind briefly explaining how things relate id be most grateful.
Cheers!

Not sure what you mean by latency? I use 2ms calculation time in mover, the aasd drivers themselves have a bigger latency than that. As soon as the data is received from mover output of pulses starts.
For the pins I have no picture, in the code there are comments which pins are used:
// pulse 0
const byte ocr1bPin = 12;
// pulse 1
const byte ocr3bPin = 2;
// pulse 2
const byte ocr4bPin = 7;
// pulse 3
const byte ocr5bPin = 45;

// direction
const byte dir0 = 30;
const byte dir1 = 31;
const byte dir2 = 32;
const byte dir3 = 33;
So first pulse pin is 12, first direction pin is 30, etc
Explanation for maxPos: These are the number of pulses needed for the maximum elongation. SFX-100 has about 110mm stroke, one rotation of the motor is 1000 pulses (encoder resolution / pn98 = 10000/10), one rotation is 5mm (pitch of ballscrew) so (110/5)*1000 = maxPos = 22000 pulses = 110mm. centerPos is just half of that.
Now in mover I use 16bit = 65535 maximum. I divide by 3 (in the code "mapToRange" so that max input from mover is close to 22000 ~ 65535/3, that's just to be able to use the whole 16 bit range.
That "Gain(logististic/value;550;10);1)" or whatever it was exactly was just a try to have a soft limit, you can use whatever you like there, has nothing to do with the controller code.
Hope things are clearer now

Thanks, appreciate the explanation. That clears things up quite a bit

For the latency i meant this bit. Could that be lower for quicker reaction of the driver/motors or isnt there much point to it?

Code:

 
// 2ms = 0.5 us * 4000 (can be adapted to needs)
const unsigned int samplePeriod = 4000;

That should be the same as in mover, its used for distributing the pulses equally across this intervall. You can make it shorter, then the pulses will be sent faster, but that in my opinion doesn't lead to better motion, because its not about "moving as fast as possible from A to B" but rather reproducing the whole continuous motion. Its fast when needed (big movement) but also smooth for slow movements

This is cool. Thanks for sharing the code - for us nerds good to see how some of it works. I'm now trying to understand hardware registers

I recently modified my sfx100 to 140mm stroke. The 140mm stroke needs 140 * 200 = 28000 pulses range, nearest bit value for mover is 15 bit = 32767. Now in the current version of mover (2.9.9) you have a "scale" value but that doesn't change the center, i.e. with 15 bit the output value for center will always be 16383.
So I had to make a few adaptions the code:
...
// for sfx140 with pn98 = 10 (pulse multiplier)
const unsigned int minPos = 2383;
const unsigned int centerPos = 16383;
const unsigned int maxPos = 30383;
...
in setup():
...
for (int i = 0; i < motors; i++) {
targetPos = minPos;
currentPos = minPos;
...
and
...
unsigned int mapToRange(unsigned int pos) {
unsigned int mappedPos = pos;
if (mappedPos > maxPos) {
return maxPos;
}
if (mappedPos < minPos) {
return minPos;
}
return mappedPos;
}
...

The scale value for mover is 28000/32768 = 0.854

@cubexxx Im assembling the electronics at the moment. I cant get it working properly. It works fine with the SFX software start/stop

I thought it would be just using the DIR from the SFX wiring on DIR and Step on pulse but i got ENA on Pulse and DIR on DIR which is straight forward enough

My issue is that it just spins randomly when its connected to these two pins. Or it will just spin as soon as i connect ENA DSUB 6 on any of the assigned pins (Also when PT move is disconnected ) but it does change direction when i move the slider in PT mover pos/neg

Any ideas? It seems to be that it just keeps sending pulses and dont know where it is

This is why i asked for wiring btw, troubleshoothing would be a lot easier if i knew exactly what wires went where. do i need just DIR ENA or all 3 ?



https://opensfx.com/build-process-controller-wiring/