Suppose I configure two recorders to gather data every sample. Can I be assured that all the recorders will have the same quantity of records at any given point in time? Supposing that I’m processing “all” the recorder data, will RecorderRecordCountGet() return the same value for each of the recorders in question (assuming they are configured identically except for the addresses used, i.e. RecorderDataAddressSet()).
I’m seeing some unexpected behavior and realized that I don’t know what guarantees I have about recorder performance and synchronicity.
Can you describe a little more what you’re doing with recorders and how? (why multiple versus just using 1, how many addresses per, are they running at the same rate, etc)
We do not guarantee any sort of synchronization between recorders. If 1 recorder has a new record, that does not necessarily mean that recorder 2 has a new record. Are you using RecorderRecordCountGet(int32_t) to check whether each recorder has information?
Would you be able to take a firmware dump using VM3 while your recorders are running? We may be able to check if there’s anything obviously wrong (missing frames due to too much processing time, etc)
You can hit F8 and send the resulting file, meiMem.dmp.
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
My Thingy
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 RecorderRecordCountGet() and RecorderRecordDataRetrieveBulk())?
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.