Servo_ThinOut and Change Servoo to double

[ProfZiebart]

Hi Mete, Current Status: ESP32 connects to Wifi -CHECK ESP32 fires up OPC-UA - CHECK ESP32 is recognized on Windows via UaExpert - CHECK Visible Objects: Relay0 Relay1 Server Servo0 and Temperature Writing a new value to Servo0 triggers action and Servo moves to new Angle - CHECK Slowly the Servo returns to 0 - dunno why. Connecting to ESP32 via NX1926 OPC-UA - CHECK Connecting an Angle Signal to the Servo0 Signal - FAIL (the internal Angle is Data Type Double, Servo0 is INT !) Connecting ESP32 via NX 12.0 OPC-UA - FAIL "A invalid Input received from a TEXT Routine"

I tried one of the following: For the NX1926 change the Signal &UA_TYPES[UA_TYPES_INT32 to &UA_TYPES[UA_TYPES_DOUBLE? And then maybe convert it via floor(DOUBLE).int (I replaced all UA_TYPES_INT32 with UA_TYPES_DOUBLE in the model.c but then (logically) the servo info does not work anymore as it expects a int. I tried this and could connect NX1926 to the OPC UA Server. In the monitor I could see a lot of "task triggered"

[cmbahadir]

Hello Jan,

I have fixed few points with commit https://github.com/cmbahadir/opcua-esp32/commit/652557f7c3c992041837a22d1f1984e62980df9d on servo branch.

Slowly the Servo returns to 0 - dunno why.

I couldn't figure out the reason, but I suspect from the internal implementation of mcpwm_init of esp-idf, I will try to fine tune the servo behavior.

But let me clarify the expected behavior; Do you want the servo and node value to remain as last angle?

Connecting an Angle Signal to the Servo0 Signal - FAIL (the internal Angle is Data Type Double, Servo0 is INT !)

I have changed the node variable type as double by casting again to int, which is similar to what you did with "floor". So when you send 40.8, angle will be 40. We have lost some resolution there, but I guess it is not a problem for SG-90. 😄

Connecting ESP32 via NX 12.0 OPC-UA - FAIL "A invalid Input received from a TEXT Routine"

I have no idea what this error means, it seems like an internal error message of NX 12.0, we can take a look at it together. Anyway, I have changed the node name of the servo as "Servo_0" which could be the reason. I think It is worth trying again.

After we are done with one servo, lets add more servos with some task scheduling in FreeRTOS.

Cheers, Mete

[ProfZiebart]

Hi Mete,

I found some for i = loop in the Servo.h and think this one is responsible for the failure. I want the Motor to move to a position and stay until a new value is entered.

As soon as I can I will test the new OPC-UA with the double values. If that one works, we needn’t check the NX12 Version.

And yes, then we will have to test more servos. I think the max could be a “Kuka” Robot, which I plan to build. It has a “constant rotation” servo in Axis 1, then 5 following servos with 180° angle.

If we provide one servo more (for what purpose ever) we would have everything we need!

Greets

Jan

Von: cmbahadir @.> Gesendet: Sonntag, 25. April 2021 16:18 An: cmbahadir/opcua-esp32 @.> Cc: Ziebart, Jan Robert @.>; Author @.> Betreff: Re: [cmbahadir/opcua-esp32] Servo_ThinOut and Change Servoo to double (#40)

Hello Jan,

I have fixed few points with commit https://github.com/cmbahadir/opcua-esp32/commit/652557f7c3c992041837a22d1f1984e62980df9d 652557f on servo branch.

Slowly the Servo returns to 0 - dunno why.

I couldn't figure out the reason, but I suspect from the internal implementation of mcpwm_init of esp-idf, I will try to fine tune the servo behavior.

But let me clarify the expected behavior; Do you want the servo and node value to remain as last angle?

Connecting an Angle Signal to the Servo0 Signal - FAIL (the internal Angle is Data Type Double, Servo0 is INT !)

I have changed the node variable type as double by casting again to int, which is similar to what you did with "floor". So when you send 40.8, angle will be 40. We have lost some resolution there, but I guess it is not a problem for SG-90. 😄

Connecting ESP32 via NX 12.0 OPC-UA - FAIL "A invalid Input received from a TEXT Routine"

I have no idea what this error means, it seems like an internal error message of NX 12.0, we can take a look at it together. Anyway, I have changed the node name of the servo as "Servo_0" which could be the reason. I think It is worth trying again.

After we are done with one servo, lets add more servos with some task scheduling in FreeRTOS.

Cheers, Mete

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cmbahadir/opcua-esp32/issues/40#issuecomment-826332165 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3HFYW4ST5N3DPTKYQC3LDTKQQBBANCNFSM43OVR6ZQ . https://github.com/notifications/beacon/AO3HFYTN3US5COCBNNJ5YIDTKQQBBA5CNFSM43OVR6Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGFANIBI.gif

[ProfZiebart]

Hi Mete,

phew I had some hardware issues as you changed the GPIO for the Servo. Then I fried my breadboard power supply but finally something moved. I made a video. The Servo is moving and you can guess that it follows the CAD-Model. But we have one Issue: The Value of the Servo_0 is not kept in the OPC-UA. So the Servo moves to it and then moves slowly backwards toward zero. So I assume it is not the servo pwm of the esp32 it’s that the OPC-UA forgets the Value as soon as it has been set. Then the Servo gets this info

Move to 180 0 179 0 178 0 This cannot be correct. We should go one step further: I found out that the ESP32 is getting instable if we send more than every 0,2secs an info. We could measure the time the Servos need to move. Then we could

Get the OPC-UA Angle infos Check if the Values differ from the ones we stand on now. If yes and the Waitflag for each servo is false we write the values into the Servos and set a Boolean “Wait” to true. We calculate the distance from the current angle For each servo. This Value multiplied by the Servo Velocity would tell us when the Servo has arrived. After this time has passed we set Wait for this servo to false. So we do not write values into the servo all the time but only if we assume it has arrived and only if it SHOULD move. For the Meantime it would be very cool if we could see the current Angle Value in the OPC-UA Field. It shall not be 0 after the next cycle. If I pause the NX MCD I would expect the current values to be seen in UA-Expert. This is not the case, there the Value is ALWAYS 0. But hey, it is moving!

Greets Jan

https://user-images.githubusercontent.com/62288610/116221280-c38c3c00-a74d-11eb-8e28-a5eb74e87f90.mp4

[ProfZiebart]

Whoops. Didnt mean to close this one

[cmbahadir]

Hello Jan,

Ahh, yes I have modified the GPIO as 14, according to my development board pinout to make the connection easier. Sorry for not letting you know about it beforehand. Hope it had not caused a big failure.

Good news and a really helpful video for me to understand how NX MCD interacts with the server.

So now there are two problems:

1. Keeping the last angle of the Servo.
2. Handling the angle values sent one by one from NX, which is also related to point 1. Servo should not return to 0 and the last value should be kept somehow for a smooth operation.

I wil try out your proposal with a flag or with a global variable shared across tasks. (Servo task and OPC UA server task)

I have also noticed some jittering during movement on my side which could be caused by the timing and dynamic frequency scaling.

We can talk about the details over e-mail or a zoom meeting. Here is public so I think it would be better to continue over e-mail 😸

Cheers, Mete

[cmbahadir]

Hello @ProfZiebart

Can you please try the latest commit in Servo branch, I think it should solve two of the problems above.