Sam Dexter Posted September 30, 2021 Report Share Posted September 30, 2021 Hi guys, I really need some help to kick off J1939 CAN interface development on NI-9853 FPGA. There are some CANopen examples on the internet but nothing for J1939 and I don't even know where to start. What makes life even more difficult is that the CAN module is residing on the Ethernet expansion chassis NI-9147. If anyone could give me something to start with that would be absolutely fantastic. Thank you in advance. Quote Link to comment
ShaunR Posted September 30, 2021 Report Share Posted September 30, 2021 (edited) This a blast from the past. SAE J1939 is an old Japanese protocol-the precursor to OBD. It has the same connector as OBD but slightly different pinout. If you look for software that supports early 90's Japanese car diagnostics, there used to be a few examples around. It's a bit hit-and-miss since, at the time, everyone was doing their own thing. If IIRC the early Mistsubishi's used it (FTO, GT, Galant) so a searching for J1939 with those names might reveal something. I very much doubt you'll find anything LabVIEWy so you will probably have to write a protocol driver. Edited September 30, 2021 by ShaunR Quote Link to comment
hooovahh Posted September 30, 2021 Report Share Posted September 30, 2021 Well the good news is you can actually find J1939 support in NI hardware and software. I've never used it but the NI-XNet hardware specifically supports J1939 under the Application Protocol selection when creating the database for the API to use. And there are several resources for CANOpen such as this document. That being said that specific document might not be very helpful in your case since it uses the NI-Industrial Communications toolkit which I don't think supports FPGA CAN devices. I do remember seeing some G based CAN Open stuff from NI before that toolkit was made and it is possible you could adapt it to work in your setup. Here appears to be a G based J1939 protocol that might shows an FPGA example. But using CAN on an FPGA device adds another layer of difficulty. I'd almost just suggest you buy a USB 8502 which is an XNet device, then seeing if you can get that to work with the latest NI tools. Maybe even using a trial of a toolkit if needed. Then if you get that working sniff the bus and figure out how to replicate the functions you are trying to get to work. Quote Link to comment
ShaunR Posted September 30, 2021 Report Share Posted September 30, 2021 9 minutes ago, hooovahh said: Well the good news is you can actually find J1939 support in NI hardware and software. I've never used it but the NI-XNet hardware specifically supports J1939 under the Application Protocol selection when creating the database for the API to use. And there are several resources for CANOpen such as this document. That being said that specific document might not be very helpful in your case since it uses the NI-Industrial Communications toolkit which I don't think supports FPGA CAN devices. I do remember seeing some G based CAN Open stuff from NI before that toolkit was made and it is possible you could adapt it to work in your setup. Here appears to be a G based J1939 protocol that might shows an FPGA example. But using CAN on an FPGA device adds another layer of difficulty. I'd almost just suggest you buy a USB 8502 which is an XNet device, then seeing if you can get that to work with the latest NI tools. Maybe even using a trial of a toolkit if needed. Then if you get that working sniff the bus and figure out how to replicate the functions you are trying to get to work. Nice. Quote This example is named J1939 NI CAN Frame Example.vi and it is located in the Examples\NI CAN Frame Example folder. It uses NI PCI/PXI CAN hardware and the NI CAN Frame API to show an implementation of reading and writing transport protocol messages. The example code abstracts the packetization, transmission and reconstruction of these messages from the user such that there is no difference in the reading/writing of messages greater than eight bytes and messages of eight bytes or less. I guess there is something very LabVIEWy now! Quote Link to comment
JKSH Posted October 1, 2021 Report Share Posted October 1, 2021 (edited) If you only need to read the basic standard messages defined in J1939, then you can can treat the frames like any regular CAN frame. You just need to map the frame IDs to J1939 PGNs (for example, CAN frame ID 0x0CF00401 is for "Electronic Engine Controller 1" and bytes 4-5 contain the "Engine Speed" value) However, if you need to do do complex things like read multi-frame data or send a command and read the response, then you need to write a lot more custom code. Fortunately, NI has provided an example that covers a big chunk of what you need with the NI-9853: https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 (use the non-XNET code) 13 hours ago, Sam Dexter said: What makes life even more difficult is that the CAN module is residing on the Ethernet expansion chassis NI-9147. On the bright side, since you're doing FPGA programming, it doesn't matter if the CAN module is on an Ethernet expansion chassis or if it's plugged directly to your controller -- your code would be the same either way 13 hours ago, hooovahh said: I've never used it but the NI-XNet hardware specifically supports J1939 under the Application Protocol selection when creating the database for the API to use. AFAIK, that only provides mapping for the basic messages that fit within a single frame, and some basic standard hanshaking + diagnostics. NI-XNET has no built-in support for multi-packet data or complex comms. I used the XNET example from https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 as a starting point, but still had to write a lot of custom code to encode/decode messages and handle command-response handshakes. Edited October 1, 2021 by JKSH Quote Link to comment
Sam Dexter Posted October 1, 2021 Author Report Share Posted October 1, 2021 Well, unfortunately, with COVID and stuff it is really hard to procure extra hardware, so we are stuck with the cRIO-9039 and we have to use NI-9853 with NI-9147 Ethernet expansion chassis to control industrial hydraulic driver that talks only hardcoded J1939. I have tried to use multiple examples (including C:\Program Files (x86)\National Instruments\LabVIEW 2018\examples\CompactRIO\Module Specific\NI 985x) but regardless where the CAN module installed (cRIO or expansion) I am not reading anything (although everything compiles nicely and there are no errors). In the example code, such as cRIO CAN Basic, they use FPGA I/O node to read the data but there is no any kind of the module configuration done prior to that. How is CAN module configured? Through NI-MAX? But the module does not appear in NI-MAX... Does it require NI-CAN? Or I/O node handler is a part of NI-RIO? Quote Link to comment
Sam Dexter Posted October 1, 2021 Author Report Share Posted October 1, 2021 OK, found where to configure the CAN module, silly me, and everything started to work - right click on the module in the project, go the properties and set up baud rate there. Also, NI-9853 works well in either configuration whether installed in cRIO or the expansion chassis. It appears that NI-CAN is not required for NI-9853 operation. I assume it is all handled in NI-RIO. Quote Link to comment
hooovahh Posted October 1, 2021 Report Share Posted October 1, 2021 Yeah when using the FPGA and CAN neither NI-CAN or XNet is used. It feels a bit bolted on and an after thought. When I did it back in the day there was just a DMA stream set up that sent frames down to the FPGA to be sent, and another stream for frames to be send to the host. I'm guessing there is logic that could have been put down on the FPGA but at the time dealing with a stream of bytes from hardware seemed difficult and so all the parsing and conversion was done on the host and the FPGA was just there to send raw frames. Not sure if things have changed since the 8.x era with FPGA CAN devices. Oh and even if you aren't using XNet you should install some of the tools. They have database parsing stuff that doesn't require XNet hardware that makes things easier to visualize and understand when it comes to frames and signal conversions. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.