virtual axis variable cycle time

I am not familiar with simotion, but I have a question:

Are you sure there isn't some minor inaccuracy in the chart or the software that creates it?

The communication link can easily cause the 2% jitter too. Windows ethernet is very bad and is normally a lower priority that updating the screen.

We buffer the motion information on our controller so that the monitoring software can read information at its own pace and still not miss anything.

Can you post the Simotion project with the virtual master and associated control.

Kataeb said:

We monitored the output on an external digital scope. Same result.

Click to expand...

What output? A virtual axis doesn't have an output. If you are talking about one of the digital outputs then you need to find out if the digital outputs are updated in a back ground task or idle loop.

Siemens people say it might be related to the firmware of the simotion. But it is a new module bought last year.

Click to expand...

The d445 was replaced by the d445-1. It makes one wonder why.

It is just amazing how a virtual axis (which is a mathematical function) can behave like this. I hope someone on the forum has seen this before…

Click to expand...

I would make sure the output you are measuring the period with is updated hard real time and not updated in a back ground task. The virtual axis could be running exactly as it should and the output is the cause of the delay

We avoid these problems by updating everything synchronously so these asynchronous jitter problems do not occur.

siemens people suggested that we update the engineering software with Hotfix 6 for SIMOTION SCOUT v4.1 sp5 , and the runtime software with firmware v4.1.5.6 . we downloaded the firmware, but where can we find the hotfix ?
note that we monitored the output of the virtual master on the trace function available with the engineering software, so it should be somewhat more accurate…
thanks

Peter, you were right: “The virtual axis is running exactly as it should and the output is the cause of the delay”.
We have found that the simotion “master application cycle time” (5 ms) is the main reason behind the shifting of the period of the cam output. The virtual axis signal is connected to an output cam which controls a fast digital output. When we run the machine at specific speeds (with period in milliseconds proportional to the cycle time 5 ms) the cam signal is exact and periodic.
We tested the program on a d445-1 and reached the same conclusion as above.
Now the problem is what to do when we run at speeds with period not proportional to 5 ms?

It looks like you have no choice but to run at cycles that are multiples of 5 milliseconds and even then there is no guarantee that the master cycle will be in phase so the signal could always be behind by the same amount even if the cycle time is a multiple of 5 millisecionds.

How critical is it that the cycle time be a constant interval? Is is critical the the output be 'in phase' so there is little delay between the cycle ending and the output being turned on? You haven't said what the controller does.

This problem is a good example of why we update EVERYTHING synchronously. If the updates are every 500 microseconds then everything is updated every 500 micro seconds. Even so there are still limitations. If a motion profile ends before the next 500 microsecond period then everything still waits for the next 500 micro second period to start. At least everything is deterministic from cycle to cycle.

Kataeb,

Are you running your tasks in the Execution System under the MotionTasks? We have found those to be unreliable and hence now run all our motion tasks under the IPOsynchronous task.

You can also use the Simotion task tracer under the task manager in the Simotion Device Diagnostics. It will tell you how much time each of the tasks are using.