PGN "On Request"

Use the J1939 default method for requesting PGN's, see SAE J1939 documentation.

Here is an example file showing how to use one master (display module SA 40) for making the request (sending PGN 59904 with a request for a PGN ), using the "poll trigger" property on a JFIN, and another master (controller SA 39) responding with the JFOUT on-request:

Request PGN example.idsx

The CAN trace with IQANanalyze shows how the traffic looks like: 

Hi,

Still no idea how it works lol . will have to get Parker on site to show me.

Reminds me of an issue I had in IQAN 3 with requesting PGN's. It seemed the request mechanism does not fully follow the J1939 guidelines.

Correct me if I'm wrong (maybe it has been fixed in the meanwhile), but the request only works if the Source of the request-PGN matches with ours. But the source shouldn't matter really, the Destination does.

Any source could send the 0xEA00  Request message, where byte1,2,3 contains the PGN we want to get back.

Whether the IQAN should respond or not, depends on the Destination source, the 3rd and 4th hex char. So, 0xEA00 is aimed at Source 0 (engine typically). 0xEA01 would be aimed at any controller with source 1, and so on. Or, if all should respond, we can also use the Global address (255). So if we request using PGN 0xEAFF, all controllers should react on that. From my knowledge, IQAN (3) didn't do that...

I checked the case history, and got reminded that there were some problems with send method on request that were resolved in version 3.15, but I am not sure if that could have been the issue you saw back then.  

This is how IQAN handles the request PGN 59904 now: 

In the request PGN, the DA may be either that of the master module, or broadcast (255). 

The SA of the request PGN must match the source address property on the J1939 module that the JFOUT with the send method on request is located on, for the sending of the JFOUT to be triggered.  

If there is a request PGN directed the IQAN master from a different source, there will be a response, but the response is a NACK in PGN 59392.

Below is an example of how the application attached to the previous post (that expects the request from SA 40) would respond if the request came from another SA, in this case 128:

Hi guys,

Found the issue. If you assign the requested message to say a dashboard, then the request only works if the SA of the dash requests it. The issue is what if another SA also needs to request it???

So how would two different modules request the same information? If the dash with a SA of 23 request machine information to display on the dash (PGN 65512). Then a service technician plugs in service tool with SA of 249 also requesting the same information?

What Carl describes is indeed the issue we had as well. Basically we don't always know who is going to request. Or in my particular case, I had 2 displays that could request the same (so I had to catch and process the request manually).

Basically the Source of the requestPGN shouldn't really matter. Just as long the DA matches ours or is set to Global, we should reply.

Yep exactly. There isn't a way to get the request to work with 255 so any device request is available.

To configure the system so that the request PGN 59904 can come in from multiple modules with different SA, you can add one J1939 module for each SA you need it to work with, copy the JFOUT with the send method 'on request', and assign on to each of these J1939 modules: 

Request PGN example two sources.idsx

The send method 'on request' will work with requests to the DA matching the IQAN module and to DA 255 (request directed to all nodes on the bus)

The alternative approach is to add a JFIN with PGN 59904 to the application, and trigger the sending of the JFOUT using the 'on trigger' method instead. This still requires each J1939 module in the system to be represented in the IQANdesign system layout, and the JFIN:s will have to be duplicated.