I've been having some very strange issues today with XC43 "System mismatch" errors on a system with an MD4-7 and XC43. We're on IQANdesign 6.01.6. There's 1 XC43 with address 1 on CAN-C. When I load this program on new MD4-7 and XC43 I get the XC43 "System mismatch" error and the XC43 has internal state "Failed 306". The amber LED continuously blinks very quickly.

When I move the XC43 to CAN-A or CAN-B and reload the program, everything works. I then move the XC43 back to CAN-C, reload the program, and everything works.

Having the XC43 on CAN-D seems to result in the same "System mismatch" error.

We've used this same program and these same modules on many other machines without this issue, so looking closer at the MD4-7-T1E2 modules I was testing with, it seems like something changed with the modules with 2023 manufacture dates (2302040070 is the earliest SN that I experienced this issue with). All our modules that are later than 2208040660 don't seem to load the firmware onto the XC43 on CAN-C or CAN-D or something. 2208040660 and earlier have no problem operating the XC43 on CAN-C.

Did something change in the CAN-C and CAN-D ports on the MD4-7 suddenly sometime after SN: 2208040660 that they can no longer load firmware onto expansion modules? Or am I doing something wrong?

This could become a fairly serious issue with replacing XC43 modules in the field in the future. If CAN-C and CAN-D can't load firmware on the modules, we'd need to either reprogram the existing system or make sure the firmware is updated before it ships out. This isn't always easily done and kind of defeats the major advantage of expansion modules (forward/reverse compatibility without reprogramming). And if we can't use CAN-C/D for expansion modules, it severely limits their usefulness, since we're already advised not to use these buses for the diagnostic bus.

Question 1:

Now that we can put a Generic Can Bus on a J1939 Bus,  Is there any reason we cannot support a Generic Bus with a Diagnostic Bus.   If I try to do this, I get an error.   

I know of this work around, but it seems like alot of work, since the principles are in place to support this on any bus that is not connected to the Diag. 

https://forum.iqan.se/communities/1/topics/1110-j1939-generic-on-the-same-bus

Question 2:

Is there any way to support 500k on the Diag bus.   This project I am working on, we are not using the Diag bus at all.  But we need (2) 500k busses. We are using the MC41 for Can Bus communication only, and 2 outputs for a relay.  So doubling the cost for an MC42 is out of the scope of this project and we would have to try to source an alternative controller, which I rather not do. 

Right now we are using (100/year) MC41's on a sister project to this one  (which just started this month), and this project would add an addition 150/year starting next year. 

If I have to source a different controller, then all 250 trucks starting Jan 1st of 2024 will be moving away from the MC41.   Would love for some feedback, so I can start making plans of what we need to do for these 2 projects. 

I'm currently working on a dual master system using IQAN Design 6.08.24. When loading an application with 24V DIN on C2:1 or C2:2 it stalls at the finalizing and doesn't go through the restart, And when cycling the power it gives an error for an incorrect address tag. I tried loading the same program on another machine and had the same results, Unless the C2 was unplug or if I used 6.07.

Hi!

We have problems updating our machines remotely. We are not using IQANconnect.

We have three controllers in the machine: MD4-10, MC42 and MC43. After sending a new project to the machines and during the reboot this is displayed on the MD4:

And there it stops. After a while we power cycle the MD4 and it boots up normally. However, the MD4 has no contact with the other controllers and, if I am remembering correctly, we have a "System mismatch". Rolling back to the previous version restores everything. Trying to update the machine with the new project results in the same issue as mentioned before. And we are in a loop...

Connecting directly to the MD4 with an ethernet cable works flawlessly so I am suspecting a communication issue. Connecting directly to the MD4 means we have to travel across half the country for an hours work though...

Our communication solution has worked great in the past. I've talked to the IT department and they say that nothing has changed regarding our communication solution so I am reaching out to you:

What is going on behind the scenes at the moment the picture was taken?

Do you have any suggestions on how to solve the issue?

At the moment we hesitate to update our machines because of this. To be honest, just thinking about an update makes me sweat :)

I will be happy to provide you with any information you may need as this is very urgent.

Thank you in advance!

Kind regards,

Christopher Fridstaden

How does a frequency input of the IQAN module work? i.e.:

a) Filtered over x milliseconds

b) Filtered over x impulses

c) Resolution 1 rpm = x digits

Hi, are you able to expand the # of bytes sent from 42 we are limited to now? The issue with sending individual pages to compensate is that we are limited by buss speed/scan time. My current requirement is over 100 bytes but the project is also expanding. Are you able to get to the 1785 byte limit? 

Hello,

Question. I have an adjust group full of Integer Parameters. Lets called this adjust group A. I have copies of the same Integer Parameters that are tied to a different Input that I want to put in adjust group B. I want to take these copies and put them into another adjust group and use the same minimum, maximum, and step size as the integer parameters in adjust group A, into adjust group B. My problem is that whenever I copy adjust group A to make adjust group B, and then change the channel to one of the copies, it not only changes the channel for adjust group B. It changes the channel for adjust group A as well. Is there a way to prevent that from happening?

Upon adding a new state to a SMC, the SMC channel name is selected instead of the new state name and you have to go back and click the New State again to edit its name. This is very annoying and often results in changing the name of the SMC instead of the new state name.

The ability to override, disable, or modify the automatic message displayed when there is a fault on a specific IO point (High Error, Low Error, Open Load) would be beneficial for us.

There's a scenario where a PWM HS+LS signal is used to monitor an interlock loop. Some of the devices in the loop require a PWM signal to accept the interlock as valid. We would like to monitor the Output status for open load to determine if the loop is broken, so using a HS output and disabling Open Load Detection wouldn't work in this scenario.

If we could override the message text and severity for each IO Point individually, it allow Parker to keep the Open Load Detection where necessary, but we could have a more friendly interface for the operator without nuisance alarms.

Within our company we have a document management system. This system provides an automatic version management of drawings, Word and Excel documents, but also the IQAN project files. The document management system provides the correct file name, display version in the file, etc.

We run into the problem that we cannot arrange this in IQANdesign. My question: is there an API available to read and edit the project properties (of the IQAN file) so that they can be managed from our document management system.