Currently have come to the conclusion that on bootup we get CAN error frames on chassis with 500k baud rate that are currently connected via CAN C, D of the MD4-7.  How is the boot up and initialization take place for the baud rate?  I have come to believe that the initialization isn't taking place correctly and is knocking out the 500k intermittently on startup.

Our machine needs to go through a few steps in order to shutdown properly. With this, our machine throws errors when we try to upload IQAN code as certain components do not get any warning they are about to be shut down.

I was wondering if there was a way to get a signal to begin the shutdown sequence when uploading code such that these components can go through their normal motions before power is cut off.

I'm pretty new to J1939 communication and need a little guidance how to send "codes" to a truck. To read on bus traffic (parameter in/frame in) i have learned the hard way, but now i need to send also. For example how do i send this code? Which "boxes" should i use? If someone explains this, then i think i will figure out the rest on my own :)

Hello, 

We are experiencing a user interface issue in Iqan Design 7.05.19.10562.

When editing a page on the display and scrolling in the Layers panel (for example towards the bottom), the main screen keeps scrolling along with it.
Even though the mouse cursor is positioned in the layer navigator, the display view continues to move.

This makes working quite difficult. Ideally, the scroll action should only affect the area where the mouse cursor is located, and the display view should remain in its current position.

Has anyone encountered this behavior before, or is there a setting to prevent the screen from scrolling together with the layer panel?

Thanks.

I like to use the Slider control in my project, as per the requirement the slider min and max value should get updated based on selection (that will be a CAN signal), Now the issue i am facing is the slider is showing fix min and max value .The max value is used from the GPOUT signal which is Fixed .

There should be a way to set fields in the Text Formatting Channel to have padding with leading 0s. E.g. If set to be padded to 3 digits then 5 would be printed as "005". This is effectively the "Number of Decimals" filed, but in the other direction.

An application would be for a clock formatted string (e.g. for countdowns). currently, 0 hours, 5 minutes, 17 seconds would print as "0:5:7" instead of the desired "00:05:07".

For searching, this may be referred to as Padding, Leading Zeros, Leading 0s, Fixed Length Numbers, Number of Digits, or Significance.

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?