we have Scout v4.2 engineering software installed on a virtual machine Vmware with windows Xp . when we try to go online on the Simotion , it takes several minutes ... what could be the cause . note that the used host laptop is very fast with solid state hard disk and windows 7 64 bits . 

Simotion D4xx v4.1 sp5 , Sinamics v2.5 , Bootloader v2.10 , PN v2.2

6AU1445-0AA00-0CA0 , SIMOTION DRIVE-BASED MULTIAXES BUNDLE D445 CONSISTING OF 1 UNIT EACH PROGRAMMABLE MOTION CONTROLLER D445 (6AU1445-0AA00-0AA0) + CF (6AU1400-2PA01-0AA0 -Z M44) WITH MULTIAXES PACKAGE LICENSE

Why are you specifically blaming VMWare? Are you saying it is different from another similar installation you have that is not using VMWare?

How many seconds does it take to establish the online connection after hitting the yellow connect button? For a large project, it typically does take a minute or more for it to compare all the technology objects and programs with what is on your local computer.

Before connecting, have you de-selected all the devices you do not want to connect to (sinamics integrated and any drives on profibus)? If those drives aren't reachable, the timeouts are typically 30 or 60 seconds, which when combined can also be a very long time. You do get a message about connection failure.

If you've just plugged in the ethernet cable, and then immediately hit the connect button, the time needed for the ethernet adapter on your computer to actually start talking will add up to a minute to the whole process. This is a flaw of the ethernet protocol itself.

Thank you for your detailed reply.

* You are right, we tried another laptop with windows xp, and we have the same issue, so most probably vmware is ok.

* It takes more than ten minutes to establish the online connection, and it is a large project.

The running software on the Simotion is v4.1 while the engineering software on the laptop is v4.2, so will it take more time to compare all the technology objects and programs? because of the version difference?

* We are selecting only the Simotion device for online access.

* Yes, first connection in the morning takes fifteen minutes to complete.

Ten minutes seems too long, as you suspect.

This is kind of complicated to explain, but my question is: how loaded is the Simotion CPU?

When you finally do get connected, right click on D445 (or whatever you renamed it to), and select target device -> Device Diagnostics from the popup menu.

In Device Diagnostics there is a tab where you can view CPU load as a vertical bar graph, but to actually see it you need to click the refresh button or select like 500ms or 1s for update rate. How loaded is the CPU (percentage)?

CPU communication back to the engineering PC has the lowest priority. Eventually the task scheduler gets around to giving communication a tiny bit of time, but it is few and far between on a CPU too busy servicing motion tasks and everything else.

The code in the background task (cyclic PLC-like scan) can do anything except get caught in an endless loop or system instruction that takes to long and triggers the watchdog timer, without affecting PC communication.

But motion tasks can be a large source of trouble.

In your motion tasks, any of the code is spinning in a loop with a "while" or "do...while" or anything else that loops back to the top like a goto? (spinlock code)?

All motion tasks that don't just run from start to end will need to regularly encounter some kind of wait statement (wait for input, wait time, wait for condition, wait for position). In any kind of loop other than a small FOR loop, it's a good idea to use a zero-second wait, example: rv:=_waitTime(T#0s); Wait instructions allow the task scheduler to move onto the next task immediately.

If a motion task isn't waiting for something (always RUNNING), it's practically consuming all available CPU time other than the servomotor and ipo tasks. In Device Diagnostics there is another tab to see the state and runtime of all of the tasks. (It's okay and desirable for a motiontask to be in RUNNING_WAITING state as opposed to just RUNNING).

Yes the task scheduler jumps away from a spinlocked motiontask after two whole timeslices (servo cycles) so it can execute all the other tasks, but it will come right back to the task(s) that are in a spinlock for the rest of any free time. This chews up all the time and makes communication back to the PC or web browser very slow and difficult with lots of unwanted disconnects.

Sort of like your "work expands to the time allotted" quote.