Task manager issues

[daves]

Issue 1

 

The biggest problem with task manager which confused me and wasted time was the tasks display:

 

 

What are the Calculation Time values in the table? What is the difference between those and the value from hovering over the bar chart? I found after a good deal of grief the hover value, and that this must be the true time.

 

Issue 2

 

Where have the CPLCs gone?

 

 

Issue 3

 

Can I reset the Tasks - Peak Time values. They could be useful if they could be reset, as it is they (particularly background) seem to peak during download or whenever and you can't use them for study after that.

 

Issue 4

 

The Programs tab does not show the true Coord and Running states, in particular I know program 1 is running in CS1 but it shows Not Assigned, No.

 

Refresh List fixes this but then clicking on other non-running programs shows them as running Yes.

 

Issue 5

 

Column clicking to order lists:

 

PMAC Memory Overview - You can order by what you choose, then next refresh the memory columns update to the original buffer order (which is not necessarily the same)

 

PLCs, Programs, Sub Programs - Size orders the column alphabetically rather than by size.

 

Servo - Motor is again alphabetical, ServoCtrl is bizarre.

 

OS Resources - Similar to above.

[curtwilson]

In the table, the calculation times are the times per cycle, so in your example, the servo tasks are taking about 71 usec each cycle. In your case, you have a 2.25 kHz servo update, for a cycle time of 442 usec.

 

In the bar graph, the times are expressed as the processor time used for the task in the span of one background cycle, which in your case is 1000 usec. So the time you get by hovering over the servo bar is ~71 * 1000 / 442 = 160 usec. In the bar graph, we had to put all of the values over a "common denominator", so to speak, to be able to show them together.

 

We have on our to-do list to add a button to this control to allow you to reset the peak times. Presently, just type into the terminal window Sys.MaxPhaseTime=0, Sys.MaxServoTime=0, Sys.MaxRtIntTime=0, Sys.MaxBgTime=0, as desired, to do this manually.

 

A bug in the most recent release of the IDE screwed up the CPLC display. This has been fixed and will be available soon.

[daves]

Thanks for the clarification. This throws up a question. Consider the following:

 

9.036kHz phase, 2.259kHz servo, 2.2kHz rti. A blank project, no motors, no ECT, RTICPLC=0. Task Manager shows P=1.1 S=1.7 R=10, B=13.6 (microsecond values of phase, servo, rti, bg).

 

Start the below code with Count=1000. My timing variables go to

 

RTITimeA=308

RTITimeM=338

 

however the Task Manager shows a tiny increase (in unexpected areas):

 

P=1.2, S=3.0, R=13, B=16

 

Great, task manager shows I'm only using 3% of my RTI. Let's double Count to 2000. Click. RTITime shows 600. PPMAC shows WTDFault BgFault.

 

Why does the contribution of the RTICPLC not get shown in task manager? It seems like it would be good to see how close I am to watchdogging. I assume my 2000 additions are starving the background processes (is this the processing limit?).

 

To me the times don't seem to represent what they say... or there are significant tasks missing.

 

global RTITime;
global RTITimeA;
global RTITimeM;

global Dummy;
global Count;

---

void realtimeinterrupt_plcc()
{
double dStart = GetCPUClock();
int i;

for (i = 0; i < Count; i++)
	Dummy = Dummy + randx(200.0);

RTITime = GetCPUClock() - dStart;
if (RTITime > RTITimeM)
	RTITimeM = RTITime;
if (RTITimeA == 0)
	RTITimeA = RTITime;
else
	RTITimeA = (7*RTITimeA + RTITime)/8;
}

[curtwilson]

Due to the way they are called, the execution time of the C PLC programs, both background and RTI, are not included in the registers that the Task Manager window reads. Your method for assessing execution time looks valid.

 

By the way, about 90% of the execution time for your sample program is in the "randx" function calls. That function is not quick to execute.

[daves]

Thanks for starting to clear up what this is showing.

 

