AC charging with Foccci and Zombie, not starting

[manny]

updated. now on 44.90.b.

with AcChargeControl set to CANremoteControlled. Behaviour is the same.

with it set to StandAlone. Foccci enabled the EVSE and after that Zombie enabled the HV.

and with a button press the HV off and EVSE off. We are getting somewhere

[tom91]

We are getting somewhere

with it set to StandAlone

So its broken for Zombie.

No idea what broke it, not really got time to look at it. It worked and now it does not.
If you got lock feedback build 80 should work with Zombie release 2.20

[manny]

Will order a 4 wire lock motor.

But it works for now with it set to stand alone.
I will post a update when the new lock motor is installed.

Thanks for the help tom91, uhi22 and johu.

[tom91]

update when the new lock motor is installed.

Be good to know if you can atleast get build 80 working to have a starting point to investigate further.

[uhi22]

From my point of view it should work also with a lock motor without feedback. So you could connect the motor leave the feedback unconnected.
The motor should turn as the AcObcState which comes from Zombie demands.
It would help to understand the intended sequence and to compare with the observed behavior.

Something like this, please correct if it is wrong...
1. User plugs in.
2. Foccci sees the PWM and sets isBasicAcCharging.
3. Foccci sets the AcCurrentLimit.
4. Foccci sets the CableCurrentLimit based on the PP resistance.
5. Zombie sees .... and sets AcObcState to Locking.
6. Foccci controls the lock motor (time based) and assumes the locked state is reached.
7. Is Zombie checking the locked state?
8. Zombie is demanding state C by setting AcObcState to CHARGE.
9. Foccci sees AcObcState is CHARGE and turns the CP state C on.
10. EVSE closes the relay.

[uhi22]

Plotting the AcObcState could bring some light into the dark.

[tom91]

From my point of view it should work also with a lock motor without feedback.

This was added (along with now a bunch of other changes) after my work on the Zombie integration and writing the AC charging logic and testing it all with BigPie.

Zombie interaction is based around ChargePortState.

It was working at build 80.

[johu]

I'm going over the code changes, looking where I changed semantics.
1. I changed CanWatchdog to require ChargeCurrent AND enable to be continuously updated. Before updating one of them was sufficient https://github.com/uhi22/ccs32clara/com ... d7c5bb8638
2. I fixed the lock implementation https://github.com/uhi22/ccs32clara/com ... 8b7ecc8d1c It could happen that the lock motor operated infinitely, among other bugs. This changed the behaviour of LockState
3. PortState changes to PluggedIn when not DC charging and PlugPresent=1. Before it only changed to PluggedIn when CP < 3%. Also changing PortState to Idle when PlugPresent=0. Before it would remain on PluggedIn https://github.com/uhi22/ccs32clara/com ... 847a899f3e

It's probably one of these causing the issues

The AC OBC interface isn't defined outside the source code. So just relying on that no one ever changes the behaviour is a bit volatile as we see.
As uhi has started to line out we should maybe write out the interface on the wiki. Which parameters are involved and what is their value at a given state

[manny]

I will get some CAN logs in StandAlone en Cancontrolled mode. probably tomorrow evening.

Then we can compare the states from Foccci and Zombie.

[tom91]

Had review of the code changes since build 80 could not immediately pinpoint where it would fail.

Need to find time to build my Foccci setup back up for testing with Zombie, but this will be a while since I can get on this.

[tom91]

Zombie sends:

Code: Select all

UnlockAllow = UnlockAllow << 7;

    if(ChargeAllow == true)
    {
        bytes[0] = 0x01; //allow starting
        AcOBCReq = 0x08; //Charge AC
    }
    else
    {
        bytes[0] = 0x00; //stop charge
        AcOBCReq = 0x08; 
    }
    bytes[0] = bytes[0] | AcOBCReq | UnlockAllow; //

Very basic control, but only really toggles enable, otherwise requests AcOBCReq = 0x02 AC charging (0x08 shift it down 2 as it starts on bit 2).

[uhi22]

Let me guess, Focccis Param::LockState is neither locked nor unlocked, and so we are stuck in the state where Zombie demands charging, but Foccci does neither lock (because it is not unlocked) nor it changes to state C (because it is not locked).
https://github.com/uhi22/ccs32clara/blo ... C.cpp#L328

[tom91]

updated. now on 44.90.b.

with it set to StandAlone. Foccci enabled the EVSE and after that Zombie enabled the HV.

Nope, as standalone works, which still uses same AC Charge logic, thus requires LockState to work

[uhi22]

Just tested on the desk some scenarios. Latest software, #90. Providing CP PWM, no PP connected. AcChargeControl = CANRemoteControlled, but nothing mapped and nothing connected to CAN. No lock feedback connected.
Setting AcObcState in the web interface for testing.
1. IDLE: Blue flashing.
2. LOCK -> motor locks, LED blue solid
3. CHARGING -> green flashing, state C.
4. COMPLETE -> green/blue solid. State B.
5. IDLE -> motor unlocks. blue flashing.
6. directly jump from IDLE to CHARGING -> motor locking, green flashing, state C.
7. button -> motor unlocks, blue flashing, state B.
8. wait 20s -> motor locks, green flashing, state C.

