J1939 Process Data Gateway App for Electrified Auxiliaries

The KEB T6 Auxiliary Inverter offers several useful application programs, or “apps,” that simplify the implementation of CAN J1939 communications. An app receives the ECU’s messages, organizes them according to the application, and decides what commands are sent to the inverter to control the motor. Each auxiliary can implement different apps based on the complexity and flexibility required. One of these is the J1939 Process Data Gateway (PDG) app, which is the most flexible in terms of both functionality and communications.

Whereas other apps, such as the Torque/Speed Control app, have pre-defined functionality and pre-configured J1939 data messages for quick and easy implementation out of the box, the Process Data Gateway app is an alternative solution that is fully configurable to meet additional application requirements with access to all inverter functionalities.

The primary purpose of the J1939 app or Process Data Gateway (PDG) app is to format the communications exchanged over the CAN-bus according to the J1939 protocol standards and manage the inverter process data parameter mappings. Here, the app is flexible both in terms of selecting the parameters (SPNs) contained within each message (PGN) as well as the protocol format used (PDU).

SPNs and PGNs

For each inverter node (e.g., of a multi-axis T6 system), there are configurable process data channels for both transmit and receive messages. A user can select how each channel’s inverter parameters are mapped here. This allows the creation of customized PGNs with specific parameters and diagnostics needed for the application. Any parameter which can be adjusted dynamically and all real-time diagnostics are generally available as parameter mapping selections.

PDU Formats

The PDG app can communicate using broadcast and/or peer-to-peer protocol formats and is selectable for each process data channel (e.g. PGN).

With the broadcast format (PDU2, Proprietary B), three transmit and three receive process data channels are available for each inverter node.  And with the peer-to-peer format (PDU1, Proprietary A), there are one transmit and one receive process data groups available for all nodes (combined message).

For either format, messages exceeding the standard 8-byte data length will utilize transport protocols (BAM, CMDT), with the app managing the data transfer using a sequence of instructions and multiple messages. Although, this process must also be managed on the other end. Due to this added complexity and additional transfer time, messages of 8-bytes or less are generally preferred.

Addressing

The PDG app is also adjustable in terms of addressing. This is particularly important if other devices on the network might have the same PGN. For example, 0xFF00 is the first Proprietary B PGN available and is often used as a default. Thus, with the PDG app, Proprietary B PGNs are adjustable via an offset shift (e.g. 0xFF10 + offset), and for Proprietary A, the embedded controller address is adjustable (e.g. 0xEF00 – 0xEFFA).

Application Example

As a practical example, consider an application that moves an actuator utilizing positioning control, such as an automated side loader arm returning to its home position. Here, the positioning module within the inverter could be used for this application. But, there isn’t an app pre-configured for positioning, so in this case, the PDG app would be a good choice since it allows the user to access the positioning functionality.

Let’s consider that from a control standpoint, the commands sent to the inverter (Rx data) will include the control word (e.g. enable modulation), the target position, and the desired profile velocity commands. Since the data length of all three parameters exceeds 8-bytes and would require a transport protocol format, the user could split these commands between two PGNs to keep the data transfer simple and likewise avoid longer transfer times from multiple messages.

In this case, the user could assign the control word to its own PGN and utilize the Proprietary A PDU format to ensure peer-to-peer with the partner ECU for controlling the inverter modulation on/off. Otherwise, considering the target position and profile velocity less sensitive, the PGN containing these parameters could utilize Proprietary B broadcast PDU format.

Rx1 Data (PropA) – PGN 0xEFxx (xx = address of partner ECU):

Control Word (2-bytes)

Rx2 Data (PropB) – PGN 0xFF11:

Target Position (4-bytes)
Profile Velocity (4-bytes)

From the diagnostics and monitoring side (Tx data), the user could have a PGN specifically dedicated to the status word, a PGN with actual position and velocity run-time diagnostics to compare with the corresponding commands, and lastly, a PGN utilizing transport protocol to containing several other relevant but less critical run-time diagnostic parameters.

Tx1 Data (PropB) – PGN 0xFF13:

Status Word (2-bytes)

Tx2 Data (PropB) – PGN 0xFF14:

Actual Position (4-bytes)
Actual Velocity (2-bytes)

Tx3 Data (PropB – BAM) – PGN 0xFF15:

DC Voltage (2-bytes) – Output Voltage (2-bytes)
Actual Current (4-bytes) – Output Power (4-bytes)
Actual Torque (2-bytes) – Heatsink Temperature (2-bytes)
Motor Temperature (2-bytes) – Error Status (1-byte)

Conclusion

The PDG app is a versatile app for all applications. It excels in applications that require access to more in-depth inverter parameter settings or diagnostics, which aren’t included in other pre-configured apps. It is also a great starting point for setting up CAN J1939 communications because it allows users to build data channels from the ground up.

If you have any questions about which app is right for you, please get in touch with a KEB Applications Engineer to discuss your application.