About CodeWasi

Hello Yacine, quite difficult to answer. By the way -there is a PNDeviceApp version 1.20.6 available to update. But 1.20.5 fullfills as well the PN requirements - checked and certified. The descripted behaviour must not be rootcaused by the ctrlX. Think of the traffic loads on the network and the unpriored setup most likely beeing present on the Controller. PN-Fielbus comm. as well as Non-PNbus traffic by engineering tools are transported on the line/s. It the load is close its capacity limit the next one will the judge for its traffic-amount. I am not that familiar with the PN-controller and PNSwitch setup, but assume that no Priorication for Fieldbus-com takes place. And the bandwidth is completed occupied. Before talking about network.analysis... what about the appearing situation... Is there e.g. an coincidence of network-breakdown and a startinga engineering-session with the ctrlX or other Devices? ... or browser based communication with our or other webUIs? The comm. capacity of the ctrlX-PND is around 100MBit - fieldbus and tcpip rest of engineering etc. Would it be possible to choose testwise other an alternative connections for the Non-PN related parts (Eth0/XF10?). These loads would be neglected on the PN-part? Bye ... View more

Update after further testing: In the case of Encoder Axis, if we use the built-in filter of the Measuring Encoder, not only is the signal smoothed out before it gets to the Encoder Axis, but also the Extrapolation in ctrlX is working much better since there is minimal noise to amplify. With the Extrapolation box checked for the Encoder Axis and the slave geared to it with SYNC_ACTUAL_EXTRAPOLATED I see that the lag that was present with SYNC_ACTUAL is corrected for. I have 0 for Extrapolation Time, so I guess the correct default extrapolation time/cycles is automatically calculated. The built-in filter of the Measuring Encoder has its own compensation for the filter delay, so there is no velocity-dependent phase shift induced by the filter. The filter can induce lag and overshoot during accel/decel, so it works best with low acc/dec and jerk limiting of the master encoder (which in real application we don’t necessarily have control over ). Red (Encoder Axis) and Blue (real axis who is following) stay in phase:   ... View more

So here is the solution how we solved the issue. We needed to change the Profinet App from running on core 2, to core 3 That was changed in scheduler ( see Picture below)   With that, all errors had been solved and system is running like desired. There is no additional licence required to move it to Core 3   Thanks for all the support. ... View more