ani94,
I'll assume the frame rates work, since it's specified in the sensor you are simulating. But there will be bus limits at some point - so there is an upper limit to the number of objects that can be reported (even if not in the spec sheet for that radar).
I assume you set up an XNET database with the frames in it, and imported it into VeriStand from there. Did you bring them in formatted from the database or as raw frames?
This is not a normal way that CAN buses tend to work. Typically a frame is sent either on an event (sporadically) or cyclically. Sending many of the same frame on a single event (such as a radar scan) sadly isn't very consistent with how CAN drivers have worked up to this point (oh the joys of merging technologies!). As a result, the built-in CAN/XNET feature might not do this well. It looks like it will take a separate firing of the software trigger for each frame... and with all that extra latency in the loop you'll never meet timing.
One way to do it is to write a custom device for VeriStand. You may potentially be able to fire software triggers much more quickly on returning an object list. As far as custom devices go, it won't be difficult - but if you've never done it before it is quite an undertaking. There still might be the possibility that the software latency in the triggers is still too slow - but you could probably do some quick tests with just some XNET code (modified from the examples) and a CAN scope.
One other option that might work is to use a frame trigger. There is a trigger line on the front of the XNET card that can be used to trigger an XNET send (with much tighter timing than a software trigger). So when the event occurs, you could generate a pulse train of triggers to get the card to send all of those instances.
The XNET manual is one of the best written by NI. The underlying answers on how to solve this almost certainly lie in there.
http://www.ni.com/pdf/manuals/372840h.pdf
In fact, in thinking of that I may have an answer. Instead of using a single-point frame session (like the ideas above), you could use a buffered write session. It will certainly involve a custom device - but you can buffer up all of the frames (with the different object properties in each) and write them all at once to the CAN port. The card will write as quickly as it can. I think the best answer lies here, but it does involve a custom device. There are many great resources on those (and the NI help is one of the best), as well as people who can develop those for you if you need it.
