At a given cycle time, is it possible to determine if a J1939 CAN frame has just been received? I am aware CAN frame blocks return a boolean indicating if their frame is new or not. However I believe this only works if the CAN frame has an enabled time out. Is it possible not to have a time out and still be able to determine if a CAN frame is new or not?

My goal is to not implement a time out, yet still be able to distinguish a CAN frame that has not been updated for a while from a CAN frame that is continuously being updated with identical values.

Thanks,

Hello,

I am working with a MC43, that controls a relay (a DOUT LS) that maintains the 24V power supply to the MC43 (enabled by a timer relay before that).

If the MC43 shuts down, it can't be turned back on, without re-toggling (manually) the timer relay. This behavior is perfectly fine except for firmware updates. I can send a IQAN project remotely, but when the firmware update is finished the MC43 systematically reboots, then looses its 24V. Is there a configuration that prevent this behavior?

Thanks.

I have an integer parameter inside of my initialization group that drives the Source Address for my TSC1 channel.

That IP channel is supposed to change it's default value depending on the truck engine model (decided in an adjustable state).

The truck state is set to DD and the default value for the Engine SA IP channel SHOULD change to 231, but it is staying at 7.  I've reset power and I cannot make it come off of anything other than the default mode default value.

Any help would be greatly appreciated.

It would be nice to be able to see what adjust group a certain parameter channel is part of directly from within the application logic.

Dear all,

Let me explain the problem and I hope someone could give me an idea how to fix it.

I have a transmission that goes to force neutral with no obvious reasons.

Attached is two picture of CAN trace on the bus.

FF20 is sent from our controller to the transmission and FF23 is what I get from the transmission.

As you can see for some reason the all bytes are changing to Fs what may cause this behavior.

In the controllers Log I see "running indication J1939 error" and althoug I am not 100% sure I believe this is relatet to the listed above. Can someone explain what this error stands for ?

Thank you in advance, all support will be appreciated.

Hi.

Although I upload the texts in Arabic and Hebrew as written from the right, it seems wrong.

I have tried "Arial Unicode MS" and"Noto Sans Hebrew" fonts, but there has been no change. I couldn't fix the Arabic and Hebrew languages appearance.

If you know the reason, can you help?

Thanks in advince.

Hello, I am using a MD4 to receive CAN message from and Inverter and the Can messages  are Muxed. So i have my application designed to receive the J1939 message and the first byte is the command bite it should then change a state machine in which allocates the data to the associated memory channel while in that state. What I'm finding is my command byte is changing but to fast to acknowledge. I have a can trace and i can see the multiple different messages of the same message being sent at different rates and with different priorities but my  command byte is not changing the state machine. Occasionally i get a value that has been received from a different command byte so the program must have worked but its very random. It reads the values sent at 10 ms and ignores the other messages with a longer send rate most of the time. Would yo have a suggestion on how to delay the time that receives the command byte in order to allow the memorizing channels to save. Or any suggestions for Muxed messages. File is attached below can trace

PD400 Status CAN.idex

Hello,
Is there a (currently or planned) feature to allow a remotely connected user (logged in with the right privileges, of course) to reset the system/ cycle power? The modules reset when you send a project, or send settings, but there doesn't seem to be a way to reset the modules after manually adjusting any parameters.
This would be especially useful when adjusting "Initialization" parameters that require a reset to take effect. 

Last weeks, we are having issues updating MC41 modules via USB-CAN (and some of our service guys told having the same issues with a MC42, but that is unconfirmed). It seems the  "Updating Firmware" step takes forever. Eventually we succeeded with one laptop, but it took ~20 minutes, where it would normally take 1 or 2 minutes at most.

Other attempts would result in a "No reply from master module" failure. And what seems to be strange: we tried to upload with IQAN 5.03 but the failure message said it failed uploading Firmware version 6.00.48. So we tried again with IQAN 6.00.48, and the upload was done within a flash... But strange enough, I couldn't upload the same (IQAN Design 6.00.48) program earlier on another MC41. It would also get stuck at the Update Firmware part, and then the older 5.03 version would upload the program without problems...

So we have this issue with both IQAN Design 5.03 and 6.00.48. Tried several laptops, but that didn't make a difference either.  Using the same KVaser LEAF Light cable as always.

The strange thing is, we have been using IQAN Design 5.03 and 6.00.48 for quite a long time, without having issues. It recently started. To me, it sounds as if something changed on the hardware, or maybe some Windows (10) update is causing trouble.

It is not possible to copy code or function groups from previous versions of IQAN design and paste them into version 6.02.  I have verified this with versions 5.04 and 6.01.