i need your help.
1. we are building a real-time system with NI veristand, 8880, and 8510.
2. now i have trouble in simulating Continent Radar, whose CAN signal has the following features
1). the radar sends 4 kinds of frame to BUS, 0x60A, 0x60B, 0x60C and 0x 60D
2). assumed the radar has detected 100 objects, the radar will send 0x60A 1 time first, and then 0x60B 100 times, each time includes one object's infomation. so are 0x60C and 0x 60D send out the same way.
3). all the above frames must be send within 70ms.
3. based on above, i must trigger the CAN very quickly. but i can only achieve the target rate 1000 Hz. if higher rate, the veristand will overrun. strangely, the CPU load seems rather low.
Not sure about continent radar, but here are some links related to radar:
thanks for your answer.
maybe i expressed not very well. it's in fact the problem of generating CAN frames.
i want the CAN board send CAN frames very quickly, almost 240 ~ 260μs per frame.
what should be paid attention is the frames are not sent periodically. they are sent one by one consecutively.
So here are some discussions regarding the maximum frame rate for CAN:
What is your baud rate, and how large are the frames?
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.
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.
thanks for your detailed explanation, i'm trying according your suggestion. and will feedback if i have some results.