BCC tool NeXTScreen distorts run-time execution speed

[HaWe]

hey,
I just observed that the BCC tool NeXTScreen may severely distort the run-time behavior:

program: PID motor regulation ver 0.89g ... 0.91g
PC: c2duo E6650 2*2.33 GHz 4GB RAM Win XP32 pro
same results at any (either) USB 2.0 port:

no polling, screen shot after program termination: approximates target quickly and smoothly


refresh rate 50ms: heavy perpetual jerking, no approximation at all


refresh rate 200ms: heavy initial jerking, approximation after a while


with another PC (Intel i7, 4*3.4 GHz, 4GB RAM Win XP32 home) everything is running fine at any polling speed.

is this normal?

[afanofosc]

The polling for screen memory via an NXT system command (IOMapRead) is a very comm-module intensive operation since the command module is where direct and system commands are handled. It does not surprise me that putting such a heavy load on the comm module could result in reduced performance in other modules.

Not sure why a faster PC would result in less of a load on the NXT exactly. Maybe it transfers data to and from the NXT faster, somehow?

John Hansen

[HaWe]

honestly I didn't expect the NeXTScreen tool to distort the NXT calculations in either way when monitoring the screen at any PC.
Anyway, good to have found out that it might do nevertheless. I was wondering why some tuned PID regulation settings worked perfectly (tuned at the faster PC) and then suddenly (on the other PC) not at all any longer.

BTW, both PCs got USB 2.0 without any USB 1 devices plugged to.

[aswin0]

Hey Doc,

I haven't studied your code but a remark nonetheless. There is a quick way to write a PID controller and a proper way. The quick way does not take the iteration speed into account as it is assumed to be a constant. The proper way does take this into account. The quick way gets disturbed very easily by variations in iteration speed and is almost impossible to get stable, as I learned the hard way. Also the tuning methods you find on the Internet are based on the proper implementation.
Your results suggest you implemented the quick way.

The quick way takes this form

Code: Select all

Out = p * Kp + i * Ki + d * Kd

The proper way takes this form

Code: Select all

Out = p * Kp + i * Ki * dt + d * Kd / dt

Aswin

[HaWe]

update:

aswin,
thank you very much!
although the topic is not about PID but about the BCC tool NeXTScreen which distorts run-time execution speed on the NXT...: ;)

As I'm currently already taking the iteration time Δt for every loop, it was not a big thing to multiply the I and D factors by an additional delay/correction-factor.
but
the effect is the same as before, there still is the same difference between both PCs as I described above.

So that the USB data transmission is distorting the run-time execution speed is still an issue !

ps:
nevertheless - admittedly the "proper PID code" is working even more stable over a larger bandwidth of adjustments! Thx again!