Uploading using IQANdesign 6 to MC42 gives error

The update is slightly different when routing via Ethernet and when connecting on CAN, but I cannot think of any change in recent versions that would explain this. 

Did you observe what blink code you had on the MC41 when IQANrun timed out?

I notice the diagnostics bus is shared with a J1939 module, was this in your previous versions also?

I have not observed the blink code.

and yes, this has always been so in previous versions, without any problems. Just because of the same Bautrate, That J1939 module is a standard UTS 90° Module.

I soon have a different machine i can try on, ill first try uploading using IQANrun/ Design 5, and then 6. But i dont think its a fault in the program, because it uploaded fine using IQANgo.

Regards

Theleo De Bruyn

I just saw that my first picture has the system layout with the MC41, This is a MC42. Im sorry. You can see this on the 3rd picture. I also want to add that this were new modules without any programs previously installed.

Regards

Theleo De Bruyn.

What is your CAN bus utilization on the diagnostic bus under normal conditions and during reprogramming?

I have no idea what the utilization is during reprogramming, but during normal conditions it's about 1/4-1/3 used.

Today i have tested the uploading process again with a new system on my test bench. I found that unplugging the UTS solved the problem. But this isn't alway possible in the machines. And also as previously writen, why does the uploading process finish via bluetooth with the UTS connected to the system. I think this is weird because i have uploaded this program with Design 5 without any problems.
What could be the cause of this problem?

I hope we can solve this together.

Regards

Theleo De Bruyn.

Hello Theo,  You have connected MasterBus and J1939 bus for UTS on same B Bus connection, as you have MC42 in application you could try to move the J1939 UTS bus connection to CAN port C on MC42. Then there is no  possible interference on the busses.  Let us know if you have still issues then. 

I could try this, but i have a similar system with a MC41 (as seen in  pic 1). And the B bus is another BAUTrate. So conecting the UTS to the C bus would not work with the MC41.

I have not yet programmed a MC41 with Design 6 with this application. But i'll try this soon. I hope the MC41 will work so i can change the wiring for the MC42. Otherwise i have to find another solution for the busses.

Thank you all!

Regards

Theleo De Bruyn

I have tested the MC41 program. This Doesn't work either with IQAN Design 6, Afterwards i treid using Design 5 (Because i've always used this) and this doesn't work anymore after first trying via Design 6. Then I tried using my phone again (via IQANGo and Bluetooth) same program as i used with Design 5 and it  uploads without any problem. Also unplugging the UTS solves the problem.

So after this i maybe think that is has to do with a firmware version or something like that on the MD4-5 or MC4x.

Or could it be that i have to place a termination ID at the UTS?

I hope I'm not annoying or anything like that. I'm trying to get some data for you so we can solve this.

Once again thank you!

Regards

Theleo De Bruyn

Really interesting to hear that unplugging the UTS from the diagnostics bus worked. 

What version of the UTS is it, and do you use its default configuration for PGN:s? 

As Jos mentioned, the shared the diagnostics bus can be problematic. If it would have been a new system I would have recommended MC42 to have the tilt sensor on another bus. 

If you should have a termination on the UTS depend on the length of the bus and location of the drop lines. If you have the default settings on termination, both masters are terminated. If the masters are close and the tilt sensor is at the far end of the bus it is better to have the termination there, and only have termination on one of the masters. 

The UTS is in a default configuration. nothing is being changed in the program. Im using only the standard functions. The P/N of the UTS is:160736ECD. The MD4-5 and the MC4x are about 16m apart from eachother. The UTS and MC4x are 1.5m apart. So i hope this won't be a problem. The MD4-5 is the older version. Not the M19 Version. I recently got one of those. Could this be a problem?

Regards

Theleo De Bruyn

Thanks. With the default configuration on the UTS, it mainly sends out PDU2 messages at a relatively low frequency. The traffic it produces should have only a limited impact, at least as long as the bus is physically OK.  

Where are the T-junctions on the bus? 

If the MD4-5 and the MC4x are the two modules furthest apart, there will be T-junctions with drop-lines to the G11 and the UTS somewhere along this backbone. 

Is the 1.5 m the length of a drop line, or the length of drop-line plus distance to the MC4x ?

In general, drop lines should be shorter than this, but I wouldn't expect a big problem even if it is 1.5 m. And I'd expect there to be problems also in runtime if the physical layout of the bus was the issue. 

Also, any luck in recording the blink code on the MC4x when routing?

Hi there, sorry for my late response. I was very busy lately.

So in the attached image you can see a overview of the Bus line with lenghtes. The dots are junctions. The ID's are also in this image. 

I also got a recording of the blink code. This is from start untill the error.

Video:

Thank you Theleo, seeing the blink code is really interesting.

It looks normal during the first minute. 

First it is showing a No contact blink (indicating it is a module with a running application that is missing one or more CAN nodes), then comes a series of one long two short yellow (indicating the update has started at the MD4), then fast blink (flashing the MC42). 

But after that, it goes back to showing one long two short yellow. "no application available". That seems strange. 

What happens if you restart the system at this point, by switching power off and back on?

The No contact blink is no problem because there where no Sonic Ski's on this machine.

After restarting the MD4-5 shows the updated program but the MD4-5 has no connection with the MC4x. This is both shown via the menu page on the MD4-5 and my PC.

What is the MC42 showing as blink code after the restart?

I have no idea, I'll record this as soon as possible.

Investigation showed the problem was caused by traffic on the shared Diagnostics bus during SW update. 

With version 6.08 there is an update to avoid this problem. 

We are having quite some trouble with updating form a 5.x to a 6.x software (so including the firmware), or a 6.0 to a >6.02 version. Hopefully this will solve that as well. It will save a lot of time in service and at the factory. 

Jan,

Is that also an application where the Diagnostics bus is shared with one or more J1939 modules?

Yes it is. It is often like this: Engine - Display - MC42 - MC41 -and some other master modules.

I've also discovered that there are some instances where it matters that you have several masters with ID 0 on the same can line. For normal operation it is fine, but for updating and service it is a nuisance in some cases. 

Hi,

Just had a simular problem updating a system trough IQANconnect server yesterday. The system consist of one MD4-7" and one mc43. The md4 is connected to internet. After "restarting md4" message during update, i disconnect, and is not able to finish the transfer. The MD4 then restarts with black screen.  

Diagnostics and J1939 communication between the two masters is sharing bus. I tested disconnecting the MC43 from the canbus, was then able to download the application to the display. Tested connecting the mc43 back again, but same error, I disconnect after "restarting md4". 

Had to get the customer to connect their pc directly to the MD4 over internet port, the update went trough on the first try when i updated it over teamviewer. 

Snip from project data: 

Sigurd,

The problem you describe sounds like it could be a different issue. If the J1939 traffic that is mixed in on the diagnostics bus is only originating from the IQAN masters, it will not have any impact during SW-update. As soon as the SW update starts, the very first action is that all IQAN masters stop their applications. 

I understand, then i have no idea what the problem is on my system. 

I think its strange behaviour, since i've never had this problem with other systems before. Seems like the MD4 disconnects from the IQANconnect server when restarting to prepare for system update. The scary part is that the machine is then left with no application, and only black screen  with version code in the lower right corner(but I can still see the machine on iqan connect) when the powersupply is  restarted. I tried to do the update many times but same thing kept happening. 

Fixed in IQANdesign 6.08