MD5
34576-0703 (Obsolete) - https://www.molex.com/en-us/products/part-detail/345760703

34576-1903 (Not Recommended For New Design = Going to be Obsoleted) - https://www.molex.com/en-us/products/part-detail/345761903
Code H version is also Obsolete. (34576-0803 & 34576-2003)

MC4x
34822-0013 (Not Recommended For New Design = Going to be Obsoleted) - https://www.molex.com/en-us/products/part-detail/348220013
34566-0103 (Obsolete) - https://www.molex.com/en-us/products/part-detail/345660103

Have you guys seen that the connectors that are used on the MD5's & MC4x are Obsolete, or going to become Obsolete soon.    What is the long term plan for these connectors, as these were just released?  Have you talked with Molex to support these longer? 
 
Just trying to plan ahead, as we mfg harnesses to support these parts. And need to know if I need to buy and stock a lot of these so we don't run into supply issues. 

We have a multi-master setup with MC43 headmaster, MC41, and 2 MD5 displays. On initial power up all modules are communicating normally without error. For a brief moment on engine start both MD5s report no contact to the MC43 and values from the CAN bus stop updating on both displays. First assumption was a voltage drop issue on the MC43 but we scoped power to ground at the MC43 during startup and we are well above the 9V minimum. We also ran a CAN trace on the bus to check for CAN errors but saw no issues there either (no CAN errors reported by anything on the IQAN side either other than the no contact error).

The no contact is transient, it appears to clear up almost immediately. There is no indication of no contact on either the MC43 or MC41 LEDs during this period. LEDs are displaying the normal running pattern. When the displays are frozen all of the control functions still work, but the display does not update to reflect our inputs.

The displays will resume updating values only if we transition to another user-created MD5 page and back.  Until we go to another screen it will never resume updating values on the display. So far we have replicated on IQANdesign versions 7.05.19 and 7.05.27. Other than this specific issue everything is operating without problems.

Does anybody have any suggestions on potential causes or tests to narrow down the issue? 

I'm encountering a problem with the downloding of the log files in IQAN run 7.

when I select all log then it shows the component, but after I selected to get all records it will not show the component anymore, and it will only show : "Unknown component"

Before:

After:

Good afternoon,

I have a system that uses an MD4-5 as the master and several XCx modules as extension módules. One of the XC44 modules randomly fails to connect when I power up the system, and the LEDs indicate the following error:

"R4:3 3:1:7 Startup check. Expected after update of XC4x to FS capable version."

This error is random; it may not appear for a week or it may appear several times on the same day.

I have checked the wiring and it is correct, as is the battery voltage.

Telematics signal ID 19 data type real is showing up in our modem data stream as 0 when program is on a functioning machine. If the program is on our test bench that does not have any I/O, the value is exactly the value we would expect it to be. We have done lots of testing to narrow down the root cause. Our best understanding right now is that when the program is running on a real machine, the I/O is changing values. That seems to be the difference between the test bench and a real machine. Some of those I/O values are sent to display page items over the DIAG CAN from an MC43FS address tag of 0 to a display address tag 1. If we set up the display to never show a page on a real machine, signal ID 19 is the exact value we would expect it to be. Is this a known issue or has anyone else experienced something like this? We are using IQAN design 7.04.8.10088. We have also used IQAN design 7.05. The issue still exists.

When you copy and past an external function it will remove 

Insert an external function (everything is correct)

I copy and paste it, to and another one.  And the ability to now adjust this item is removed, and I cant not figure out any way to fix this.   Other then deleting the whole group and adding it manually back.  

Hello,

What does !!! 0,00 mV mean in the Log's status ?

Running the latest version of IQAN 7.05.27.10981, I am having a problem where buttons will not update location on simulate and the physical display. 

In design it looks like this. 

Simulate and if I program the display it looks like this. 

If I delete the layer these items are on and add them to a new layer then everything is fixed. 

Has anyone experienced an issue in IQAN Analyze where the screen font size is extremely small? If so, is there way to correct it? It's as if I zoomed out to 10% but there is no zoom feature that I can find.

I would like to see the behavior of the DM1 fault message popup change with regards to how it updates when faults go inactive. Currently when there are multiple undefined SPNs active, and they all go inactive, all but the last active fault is left displayed in the warning message. I will provide an example below where an end user might be able to solve the problem by sending a picture to their dealer, but the current way the dialog works might result in a dealer service call. Could we perhaps have a way of still showing these faults on the DM1 warning popup, but indicating that they have gone inactive? Perhaps put an “IN” on the line with the SPN/FMI that is inactive?

EXAMPLE Case:

SPN/FMIs active for:

• DEF quality. (Bubbles have accumulated on the sensor after filling causing a temporary unstable reading.)

• SCR fault caused by elevated NOx. (Since the dosing system has stopped dosing because of the previous fault.)

• 1^st torque derate fault (due to emissions issue being present for a given length of time.)

The machine has been running for some time, but the DEF quality fault is not reassessed until a new key cycle. Once the first torque derate kicks in the operator shuts the machine off and restarts it to see if the faults go away. Given that it hasn’t, he leaves the machine to grab his supervisor who calls over the maintenance team. Since he has left the machine running, the DEF quality fault clears and now only the elevated NOx and 1^st torque derate message are left. By the time the maintenance person gets to the machine, all faults have gone inactive, but only the 1^st torque derate is still shown.

The maintenance person takes a picture of the main screen with the DM1 warning showing only the SPN/FMI combination for the 1^st torque derate and sends it to the dealer’s service team to see if there is any way he can fix this without a call out, as this is a recurring but sporadic issue. He hasn’t found the correlation between one of the DEF pumps on site pumping faster causing aeration of the DEF when refilling the machines.

Because there are many different types of problems that could cause a torque derate, the dealer sends out a tech with the engine diagnostic tools. Had the dealer had the DEF quality SPN/FMI they could have passed along a service bulletin from the engine manufacturer that relates to aeration causing these fault codes, and the end user could have verified this as the cause and implemented countermeasures such as lower flow DEF pumps at their fuel depot.