+3
Completed

JFOUT multi-packet for handling text strings

Nick Pridham 10 years ago in IQANdesign updated by Gustav Widén (System support) 7 months ago 12

I have an application where I want to send text strings over CAN on a very occasional basis. A tool for handling extended outgoing CAN frames for this task would be very useful.

Please include an auto ASCII converter in the tool.

Planned
Planned to be implemented in 4.x (not 4.0 though).
I would belive this one is really two separate features. The title suggests that the CAN frame is "extended", but what you actually have to do to send a string that is >8 bytes is to use a protocol that splits up the message over several CAN frames.

In J1939, this can be done with the Data Transfer Message (that we use when reading DM1/DM2)

As the request also mentions GFOUT (generic CAN frame out), that would have to be able to support at least some additional protocol, e.g. the methods used to send CANopen SDO:s with >4 bytes of data.
I do a program for a MD3 display and communication with a recite printer. This are lot of information to store in the master module and then to convert it to ASCII cod. To create text I use an event counter to control a state machine to create letters to display and to make the ASCII cod I use an Integer parameter ea. letter have to be stored (RAM memory eats up quick). For standard text and number I use Lockup table. Lockup is easy to send out on the can but the decimals have to been taken away before. If it was a way to load the lockup table from the display like text massage I think that save RAM and text or numbers can be added of the operator of the unit.

Can someone help explain how I read in SAE J1939 EC1 (65251) SPN 544, with the JFIN/JPIN functionality. This is an extended data frame message and I am struggling to understand how to set this up in IQAN. It appears I am only able to read 8 bytes of data using JFIN.  

Yes, the JFIN channel is only reading PGN:s that fit in a single CAN frame. 


To read a J1939 multipacket broadcast message, one would have to set up the JFIN channels to PGN numbers 60416 (Transport Protocol Connection Management) and 60160 (Data Transfer)

It is kind of tricky, as these same PGN:s are used for transferring all multipacket  PGN:s adding JFIN:s with these PGN:s to the application will take priority over the built-in DM1/DM2 handling. 

Gustav, thanks. 


Do you mean that the existence of these JFIN's in the application will cause the IQAN DM1 handling not to function at all?


Also could you provide some more specific guidance on how to set up this in the application to specifically read in SPN544? I am struggling to construct this. 


Thanks, 

Yes, if you add JFIN:s with PGN:s 60416 or 60160 that will mess up the reception of DM1 messages with more than one active error. 



I took the liberty of chaining title to "JFOUT multi-packet for handling text strings", as the JFOUT implementation would have to be a specific implementation conforming to the J1939 transport protocol for messages > 8 bytes. 


Should hopefully make it more clear what one is voting for with this topic. 

Completed

Outgoing J1939 multi-packet for text channels implemented in version 5.02

Improved in IQANdesign 6.00, see https://forum.iqan.se/communities/1/topics/2046-iqandesign-6-is-now-available


6.00 changes how one can implement outgoing multi-packet text, now it is done by adding a TPOUT channel to a JFOUT set to multi packet. This makes it possible to mix numerical values (JPOUT) and text strings in the same multi-packet message. 

For incoming J1939 messages with text, use JFIN set to multipacket combined with a TPIN. 

For generic CAN, the TPIN and TPOUT can be used ,with GFIN and GFOUT, if the text is sufficiently short to fit within a single CAN frame. 



I used all 8 bytes and the last byte is being corrupted. Any Idea's?

Image 4295

On the TPOUT channel, check if you have a delimiter character. That adds another byte. 

JFOUT has support for >8 bytes when setting multipacket support. 

GFOUT is giving only one CAN frame.