About Robert_

Robert_ · ‎02-23-2023

I get an error when I try to home an axis through the REST API, and my axis also goes to the error state. I try to home the axis by sending a POST request to the homing command. I use the following request: url: https://192.168.0.61/automation/api/v1/motion/axs/Axis_4/cmd/homing body: {"buffered": false, "newRefPos": 10.0} The response tells me there is an error: {"type": "about:blank","title": "General axis command error","status": 500,"detail": "original error: DL_CREATION_FAILED","instance": "motion/axs/Axis_4/cmd/homing","mainDiagnosisCode": "090F2002","detailedDiagnosisCode": "0C570101","dynamicDescription": "cmd: One problem is that the response is truncated to 256 chars which results into a JSON parse error in Python. The second problem is that I get an error combination which is not documented (090F2002 0C570101). I am following the homing schema (types/motion/axs/cmd/homing). Why do I get this error? Additional background information: I am able to home my axis through the PLC application, using the axisinterface. I use the same newRefPos := 10.0, and the _opMode := ModeAxsHoming.

Robert_ · ‎01-16-2023

The problem at the customer got resolved (It has been an issue more than a year ago). But not because of the support through the forum. In my opinion the forum should be a place where ctrlX users can share their challenges and find solutions on (known) problems. This post is about an error that is being generated by the Webclient function block, where the documentation does not provide any information on possible causes. At this moment the post does not provide any valuable information for somebody who runs into the same issue in the future. If you want to add value to the forum, I would not discard questions without providing any information on the specific problem. My recommendation is to check with the product owner for possible causes/remedies for this specific error, and add this information to this post.

Robert_ · ‎06-08-2022

I have seen the same error when trying to run a SoftMotion PLC application on the virtual core (version 1.14).

Robert_ · ‎12-16-2021

I have a customer using the WebClient FB from the CodeSys IIoT library. In general this works well. The issue we have now is that we get a RESULT_PARSE_ERROR with a certain transaction. We do not know why we get this error and the CodeSys help provides no further information on this error. This is from the help: RESULT_PARSE_ERROR 7 Error while parsing the response What can be the problem my customer is having? How can we troubleshoot this error?

Robert_ · ‎06-10-2021

I performed some additional tests with the EAL library. As a correction of the reporting of Nate, I do use a GB switch between the PC and the drive. And I use the .NET library (just like our customer). I adapted the code for an absolute move to also measure the duration of the motion command: And I made a Move absolute that polls S-0-0342 (Is the same as S-0-0437 bit 0, but this one does not require any bit-masking to check a single bit). The this.TargetPositionAttained is a property of my axis class, it actually reads parameter S-0-0342 and returns a true value when this parameter is equal to 1. The results are: Movements without jerk will result into the MoveAbsolute duration of around 57ms When I poll the target position attained parameter, the time I am polling is very close to the actual motion time (around 1ms higher > It seems that the MoveAbsolute method returns when the axis motion has started > The total overhead on a move is mainly the duration of the MoveAbsolute (98%) -> The preparation of the move… When I use the Movement.Wait mechanism to synchronize, the Wait duration is around 25ms longer as the actual motion time > The total overhead is now increased Movements with jerk will result into a MoveAbsolute duration of around 60ms When I poll the target position attained parameter, the time I am polling is now around 28ms longer as the motion time > When I look into the scope data, I can see the axis profile going into a constant velocity of zero for 28ms before accelerating > The MoveAbsolute method still returns when the axis motion has started (with velocity zero though) > Again, the polling does not add much overhead (1ms) When I use the Movement.Wait mechanism to synchronize, the Wait duration is around 50ms longer as when polling > The overhead is now increased to around 140ms So if there is a way in reducing the overhead, it has to come from: Optimizing the MoveAbsolute -> average time is around 60 ms Optimizing the Movement.Wait -> average time depends on type of move, but at least 25ms (Polling can reduce this to 1ms!) Optimizing the jerk profile generation -> This may be move profile dependent -> 28 ms for the short move I used for testing (dx=2mm, v=100mm/s, a=1000mm/s^2, j=10000mm/s^3)

About Robert_

Error when homing axis through REST API

Re: RESULT_PARSE_ERROR with WebClient (CodeSys IIoT library)

Re: Error while test MQTT client SL library example

RESULT_PARSE_ERROR with WebClient (CodeSys IIoT library)

Re: EAL Motion Delay Times