Why would Axis::StopTimeSet(...) complain about "moving" when it is in an error state?

[RMP 8.3.1]

(I’m attempting to recover from the network going away…)

I’ve discarded all my objects once, and I’m trying to re-acquire and use them. When I try to configure an axis, shortly after calling AxisGet(...), I’m seeing errors like this:

Motion: cannot map axis while moving :: {motion.c, line 5866} (Error 3867) (RSI::RapidCode::Impl::RapidCodeMotion::StopTimeSet) (Object 0) (File …..\source\rapidcodemotion.cpp) (Line 1166) (Version 8.3.1 for 04.04.02.RMP)

The axis state (RapidCodeMotion::StateGet()) after I catch the exception is ERROR. (I didn’t check for errors prior to calling RapidCodeMotion::StopTimeSet(...))

I’m fairly confident that the motor isn’t “moving” in any sense. I called RapidCodeMotion::Abort() a few milliseconds earlier, and haven’t attempted to start streaming motion yet. I refreshed the motion controller before attempting to AxisGet(...).

Can you help me interpret this error message? What might I be doing wrong?

Hi Todd,

After getting the new objects did your version of CheckErrors return a count of zero?
If you call Abort on the axis first does things?

Internally, it is checking to see if the axis is Idle. If it isn’t, it throws that error message.

When should I look at the error count vs expect exceptions from API calls?

Hi Todd,

After creating objects, you should check the error count/logs. If you have turned throw exceptions off for an object, you should manually check errors if you run into any trouble.

I haven’t explicitly done anything regarding exceptions. Is the default to throw them?

What state information can I get from an Axis object that will help diagnose the problem?
ErrorLogGet()? Is there likely to be anything in there if the object is configured to throw exceptions?

What else will tell me (or you) anything?

We turn off ThrowExceptions for Object initialization, but turn them back on afterwards. We also give users the option to decide how they get them via that function and associated ErrorLog calls.

The default is to throw Exceptions. Template and Sample Code are supposed to push you towards checking errors after creating objects. All too often I see this skipped though.

The CheckErrors Helper function is the recommended standard for checking. and reporting. I suspect every app has their own logging and display preference though.

Are you getting an error count of 0 on that axis before StopTimeSet call?
Did an abort resolve the behavior or is the axis unresponsive to other calls?