Hello,
I realised during my testing that the nMotorEncoder resets after the nMotorEncoderTarget command. My project requires a nMotorEncoder that never resets(unless I tell so). Can I do something about that?I tried to find the function in the include files to modify it but with no success. What I am needing is like "total tach" from the debugger window.
So far I built a task that keeps the count but in fast oscilative movements(with other tasks working) it skips some ticks .
Any help would be highly apreciated.

Best Regards,
George T.

The solution is to not use the nMotorEncoderTarget feature and do the tests yourself. I suggest creating your own array of target values and having a separate task that loops forever checking the position of each encoder and stopping any motor(s) that have met or exceeded their target. That way you can use it just like the built in behavior but without the reset feature. You will need to think about how to deal with the counters wrapping and other similar boundry conditions.

I understand what you say but nMotorEncoderTarget is very good because it has that slow-to-stop movement that skips in the worst case 1 tick. That is why I tried to change the nMotorEncoder.But how does nMotorEncoderTarget slows?that´s why I asked for the include.Is it using PID based algorithm?

Best Regards,
George T.

I don't know for sure what method it is using but I would guess that it uses PID. Are you using standard LEGO motors? The code for Tetrix motors is likely to be quite different since the encoders have about 10x the resolution of the LEGO motors.

I am using standard Lego motors. But one question still remains: Where is the file with the code of the nMotorEncoderTarget and nMotorEncoder?

Best Regards,
George T.

there is no certain file. It's a hidden obscured undocumented function, certainly a feature, not a bug

Sarcastic as usual...

well I've built a PD algorithm that works theoretically. But when I try to add the Integral part everyting goes messy(the motor runs endlessly). I used the constants that were apearing in the robotc debugging window(450,50,650) and divided the whole PID ecuation by 100. Are these the correct constants that the nMotorEncoderTarget is using? If not I haven't found a good way of finding them. Trial and error sounds a bit to time consuming so if anyone knows a theoretical way of finding them(or a more theoretical trial and error) it would be really apreciated. I read about the Ziegler–Nichols algorithm but calculating the oscilation period of the motor is quite triky because it oscilates very fast. All in all this is what I wrote so far:



There may be some syntax errors because I worte it from my rememberings(i don't have my laptop with my files right now).

EDITED by Miki to add code tags around code section

Hi todorangrg,
I would say this code is part of the firmware released with RobotC and can't be find (as source code) in programs running over it.
Miki.

Um, not to be rude Miki, but why did you revive a thread of 3-years age?

well just after I rescued my PC, I tested it a bit to check if everything was ok. I went on RobotC forum and answered to this new topic.
then I updated the PC clock

Miki.

Aha, I was wondering about that. I was curious that I'd never seen this thread before, and then I noticed Ford Perfect had posted, and after much surprise, I noticed the date. Does phpBB really work off of your system time?

Hum. you may be right. The fact my PC believed we were in 2002 doesn't explain anything. It is possible that I saw a new post (the one stamped April 24th, 2012, 12:41 pm) of todorangrg and then I navigate in his posts without paying attention to their date.


April 24th, 2012, 12:41 pm

I hereby award you the prize for longest unintended thread bump in history!!!!!