Should I expect RapidSetup to show user labels? I have seen inconsistent behavior (possibly related to how I’m using it), and I don’t know what to expect.
If I load RapidSetup after I set the user labels, it only shows “MultiAxis ” as the name of the objects.
Within my application (not what’s shown above), I have two MultiAxis objects, and I set user labels on both of them. In RapidSetup, only the first MultiAxis has the label I set. The other one shows up as the default name, “MultiAxis 7.”
I’ve tried refreshing the view, restarting RapidSetup, and nothing I’ve thought to do has changed anything.
Should I expect RapidSetup to show user labels?
In your python code example, do you also set AxisCount? MultiAxisGet(0) will get you the first “motion” object available after all the Axis objects. If AxisCount is 0, your first MultiAxis.NumberGet() will return 0.
It seems like when you open RapidSetup, it may detect some axes so it sets AxisCount. Now your originally created MultiAxis is no longer valid (it was overwritten).
RapidSetup reads the MultiAxis UserLabel when it starts/refreshes. You can test this by setting the UserLabel then reopening RapidSetup.
Sorry. I left out axis stuff. There are 6 axes. I set the motion count to 9 in order to create three MultiAxis objects. I didn’t call AxisCountSet(...), but AxisCountGet() returns 6.
I don’t think RapidSetup is doing any reallocation in my scenario.
Restart Node A
Start RapidSetup
Start Network
Node Count: 13
Axis Count: 6
Multi Axis Count: 0
User Limit Count: 0
Axis License Count: 64
mc.MotionCountSet(9)
mc.MotionCountGet() → 9
(RapidSetup crashes; restart RapidSetup)
Multi-Axis Count: 3
Set user labels for all 6 axes.
for axis_idx in range(mc.AxisCountGet()): mc.AxisGet(axis_idx).UserLabelSet(names[axis_idx])
Refresh RapidSetup
All axes show the user labels I set.
Set user labels for all 3 multi axes
for ma_idx in range(3): mc.MultiAxisGet(ma_idx).UserLabelSet(f'MA_{ma_idx:02d}')
MultiAxis::UserLabelGet() returns the names I just set (“MA-00”, “MA-01”, …).
Ok I was testing with a 10.3.3 pre-release and it works fine. I tested 10.3.2, it works fine.
10.3.1 does not work. So you’re not doing anything wrong, you just need a newer release. I don’t see this bug called out specifically in the changelog, so I’ll investigate what happened.
Thanks, @scott. We’ll upgrade at some point. I was just waiting until there was a feature I wanted in order to justify the expense. This is not a mission-critical feature. It was just sugar for customers.