MD4 - GFOUT or JFOUT Assignment

Since you want to send out a CAN frame, one can assume that you have a recipient of that CAN frame.

In the application logic you will need to model that receiver with a module.

Assigning a xFOUT to that module will logically represent the application sending out a CAN frame to that module.

An xFIN assigned on the (same) module will represent messages received to the application from the module.

For a Generic module there is no special meaning, other than it provides structure to the application.

For J1939 modules you have the source address which is an integral part of the CAN id for the J1939 protocol.

Since a module is a logical representation of a physical module, the MD4 (should) have the same source address regardless of how many (physical) J1939 buses it has.

Thanks Marcus,

If I do not intend to send the message to a specific module (not sure yet), but just broadcast the CAN frame onto the bus so that any device on that bus could read it in, would I just create a device on the bus with the global source address of 255?

Chris

I'm a bit baffled over the fact that we allow setting Source address to 255 on a module, since it's a bit nonsensical, and would not be considered good practice.

For your purpose it'd be best to create a 'dummy' module with a source address that is not used by any other module in the system, and then perhaps override the Destination address on the JFOUT channel.

I say perhaps, since PGN numbers >= 61440 (PDU2) does not contain destination address information and are de facto broadcast. Perhaps you can find a suitable PGN for reuse, or use Proprietary B (65280 - 65535).

This is probably the best way to go!

In order for the Destination address property to become available on the JFOUT you'll have to use a PGN numbers < 61440 (PDU1).

For all intents and purposes, if you choose to go PDU1, PGN 61184 (Proprietary A; 0xEF00) is your best option. Lots of reserves down there.

Reading up on the matter, setting address 255 (and 254) on a module is not only bad practice, it also opens up for violations of the standard. I've opened a case to see if we can tighten up the limits on that...

Hey IQAN team, I am coming back to this topic as I have another example that I believe falls into the same case. We are logging vehicle hours in the IQAN system using a Timer Channel (TMR). Then we are looking to follow the J1939 standard and send this information back out on the vehicle bus using PGN 65255, which I believe is in the PDU2 range. Again we are following the J1939 DA and wanting to only send this message on request from other ECUs. What I am struggling with is how to assign this JFOUT channel to an ECU on the J1939 bus. There are many ECUs on this bus in our implementation, but this JFOUT channel is not really specific to any of them as a destination, and will only be sent on request. How should I assign this channel in the application code? Is there a "correct" method to do this so that it complies with the J1939 standard and does not effect the message content?

Cdvorak, 

I saw in another post that you probably figured this out already. 

When configuring a JFOUT with a PGN number in the PDU2 range, the only think the assignment to a J1939 module does is to send it to the bus that module is on. 

(PDU1 messages are different, as they have a Destination Address)

One thing you could do if you like is to add a dummy module with the J1399 broadcast address 255 to the system layout. But such a module would show up in the list of module in IQANrun and might be confused with a physical module. 

The best is probably to put this JFOUT on any the J1939 modules representing a real module.