Has there been any thought for creating a block the just decodes the DM1 messages and put them into an array or other object.  this could then be used to display the SPN, FMI, and occurrence without having to decode each message and display it.  This would be very useful based on the number of DM1 error code that need to be decoded.

  There are other software packages that have create block to handle this for both DM1 and DM2 messages.  They have incorporated an up/down scroll to scroll thru the faults held in a buffer.  You can also clear this buffer but would reload if the engine or other device sends another packet of faults.  It also handle all of the status lights that would need to displayed along with any flashing that would be required.

Hello,

It would be nice if CANopen and CANopen Safety was implemented in IQAN Design.

We see the need of CANopen Safety as most of the suppliers for components such as CAN sensors are using or are planing to use CANopen Safety as the CAN-protocol for their safety related components (ISO 13849).

Today J1939 and Generic is implemented in IQAN Design. It would be nice if there was J1939, CANopen, CANopen Safety and Generic.

Regards

Fredrik Forsberg

Hi, today we have silver and red reference lines. Furthermore we have the possibility to show all or only the lines from a component. When I select a component, the associated lines are highlighted a little bit with a thicker line. But it is still hard to see, if you got a mesh like I have here below.

Wouldn't it be nice if we add a third colour to highlight the lines of the selected component?

Currently its not possible to have J1939 & Generic on the same line... why not? As long as the bitcount (29) and KBPS are the same...

The thing is, I need some tricks from both systems. J1939 allows to handle engine messages more easily, and also allows to use the Page Mask byte(s), so the same PGN can be defined multiple times and split ways. But J1939 JFOUT does not allow to change the PGN programmatically, which is needed in this particular case in order to make a reusable library.

Generic JPOUTS do allow a dynamic messageID's, but don't bring the other benefits...

Showing the pin connections on the module screen in Version 5 is really nice.  However, not showing all of the available I/O makes it difficult to see how pins are shared between different channel types. For example, you may not realize that you could simply move a DOUT to a different channel assignment (i.e. DOUT:F rather than DOUT:I) to allow for an additional COUT that shares a pin assignment with DOUT:I (ref XA2 module).  Is it possible to have the option to show all the I/O like before, but keep the pin connections displayed?

Adapting the MC4x modules on our first machines now, we had quite a struggle with the various pin characteristics (DIN Pull-up / Down, A15/17 suitable for relays on the MC3, et cetera). Such details can be found in the Specs of course, but it would be quicker & easier if we can see such details in IQAN Design, for example in the bottom-right corner when clicking an in- or output pin.

I am doing a bunch with functional groups in the latest project to clean things up a bit, and it is annoying to have to individually name/rename each of the FGIs, especially when I change the name of the source and then "have to" rename it again in every Funtional Group where it shows up.
Maybe have a box to check to override the default name strategy for the times someone might want another name used.