I don’t think I’ll be able to meaningfully distill 25% of my multithreaded application into a chronological list of API calls that I make. It’s just too big and changes slightly every time I run it. I’m not submitting a bug as much as asking for clarification about expectations I should have.
- set error actions
- set origin offsets
- configure interrupts
- make SDO calls
- get/set PDO values
- many, many, many things
- User Limits
- configure, config, enable user limits
- perhaps even one or two will hit/activate
- set data counts, addresses, masks, etc.
- start recorders
potentially stop (some) recorders (depending on circumstances)
The thing that makes what I’m doing complicated is that there is no central agent that knows what the requirements are for the number of user limits or recorders. Any of a dozen different objects of mine determine their own needs, and then submit requests to an agent acting as the interlocutor to the motion controller to set the count, etc. So, generally, the interlocutor asks each of its “clients” how many “thingies” they need, they reply, a total is calculated, and the count is set (API call).
One down side of this strategy is that changing counts invalidates all my RMP objects, so I have to destroy and recreate them. This is OK, but to accomplish this, I basically start over as if I just started the network.
It’s possible that one of my modular objects will decide, based on its individual configuration (not known early on, when the initial count of objects is assessed) that it needs more of these resources than are currently allocated. In this case, the interlocutor will set the count (again), discard all my objects, and start over, as if the network had just been started.
In this circumstance, I’m seeing problems with recorders and user limits because I cannot discard anything about them and start over. The API doesn’t return anything to me that I can “get” again. I just use the indices (a handle to an RMP object, essentially) to use them. I don’t know of a way to “reset” them or have RMP re-create/re-issue them, like I would using
MotionController::AxisGet(...), for example.
I’m not so much asking for software design advice here. I realize that knowing everything up front would make this problem wonderfully simple to fix. In my case, I cannot feasibly know everything up front. I’m trying to use RMP features that seem sensible, but that’s just based on my own reading of the docs.
I want to know what I should expect from RMP in this scenario.
- Is it legal to change allocation counts for a specific resource multiple times?
- It seems like this ought to work.
- What kind of behavior (on my part) is allowable?
- What API calls (or host/firmware settings changes) could I make that could cause the behavior I’m seeing?
- I can’t give you a simple list or MWE. It’s neither simple nor minimal. I need to be able to narrow down my investigation to likely candidates for problem behavior.
- Is there any way to get RMP to “recreate” obsolesced user limits or recorders (similar to what
- In other words, how do I recover from one of the OBJECT_OBSOLESCED errors I might encounter?