Motion Scope Limitations
- Limited to 31 traces
- It is tedious to define custom traces (unlike using the predefined ones, like cmd/act pos/vel/accel), because you have to acquire lots of addresses (that will change if anything about the network topology changes).
- using things like user buffers means that you can’t even look the address up in RapidSetup
- It cannot be automated from a script
- start/stop capture
- defining traces
- goofy file format
- traces are autoscaled and laid on top of one another, making it difficult to correlate events (in time) between different traces
I am trying to make something the does what the scope does (minus the visualization), only better (for me).
The scope’s limit of 31 traces is probably due to the fact that it uses only a single recorder and the sample count is included. I want to be able to have many more traces. Thus, I’m using multiple recorders, when the number of traces requires it. For example, if I want 40 traces, I use 2 recorders.
I am configuring them identically (sample period—which I set to 1, etc.), except for the actual memory addresses monitored.
I have a thread that harvests the data from the motion controller every so often (e.g. 10 ms). I had been expecting each recorder to contain the same number of records (not data items; “record” here is a collection of the value at each data address for the given sample count).
My observation is that this assumption is incorrect. I’ll see one recorder with more or fewer records than another in a single “sweep” of all the recorders to collect the data.
This was a simplifying assumption (and the behavior is not documented in that kind of detail) that I wanted to see if you could give me an authoritative answer regarding the behavior I should expect.
- Is it reasonable to think that I can harvest all the data (
RecorderRecordDataRetrieveBulk(...)) for all my recorders before more data is added to them?
- I mean, if I start with #10 and get 10ms worth of data for each one, will #15 have more records than I got for #10? This seems plausible, but I don’t have a good idea about performance.
- How much thread synchronization occurs under the covers for
- Assuming that the quantity of available records is not guaranteed to be symmetric:
- Can I guarantee that sooner or later, I will get a record for every sample count on each recorder, even if I don’t harvest them all at the same time?
- I can cope with asymmetric record counts (I’ll just have to change how I consume and then export them), so long as I am guaranteed that records for the same sample count that came in for some recorders will come in (first) for the other recorders the next time I harvest data.