Conclusion: At least this seems to work fine.

params_CI90_AcChargeTestOnDesk.json

parameters for testing ac charging on desk

(613 Bytes) Downloaded 435 times

[tom91]

That is very strange if Enable and AcObcState are mapped it should in theory just work.

@manny probably best to rerun the Zombie "auto config" for Foccci to ensure the CAN map is correct. Then proceed by checking if the params update as expected.

[manny]

Started to replicate uhi22 steps but no lockmotor action.

Went to test the lock motor. But have some strange results.

On #90 when using the ActuatorTest motor did nothing. So removed the motor, tested it with a 12 battery it worked fine.

Hooked the scope up to the motor outputs from the Foccci and I see strange behaviour.

With LockClosedThresh and LockOpenThresh set to 0. I get this when switching to CloseLock nothing on Open

With LockClosedThresh set to 0 and LockOpenThresh set to 300. I get this Close both high Open both low

With LockClosedThresh set to 300 and LockOpenThresh set to 0. I get this when switching to Close nothing on Open

Change the firmware to #80 and get expected behaviour.
Open

Close

Next I will get some CAN logs

[manny]

Got two CAN logs, one in standalone and one in cancontrolled.

If I manually change the AcObcState to lock. The spot value also changes to locked
and then to Charging, charging starts.

So it seems that the AcObsState does not get to Focci.

Found it! chaged the CAN mapping for AcObcState, set the lenght to 4 bit. And the AcObcState changed to Charging

[tom91]

I will review the code then to update this, I am surprised it worked before then. No idea what done it, maybe the change of the length.
https://github.com/uhi22/ccs32clara/com ... 4e105a0a55

Will review my Foccci code and update. Does you lock work in latest build?

[uhi22]

Do we have a dbc for Savvycan which contains the intended signal mapping for the communication between Zombie and Foccci? This would help to have a consistent mapping on both sides and also help to interpret the logs.

[tom91]

Here is one I made earlier. Loads of extra bits as this is just an adjusted DBC.

Indeed obcstate should be 4.

[manny]

Does you lock work in latest build?

No, spot value changes as expected, but the physical motor does not move.

Got the new motor today ordered yesterday at 23:45. Delivered today at 19:45. and cheaper than on aliexpress

[tom91]

https://github.com/damienmaguire/Stm32-vcu/pull/157

Update to spec AcObcState to length of 4 in auto map config

[uhi22]

Hooked the scope up to the motor outputs from the Foccci and I see strange behaviour.

The pictures look like one cable of the motor is not connected or not driven. So on both ends of the motor we see the same voltage. If the cable between the motor and Foccci is not the root cause, we need to check what the driver does. It it possible to hook the scope to pin 1 and pin 2 of the driver IC (IC1, DRV8874)? Normally, to drive the motor, one of the pins should be high and the other low. I see no obvious reason in the software, that this control does not work.
When LockOpenThresh and LockClosedThresh are different, then just the timing changes, because the software considers the feedback, instead of using the fix control time LockRunTime. And if the feedback says that the target position is reached, the control stops. So changing the type of motor between "without feedback" and "with feedback" does not help to fix the issue in the control path. We need to find out, why both motor lines go to high when trying to turn the motor.
We could change LockDuty from 100% to lets say 50% to get PWM control of the lock motor, this could help to see on the scope which line is driven in which way.

[manny]

The scope shot where taken with the motor disconnected and a channel connected to each of the motor leeds from Foccci.

When LockOpenThresh and LockClosedThresh are different, then just the timing changes, because the software considers the feedback, instead of using the fix control time LockRunTime

A yes this makes sense.

It it possible to hook the scope to pin 1 and pin 2 of the driver IC (IC1, DRV8874)? Normally, to drive the motor, one of the pins should be high and the other low.

Yes will do some tests.

We could change LockDuty from 100% to lets say 50% to get PWM control of the lock motor, this could help to see on the scope which line is driven in which way

Will do

[uhi22]

Oops, found something. 50 is the new 100. I tested yesterday with LockDuty 30%, this worked perfect (always software #90). Just measured the inputs and outputs of the driver, they show PWM, with different duty cycles on both pins, and depending on the lock/unlock direction. Fine, so far, at least if not looking too much into details ;-/
Increasing the LockDuty to 100%, I see the issue: Both lines are controlled to 100% high, no matter of the intended control direction.
Setting LockDuty to 50% seems to be what we wanted with 100%.
So recommendation for the moment: Set LockDuty to something in 30% to 50% range. And we need to understand the PWM ratio calculation and fix this in Foccci.

Edit: The calculation of the pwm based on LockDuty was 50% off.
Fix: https://github.com/uhi22/ccs32clara/com ... c2d3e2d60f
New software #91: https://github.com/uhi22/ccs32clara/act ... 3195982499