Hi there.  Really like the new DM01 / Log folder reading in the FW6.06.10 just released.  Also the shortcut function to read DM01/2 is a great addition.  This comment is the same for the Log folder access and viewing.  

Only additional comment is that there is a difference between the DM01 and the Log folder when the message is longer than the space on the screen.  In the Log folder, the log description + value text is shown at the bottom (great) and automatially shrunk to fit (and centred it looks).  So long text descriptins and values are supported well.

BUT the DM01 does not do this.  If the DM01 has fairly long txt for the FMI description, then when this FMI text is shown at the bottom of the screen, the text is truncated and not shrunk to fit.  It would make sense to have the Log folder and the DM01 react the same way if the text does not fit the space at the bottom.  Make sense?

Thanks

Julian

I have a question about the length of J1939 when the data is less than 8 bytes.

IQAN seems to set automatically the data length to 8 bytes, no matter what the DBC files contains.  

But, for example, when a PGN is set to 4 bytes by a manufacturer, the communication fails.

Is there a way to set the proper value of the DLC in IQAN when the data length is less than 8 bytes on J1939 CAN bus?

The past year (since Februari or so), we've been experiencing a lot more CAN related issues than in previous years. Usually BUS-ERRORs (so the safety module will lock down). It happens sporadic, it has been extremely hard to reproduce, but it happens on quite a lot machines, a few times a week in some cases. Machines with different software, different engines (FPT, Scania), different programs, different wiring. So they must have something in common that makes this happen.

I suspect it's "just" somewhere in the wires/terminators or other external factors that may reduce the bus health in general. But, what strikes me it started to happen on somewhat older machines, after updates. Some MC4x modules went from IQAN 5.03 to IQAN 6.xx, and it seems that CAN problems started there as well.

Could it be that the problem was always there, but that IQANs have a more strict check (less tolerance) since a specific firmware version?

Couldn't find it in the release notes, other than that several new CAN features (high speed, FD) have been added. A bit off topic, but in the same fashion we just updated a very early MC43 with a new program, and suddenly there is a VREF error that didn't occur before the update. Again, I guess the error was always there, but slipped through somehow in the older firmware?

For the info:

* We use 250 kbps

* Faults happen on the primary CAN-bus (about 4 MC IQANS, a display, an Engine)

* Usually the Safety Module will lock down, while the others continue to talk

* Networks are often a mixture of firmware versions (IQAN 5.03, IQAN 6.00.49, and more recent IQAN versions) - depending which modules got updated

Hello IQAN Team -

We are using Siemens Polarion to do requirements tracking of our software (requirement, V&V, etc). One possibility is to have a 'connector' between the requirements and the SW modules, basically a link between the two softwares, which is an industry practice and a requirement for certain certifications. 

This allows to link certain textual software requirements to actual pieces of code.

Is this a request that you have had before? Do you know of any connectors between IQAN and Polarion ?

Thank you -

Marc Daigneault

Could a selection box be added for "Log value" underneath "Dialog priority"? the default would be "not logged" with the capability of selected a previously defined Event or Statistic log. You've already done the work to have a pop up message whenever a DM1 is active for any SPN. Log the item whenever the DM1 is >-1.

I need to be able to display multiple FMI error messages  that are being broadcasted from the same SPN in a DM1 J1939 engine broadcast.

SPN = 3251

FMI = 3

FMI = 4 

FMI = 7

The IQAN system MD3 running with 5.06 will only display the highest FMI occurance which in this case is FMI = 7.  The other two FMI's are not displayed.  If a single FMI is present from this SPN, it will be displayed.

Any one done this before?

I have a system with 1x MC42 and 1x XA2 module. I am getting what i believe are random shut downs and has to be manually power cycled. The unit doesn't throw any error light codes that I have seen and there are not issues on the logs when i pull them. I went ahead and measured my cycle utilization and memory utilization. The cycle utilization is running consistently at 45% and the memory at 27%. I have checked for small things such as lose wiring etc.  

Has anyone encountered a similar issue? 

PS this is the second module to do this. We have replaced the module after thinking it was possibly something with the hardware. 

I have had the latest Design and Run 5.05.8.55.04 software crash multiple times over the last few days both while working offline as well as remotely connected to a machine. This is causing a lot of issues for me. Has anyone else experiences this?

Version 5.05 of IQANdesign, IQANrun, IQANsimulate and IQANscript is now available:

https://www.iqan.se/store/downloads.html

New features

Keypad style adjust for parameters

In the menu system, you can tap on the value of the adjust item to bring up a keypad-style adjustment:

CAN routing on MC4xFS

The CAN routing feature is now available also on MC4xFS. 

The above features will soon come in the 6.01 release also.

Version 5.05 also include some of the features already introduced in 6.00:

Add Blinking Lamp status to J1939 DM1 decoding

When enabled, the lamp status MDGN:s will blink according to DM1.

IQAN-SV properties for flip/mirror/bitrate/HDR moved to video control.

This means that individual video controls can have different settings.

Support external esc key in PDF reader

Implement full circle mode on gauge

For details, see release notes:

http://divapps.parker.com/divapps/iqan/Downloads/IQANdesign%205/ReleaseNotes5.05.8.htm

http://divapps.parker.com/divapps/iqan/Downloads/IQANrun%205/ReleaseNotes5.05.5.htm

http://divapps.parker.com/divapps/iqan/Downloads/IQANsimulate%205/ReleaseNotes5.05.4.htm

http://divapps.parker.com/divapps/iqan/Downloads/IQANscript%205/ReleaseNotes5.05.4.htm

Hi.

I have noticed that sometimes my MC43 gets stuck in a "Bus-off" state (Error code 3.4) a it does not recover, until I shut of the entire system. In my case the controller is used for steering and I need it to be able to reboot and recover locally on its own, in order for me to uphold my steering functionality without shutting down my system.

We have put in a functional request for this, and I'm just reaching out to see if anyone else is experiencing the same problem?

Regards

David PH Sc