0
$\begingroup$

Rosanswers logo

Hello!

The solution is given in the answer section.

The original question with different edit parts start here:

-------------------------------------------------- ORIGINAL QUESTION --------------------------------------------------

i am trying to communicate with a single motor through CANopen. I had posted the initial problems earlier in the following question: #q294570.

The original problem was that i was unable to spawn the controllers after the canopen driver was initialized. This problem was solved by correcting the EDS file (object [6502] datatype 0x0007).

However there is a new problem.

After successful spawning (i.e., after i call /driver/init) new errors occur. This is the error message:

[ INFO] [1529588044.212953924]: Initializing XXX
[ INFO] [1529588044.213546917]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[ INFO] [1529588044.214010384]: Current state: 2 device error: system:0 internal_error: 0 (OK)
EMCY: 81#0000000000000000
[ WARN] [1529588059.484589143]: RPDO timeout
Loaded joint_state_controller
Loaded joint_1_position_controller
Started ['joint_state_controller'] successfully
Started ['joint_1_position_controller'] successfully
[ERROR] [1529588059.984608960]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: 
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

[controller_spawner-6] process has finished cleanly
log file: /home/akosodry/.ros/log/bc213964-7557-11e8-ac9e-78321b043645/controller_spawner-6*.log
[ERROR] [1529588069.994551018]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: 
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

[ERROR] [1529588079.994594260]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: 
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

The aforementioned error message repeats.

------------------------------------------------------------ EDIT1 ------------------------------------------------------------

As Mathias Lüdtke recommended i edited the launch file, and spawned only the joint_state_controller. Then, there is NO error message.

Then i tried to load the controller, which returned "OK":

rosservice call /controller_manager/load_controller "name: 'joint_1_position_controller'"

If i do rosservice call /controller_manager/list_controllers:

controller: 
  - 
    name: "joint_state_controller"
    state: "running"
    type: "joint_state_controller/JointStateController"
    claimed_resources: 
      - 
        hardware_interface: "hardware_interface::JointStateInterface"
        resources: []
  - 
    name: "joint_1_position_controller"
    state: "stopped"
    type: "position_controllers/JointPositionController"
    claimed_resources: 
      - 
        hardware_interface: "hardware_interface::PositionJointInterface"
        resources: [joint_1]

If i do rostopic list, i see the following topics:

/clicked_point
/diagnostics
/initialpose
/joint_1_position_controller/command
/joint_command
/joint_states
/move_base_simple/goal
/rosout
/rosout_agg
/tf
/tf_static

I tried to publish something to the /joint_1_position_controller/command topic, like:

rostopic pub /joint_1_position_contller/command std_msgs/Float64 "data: 1.0"

But nothing happens (i mean i an ideal world the motor would rotate :) ...also i tried different bigger, smaller numbers).

Then i tried to diffent ways to start the controller: FIRST WAY: If i do the following:

rosservice call /controller_manager/switch_controller "start_controllers:
- 'joint_1_position_controller'
stop_controllers:
- ''
strictness: 2" 
ok: False

i got the following error message:

[ERROR] [1529592920.142827840]: Could not stop controller with name  because no controller with this name 
exists
[ERROR] [1529592942.782467753]: Could not stop controller with name  because no controller with this name 
exists

SECOND WAY:

rosservice call /controller_manager/switch_controller "{start_controllers: ['joint_1_position_controller'], stop_controllers: [], strictness: 2}"
ok: True

and i got the following:

