[_Basser_]

I have been working to get a GEVCU 6.22 and an air cooled DMOC645 functioning. At this point I have not been able to get the motor spinning and input/help from others would be very welcomed.

The GEVCU and DMOC were recently purchased as a pair from the EVTV store. The DMOC arrived having been reflashed and it thinks it is a liquid cooled unit.

The items were wired up as per the documentation although at first I had overlooked the free wheel diodes on the HV pack contractors. The GEVCU was working as expected until it was powered down about the 12th time. The collapsing coil pulse from the contactors appeared to temporarily damage the GEVCU. Upon trying to re-power the unit the 12v and 5v status LEDS would not light. The 12V LED would appear to dimly light and then go out. I thought I had cooked one of the DC/DC convertors but the next day everything appeared to function normally.

The GEVCU firmware is build 1060. Connected to the GEVCU is a single channel hall effect throttle and the input is being read correctly by the GEVCU. The CAN bus is connected to the DMOC using a 4 conductor shielded cable along with GROUND and +12V. The GEVCU CAN leads that are connected to this shielded cable on not twisted. Is this a requirement during testing in the shop? Changing the GEVCU loglevel to "DEBUG" shows many CAN bus message transmissions.

Using ccShell with the DMOC originally showed a critical fault with P1XG.DMOCstate =6. Along with this critical fault 206 "DMOC_FAULT_CAUSE_UNKNOWN_CAN_FAULT". I found some older work of Collin's that suggested the following DMOC register values were required:
EEXCANDMoCIntegrityChallengeCycleSec\ (T_INT,C)=-1.0
EEXCANIntegrityMonitorEnabled\ (T_INT,C)=0.0
EEXCANVCUIntegrityResponseTimeoutSec\ (T_INT,C)=-1.0
EEXCANDMoCIntegrityResponseCycleSec\ (T_INT,C)=-1.0
EEXCANVCUIntegrityChallengeTimeoutSec\ (T_INT,C)=-1.0

These changes were made and flashed to the DMOC EEPROM. The DMOC was restarted and the critical errors were absent and the DMOC reported to be waiting for a power request.

After depressing the throttle I was not rewarded with the whirl of a spinning motor, but rather the DMOC reported a CAN bus overflow error.

I'm in need of encouragement and knowledge of the online collective! Hopefully someone has advice, insight or ideas as to how to proceed.

 

[CKidder]

You do sound to be getting an error in CAN communication. There's a couple of possibilities:

1. Have you properly added termination resistors? Your CAN bus should show 60 ohms of resistance from CAN High to CAN Low with all items off. This should have been part of the documentation so you should have been aware of the need for termination but it's always good to check.

2. Did you enable the DMOC driver in GEVCU? It sounds like you did as you said you were getting a lot of traffic when going into DEBUG mode. I believe a fresh install of GEVCU defaults to having it on so probably you didn't even need to turn it on.

3. Are you sure you've set the proper CAN speed? It should be 500k

4. Last but not least, make sure CAN high is really connected to CAN high on the other side and low to low. There's always the possibility of accidentally reversing that. It doesn't work that way - I've experimentally tested this on accident too many times.

 

[_Basser_]

CK thanks for the response. I had missed the adding the resistor at the DMOC end. The manual for GEVCU 5.22 shows the resistor, but the manual for 6.22 does not. One page 55 of the new manual it states the wiring harness handles all terminating resistor issues. A quick check with a multimeter showed a resistance of only 120ohms. I added the resistor and hoped that was the easy fix. Well, I was still faced with Critical Fault errors with the original *.par file and CAN bus overflow errors when I used the modified parameters as posted above. For some reason after an hour of digging around in ccSHell I decided to unplug the computer serial bus and restart the DMOC. AND IT WORKED! The motor smoothly accelerated to my test imposed limit of 700RPM.

The new GEVCU manual also states, on page 56, that the CAN bus speed for the DMOC645 is 250kbps. As you stated above, you believe it should be 500kbps. Is there any chance that the DMOC could work at the wrong speed? I will do some more searching.

Anyhow it was a good night as I now have a spinning motor. Thanks CK. It is not the EV grin yet, but I foresee it in my future.

 

[_Basser_]

