The switch Voltage → Current control is NOT bumpless

[pattacini]

          Indeed, it seems that it happens also with the upstream architectural model, see the video.

Given that this workflow is very unlikely to happen, it might be useful to notify it in a separate issue with low priority.

MATLABWindow_hnlp1F7PTL.mp4

Originally posted by @mfussi66 in #84 (comment)

[pattacini]

I don't have a suitable simulation infrastructure (either harness or ad-hoc test module) for testing this. Postponed to the next sprint and to be discussed with @mfussi66.

[pattacini]

Hi @mfussi66

Last week, I had a quick look at all the state machines involved and, apparently, the setting of the proper current setpoint that guarantees a bumpless transition should be handled as expected, if I recall it right.

As said though, I don't have the simulation infrastructure to carry out the tests on my own.

/remind Thursday let's talk about this F2F.

[octo-reminder]

⏰ Reminder
Thursday, April 4, 2024 10:00 AM (GMT+02:00)

let's talk about this F2F.

[octo-reminder]

🔔 @pattacini

let's talk about this F2F.

[mfussi66]

If it won't be possible to discuss it F2F, I can work on this issue in this sprint.

[pattacini]

Sorry @mfussi66, I had a setback today.
We can get aligned tomorrow, but yes if you have the physical setup ready, that would be great.

At any rate, discussing how to complete the simulation machinery is helpful.

[pattacini]

After a F2F alignment, the plan is that @mfussi66 will debug the problem on a physical setup.
The fix will be duplicated to address the official and the experimental architectures.

I'll put the issue on the next sprint, but feel free to reschedule it.

At any rate, discussing how to complete the simulation machinery is helpful.

Simply a harness created at the architecture level should suffice. A surrounding machinery should be needed anyhow, which can be probably copied out from sim2can.

[mfussi66]

I resumed the activity, and I found the following:

• It occurs only when continuously sending messages to the board
• It does not occur when doing the procedure:
  • Sending voltage target
  • stop sending voltage target
  • switch mode to current
  • In this case, the bumpless switch is perfect

To avoid readings of the spikes, I did the following:

Now the control mode change uses the filtered Iq instead of the raw one. But it did not help.

Also, I read with the debugger the current target in input to the FOC, and found the following. Units are Ampere:

0.00       <---- IDLE
-0.400    <---- Switch to Voltage
-0.400
...
-0.400
0.400     <---- Switch to Current
 0.400
...
0.400
-0.057       <---- IDLE
-0.057

So the outer controller is sending these targets. It will be checked who is the culprit.

[pattacini]

Great!

It should be: EstimatedData.Iq_filterd.current.
Apparently, .current is missing in the screenshot above.

[mfussi66]

Great!

It should be: EstimatedData.Iq_filterd.current. Apparently, .current is missing in the screenshot above.

Ah yes, when I made the refactor of the dictionary, I missed the Iq filtered defined as bus. I'll correct it, but I'm pretty sure it is not part of the problem.

This implies that I tackled this issue with the experimental amcbldc code, but it's better if I switch to the official one.

[pattacini]

I'm pretty sure it is not part of the problem.

Yes, I was just pointing it out.

This implies that I tackled this issue with the experimental amcbldc code, but it's better if I switch to the official one.

Yep, definitely. We should stick to the whole official framework for the fix.

[mfussi66]

I think at the end of the day, the culprit is the experiment_supervisor.
If I switch the streaming message to send from "Target" (in Voltage) to "Set Control Mode -Current", WHILE the application is sending messages, it does not stop sending the target.

This behaviour does not occur when a ETH board communicates with the AMCBLDC, but I wonder if it is a hidden bug that might have been triggered by this non-standard behaviour.

[pattacini]

Nice debuggging!

This behaviour does not occur when a ETH board communicates with the AMCBLDC, but I wonder if it is a hidden bug that might have been triggered by this non-standard behaviour.

I kind of concur that the system should be robust against things unforeseen by the protocol. That being said though, this is a general remark that holds for the whole architecture and not just for this specific case. Thus, we may consider ourselves satisfied here.

I would only adapt the experiment_supervisor to be more consistent with the protocol and stops sending the previous messages when you do the switch.

[mfussi66]

A simple change on the logic of the Periodic message trigger fixes the error. I added a "reset on change system", so that for one Model Ts the CAN Transmit would stop sending messages periodically.

Implementation:

For some reason, keeping the periodic transmission enabled would keep sending the same messages over and over.

Now it is fixed: as soon as the message type changes from 10F (Send target (Voltage)) to 001 (Change mode (current)), the message 10F is not queued up anymore:

[mfussi66]

PR: #91

[pattacini]

PR merged!