ascii characters from J1939 parameter

If they are all upper or lower case letters (for instance) - it could be done with a simple state machine channel with 26 states for each character and then join them with a text formatting channel...but I don't believe there is anything built in. http://sticksandstones.kstrom.com/appen.html.

Thanks for the tip.  Unfortunately, that is what i was doing for the specific characters i needed to cover most cases.  I was hoping for something more general and conventient.

The other inconvenient thing is the text looks goofy with different sized characters at fixed distances apart.  It gives it the "cheap display" affect.  

Perhaps this could be a suggestion for the future?

Using one state channel and combining the characters using a TFC is the workaround I have used too. A variant I used was to first run each byte through a math channel to skip the first non-printing characters, and then use this math channel as input to a state parameter. 

I have come across several applications where some built-in support for string handling functions would be useful. I'll convert this topic from "question" to "idea"

When I am using the state machine or state parameter, they would take too much memory from my experience. Is there any way to reduce the memory usage for state machine/parameter?

In general, designs with large state machines tend to take up more memory when calculation objects are duplicated in different states. 

For this particular example of a text conversion workaround, a solution based on one integer math channel feeding into one State parameter channel is probably more efficient than creating a large SMC to identify the individual character. 

A built-in function for this would most probably be a lot more memory efficient still.

Thanks for the tip.  This way makes more sense and easier to generalize it for copy and paste to other applications.

Would it be possible to take this a step further and support receiving (and transmitting) J1939 messages longer than 8 bytes?  The ability to read SOFT and VI messages from J1939 hardware i have found useful to put on diagnostic pages.  I also transmit a configuration message to a non-IQAN controller from an MD4.  Currently i have to send a single message for each parameter.  However, the controller supports sending multiple parameters in a signal message using pgn 0xEF00 of various lengths, which would be easier from a programming and tracking perspective.

Yes, support for J1939 messages longer than 8 bytes, (together with better string handling), is something we hope to introduce. Can not give a date, but it's on the road map.

Exists in IQANdesign 6, with the TPIN channel and multipacket support.