I have confirmed that the GEVCU was configured with a CAN bus speed of 500kpbs. The root cause of the CAN bus errors has been determined. It was related to ground potentials. I’m running the car in the garage using rectified 240V as the high voltage power source. The computer I was using for ccSHell was an old desktop. The ground potential of the desktop was equal to that of the household earth potential. Unfortunately because I was using the household 240v for the high voltage its negative lead was about 170 volts below the household earth potential. With the old desktop computer powered by a 12VDC-to-120VAC inverter there were not DMOC CAN bus errors when everything was running.
I should have thought of the potential differential ground issue in advance, but was too eager to see the motor spin. Thankfully it was not a smoke releasing event.

 

[FROGSA]

I have been working to get a GEVCU 6.22 and an air cooled DMOC645 functioning. At this point I have not been able to get the motor spinning and input/help from others would be very welcomed.

The GEVCU and DMOC were recently purchased as a pair from the EVTV store. The DMOC arrived having been reflashed and it thinks it is a liquid cooled unit.

The items were wired up as per the documentation although at first I had overlooked the free wheel diodes on the HV pack contractors. The GEVCU was working as expected until it was powered down about the 12th time. The collapsing coil pulse from the contactors appeared to temporarily damage the GEVCU. Upon trying to re-power the unit the 12v and 5v status LEDS would not light. The 12V LED would appear to dimly light and then go out. I thought I had cooked one of the DC/DC convertors but the next day everything appeared to function normally.

The GEVCU firmware is build 1060. Connected to the GEVCU is a single channel hall effect throttle and the input is being read correctly by the GEVCU. The CAN bus is connected to the DMOC using a 4 conductor shielded cable along with GROUND and +12V. The GEVCU CAN leads that are connected to this shielded cable on not twisted. Is this a requirement during testing in the shop? Changing the GEVCU loglevel to "DEBUG" shows many CAN bus message transmissions.

Using ccShell with the DMOC originally showed a critical fault with P1XG.DMOCstate =6. Along with this critical fault 206 "DMOC_FAULT_CAUSE_UNKNOWN_CAN_FAULT". I found some older work of Collin's that suggested the following DMOC register values were required:
EEXCANDMoCIntegrityChallengeCycleSec\ (T_INT,C)=-1.0
EEXCANIntegrityMonitorEnabled\ (T_INT,C)=0.0
EEXCANVCUIntegrityResponseTimeoutSec\ (T_INT,C)=-1.0
EEXCANDMoCIntegrityResponseCycleSec\ (T_INT,C)=-1.0
EEXCANVCUIntegrityChallengeTimeoutSec\ (T_INT,C)=-1.0

These changes were made and flashed to the DMOC EEPROM. The DMOC was restarted and the critical errors were absent and the DMOC reported to be waiting for a power request.

After depressing the throttle I was not rewarded with the whirl of a spinning motor, but rather the DMOC reported a CAN bus overflow error.

I'm in need of encouragement and knowledge of the online collective! Hopefully someone has advice, insight or ideas as to how to proceed.

Hi BASSA,
I have the identical error report from the DMOC as you reflect above. You have updated and flashed your DMOC Eeprom. Please direct me to the link for me to download and apply the fix. Will appreciate any assistance. Rgs Fred

 

[FROGSA]

You do sound to be getting an error in CAN communication. There's a couple of possibilities:

1. Have you properly added termination resistors? Your CAN bus should show 60 ohms of resistance from CAN High to CAN Low with all items off. This should have been part of the documentation so you should have been aware of the need for termination but it's always good to check.

2. Did you enable the DMOC driver in GEVCU? It sounds like you did as you said you were getting a lot of traffic when going into DEBUG mode. I believe a fresh install of GEVCU defaults to having it on so probably you didn't even need to turn it on.

3. Are you sure you've set the proper CAN speed? It should be 500k

4. Last but not least, make sure CAN high is really connected to CAN high on the other side and low to low. There's always the possibility of accidentally reversing that. It doesn't work that way - I've experimentally tested this on accident too many times.

Hi Collin, Please advise me of the link to download the fix for the DMOC as highlighted by BASSA. My DMOC also reflecting critical fault. Also installed the 60Ohm resistor with no change in results. Does the DMOC645 require this resistor at all? Rgs, Fred