PLUS+1 User Forum

PLUS+1 Software => Communication => Topic started by: enigmapaul on May 16, 2016, 08:58:10 PM

Title: New J1939 PGNs
Post by: enigmapaul on May 16, 2016, 08:58:10 PM
Hi Folks -

I was wondering the best way to handle PGN's that aren't already in the J1939 function block library. 

Is there any way to create my own Rx J1939 blocks, like a generic J1939 receiver?  Or would it be necessary to get into using the CAN components and deal with all the nuts and bolts of manually building the CAN messages based on the PGN data from the SAE documents?


Title: Re: New J1939 PGNs
Post by: FluidPowerTom on May 17, 2016, 02:27:33 AM
I'm pretty certain that you could create your own generic J1939 receiver using the CAN Rx compliance block or CAN components and building on that.  Honestly though I've just gotten used to manually building the CAN ID when necessary for J1939 stuff that's not in the library.  The stuff that I always do for manually building J1939 messages is:

- look up J1939 29-bit CAN ID structure (priority, couple of blank bits, then PGN, then source address)

- look up a Bit shift calculator (ex:  Priority is first in the ID and 3 bits long, so your Priority value is shifted left 26 bits.

- Add up priority (after shifting left by 26 bits), PGN (after shifting left by 8 bits), and Source Address

- Convert to hex if desired before feeding into CAD ID input on component

Doing the above steps can be done with the Array components I imagine such that you could build your own generic J1939 Rx block with priority, PGN, SA for inputs (and data too of course).
Title: Re: New J1939 PGNs
Post by: enigmapaul on May 17, 2016, 11:23:20 PM
Tom this makes sense.

It seems to me though that constructing the CAN ID is a numerical transformation based on PRIORITY, PGN number, and SA  - that could be automated as you suggest without any reference to the J1939 docs.

However the trickier part of building a Generic J1939 Rx Block would lie in the processes of:
- Extract/decode data from CAN data field
- Scale it
- Offset it
- Check for valid range
- Convert units (if applicable)

Our "Generic Block" then would need a series of inputs from the J1939 docs.  Perhaps we would need give our blocks a bunch of additional inputs such as:
- Data Range
- Resolution
- Offset
- PGN Data Length
- SPN  Start Position
- SPN Length

Then it would be smart enough to parse the meaning out of the raw data.

What do you think?

Title: Re: New J1939 PGNs
Post by: FluidPowerTom on May 18, 2016, 01:12:10 AM
Yep, extracting the desired meaningful data is something that would add a lot of work to automate and would need all of those additional inputs.  If you're needing to make this block for use by multiple PLUS1 developers who aren't familiar with the nuts and bolts of applying J1939 then maybe it's worth the time investment to make something like that.  Otherwise you might consider just making custom blocks for the specific PGNs that you need. 
Title: Re: New J1939 PGNs
Post by: Jeffrey2u on August 25, 2016, 02:43:00 PM
I am also working on a 1939 connection to a Combine. We need to read the Gear signal. I have done a CAN trace and found the address.
Does anyone have an example of the block they wrote to extract info from a specific byte. In my case it is on:
Priority 6

The gear is on Byte 7. It is the actual numbers, 0, 1, 2, 3 and 4. I need the full 256 bit message from Byte 7.

I have tried to write my own block but I either have the filter or mask incorrectly. I am used to the standard 1939 blocks and also simple RX and TX I use to communicate with displays, joysticks and peripheral items.

Any suggestions would be appreciated.
Title: Re: New J1939 PGNs
Post by: Jakob on August 25, 2016, 03:01:37 PM
Hi Jeffrey2u,
Niterider made a post a while ago, that might help.
Under the topic "Re: Can Rx J1939 signals?"