- Software
-
Questions
MC2 Error
I have been using an MC2 as a control module for an excavator attachment. It was working fine until I added tried to add some CAN communication to send pressure sensor pressure values and joystick inputs to a Data Acquisition System. There were 9 signals. I attempted to load the file on, and at the end of the load it through an error saying something like "no return handshake from Master Module." I tried to reconnect to the system repeatedly but it would not establish a connection. I attempted to use the attachment and the MC2 was not sending out any signals.
After turning the power supply on and off and trying to reconnect unsuccessfully, I tried to read the lights. The following sequence repeated:
-2 long yellow followed by 3 short yellow. While not exact (extra long yellow), does this mean "Waiting for Restart"?
-4 Short Red followed by 1 short yellow: Internal Error
-18 short yellow - is this just the "there is something abnormal going on"?
I read this thread: http://forum.iqan.se/topics/98-mc2-cause-of-internal-errorose/ which seems to describe a similar issue. It seems like the advice is to short the ID pins and start in "safe" mode.
If the "waiting to restart" error keeps appearing even after cutting power and repowering, does that mean I need to try and start the program in "safe" mode and reload the program?
Anyone have a nice clean way to short the ID pins? Should I just put 2 clips on the end of a single wire? And what happens once I successfully reload the program? Should I cut power and then remove the shorting wire so it does not restart in "safe" mode?
It looks like there was an error in the software: I specified it try to broadcast the CAN data out over the wrong bus. The CAN data was also unconnected. In this case the information was not vital to the operation, but I am thinking this would be enough to throw an internal error and cause problems. Can someone confirm or deny that a module shut down could be due to a CAN comm error due to incorrectly spec'd bus OR unconnected CAN Comm cable?
Thank you, Graham
Customer support service by UserEcho
This is what I have learned:
-Shorting the address pins and starting in "safe mode" allowed me to reload the older functioning program
-To short the addess pins: make a single wire with the clips. If I were going to do it again I would remove the retaining clips so they could be easily removed once "safe mode" is no longer necessary.
-After loading the old version of the program, I shut down the power, removed the address pin shorting wire and the repowered. everything functioned like before.
Unlike the other MC2 internal error thread, there is no memory error shown when I try to upload the program.
What I would still like to know:
-Would an unplugged CAN cable cause an "internal error" and shut down the MC2?
-Would a mis-specified CAN output cause an "internal error" and shut down the MC2?
-Is it possible to have a cycle time error if my JFOUTs are set to send "Continuously" at a transmit rate of "Every Cycle"? It seems the "Every Cycle" should eliminate the issue with cycle time errors.
So I successfully uploaded the program with the J1939 communication through a USB connection while the controller was in safe mode. When I restarted the program, it showed an internal error code and acted as it did last week. So it looks like it is either a total system issue or a software issue.
Is there a problem broadcasting J1939 signals on a J1939 bus without any other J1939 devices on the bus? Would that be enough to throw an internal error?
It is looking like my issue is traced back to the cycle time being too low to transmit all the CAN signals without issue.
I have a setup that pretty much maxes out the system I/O and is running at 3ms/cycle. I am trying to send 9 messages across the J1939 layer. It seems like 30ms is sufficient time and 3ms is not. Does anyone have a feel for minimum transmission rates that will work for sending frames out over the J1939 layer?
Thanks, Graham
As a rule of thumb you can assume that one J1939 message on a 250 kbps bus takes 0.7 ms to transmit. So, 9 * 0.7 = 6.3 ms. Of course you need some margin also, so a cycle time of at least 10 ms will probably work.
Thanks, Ulrik. That is good to know.