cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

Command State of Motion Commands

Command State of Motion Commands

Anonymous
Not applicable

I control the motion app via the datalayer interface for C++. When I call a command, like "move absolut" I need to wait until it is done to continue with a movement, that's why I am using the command-ID and the commando-state to check if the commando is done. I check this by the state ACTIVE. So I wait in a thread as long as the command state is ACITVE, when it is not ACTIVE anymore it is DONE or ABORTED. The thing is that the command state can before be in PREPARED, CREATED or INBUFFER, but this can be solved by also waiting in the thread for these states too. The problem is that when you ask for a random/unused command-ID the state is also INBUFFER. So it can not be detacted, when a wrong command-ID is used and the program/thread is locked forever, because the state will not switch from INBUFFER. 

One way to solve this would be to not buffer any command, so INBUFFER can be a error state. But the C++ interface doesn't offer a parameter to decide whether a command is buffered or not as far as I know. Is there a way to change the default for commands to not put them into the buffer?

Is it okay not to use a timeout for waiting for a command state and trust that a command state will always change to DONE or ABORTED somewhen?

Command state flowchartCommand state flowcharthttps://docs.automation.boschrexroth.com/document/version/1.0/R911403791_01_Motion_App_-1_-en_US/cha...

5 REPLIES 5

CodeShepherd
Community Moderator
Community Moderator

Commandos will always go through "Done" or "Aborted" this logic is fixed. After several other processed commands the state will turn to "Outdated" and stay there forever.

I will check how we can improve the information in the documentation.

Anonymous
Not applicable

Thank you for your answer.

The question that is unanswered is whether there is a possibility to use motion commands unbuffered, like when using the python interface or the bundle?

<cmdID> =  motion.axs_cmd_add_to_kin( axs=<axsName>, kin=<kinName> [,buffered=<buffered>] )

In python there is a parameter for buffer

  //! Create an object. This function is synchronous: It will wait for the answer.
  //! @param[in]  address   Address of the node to create object in
  //! @param[in,out]  data      Data of the object, result of write
  //! @param[in]  token     Security access token for authentication as JWT payload
  //! @result status of function call
  virtual DlResult createSync(const std::string &address, Variant *data, const std::string &token = {}) = 0;

In the C++ interface/via the datalayer there is no option to buffer the command. (The cmdID will be written in data)

 

If this isn't possible, why are all command ID's that are uninitialised in the state INBUFFER and not OUTDATED?

In the bundle example in the SDK 1.10 it looks like this for a command with buffered option is possible:

 

::motion::core::MotionResult(*axsPosCmd )( void *handle, const ::motion::core::dia::CmdSourceInfo& sourceInfo, const char* axsName, ::motion::core::cmd::axs::AxsCmdType cmdType, double targetPos, const ::motion::core::cmd::DynamicLimitsT &dynLim, bool buffered, uint64_t &cmdID );
::motion::core::MotionResult(*kinMoveCmd)(void* handle, const ::motion::core::dia::CmdSourceInfo& sourceInfo, const char* kinName, ::motion::core::cmd::kin::KinCmdType cmdType, double* targetPos, ::motion::core::cmd::kin::CmdTargetCOS targetCOS, const ::motion::core::cmd::DynamicLimitsT& dynLim, bool buffered, uint64_t& cmdID);

 

 

I will check if the states can be inbuffer but are not used at this point. If yes it is an unwanted behavior.

Normally, when you create a command, nomatter with datalayer, python, plc, motion will return you an unique command ID and you can check state of the command with this ID.  ID is the input of the state check function.

However, when you check command state with a random ID value, normally motion will return a "OUTDATED" since motion can not find any command infomation with this ID. If you indeed get other state e.g. "INBUFFER", I would say it is a bug and please create a bug infromation with your test code.

As an extension:

When you check command state with a random ID value, the state is undefined. Customer have to make sure to use a valid ID.

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist