D510MO

Checked it today: The X server seems to be stable after I disabled hyperthreading. This problem is obviously solved.

What I didn't solve was the realtime delay. I just found out that it only appears once when I start the first ngc-file after starting axis. After that the program runs without errors and also following ngc-files will be started without an error.

When starting the first file I'll always be prompted for tool change. I never paid any attention to it but it seems that the realtime delay only appears in cases when I was prompted for tool change. I make my g-code with Aspire and got used to split the jobs in files for each tool because Aspire gives me an error "The visible toolpaths use different tools and the selected Post Processor does not support toolchanging" when I try to save toolpaths with different tools into a single file.

I know that this isn't the right place for asking questions about Aspire but since the realtime delay only appears with the "new" D510MO after I was prompted for tool change, I would like to attach my postprocessor as well.

andypugh wrote:

Unfortunately that doesn't mean that there are no more over-runs, as the error message is only printed once per session.

Does this apply to any realtime delay message? I remember other realtime delay messages in Axis that clearly said that they only appear once per session but this one did not.

r0sewhite wrote:

andypugh wrote:

Unfortunately that doesn't mean that there are no more over-runs, as the error message is only printed once per session.

Does this apply to any realtime delay message? I remember other realtime delay messages in Axis that clearly said that they only appear once per session but this one did not.

Yes it does.

andypugh wrote:

My D510 is bulletproof unless I have the webcam plugged in. I wonder if it is your game controller?

Have you tried removing the gamepad? That would have been my next guess too, USB devices sometimes cause peculiar realtime errors.
It was attached during the session you attached the dmesg for.

Regards the dmesg you attached, no error occurred that was logged, during that session.

You can easilly discount toolchange from the equation by simply loading a file that does not contain one.

One of the most obvious places to start looking is HDD access.
If your files are generated by a CAM program I would suspect they are quite large. Did you try large file opens, general HDD accesses during the original latency testing?

This kind of error has come up before coinciding with HDD activity and sometimes is down to incorrect jumpering, HDD not on channel 0 or effectively a slave to CDROM on IDE systems, and sometimes just changing the SATA port for SATA systems can help.

That it does not happen on the next file load, could simply be down to the HDD cache having pre-fetched all the files in that directory when the original file fetch was requested, making all subsequent ones directly from cache.

Go at it in a methodical fashion.
Use the halmeter that Andy described to see if it recurs or is just on first file load.
Remove the gamepad and re-test
Load a file without toolchange
Try moving SATA ports and re-test

regards

Did some more tests today with loaded halmeter. The biggest number of overruns appear at the first rows of the code. I guess it's the row that runs the machine to x0 y0 z0 and starts the spindle (row 73 in the pp file) but it's hard to tell since the rows pass through very quickly.

After that the number increases very slowly in steps of 1-5 overruns every 2-5 minutes. The funny thing is that increasing the base thread period doesn't seem to change much. There is almost no noticeable difference between 24000 and 50000. I even experienced a initial number of more than 500 overruns with a base period of 45000 and only a initial number of 12 overruns with a base period of 25000.

What I did so far is:
- swapping the SATA ports: didn't change a thing
- loading the same file (size: 120kb) one time from USB stick and one time from HDD: no difference
- disconncting the game controller and disabling all controller functions in my postgui.hal: no difference
- running another latency test and abusing the computer: Worst latency time was 6700

I got one step further today: Increasing the base period didn't help at all but increasing the servo period does. After I set its value from 100000 to 200000, I got rid of the realtime delay. Shouldn't I get better values with this board?

Are those numbers accurate?
100000 ns is 100 usec or a 10 KHz servo thread

This is very unlikely to work
are you sure you have not misplaced a '0'?

default servo thread period is 1000000 ns or 1 ms = 1 KHz rate

Yep, the numbers are correct. So it's the thing between my ears which is faulty and not the computer?

Well a 10 KHz servo thread may work on a high end CPU
but an Atom cannot possible manage this, I would set the servo thread back to
1 KHz unless you have a reason for running it any faster

(I have a Intel Mini ITX H41 /Core Duo that will just do a 6KHz servo thread reliably)