Question motor speed adaptation to the motors

ok, yes, that's exactly what I'm doing
But I can not do anything good.
it's too violent. or too soft.
it gives the impression that there is not enough resolution.

Ok,
here is a video with the automatic recording of the values without any accident:
40% Surge, only Surge.


now I will repeat what I wrote above.
it's violent, too violent.
if I want to reduce this violence, I have to increase the values.
if I increase the values, I lose the effects.

I do not know how you translated things, but for me there is a problem of adaptation of the resolution, speed motor.

if I want less violence I must increase the values or lower the speed.
whatever I do, I lose in violence but also in definition.

if I lower the engine speed, it's the same thing, I can not find a solution.

I would have to increase values but also increase the resolution.

I do not say it comes from Simtools, it's a feeling.
if I could multiply by 10 or more the resolution, I could increase the values to lower the violence, without losing in details.

what is the point of having an axis of 17 ° and limiting it to 10%?
it's really a shame
for 6DOF for example, the% are fixed.
in fact lower the% of the axis decreases the inclination, for braking it is even worse.
my post title was well representative of the problem:
I can not find a good setting between violence and quality effects.

I did what you said to me, I already did that before.
and the result is bad.

too violent or without any effect as I say from the beginning.

there is no way out.
I can just find a compromise by lowering the speed of the engines.
But I get to the same result, lowering speed is like increasing the value of effects

I put the question to Thanos, I think there is a problem of resolution or adaptation between the firmware, and the choice of 16-bit resolution.

can be a problem between Simtools and the Thanos AMC

I tested with 2 / 2.5 / 3 / 3.5 / 4
10% / 20% / 30/40/50/60/70/80/100%
all combinations% and effects
with all the effects one by one and they too in all combinations.
Normally Heave is very detailed. I chose it as a reference when I test, and although it is very bad.

http://hpics.li/9a7b441

I already tried to put the full parameters, I thought, but it does not matter, I can still try with the full settings ...
For the PID, it is set to not have an overflow.
I think that if it was slow, I could have a smoothing effects and that kind of behavior, but there it is rather reactive and precise.

in the past, with the AMC 64 / then 128, by ignorance I put 32 bits in the settings of the interface.
I thought it was better!

it worked well!
but now it's impossible.
if I put 32 bits it drives the engines in a bad position.

yes you're right, I also know, normally you have to put 16 bits in the interface for the map AMC Thanos.
But by putting 32 bits, it increased the resolutions and improved the feeling on the effects!
I do not know why, I'm not a developer, how is that possible?

the fact is that today it does not work anymore ...
can be a firmware update? or soft? Xsim or Simtools? or both.

I asked Thanos

there are updates at the moment ...

the first seems to improve the resolution

The AMC1280USB is trully 16-bit only. The serial interface has capture counters for the data, and data rejection function for data that doesn't meet the requirements.

After it receives the Data start identifier ( AB or AC ) it counts incoming data in packets of 2bytes to form each axis 16-bit values. If the new value for each axis is too different than what is expected it gets rejected. For example:
a series of values: 100, 102, 104, 108, 116, 53, 130, 135 ....
It will reject the value "53" as its most likely not part of usable data, probably is corrupted data or stray data as it doesn't follow the general direction of the rest data samples.

So if you send to it 32-bit data, it will strip down the extra additional 16-bits, but it might keep the wrong information if it seems more relevant.

Please only use 16-bit mode and if you have any issues with the motion, try increasing the data transmission delay to 4ms or 8ms. Also don't use USB extender cable, even a powered one sometimes cause data corruption.


Thanks
Thanos

Ok, but then, why in the past the quality of effects was improved by putting 32 bits?
Well, today it does not work anymore.

what is the best value of time for the quality of the effects? 0, 1,2,3,4 or 8 ms?

Not sure why. I could not replicate it. But the serial communications module have had undergo huge reconstruction since to be as much accurate and error free. The new module is three times the code size as it checks the validity of data and includes failsafe features that weren't present before in early firmware versions. I think these are introduced in early v2.1x versions.

You may want to set the controller to work in "Motion Data" mode only. See this video how to find this setting.


The recommended delay is 4ms, but if your USB latency is not set correctly, you may need to increase it to 16ms (USB standard latency). You can decrease the latency of the USB serial driver in the device manager.


Thanks
Thanos

Ok , thank you for your expertise
My USB setting:
http://hpics.li/d995bad
I put 1ms in the setting of my USB
by default, it was 16

I changed the setting and put "seer feedback off" what is this function? does this cause other problems?
it was before on "On"

edit
if I put 1ms in the USB settings, can I put 1m in the interface of Simtools?
or the best result will be with 4ms?
I tried 1 ms I do not notice too much difference ...

The only setting needs to changed in ftdi driver is the latency one. No need to change other settings.

Use 4ms in simtools to let the AMC1280USB sync to that. If you put smaler delay than the serial communication module can handle, it will simply reject the overflow data and flush them from the buffer.

The serial communication module runs independent from the PID loop and has ultimate priority in processing incoming data. If you overload it, it might delay a little bit other functions like the PID loop and the position sensors reading that it takes place every 1ms, resulting in time stretching up to 2ms (not big deal).

The LCD menu also delays the PID execution a little bit, and this is the reason I enforce it to be disabled now while the controller is in online mode receiving motion data from the motion software.

Thanks
Thanos

""The LCD menu also delays the PID execution a little bit, and this is the reason I enforce it to be disabled now while the controller is in online mode receiving motion data from the motion software.""

it's automatic now, there is no switch to go down?