Hi Siddu,
There are two restrictions that apply to cases like this that can make
it pretty ‘tricky’ if the transmission needs to happen on the same CAN
port:
1. You can’t configure two CAN Objects with the same arbitration ID for the same port (doesn’t matter for your use case).
2. When you configure the Network Interface to ‘Transmit a CAN Frame on
RTSI Input’, (any) frames will only be transmit when there is a RTSI
pulse.
That obviously leaves CAN Objects for the transmission. For the
receiving side however, there are only very (very) few cases where it
is useful to use CAN Objects instead of the Network Interface.
However, I’m not 100% sure, if I understand your need to (hardware)
trigger the second frame. Assuming that you don’t generate any other
CAN traffic, when you write both frames with ncWriteNet.vi (or
ncWriteObj.vi) into the output buffer of the CAN card, the card will
transmit the second frame as soon as it successfully transmitted the
first frame. Thus, why the need for the RTSI trigger pulse?
BTW: The ncWrite VIs complete when LabVIEW passed the data to write to
the CAN card – NOT when the card successfully transmitted the frames.
If you call ncClose right after calling ncWrite, the ncClose might stop
the CAN card before the remaining frame(s) are written to the bus.
Therefore, it’s always a good idea to use ncWaitForState
(Write_Success, 0x2) before closing handles. This could be the reason
why your VI only works when ‘highlight execution’ is turned on (as
there is enough time between the ncWrite and the ncClose calls).
Your VI (NI CAN Loopback Test RTSI.vi) also generates an error, but as
the error cluster is not wired through, one doesn't see it right away:
1. ncConfig ("CAN1", 8, {0x80000006,0x80000007,...}, {0x00000001,0x0007A120,...})
Status: 0 (VI_SUCCESS)
2. ncConfig ("CAN0", 8, {0x80000006,0x80000007,...}, {0x00000001,0x0007A120,...})
Status: 0 (VI_SUCCESS)
3. ncConfig ("CAN0::STD5", 12, {0x8000000F,0x80000013,...}, {0x000003E8,0x00000000,...})
Status: 0 (VI_SUCCESS)
4. ncOpenObject ("CAN0::STD5", 41419424)
Status: 0 (VI_SUCCESS)
5. ncWrite (41419424, 8, "........")
Status: 0 (VI_SUCCESS)
6. ncCloseObject (41419424)
Status: 0 (VI_SUCCESS)
7. ncConfig ("CAN1::STD5", 7, {0x8000000F,0x80000013,...}, {0x00002710,0x0000000A,...})
Status: 0 (VI_SUCCESS)
8. ncConfig ("CAN0::STD5", 12, {0x8000000F,0x80000013,...}, {0x000003E8,0x00000000,...})
Status: 0 (VI_SUCCESS)
9. ncOpenObject ("CAN1::STD5", 41419424)
Status: 0 (VI_SUCCESS)
> 10. ncOpenObject ("CAN0::STD5", 0)
> Status: 0xBFF6211D
> 11. ncWaitForState (41419424, 17, 20000, 18)
> Status: 0xBFF62021
12. ncCloseObject (41419424)
Status: 0 (VI_SUCCESS)
> 13. ncCloseObject (0)
> Status: 0xBFF62024
The problem here is, that the second ncOpenObject (for CAN0::STD5)
fails (error code: 0xBFF6211D). The reason for that is that when the
port (CAN0) was never opened directly, closing the only CAN Object on
that port (fucntion call #6) will stop the port and reset its
configuration. Thus when you try to open an object again, the above
error occurs.
-B2k
