The way I would approach J1939 on the cRIO would depend on what features of J1939 you needed for your app. If you are just reading or writing broadcast messages that fit in a single 8 byte frame it will be just as straight forward as standard CAN. Basically in this case you would be reading frames on the FPGA code, transmit them to the realtime portion where you can convert them to channel data using a CAN database. Writing would be just the opposite direction.
If you are using requests for PGN data, lets say to retrieve DTC codes, or R/W data using advance diagnostic messages (say DM14/15/16 for example) things will get a bit more difficult but not too bad. If you are expecting to tx or rx multi-frame packets and need the transport protocol of J1939, then things can get complex fast.
DMC recently developed a set of J1939 protocol drivers for LabVIEW which are based on the NI-CAN channel API. The drivers were written in LabVIEW just like the NI frame example, but provide functions at a layer above the base CAN channel API layer. This allows the simultaneous capture of data from both J1939 packets which are simple broadcast CAN frames, or more complex transport using BAM, including extended data frames.
I suppose something like this could be written into the realtime of the cRIO, and just pass frame data back and forth using some very basic code on the FPGA.
