About CodeShepherd

CodeShepherd · ‎09-18-2021

As soon as you are using cont slope in the ctrlX MOTION it will also not happen there. But for now you are using block slope. So what you see in the values is always the actual running command. That means that the peak at 13s is the change between the first and the second command while blending. Also your still having a quite low resolution in your trace so you cannot see any ramping up or down or even at 13,25s it seems your record is missing a peak.

CodeShepherd · ‎09-16-2021

Following steps need to be done: Build and install your app Add your callable to a task: Switch on trace functionality via the Data Layer: Switch on show system messages, switch on showing traces and filter for the the unit in the diagnostic log window: EDIT: I will talk to our R&D to implement the complete description to the documentation of the SDK.

CodeShepherd · ‎09-10-2021

What exactly do you like to avoid there? The actual acceleration will always change when velocity changes. It only looks like a peak because the time it is not zero is that short. If you like to keep it lower command less or use a lower jerk.

CodeShepherd · ‎09-10-2021

Questions related to EtherCAT ProfiNet OPC-UA other communication protocols

CodeShepherd · ‎09-10-2021

In your screenshots you gave your self the answer I guess: You think you are commanding mm/s² but the motion kernel calculates m/s² so it is a extremely fast acceleration (5000m/s²) and in 80ms, what then must be the cycle time of your task, the ramp up of the values is simply already done from one to the other measuring point. Please have look to my second measurement in my previous post where I changed the units.

Search in community

About CodeShepherd

Re: Robot path acceleration management with PLC Open FB or CXA_Motion Library

Re: SDK-RT Scheduler logs

Re: Robot path acceleration management with PLC Open FB or CXA_Motion Library

What topics are posted here?

Re: Robot path acceleration management with PLC Open FB or CXA_Motion Library