canopen_motor_node: /usr/include/boost/thread/pthread/mutex.hpp:127: void boost::mutex::unlock(): Assertion `res == 0' failed.
[canopen_driver-5] process has died [pid 27211, exit code -6, cmd /home/akosodry/catkin_ws/devel/lib/canopen_motor_node/canopen_motor_node __name:=canopen_driver __log:=/home/akosodry/.ros/log/beb24260-7564-11e8-ac9e-78321b043645/canopen_driver-5.log].
log file: /home/akosodry/.ros/log/beb24260-7564-11e8-ac9e-78321b043645/canopen_driver-5*.log

I am using ubuntu 16.04 lts and ros-kinetic.

------------------------------------------------------------ EDIT2 ------------------------------------------------------------

I started the rqt_console, then loaded the joint_1_position_controller, then i wanted to start the controller with the following command:

rosservice call /controller_manager/switch_controller "{start_controllers: ['joint_1_position_controller'], stop_controllers: [], strictness: 2}"

Then, i get the following error in rqt_console:

Node: /canopen_driver
Time: 11:40:22.597297977 (2018-06-22)
Severity: Error
Published Topics: /diagnostics, /joint_states, /rosout

Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument


Location:
/home/akosodry/catkin_ws/src/ros_canopen/canopen_chain_node/src/ros_chain.cpp:RosChain::run:60

------------------------------------------------------------ EDIT3 ------------------------------------------------------------

Steps i performed:

  1. sudo apt update && sudo apt full-upgrade
  2. build and devel folders were deleted
  3. catkin_make

Then i again tried to load and start the joint_1_position_controller but again i got the same error (Throw location unknown (consider using BOOST_THROW_EXCEPTION)) id got before.

So, as Mathias recommended (and if i understood correctly), i ran the canopen_motor_node with launch-prefix="gdb -ex run --args" in the robot.launch file

These are the messages i got in the terminal:

NODES
  /
    canopen_driver (canopen_motor_node/canopen_motor_node)
    controller_spawner (controller_manager/controller_manager)
    robot_state_publisher (robot_state_publisher/state_publisher)

auto-starting new master
process[master]: started with pid [28794]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 2fbdebb4-761c-11e8-9f42-78321b043645
process[rosout-1]: started with pid [28807]
started core service [/rosout]
process[robot_state_publisher-2]: started with pid [28825]
process[canopen_driver-3]: started with pid [28826]
process[controller_spawner-4]: started with pid [28827]
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/akosodry/catkin_ws/devel/lib/canopen_motor_node/canopen_motor_node...(no debugging symbols found)...done.
Starting program: /home/akosodry/catkin_ws/devel/lib/canopen_motor_node/canopen_motor_node __name:=canopen_driver __log:=/home/akosodry/.ros/log/2fbdebb4-761c-11e8-9f42-78321b043645/canopen_driver-3.log
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[New Thread 0x7fffede5a700 (LWP 28863)]
[New Thread 0x7fffed659700 (LWP 28864)]
[New Thread 0x7fffece58700 (LWP 28865)]
[New Thread 0x7fffe7fff700 (LWP 28870)]
[New Thread 0x7fffe77fe700 (LWP 28871)]
[New Thread 0x7fffe6ffd700 (LWP 28872)]
[New Thread 0x7fffe67fc700 (LWP 28873)]
[New Thread 0x7fffe5ffb700 (LWP 28874)]
[New Thread 0x7fffe57fa700 (LWP 28875)]
[New Thread 0x7fffe4ff9700 (LWP 28876)]
[New Thread 0x7fffc7fff700 (LWP 28877)]
[New Thread 0x7fffbffff700 (LWP 28878)]
[New Thread 0x7fffc77fe700 (LWP 28879)]
[New Thread 0x7fffc6ffd700 (LWP 28880)]
[New Thread 0x7fffc67fc700 (LWP 28881)]
[New Thread 0x7fffc5ffb700 (LWP 28882)]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[New Thread 0x7fffc57fa700 (LWP 28886)]
[New Thread 0x7fffc4ff9700 (LWP 28891)]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[ INFO] [1529672407.945701612]: Using fixed control period: 0.010000000
[ INFO] [1529672422.971112527]: Initializing XXX
[New Thread 0x7fffbf7fe700 (LWP 29062)]
[ INFO] [1529672422.972067179]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[New Thread 0x7fffbeffd700 (LWP 29063)]
[ INFO] [1529672422.972807059]: Current state: 2 device error: system:0 internal_error: 0 (OK)
[New Thread 0x7fffbe7fc700 (LWP 29064)]
EMCY: 81#0000000000000000
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[New Thread 0x7fffbdffb700 (LWP 29093)]
Loaded joint_state_controller
Started ['joint_state_controller'] successfully
[controller_spawner-4] process has finished cleanly
log file: /home/akosodry/.ros/log/2fbdebb4-761c-11e8-9f42-78321b043645/controller_spawner-4*.log
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
Supported drive modes (object 6502) not valid
Supported drive modes (object 6502) not valid
[ERROR] [1529672455.093311261]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

[ERROR] [1529672465.103298004]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

[ERROR] [1529672475.103292764]: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >
std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

------------------------------------------------------------ EDIT4 ------------------------------------------------------------

(History): A candump was made which started after driver/init and stopped after the position controller spawn attempt. Based on the candump Mathias concluded that it looks wrong, the driver does not receive any joint values and even the status words gets sent at a rather strange timing.

Mathias recommended the following things to be addressed:

  • Does the sync rate fit (might be restricted by the controller)? Does it need a certain format (e.g. with overflow)? *

Ans: I did not find anything related to the sync rate in the technical guide not in the user manual . However this issue can be checked by changing the interval_ms value in the can0.yaml. By default it was 10ms, but i can change it to for example 100ms.

With 100ms sync rate i did a new candump: CANDUMP_100ms

Does this look better?

Is the PDO mapping correct?

Ans: In this one im still not 100% sure, and i'd like to ask some feedback regarding this. So, Since Mathias recommended in #q294210 that the Schunk_0_63.dcf in canopen_test_utils can be used as a reference, i basically, copied the PDO mapping values to be exactly the same as in the schunk dcf file (i only changed the parameterValue part). Therefore, here is what i have:

(Receive PDO Mapping Parameters)

`1600sub0`: ParameterValue=2
`1600sub1`: ParameterValue=0x60400010
`1600sub2`: ParameterValue=0x60ff0020


`1601sub0`: ParameterValue=2
`1601sub1`: ParameterValue=0x607a0020
`1601sub2`: ParameterValue=0x60c10120


`1602sub0`: ParameterValue=0

`1603sub0`: DefaultValue=0

(Transmit PDO Mapping Parameters)

`1A00sub0`: ParameterValue=2
`1A00sub1`: ParameterValue=0x60410010
`1A00sub2`: ParameterValue=0x60610008

`1A01sub0`: ParameterValue=0

`1A02sub0`: ParameterValue=2
`1A02sub1`: ParameterValue=0x60640020
`1A02sub2`: ParameterValue=0x606c0020

`1A03sub0`: DefaultValue=0

Mathias, may i ask you to confirm if this is OK? (This is what the Schunk_0_63.dcf/schunk_mapping.py contains in your canopen_test_utils package)

Is it set to transmission type 1? (Sent data after every sync message)

Ans: this was also set up based on the Schunk_0_63.dcf, namely:

(Receive PDO Communication Parameter transmission types)

1400sub2: ParameterValue=0x1
1401sub2: ParameterValue=0x1
1402sub2: DefaultValue=255
1403sub2: DefaultValue=255

(Transmit PDO Communication Parameter transmission types)

1800sub2: ParameterValue=0x1
1801sub2: ParameterValue=0x1
1802sub2: ParameterValue=0x1
1803sub2: ParameterValue=254

Again, Mathias, i'd like to ask if you could confirm these values?

For now you might want to turn off homing: Set homing method to 0 (if possible) or remove the homing mode bit from 0x6502 (in DefaultValue)

The homing method is currently set to 0 through the object 6098:

[6098]
ParameterName=Homing method
ObjectType=0x7
DataType=0x0002
LowLimit=0
HighLimit=35
AccessType=rww
DefaultValue=0
PDOMapping=1
ObjFlags=0x0

What could be the problem again? Something is missing i guess...

This is the package i am running: repo link

Thank you in advance your help.


Originally posted by akosodry on ROS Answers with karma: 121 on 2018-06-21

Post score: 0


Original comments

Comment by Mathias Lüdtke on 2018-06-22:
First of all, the joint_state_controller must work. Do you get sane data in /joint:states? Afterwards you could open rqt_console, start the position controller and see in which file the error was reported.

Comment by akosodry on 2018-06-22:
Thanks for the reply, Mathias! Its not obvious for me, that in the launch file, should i run the joint_state_publisher and rviz, or these can be omitted? If i run the joint_state_publisher and rviz then by changing the rviz slider the link starts to "shake".

Comment by akosodry on 2018-06-22:
If i dont run the joint_state_publisher then the /joint_states topic pos, vel values stays on zero. Of course (i think), since no desired/goal value was given?! How to test if the joint_state_controller works correctly?

Comment by Mathias Lüdtke on 2018-06-22:
joint_state_publisher is not needed in your case. (mostly used for rate limiting and mimic joints) Can you turn your motor manually? You should at least see little changes.

Comment by akosodry on 2018-06-22:
Unfortunatelly i can't turn the motor manually, i think its in a break, its a quite big motor, i am driving it with a 750W motor controller. I updated the question, there is a EDIT2 part, where i posted the output of the rqt_console

Comment by Mathias Lüdtke on 2018-06-22:
Please try spawn the position controller multiple times until the node crashes (like in "SECOND WAY"). GDB will then show an interactive shell. Type "bt" and hit enter to get the backtrace.

Comment by akosodry on 2018-06-22:
OK, so now, the node wont crash :D idk what did change, but im trying multiple times, even restarted the launch file, but it wont crash..

Comment by akosodry on 2018-06-22:
It just gives the error messages: either: Throw location unknown (consider using BOOST_THROW_EXCEPTION) or Controller 'joint_1_position_controller' is already running,

So basically i think the spawning was succesfull.

Comment by akosodry on 2018-06-22:
I have now both joint_state_controller and joint_1_position_controller in running state. In the parallel terminal i am getting continously the error message Throw location unknown. But if i publish to /joint_1_position_contller/command nothing happens

Comment by akosodry on 2018-06-22:
If i stop the controller and start again, i get the following error:

[ERROR] [1529679302.698301311]: joint_1 is not ready to switch mode
[ERROR] [1529679302.698396748]: Could not switch controllers. The hardware interface combination for the requested controllers is unfeasible.

Comment by Mathias Lüdtke on 2018-06-22:
if you prefix it with gdb, some errors might not occur :-/ Can you upload a candump (candump -l can0) e.g. to gist? Start it after init and stop after the position controller spawn attempt. This might help to identify the "unknown throw location".

Comment by akosodry on 2018-06-22:
Dear Mathias! Thank you for the help!

Here is the log file.

Comment by akosodry on 2018-06-23:
Hello Mathias. I just want to inform you, that i did tried to run the package on a new computer, with a fresh installed ubuntu 16.04, with a fresh installed ros-kinetic, and i get the same error messages. So im totally clueless what to try what to change.

Comment by akosodry on 2018-06-23:
Maybe i forgot to mention you what is my setup: Microchip CAN BUS Analyzer (driver: mcba_usb), ASD-A2-0721-M driver, ECMA-C10807RS servo motor.

Comment by akosodry on 2018-06-23:
The motor driver was set up to CANopen mode (0x0C), + Node id to 1, + Baudrate to 500 kBps + Sync (page 7)

Comment by jayess on 2018-06-29:
@akosodry can you put your solution in an answer instead of your question? Then you can accept it as the correct answer. This will make it easier for others to find the solution should they have the same problem.

Comment by akosodry on 2018-06-30:
@jayess yes, i updated everything.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

[ERROR] [1529588059.984608960]: Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: boost::exception_detail::clone_implboost::exception_detail::error_info_injector<boost::lock_error > std::exception::what: boost: mutex lock failed in pthread_mutex_lock: Invalid argument

This really looks suspicious, I have never seen this before. Which OS/architecture are you using?

Please try to spawn only the joint_state_controller. And which part of the code does issue the ROS error? (check with rqt_console).

Update: I must admit that I am running out of ideas.. I would suggest to upgrade ALL ros packages to the latest version to rule out ABI problems. Afterwards you have to clean and rebuild your workspace.

If the node keeps dying, please debug it with GDB and provide the backtrace of the crash.

Update 2: Your candump looks wrong. The driver does not receive any joint values. And even the status words gets sent at a rather strange timing. I think you should first solve the joint state issue before trying to move. Some things to check:

  • Does the sync rate fit (might be restricted by the controller)? Does it need a certain format (e.g. with overflow)?
  • Is the PDO mapping correct? Is it set to transmission type 1? (Sent data after every sync message)
  • For now you might want to turn off homing: Set homing method to 0 (if possible) or remove the homing mode bit from 0x6502 (in DefaultValue).

Originally posted by Mathias Lüdtke with karma: 1596 on 2018-06-21

This answer was NOT ACCEPTED on the original site

Post score: 2


Original comments

Comment by akosodry on 2018-06-21:
Thank you again! I ve just edited/updated the question

Comment by akosodry on 2018-06-22:
If i am not asking too much, can provide the commands for the upgrade ALL ros packages to the latest version? I guess: it should start with sudo apt-get update, then sudo apt-get install ros-kinetic- ? (does * stand for the all packages?)

I know this is a noobie question.

Comment by Mathias Lüdtke on 2018-06-22:
The easiest way might be: sudo apt update && sudo apt full-upgrade This will upgrade ALL packages. If you don't want to do that, you could use synaptic (graphical packages manager) to select only specific packages.

Comment by akosodry on 2018-06-22:
Thank you! I am doing it. I will report back what is the situation after the upgrade. This is quite unfortunate situation... Could not it be the EDS file that makes some problems still? I dont know, maybe another object is wrongly defined, or is missing. No idea.

Comment by akosodry on 2018-06-22:
@Mathias Lüdtke, i updated again the question. There is an EDIT3 part. Thank you for the help. Also i was considering to write to Delta about the canopen mode or EDS file, but i dont really know what specific problems should i address.

Comment by akosodry on 2018-06-27:
Hello @Mathias Lüdtke. Thank you again both for the help and the recommendations. I updated the post, now it contains an EDIT4 part. May i ask you to check it? Iam waiting for the replies. Thank you.

Comment by akosodry on 2018-06-27:
@Mathias Lüdtke: i also uploaded a new candump at 100 ms sync rate, i updated the post, the github link is in EDIT4 part.

Comment by akosodry on 2018-06-29:
I found a solution. Still not 100% clear why the PDO mapping of Schunk did not work.. I updated the post with the solution.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Solution:

*(History:)*Originally I was unable to spawn the controllers after initializing the canopen driver. A lot was discussed here and i was really struggling with my setup, but here are the solutions that made it work finally:

First problem was identified by @Mathias Lüdtke. Namely, the original EDS file had a wrong object description, the right one is DataType=0x0007.

The second problem was again around the EDS file, namely, the correct PDO mapping was the issue. For me its still not 100% clear why the PDO mapping from the working Schunk package did not allow to successfully spawn the position controller and control the motor,

however the following PDO mapping allows both to measure the shaft position (through joint_states topic) and control the shaft position (through the /joint_1_position_contller/command topic):

[1600sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=1
PDOMapping=0
ObjFlags=0x0
ParameterValue=2

[1600sub1]
ParameterName=PDO mapping 1
ObjectType=0x7
DataType=0x0007
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0x60400010
PDOMapping=0
ObjFlags=0x0
ParameterValue=0x60400010

[1600sub2]
ParameterName=PDO mapping 2
ObjectType=0x7
DataType=0x0007
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0
PDOMapping=0
ObjFlags=0x0
ParameterValue=0x607a0020

[1601sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=2
PDOMapping=0
ObjFlags=0x0
ParameterValue=0

[1602sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=2
PDOMapping=0
ObjFlags=0x0
ParameterValue=0

[1603sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0
PDOMapping=0
ObjFlags=0x0

[1A00sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=1
PDOMapping=0
ObjFlags=0x0
ParameterValue=3

[1A00sub1]
ParameterName=PDO mapping 1
ObjectType=0x7
DataType=0x0007
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0x60410010
PDOMapping=0
ObjFlags=0x0
ParameterValue=0x60410010

[1A00sub2]
ParameterName=PDO mapping 2
ObjectType=0x7
DataType=0x0007
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0
PDOMapping=0
ObjFlags=0x0
ParameterValue=0x60610008

[1A00sub3]
ParameterName=PDO mapping 3
ObjectType=0x7
DataType=0x0007
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0
PDOMapping=0
ObjFlags=0x0
ParameterValue=0x60640020

[1A01sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=2
PDOMapping=0
ObjFlags=0x0
ParameterValue=0

[1A02sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=2
PDOMapping=0
ObjFlags=0x0
ParameterValue=0

[1A03sub0]
ParameterName=number of mapped application objects in PDO
ObjectType=0x7
DataType=0x0005
LowLimit=
HighLimit=
AccessType=rw
DefaultValue=0
PDOMapping=0
ObjFlags=0x0

I hope this solution can help others to save some time.

I would also like to thank Mathias for the constant help!


Originally posted by akosodry with karma: 121 on 2018-06-30

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Mathias Lüdtke on 2018-06-30:
Great! Could you provide me the full broken and working EDS, please? There must be a certain case / error that was not handled properly and I'd like to handle this in a better way :)

Comment by akosodry on 2018-06-30:
Hello!

The original EDS from the manufacturer: Original

The edited EDS based on Schunk: edited based on Schunk

Comment by akosodry on 2018-06-30:
The working EDS: Working

Would be good if you can explain what was the problem with the former EDS files :)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.