I see that the MotionScope has a number of preset traces (Axis 0 commanded position, etc.) that correspond to the latest state of the network (as seen in RapidSetup, I presume).
It’s very easy to include these traces in a scope capture/plot.
Is there a way, even a hack-ish one, that my application can augment this list?
There are a number of data points that are pertinent to our application that would be useful to have in the scope, but the only way to get them is to have the application lookup the memory addresses, write them to a text file, and then manually type them into the scope.
How is the scope acquiring this information? It doesn’t have to be your task to provide me a solution. If you can provide answers or details, that would probably be enough.
A hack-ish way would be for you to create all your manual traces, then close MotionScope. It will save those custom traces into MotionScope.ini (so they’re all there if you re-open MotionScope). Take a look at its contents to see how custom traces are stored.
Thanks for the reply, Scott.I noticed that the traces I’d already defined were in there. The down side of this is that I’d have to define a bunch of traces that would then get deleted whenever I wanted to run only a subset of them all.
My hope is that I could somehow augment the list of traces to choose from so that they were available, but not temporally defined as active traces.
It seems like RapidSetup is informing the scope about these predefined traces (since it reflects changes in the network configuration, like the number of axes) when MotionScope is invoked. This would be a preferable style of solution for me, so that I could have my application start the scope with the traces we’d want to be able to choose predefined.
I guess it would answer some questions for me if I knew how RapidSetup/RSI was informing the MotionScope about the available traces. Is it all done in the MPI library (mpivc100.dll) by the RTA, or is it something done on the Windows side?
So, just in case someone really wants to take a go at this type of solution, there’s a limit to the number of traces that the scope will allow.
Of course, if you programmatically create a bunch, it won’t offer such helpful detail. Instead:
Note: I was able to create 31 traces without error. #32 was the straw that broke the camel’s back. If the scope is using (only) recorder #0, I suppose the 64 items-per-recorder limitation is what’s at play.