I’m attempting to use the latest features of RMP to find some PDOs that I will need. In this case, I’m trying to get actual/demand velocity, using Axis::NetworkIndexGet(…).
Question 1
Does RMP automatically attempt to locate the axis features described in RSINetworkIndexType?
I’m currently looking for VELOCITY_ACTUAL_INDEX and VELOCITY_DEMAND_INDEX.
My guess is that it would rely on information in NodeInfo.xml, in particular, the VelocityDemand and VelocityActual elements of a Product.
Would I need to do more to help RMP find the right things than ensuring that NodeInfo.xml defines these elements for a product?
Question 2
What should I expect the return value to be if the lookup fails? I have observed that it’s a 32-bit unsigned integer with the (conspicuous) value of 65535 (0xFFFF), but the documentation doesn’t say what I should expect.
Assuming 0xFFFF is what’s returned on failure, why is this 16-bit value (-1) used? Is that type used because of the hardcoded limit of how many network ins/outs there are (i.e. 32,767)? Why doesn’t the function return a word that’s the same size? Is there some other context in which a 32-bit number makes more sense?
(EDIT: I corrected the decimal representation of 0xFFFF. It should have been 65535. I also corrected incorrect API scope.)
As a part of startup, our EtherCAT Master scans NodeInfo.xml and tries to locate the values encoded to it on the network. If found, we record the input/output index so it can be used information with the Motion Controller. The function was designed as an helper to make finding indexes easier.
The default value is 65535 for all of these unless defined in NodeInfo.xml. Keep in mind this is just an index. We only support 1024 Inputs and 1024 Output PDO entries. Something no customer has hit to date. 65535 is well out of range of what you could expect to fit in a EtherNet packet in the first place. I don’t see this limit harming anyone.
Choosing -1 made sense as valid values are 0 to N. 0xFFFF was used elsewhere as our Out of Range value so was used here as well. It could be set to other values, I’m thinking the decision to keep things mostly uniform was made at the time.
We have quite a few EtherCAT Master values defined as ints or unsigned ints when they contain much smaller data ranges. A case could be made either restrict for precision or leave open for future extension. I’m inclined to leave things as they are unless you want to make a case for some other pattern.
I appreciate the explanation. I was wondering whether I should actually be comparing the result to -1 or an unsigned value that was not -1.
As for NodeInfo.xml, do I need to do anything other than define the intuitively-named subelements of a Product in order to help RMP locate these axis features?
How about we throw an exception when you try to get an index which isn’t supported by the implementation? Then you don’t need to know a magic number which could (if unlikely) change in the future.
I can go either way, so long as it’s clear what I should expect.
Exceptions aren’t completely free in C++, so I could understand why somebody wouldn’t want it. If the API is intended always to succeed, then an exception makes sense. If it’s more of a question, like “Does this axis feature exist?” than an exception might be the wrong response. IDK how your other customers might be using the API. I’m not doing this inside a loop or anything, so the cost of handling exceptions is not significant to me.
It looks as though the NodeInfo.xml that ships with 10.2.3 could have some additional information for Sigma-V. There is no VelocityActual element, even though it’s defined as one of the PDOEntry items for 0x1a00.