Coming from a position of ignorance I would imagine the rticplc and cplc function is called from somewhere and it would simply be a case of

 

double dStart = GetCPUClock();
realtimeinterrupt_plcc();
INTERNAL_REGISTER.RTIPLCTime = GetCPUClock() - dStart;

 

True?

 

I hope you can agree that the task times are not useful to a developer wanting to know the load on his/her system. I feel sure the intention of this display was to recreate the PEWin CPU load display which DOES include code running in PLCC0 (and userservo in the servo section).

 

The IDE manual describes the tasks scantly and in particular "Real Time Interrupt - Move planning and real time Script and C PLCs".

 

Another misleading implication comes from the colours and names used. These match the March 17, 2014 user guide picture of 'Sample Power PMAC Multi-Tasking Time Line' on p61, where again the "RTI task" is said to contain foreground PLCs, It definitely gives the impression the tasks listed in task manager are the coloured blocks in the picture.

 

Can you tell me exactly what is included in each task and what I need to time myself? For example for the RTI, Sina's post http://forums.deltatau.com/showthread.php?tid=1144 lists 17 items as part of the "RTI task" including rticplc.

 

If I were to write my own task manager summing your reported times with my measured times for the missing activities I assume I would have to add it to Sys.RtIntTime before removing servo/phase interrupting tasks as described in SRM p1018 (I'm not sure I have time/resources to do this).

 

Sorry to bang on about this but I am using the IDE 9hrs a day, 5 days a week to get a large project running and I need a feel for what my system is doing without losing my time to misunderstandings.

[curtwilson]

The C PLCs are the only scheduled tasks not caught by our Script status elements and used by our Task Manager control.

 

You can use your beginning-to-end time measurement for your rticplc, add it to our Sys.RtIntTime, and then process that sum as a modified Sys.RtIntTime as documented to see the time it actually took.

 

There are actually 33 sets of time values for the C PLCs, 1 for the RTI and 32 for the BG, each with Min, Max, and Latest time. We have not "exposed" them to the Script environment yet, but we are evaluating how best to do these.

[daves]

OK I think I can live with my own timing in RTICPLC, CPLCs are not so critical I think.

 

I would ask please that all tasks are included if you guys can get that sorted, thanks.

 

I see if I put my RTI code in a userservo the task manager shows it nicely so I might consider that if I get round to thinking about the ramifications of when it executes in the scheduling (hopefully none).

 

EDIT: this is if I can get my usrcode.c to build (see post http://forums.deltatau.com/showthread.php?tid=1577)

[smr99]

Given that this comment was made in April 2014:

 

 

A bug in the most recent release of the IDE screwed up the CPLC display. This has been fixed and will be available soon.

 

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

[smr99]

Given that this comment was made in April 2014:

 

 

A bug in the most recent release of the IDE screwed up the CPLC display. This has been fixed and will be available soon.

 

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

[smr99]

Given that this comment was made in April 2014:

 

 

A bug in the most recent release of the IDE screwed up the CPLC display. This has been fixed and will be available soon.

 

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

 

OK, so a simple experiment shows that 1.7 / firmware 1.6.1.1 is still affected by this bug. I compute the time taken by our RTI CPLC by subtracting the values of GetCPUClock() at the end and beginning of realtimeinterrupt_plcc() and put it into a P-variable. In the watch window I can see that this value greatly exceeds Sys.RtIntTime.

 

Next question: is this bug fixed in the upcoming 2.0 release?

[smr99]

Given that this comment was made in April 2014:

 

 

A bug in the most recent release of the IDE screwed up the CPLC display. This has been fixed and will be available soon.

 

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

 

OK, so a simple experiment shows that 1.7 / firmware 1.6.1.1 is still affected by this bug. I compute the time taken by our RTI CPLC by subtracting the values of GetCPUClock() at the end and beginning of realtimeinterrupt_plcc() and put it into a P-variable. In the watch window I can see that this value greatly exceeds Sys.RtIntTime.

 

Next question: is this bug fixed in the upcoming 2.0 release?