- Class cDSA
- cDSAException: Checksum Error on Windows console While communicating with the tactile sensor controller a "cDSAException: Checksum Error" might be thrown once in a while. This seems to happen only when the program is started from a native windows command console (cmd.exe), but not e.g. when the program is started from a cygwin console. Strange. Workaround is to catch the exception and ignore the frame.
=> Resolved in SDHLibrary-C++ v0.0.2.1
Problem was an overrun of the windows input buffer, e.g. on heavy processor load.
- Member cDSA::GetMatrixSensitivity (int matrix_no)
- With DSACON32m firmware R218 and before this did not work, instead the factory default (0.5) was always reported
=> Resolved in DSACON32m firmware R268
- Member cDSA::SetFramerate (UInt16 framerate, bool do_RLE=true, bool do_data_acquisition=true)
SCHUNK-internal bugzilla ID: Bug 680
With DSACON32m firmware R276 and after and SDHLibrary-C++ v0.0.1.15 and before stopping of the sending did not work.
=> Resolved in SDHLibrary-C++ v0.0.1.16
SCHUNK-internal bugzilla ID: Bug 680
With DSACON32m firmware before R276 and SDHLibrary-C++ v0.0.1.16 and before acquiring of single frames did not work
=> Resolved in SDHLibrary-C++ v0.0.1.17
SCHUNK-internal bugzilla ID: Bug 703
With DSACON32m firmware R288 and before and SDHLibrary-C++ v0.0.2.1 and before tactile sensor frames could not be read reliably in single frame mode.
=> Resolved in DSACON32m firmware 2.9.0.0
=> Resolved in SDHLibrary-C++ v0.0.2.1 with workaround for older DSACON32m firmwares
- Member cRS232::Open (void)
- The binary communication introduced in firmware 0.0.2.15 and SDHLibrary-C++ 0.0.2.0 did not work properly on Linux when RS232 was used for communication.
See also:
- Member cSDH::EmergencyStop (void)
- For now this will NOT work while a GripHand() command is executing, even if that was initiated non-sequentially!
- Member cSDH::GripHand (eGraspId grip, double close, double velocity, bool sequ=true)
With SDH firmware > 0.0.2.6 and SDHLibrary < 0.0.1.12 GripHand() does not work (Bug 575)
=> Resolved in SDHLibrary 0.0.1.12
With SDH firmware < 0.0.2.6 GripHand() does not work and might yield undefined behaviour there
=> Resolved in SDH firmware 0.0.2.6
Currently the performing of a skill or grip with GripHand() can NOT be interrupted!!! Even if the command is sent with sequ=false it cannot be stoped or emergency stopped.
With SDH firmware < 0.0.2.6 GripHand() does not work and might yield undefined behaviour there
=> Resolved in SDH firmware 0.0.2.6
Currently the performing of a skill or grip with GripHand() can NOT be interrupted!!! Even if the command is sent with sequ=false it cannot be stoped or emergency stopped.
- Member cSDH::MoveAxis (std::vector< int >const &axes, bool sequ=true)
- With SDH firmware < 0.0.2.7 calling MoveAxis() while some axes are moving in eCT_POSE controller type will make the joints jerk. This is resolved in SDH firmware 0.0.2.7 for the eCT_POSE controller type with velocity profile eVP_RAMP. For the eCT_POSE controller type with velocity profile eVP_SIN_SQUARE changing target points/ velocities while moving will still make the axes jerk.
=> Partly resolved in SDH firmware 0.0.2.7
- Member cSDH::MoveFinger (std::vector< int >const &fingers, bool sequ=true)
- With SDH firmware < 0.0.2.7 calling MoveFinger() while some axes are moving in eCT_POSE controller type will make the joints jerk. This is resolved in SDH firmware 0.0.2.7 for the eCT_POSE controller type with velocity profile eVP_RAMP. For the eCT_POSE controller type with velocity profile eVP_SIN_SQUARE changing target points/ velocities while moving will still make the axes jerk.
=> Partly resolved in SDH firmware 0.0.2.7
- Member cSDH::MoveHand (bool sequ=true)
- With SDH firmware < 0.0.2.7 calling MoveHand() while some axes are moving in eCT_POSE controller type will make the joints jerk. This is resolved in SDH firmware 0.0.2.7 for the eCT_POSE controller type with velocity profile eVP_RAMP. For the eCT_POSE controller type with velocity profile eVP_SIN_SQUARE changing target points/ velocities while moving will still make the axes jerk.
=> Parltly resolved in SDH firmware 0.0.2.7
- Member cSDH::SetAxisValueVector (std::vector< int > const &axes, std::vector< double > const &values, pSetFunction ll_set, pGetFunction ll_get, cUnitConverter const *uc, std::vector< double > const &min_values, std::vector< double > const &max_values, char const *name)
Setting a single axis velocity only sets the velocities of all other axes to 0! So in order to address only some axes you must provide the desired velocity for all axes that you want to move in every call:
With SDH firmware 0.0.2.16 and SDHLibrary-CPP 0.0.2.3 and binary communication (see also SDH_USE_BINARY_COMMUNICATION) setting of single (more precisely: less-than-all) axis parameters (position, velocity, acceleration) does not work as expected: If a single parameter is to be set for a single axis then that parameter is set to 0 for all other axes.
Workaround: If you want to access several different axes one after another then you have to keep a vector of the parameter for all your used axes in your application. You can then update single values of the vector on demand, but you have to send the complete vector to the SDHlibrary functions on every call.
With SDH firmware 0.0.2.16 and SDHLibrary-CPP 0.0.2.3 and binary communication (see also SDH_USE_BINARY_COMMUNICATION) setting of single (more precisely: less-than-all) axis parameters (position, velocity, acceleration) does not work as expected: If a single parameter is to be set for a single axis then that parameter is set to 0 for all other axes.
Workaround: If you want to access several different axes one after another then you have to keep a vector of the parameter for all your used axes in your application. You can then update single values of the vector on demand, but you have to send the complete vector to the SDHlibrary functions on every call.
- Member cSDH::Stop (void)
For now this will NOT work while a GripHand() command is executing, even if that was initiated non-sequentially!
With SDH firmware < 0.0.2.7 this made the axis jerk in eCT_POSE controller type. This is resolved in SDH firmware 0.0.2.7 for the eCT_POSE controller type with velocity profile eVP_RAMP. For the eCT_POSE controller type with velocity profile eVP_SIN_SQUARE changing target points/ velocities while moving will still make the axes jerk.
=> Partly resolved in SDH firmware 0.0.2.7
With SDH firmware < 0.0.2.7 this made the axis jerk in eCT_POSE controller type. This is resolved in SDH firmware 0.0.2.7 for the eCT_POSE controller type with velocity profile eVP_RAMP. For the eCT_POSE controller type with velocity profile eVP_SIN_SQUARE changing target points/ velocities while moving will still make the axes jerk.
=> Partly resolved in SDH firmware 0.0.2.7
- Member cSDH::UpdateSettingsFromSDH ()
- For SDHLibrary prior to 0.0.2.9 the settings read from the SDH were not used correctly when a non default unit system (degrees) was used
=> Resolved in SDHLibrary 0.0.2.9
- Member cSDH::WaitAxis (std::vector< int > const &axes, double timeout=-1.0)
Due to a bug in SDH firmwares prior to 0.0.2.6 the WaitAxis() command was somewhat unreliable there. When called immediately after a movement command like MoveHand(), then the WaitAxis() command returned immediately without waiting for the end of the movement. With SDH firmwares 0.0.2.6 and newer this is no longer problematic and WaitAxis() works as expected.
=> Resolved in SDH firmware 0.0.2.6
With SDH firmware 0.0.2.6 WaitAxis() did not work if one of the new velocity based controllers (eCT_VELOCITY, eCT_VELOCITY_ACCELERATION) was used. With SDH firmwares 0.0.2.7 and newer this now works. Here the WaitAxis() waits until the selected axes come to velocity 0.0
=> Resolved in SDH firmware 0.0.2.7
With SDH firmware 0.0.2.6 WaitAxis() did not work if one of the new velocity based controllers (eCT_VELOCITY, eCT_VELOCITY_ACCELERATION) was used. With SDH firmwares 0.0.2.7 and newer this now works. Here the WaitAxis() waits until the selected axes come to velocity 0.0
=> Resolved in SDH firmware 0.0.2.7
- Member cSDHSerial::kv (int axis=All, double *kv=NULL)
- With SDH firmware 0.0.2.9 kv() might not respond kv value correctly in case it was changed before. With SDH firmwares 0.0.2.10 and newer this now works.
=> Resolved in SDH firmware 0.0.2.10
- Member cSDHSerial::Open (cSerialBase *_com)
- SCHUNK-internal bugzilla ID: Bug 1517
With SDH firmware 0.0.3.x the first connection to a newly powered up SDH can yield an error especially when connecting via TCP.
=> Resolved in SDHLibrary-C++ 0.0.2.10
- Member cSDHSerial::pid (int axis, double *p=NULL, double *i=NULL, double *d=NULL)
- With SDH firmware 0.0.2.9 pid() might not respond pid values correctly in case these were changed before. With SDH firmwares 0.0.2.10 and newer this now works.
=> Resolved in SDH firmware 0.0.2.10
- Member cSDHSerial::tvav (int axis=All, double *velocity=NULL)
- With SDH firmware < 0.0.1.0 axis 0 can go no faster than 14 deg/s
=> Resolved in SDH firmware 0.0.1.0
- Member cSDHSerial::v (int axis=All, double *velocity=NULL)
- With SDH firmware < 0.0.1.0 axis 0 can go no faster than 14 deg/s
=> Resolved in SDH firmware 0.0.1.0
- File demo-GetFingerXYZ.cpp
- When compiled with MS Visual Studio then using the "-R" command line parameter will make the demonstration program demo-GetFingerXYZ abort.
- Member SDHUSAGE_DEFAULT
- When compiled with VCC then the macros WITH_ESD_CAN / WITH_PEAK_CAN used above are not available since these are defined in the VCC project settings of the SDHLibrary VCC-Project. Therefore the value of SDHUSAGE_DEFAULT is incorrect and thus the cSDHOptions will display an incomplete usage string when called with -h/–help.
Workaround: use the online help contained in the doxygen documentation: Online help of demonstration programs