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

Hi, I have a couple of questions about the program.

Where did the pulseLength value of 5 come from? Is that based on the frequency of the ATmega?

How did you determine the number of pulses per revolution for the servo drives? I can't find that in the servo manual. The multipliers don't seem to list a base value unless it's just one pulse per rev.

Sorry for the basic questions, this is my first experience with Arduino.

The pulse length was chosen so that the timing works well with the arduino timers and the 50kHz base frequency and is long enough for the drives. You shouldn't change it unless you know exactly what you're doing. The motors uses normally with the aasd drives have 10000 pulses per revolution, but you can set dividers and multipliers with P98 and P102. Somewhere in the thread I have explained how to calculate the needed number of pulses

I want to try it without download link

just have made a case for the mega
https://www.thingiverse.com/thing:4673813

I added it on github: https://github.com/cubexvr/servoController

@cubexxx
I have been setting up your program with the Mega board.
However in PtMover I am not seeing any output.
I have tried ver 2.9 and ver 3.33
I was wondering if the output string has changed...
I am using <255><255><a1><a2><a3><a4>

You have to use the actual actuator keys in the output string (you named your actuator keys "Axis1a" and so on), that's a standard FlyPT Mover thing

Thank you.. That did solve the problem. I never saw the documentation on that and the program defaults to the "<Axis1a> format in the Rig Module. I see it now has a "Speed Key" any idea what that does?

@cubexxx
I printed the spacer and I am assembling my new SFX100's.. Am I correct that there is no physical stop on the slider to prevent the Ball Nut going too far and spilling its ball bearings?
I know the Thanos board senses the park position by "jamming the motor"
I am not sure if it does the same if the actuator is extended too far or not.....

Correct, the software has to assure that the limits are not exceeded by not sending values out of the range. By printing a shorter spacer you can create a hard stop for the slider. I'm using 140mm and so far I never had problems, arduino software and motor drivers are very stable, never had a position error here. You have of course to assure that the rig is in its lowest position (acuators fully retracted) on startup (position 0) for that to work, but gravity does that automatically

Thank you for your response. I have already managed to unscrew the ball nut once and have suffered the consequences. lol.
I understand your reliance on the Arduino to prevent the problem.
If things can go wrong it will at my house.
I think I will just stack some rubber "O" rings after the slider to limit the extension travel.
I hope to add traction loss and surge to the rig in the future.
At that point I will most likely switch to a Thanos controller.
Have a great New Year !
tp

after expanding a second controller and additional motors, I had a strange behavior that under
booting or restart the operation system the motors have some accidental movement (maybe EMI ?)
So I decided to add some safety function.I took port 53 (arduino) with a pull up resistor for enable pin 6 (AASD-15 SUB_D) signal of the E-stop so the motors are only active if FlyPT ist connected.

@cubexxx May I ask you which are the driver parameters you use together with your arduino sketch?
I'd be interested regarding ramps (pn109 ~pn112) and "pid" parameters (pn258 and pn259).
I like fast unfiltered servos (pn109 = 0, pn258=1, pn259=4) but slow movements are "broken" in bits and not smooth at all. But if I start inserting ramps or tame the drivers, then I lose the detail below.

Hello

Gonna double post this one.

One issue i am having using this and im not 100% if its a code thing or a Mover thing. Been using this sketch for quite some time now and this one issue means i really cant trust it completely.

If i restart my computer and connect to the Ardunio it will just go the wrong way and slam it. My SFX is on the bottom so it will just try and move until the drivers fail but my gearboxes just go full back and rips out whatever is able to be ripped out.

Now if i keep the power off, turn on and off Mover connection its usually ok but sometimes i have to to do it several times. Something i cant take the chance on really. This is the same on all Mover versions. What do you think could be the issue here?

Are there any messages on the aasd driver panel?

Sorry for the late reply.

it kicks to -400 and sits on 0 from there. It makes no sense really. Why does it fail after a comp restart and work if i reset the ard and cycle mover on/off when its off.

Edit.
I see Wingert here most like has had the same or similar issue as me.

Regarding some of the usb-problems that have been reported and that I had myself (sometimes mover would disconnect) I added another layer of isolation between arduino and drivers, i.e. I don't connect the output pins of the mega directly to the driver inputs but bought this little device for electrical isolation. So far it's more stable now and I didn't have connection failures since. Now when you look at the schematic of the aasd drives there should be already an optocoupler at the inputs but I think there may still some "pollution" come across and spread into the arduino and via the usb to the pc.

Simpler than that: don't wire the DB25 shield on the same ground as the USB...

Did that already, still it is better with additional isolation

Or use common ground for your PC and servos behind a line filter wall, to avoid ground loops.
Ground loops can literally kill the USB power circuit on your PC or activate safeties on it causing the disconnects you experience. Using the USB isolator you mention, you just moving the ground loop to another device also attached on your rig and can cause ground loops, like your steering wheel, pedals or VR headset...