Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

NC_OP_START and NC_OP_STOP purpose

I don't understand well the purpose of ncAction with NC_OP_START and NC_OP_STOP on a network interface object and I have no PCI-CAN available at the moment to test it.

Is it correct to say that the processor of a stopped board will accept the new frames written to the write queue with ncWrite but will delay the actual transmssion until a NC_OP_START is issued ?

I must send 18 frames over the CAN bus but the thread that calls ncWrite is interrupted by other threads of equal or higher priority and I end up with some unacceptable delay in the flow. May I issue a NC_OP_STOP then fill the write queue and issue a NC_OP_START and expect the frames to be sent without interruption by the board ?
0 Kudos
Message 1 of 5
(3,866 Views)
Hi fmarchal,

the sequence: stopping the interface, filling the write queue and starting the interface will result in the desired behavior. Once the network interface is started, the CAN card will transmit the contents of the write queue. However, there is one catch:
Stopping the network interface disables the CAN controller, thus preventing it from acknowledging any frames on the CAN bus. If you have only one other CAN device on the bus that transmits data, it could get 'confused' about no-one acknowledging its frames (and detect the CAN card as 'missing'). If you have multiple CAN devices on the bus, you're fine.

Good luck,
-B2k
0 Kudos
Message 2 of 5
(3,866 Views)
Thank you B2k,

I finally got access to the CAN board and I could make some tests. I comment your post so that others may know the outcome...

First, the attribute NC_ATTR_NOTIFY_MULT_LEN is lost when the board is stopped (or is it when it is started ?). Not really a problem, though.

Second, and far more annoying, the whole process is much slower when I use the technique described in my previous post. The whole process time jumped from 90s to 140s on average just by adding the two ncAction necessary to stop and start the communication. It's too slow for the production line and therefore, we prefer to have some rejects than slowing down the production.

I wonder why a seemingly trivial operation such as stopping and starting the communication tak
es so much time ! Until now my experience with the NI-CAN driver has shown that it was incredibly slow even for the most basic operation.
0 Kudos
Message 3 of 5
(3,866 Views)
Hi fmarchal,

those numbers don't sound right. Is the difference really 50 seconds? You're right, it shouldn't take that long. On how many objects do you perfrom the stop/start actions?
You posted in another thread that the NI-CAN driver seems to be much slower than it used to be since you installed NI-CAN 2.1.3. The start/stop actions usually happen very fast (a few usecs.), that makes me wonder if this issue is related to the 'slower' NI-CAN driver.

Actually, the 2.2 version of the NI-CAN driver seems to be slightly faster than 2.1.2 (from my experience at least), so just send en email
to NI's technical support staff (support@ni.com) about this issue.

-B2k
0 Kudos
Message 4 of 5
(3,866 Views)
Hello B2k,

The difference is 50s but I should have mentionned that those 50s are lost over 4096 stop/start cycles and each cycle places 18 frames in the write queue between the stop and the start. I open no CAN object and the whole process is performed at the network interface object level. The computer is a P3 at 850MHz.

I believe that a part of the delay may be due to the time it takes to write the frames on the queue. Without the stop/start action, (I guess) the first frame is sent on the bus immediately and the next frames follow as fast as possible. But when the board is stopped it must wait until it is started (i.e. all the 18 frames have been written) to send the first frame.

The driver may be faster with one board, but i
t is definitely slower when using four boards each driven by a separate thread. There is no document I could find to explain the changes between the versions, but I understand NI applied several patches to prevent some crashes in a heavily multi-threaded environment. One possibility could be they prevent concurent threads from running the driver at the same time to avoid reentrancy conflicts. I observe now that the CPU usage is around 60% when it used to stick at 100% with v2.1.2 and the process is a little bit slower (it went from 82s to 90s).
0 Kudos
Message 5 of 5
(3,866 Views)