J1939 / Generic on the same bus

Got to correct. JPIN blocks actually do allow Page Masking. So that reduces the problem. Still, it would be a handy feature being able to mix them.

The project I'm currently working this would be very helpful because one of the modules utilizes J1939 for control but the diagnostic messages are generic 11-bit.

Changing this to feature request

I hope being able to put an ext generic and j1939 with same kbps together on the same physical port is possible in the near future.  What is the status?

This can be done already, although you have to define your frame channels as GFIN / GFOUT for J1939 messages.  This should be a work around for now.

is it possible to do the other way around. Define frames as JFOUT/JFIN for extended generic, if the receiver does not care about the SA?

Is this still under review? I found it would be really helpful in some cases.

We actually decided that we would't make this change. 

It may seem like a small change, but if we were to implement this, it would require significant effort in reworking the firmware. 

For flexibility in the J1939 identifiers, it is possible to have dynamic Source Address on J1939 modules (since 5.00), and also DA on PDU1 messages. 

But the case with modules that use a mix of 11-bit identifiers and regular J1939 is one that cannot be handled, and that would need this feature idea.

Hi Gustav,

Even with 29bit ID, not all ID can be reproduced in J1939. Is it possible to just allow 29bits Generic CAN with same bus of J1939?

Regards,

Frank

Frank,

Is it the bit that corresponds to "EDP" in the J1939 identifier that you need?

That is the one bit in a 29-bit identifier you cannot set with the JFIN/JFOUT. 

The DP bit can be set using the PGN property.

Actually, I believe it would be less effort to rewrite the IQAN module firmware to handle a mix of 11-bit generic and J1939, than to sort out a mix of 29-bit generic and J1939. 

Hi Gustav,

Could you please advise how to set DP as 0 by PGN? For example, I was trying to send to 0x16300011. From IQAN6, I can only get 0x14300011 sent out.

Regards,

Frank

Frank,

For the CAN ID you were trying to send, 0x16300011, it is the EDP bit that you'd need to set 

(marked in red) 

‭0001 0110 0011 0000 0000 0000 0001 0001‬

Yes, so we can not do that via IQAN at this stage, correct?

Not with the J1939 bus. 

You need to configure the bus as Generic CAN and use GFOUT for this identifier. 

Update on this: With IQANdesign 6.08.28, it is possible to set the EDP bit on J1939 channels. 

We are all looking forward to this new can merging feature (like we can do with 11bit and 29bit CAN bus). I recently had to switch from generic CAN protocol to J1939 for a specific device that is already implemented on a shared (multi-controller) bus. It's a nightmare to change our vehicle architecture by adding a new gateway and hack messages in master controller just to patch this missing option ! Please let us know when this merging limitation would be fixed !  <3 

You should still be able to define J1939 message on a Generic bus.  You need to define a Generic bus with 29-bit identifiers in the system layout.  Then use the GFIN / GFOUT channels with JPIN / JPOUT channels.  You'll have to specify the full 29-bit ID, but if you understand J1939 identifiers, this shouldn't be too difficult.  It isn't as convenient, but better than adding extra hardware to the system.

I'm not sure what part of this request requires a substantial firmware change, but it would be so nice if the JFOUT/JFIN channels were more flexible and allowed for the input of the full identifier or a breakout of the PF,PS,SA from an external channel. The alternative of allowing a generic bus configured with a 29-bit ID and 250kbps baud rate to be on the same bus as an expansion or J1939 bus would work, too. 

This feature would allow for libraries to be constructed for J1939 products much easier. It would also allow for a more streamlined method for configuring J1939 devices over the CAN bus; greatly improving serviceability.

I loathe being restricted..........don't be the Apple of the mobile electronics world!!

I'm also in the need to send generic 11-bit frames on the same bus as J1939.

A also wonder you define "indentifier size" and J1939/Generic on bus-level rather then on message-level(As you do when working with any CANcontroller or CAN-interface). The same thing with DBC-files. J1939 is defined on message level.

The only thing that has to defined at bus.level is the bitrate.

The way I would like a GFIN/GFOUT to work, would be to add "CAN bus" as a property (allowing any bus(J1939 or Generic), and skipping the assosiation . It makes no sence to define a specific "receiver" or "source" when it comes to generic CAN-networking anyway.

I communicate both J1939 and 11-bit generic on same physical bus by connecting two CAN ports from the MC43 to the same bus. One port is configured for 11-bit generic, and one for J1939. Keep in mind that connecting IQAN-design through this bus will not work.

This is a waste of buses and patience, but it works in my application.

From 6.08, 11-bit generic and J1939 can be mixed on the same bus. 

Using generic CAN blocks the bus from being used for IQAN diagnostics and IQAN expansion traffic. 

Note that this does not solve the original post, where there was an idea about using 29-bit generic as a workaround for changing PGN with application logic. Controlling PGN as from a channel could be a different post. 

Can 29-bit generic be used on the J1939 bus?

No, it is only 11-bit generic that can now be mixed with J1939. 

With 29-bit generic, the controller wouldn't know if a messages is intended as generic or as J1939. 

It would be very nice to have the controller assume that it is J1939 and allow it. A lot of devices are designed with J1939 and CANOpen as options and the identifier or PGN is some calculation based on the node ID. I'm sure you're familiar with this. Now that IQAN has implemented external functions, it would be possible to have one external function defined that satisfies a multitude of PGN numbers, if the PGN could be a function of the node ID as a function group input. The alternative to this would be to allow a 29-bit generic bus to be on the same bus as the J1939/expansion bus and assume that it is meant to be a J1939 device. Below is a table from a valve manufacturer that illustrates this.