How to initialize the EDDP by BTN3

[Jason bourne]

When I use IIOT-EDDP, I want to see how the motor is initialized.
However, I only found that BTN3 was used to achieve the motor's return to 0, but I did not find the program to achieve it.
May I ask which module or file is used to realize the return to 0 operation?
Looking forward to your answer.

[Andrei Errapart]

Hi Jason Bourne,


By now it is definitely too late.

In this program, the motor initialization code is a copy of the one found in "focserver".

You can send me a message to request the sources. There is nothing new when compared to the "focserver".


best regards,
Andrei

[Jason bourne]

Sir, thank you very much for taking time out of your busy schedule to reply me. Now I have realized the initialization of FOC by my own way. I first guided the motor to rotate through a virtual electrical Angle to find the place where I of the encoder is located. Then, by setting the electrical Angle to 0, electrode A is found and the Angle deviation is calculated.

[Jason bourne]

At the same time, I hope you can provide the project of implementing FOC only through FPGA, because I am a student who only learns FPGA, and I have not learned Linux embedded, so I feel very confused when I look at the code, I hope you can provide the implementation of vivado.
Yours sincerely，
Jason

[Andrei Errapart]

Hi Jason Bourne,


This version of EDDP control code is also running on a CPU, but it might be easier to understand than the Linux one. Please find it attached to this post.


best regards,
Andrei

[Jason bourne]

Hi Andrei Errapart，
Thank you for providing me with the document, which broadens my thinking. Unfortunately, I opened the vivado project through the file you provided to view the PL-side design (vivado's block design). I don't know if you didn't provide the Tcl boot file enough to restore the vivado project. I'm looking forward to seeing the design on the PL side.
Yours sincerely，
Jason

[Andrei Errapart]

Hi Jason Bourne,


There are several projects demonstrating working with the EDDP.

Assuming you are trying to open the project in the folder "IIoT-EDDP/HLS/ARTY_Z7_FULL", you have to use Vivado 2017.1 for that. In this project, FOC is implemented as multiple IP core blocks developed in HLS. When writing one of the previous answers, I had Block Design in this project opened for the reference.

For the project in the folder "SDSoC", Vivado SDSoC 2017.1 is required. In this project, FOC is implemented as a single HLS IP core in a SDSoC project. The source for this can be found in the file "foc.cpp". In the block design of the SDSoC project, the internals of this IP core are not visible.

In the folder "Vitis", one can find Xilinx Vitis project. The FOC is again implemented as a single HLS IP core. This project was implemented by our Xilinx partner, thus I have little experience with it. But you can give it a try.

I am not sure if it helps. If you still are having problems, please supply the Vivado version and the project you are trying to open.

If you have further questions, don't hesitate to ask.


Best regards,
Andrei

[Jason bourne]

Hi Andrei Errapart，
Thank you for your help. I successfully found Vivado Block desgin in the following figure, but the following error occurred when compiling the Block design:
1.[BD 41-1376] Forcibly mapping </ps7/S_AXI_ACP/ACP_DDR_LOWOCM> into conflicting address 0x00000000 [ 512M ] in address space </axi_datamover_0/Data_S2MM>. This must be resolved before passing validation.
2.[IP_Flow 19-3478] Validation failed for parameter 'My M00_A00_ADDR_WIDTH(M00_A00_ADDR_WIDTH)' with value '29' for BD Cell 'axi_interconnect_0/xbar'. PARAM_VALUE.M01_A00_BASE_ADDR overlaps with address segment PARAM_VALUE.M00_A00_BASE_ADDR.
3.[BD 41-1354] Segment </axi_datamover_0/Data_S2MM/SEG_ps7_HP1_DDR_LOWOCM> at 0x00000000 [ 512M ] overlaps with </axi_datamover_0/Data_S2MM/SEG_ps7_ACP_DDR_LOWOCM> at <0x00000000 [ 512M ]> in the same network.
4.[BD 41-971] Segment </ps7/S_AXI_ACP/ACP_DDR_LOWOCM> mapped into </axi_datamover_0/Data_S2MM> at 0x00000000[ 512M ] overlaps with </ps7/S_AXI_HP1/HP1_DDR_LOWOCM> mapped at 0x00000000[ 512M ]
5.[BD 41-1629] </ps7/S_AXI_ACP/ACP_IOP> is excluded from all addressable master spaces.
The EDDP kit I used was purchased from https://shop.trenz-electronic.de/en/TEC0053-04-K1-EDDP-Motor-Control-Kit-with-Motor-Power-Supplies?c=476.
Yours sincerely，
Jason

[Andrei Errapart]

Hi Jason,


are you trying to build the project in "IIoT-EDDP/HLS/ARTY_Z7_FULL" ?

I just want to be sure.


MfG,
Andrei

[Jason bourne]

Hi Andrei Errapart，
I directly open the xpr file on \ Xilinx-iot-eddp-master\ SDSoC\platforms\arty_z7_10_foc\hw\vivado through Vivado 2017.4.
best regards,
Jason

[Andrei Errapart]

Hi Jason,


Can you try using the Vivado version installed within the SDSoC package?

With the default settings it should be installed as "C:\Xilinx\SDx\2017.1\Vivado\bin\vivado.bat". I am not sure whether there should be "SDx" or "SDSoC" in the path, will check as soon as I have re-installed Vivado SDSoC ...


Let me mention that the project file in the repository has been created with the 2017.1 version.


MfG,
Andrei

[Andrei Errapart]

Hi Jason,


Something has slipped through, I can build "arty_z7_20_foc" but not "arty_z7_10_foc".


best regards,
Andrei

[Andrei Errapart]

Hi Jason,


git pull

Try it now.

C:\Xilinx\SDx\2017.1\Vivado\bin\vivado.bat is the right tool for the job.


best regards,
Andrei

[Jason bourne]

Hi Andrei Errapart，
Thank you for your help, sdx 2017.4 counld't open this project but sdx2017.1 could. 
By the way I meet another two problems.
Firstly I can't understand how to realize the wave like saddle by IP core svpwm(hls). Could you please give me some doucument or web to help me understand, because I realize Svpwm by traditional way.
Secondly，when I use another motor with encoder(counts: 32768), I found enconder's IP counld does not identify the current location well. I changed the encoder counts number and the filter width from 32 to 16， so what else do I need to modify.

best regards,
Jason

[Andrei Errapart]

The IP core defined by the file "IIoT-EDDP/design_hls/SVPWM/svpwm.cpp" is not a good place for implementing the saddle wave. This IP core only adjusts PWM duty cycle-s and limiting.

I think you can introduce saddle wave modulation to the FOC. The PWM duty cycles are for all channels are defined by Inverse Park Transform and Inverse Clarke Transform. The Inverse Park Transform just rotates a given vector around. Here one can use the atan2(Vq,Vd) (or atan2(Vd,Vq)) to calculate the correction for theta. The phase of Va equals theta+correction and this you can use to modify the the duty cycle such that the result is a saddle wave. Repeat the procedure for other phases. May I ask what do you need the saddle wave for?

My recommendation is to get the encoder working first and worry about saddle wave later. Unfortunately, the encoder resolution is hard-coded in a couple of places:
1) In the files "sin_cos_table.h" as the size of the sine wave lookup table,
2) In the settings of the IP core "axis_encoder_0",
3) In the files "foc.h" as #define CPR
This is just off-the-top of my head. The list might not be exhaustive.

Thus, if you change CPR, you have to rebuild the Vivado (SDSoC) project(s) and rebuild the firmware.


Best regards,
Andrei

[Jason bourne]

Hi，
When I tried to convert the target motor that needed to be controlled, I found that I could not guide the motor to turn. Therefore, I tried to guide the motor to rotate by open-loop, but found that the motor just jerked indiscriminately.
I want to find the problem by checking how the link output of the IPark, IClark, and Svpwm differs from the output of each module compared to the eddp platform.
I am clear about the correction of the angle, and the initialization is also for the incremental encoder to find this corrected angle.
For now, I've tried to solve the encoder pure problem, but the Xilinx engineers haven't answered me yet.
regards
Jason

[Andrei Errapart]

Hi Jason,

1) Have you been able to rotate your target motor with the original EDDP firmware?
2) Have you verified the output of your new encoder over the full range?
3) Did you change all 3 definitions of the encoder resolution and rebuilt (verify the file timestamps) the bitstream and the firmware?


MfG,
Andrei

[Jason bourne]

Hi Andrei，
1) The firmware platform has been modified, but the main control is all Zynq series chips.
2) I guide the motor to rotate by hand and use ila IP to capture the angle from the encoder IP output, which can output a relatively stable angle.
3) At the moment I have only updated the filter and codes Per Revolution in the IP core at the vivado block design level.

regards
Jason

[Andrei Errapart]

Hi Jason,


Did you check that the modified "sine_cos_table.h" files were taken into account when building the the firmware?

For the motor to rotate correctly, the sine/cosine table(s) (files "sin_cos_table.h") have to be updated as well to match the encoder resolution.

The reason for that is that regardless of the operating mode, the motor is driven by sine waves and these sine waves have to be generated in real time.

The SDSoC version is easier to modify as there is just one set of files - foc.h, foc.cpp and sin_cos_table.h and the foc.h in the firmware. In the HLS design, the sine/cosine is used by both Park Transform and Inverse Park Transform IP Core-s, thus at least these have to be rebuilt.


Let me know whether it helps.


best regards,
Andrei

[Jason bourne]

Hi Andrei，
Thank you for your answer. I've modified the file on the lookup table for sin and cos, and the hls package has been repackaged. But the problem is not here.
regards
Jason

[Andrei Errapart]

Hi Jason,


Let me note that when you increase your sine table array size by +1, the array length will match the number of encoder positions.

Please find attached the files to compare your calculations with. You can see from the plots that the sine table for 32768 steps is visually the same as the sine table for the 1000 steps. It is a LibreOffice worksheet. I think a "C" program would have been easier.


Best regards,
Andrei

[Jason bourne]

Hi Andrei，
Thank you so much. Unfortunately my target motor is 7 pole pairs, and what you sent me is 2 pole pairs.
And  result I generated is shown in the image below.（This image is about cos）
regards
Jason

[Andrei Errapart]

Hi Jason,


The matching title for the plots would be "cosine".

I would start with the mode "MODE_MANUAL_TORQUE_FLUX_FIXED_SPEED", e.g. 6. I think you already did it ("open-loop" mode). You can check the source code for the calibration to see how it is done. As the next step, I would check whether the original design is able to rotate the target motor - it should. After that I would check whether the modified project is able to rotate the target motor.

It could be that there are some more places where the number of encoder positions is hard-coded, as I have never changed it.


MfG,
Andrei

[Jason bourne]

Hi Andrei，
Perhaps my initialization operation is a little different from the mode"MODE_MANUAL_TORQUE_FLUX_FIXED_SPEED" in the process, I use Vq = 0, Vd = 2047, and then increase the electric angle to guide the motor direction, but the goal is the same.
I am very grateful for the answers you have always given to my questions.
regards
Jason

[Andrei Errapart]

Hi  Jason,


You're right, the end effect is the same.

Just an idea: approach your target motor step by step:
1) Increase the number of full periods in the sine/cosine tables to 7 but keep the length same. Observe the rotation speed. If it increases 3.5 times, you're on the right track.
2) Increase the CPR and the sine/cosine table length to 32768 such that the number of full periods is still 7.
By doing it in little steps and always keeping the Last Known Good copy of your project you will have less possible sources for errors at each step to consider.


best regards
Andrei

[Jason bourne]

Hi Andrei，
Please forgive me for taking so long to reply, I have encountered some problems on my side.
Firstly, I would like to ask what is the specific definition of open loop;
Secondly, whether the flowchart I showed is an open-loop operation;
Thirdly, whether the open loop can guide the rotation without the virtual electrical angle, and subtract the offset from the electrical angle taken by the real encoder, then guide the motor to open loop rotation through Vq.

regards
Jason

[Jason bourne]

Hi Andrei,
Before you provided me with EDDP-demo .zip files only ARM files, I want to ask if there is hardware support on the FPGA side, now the underlying hardware of EDDP projects does not support the ARM program running.
best regards
Jason

[Jason bourne]

Hi Andrei，
Please forgive me for taking so long to reply, I have encountered some problems on my side.
Firstly, I would like to ask what is the specific definition of open loop;
Secondly, whether the flowchart I showed is an open-loop operation;
Thirdly, whether the open loop can guide the rotation without the virtual electrical angle, and subtract the offset from the electrical angle taken by the real encoder, then guide the motor to open loop rotation through Vq.When I was using the mode MODE_MANUAL_TORQUE_FLUX, I couldn't boot the motor to rotate and didn't know what was wrong.

regards
Jason

[Andrei Errapart]

Hallo Jason,


My apologies for the delay in answer.

Open loop means not accepting any feedback from the controlled output. Think about it - when the control system is using the feedback from the output, the information goes around in a loop and this is a closed loop system. PID control loop is an example of closed loop.

1&2:
The flowchart you draw is not open loop, because the encoder is connected to the mechanically to the output.

However, it becomes open loop when you remove the encoder from the motor.

3.
I think I wasn't expressing clearly previously. What I meant was the following: when you remove the encoder from the rotor and set the register "ANGLE_SH_REG" manually (increasing it step by step) in the mode MODE_MANUAL_TORQUE_FLUX, the effect is the same as using MODE_MANUAL_TORQUE_FLUX_FIXED_SPEED.

By not taking into account the encoder readings, this is the open loop operation.

Hopefully this helps.


Best regards,
Andrei

[Andrei Errapart]

Hallo Jason,

Before you provided me with EDDP-demo .zip files only ARM files, I want to ask if there is hardware support on the FPGA side, now the underlying hardware of EDDP projects does not support the ARM program running.

You can always use a soft-core CPU to control your system. The AXI bus is not difficult to interface with. Let me note that questions about interfacing to the AXI bus are best asked in the Xilinx forums or general VHDL forums, as there are experts on this matter.

Another option is to adopt the system to be controlled by other means. In the project "IIoT-EDDP/HLS/ARTY_Z7_FULL" the FOC receives its inputs from a "axi_reg32_0", which provides 16 control signals, each 32 bits wide. This can be used as a basis for your system (which doesn't have ARM core). Just provide some initial values for the FOC to work with.


Best regards,
Andrei

[Andrei Errapart]

Hallo Jason,

Thirdly, whether the open loop can guide the rotation without the virtual electrical angle, and subtract the offset from the electrical angle taken by the real encoder, then guide the motor to open loop rotation through Vq.When I was using the mode MODE_MANUAL_TORQUE_FLUX, I couldn't boot the motor to rotate and didn't know what was wrong.

Try various small values for the register ANGLE_SH_REG. Can you find a a small value for ANGLE_SH_REG such that the motor rotates?

Failing that, my recommendation is to start with our design and modify it in as small steps as possible into your desired design.


Regards,
Andrei

[Jason bourne]

Hi Andrei,

1:
I verified this message is fine (when you remove the encoder from the rotor and set the register "ANGLE_SH_REG" manually (increasing it step by step) in the mode MODE_MANUAL_TORQUE_FLUX, the effect is the same as using MODE_MANUAL_TORQUE_FLUX_FIXED_SPEED.）
And according to the code (as shown in the figure), only Vd and Vq can guide the rotation after correcting the deflection angle, without the need to manually add or subtract ANGLE_SH_REG.

2:
At the moment I can only guide the rotation by repeatedly adjusting ANGLE_SH_REG. I can't modify it once ANGLE_SH_REG and then the motor keeps turning.


best regards
Jason

[Andrei Errapart]

Hallo Jason,


1.
The Vd and Vq are later rotated by "theta" in the Park Inverse transform.

2.
No doubt you have already checked this, but just in case: have you verified encoder direction and the motor rotation direction?
Write the directions down on the motors. Verify whether they are the same for both new and old motor.

May I ask whether your new motor is bigger or smaller than the old motor? Let me note that the EDDP HW is relatively powerful and the current sensors have much more range than necessary for the small motor supplied with the EDDP. This makes the phase current readings more noisy than necessary; for a smaller motor this can be a real problem. If I remember correctly you should be able to observe the current waveforms in the Web API. Setting the mode to fixed speed might require changes to the Web UI. Then you can see yourself whether it really is a problem.


MfG,
Andrei

[Jason bourne]

Hi Andrei,

With regard to the first recommendation, I tried negating the encoder under observation.

To troubleshoot the problem, I am now using a full EDDP hardware platform and then generating the relevant hls IPs (Ipark, Iclark, Svpwm), so there will be no second problem.

best regards
Jason

[Jason bourne]

Hi Andrei,

I modified the problem that I said yesterday that it does not work in MODE_MANUAL_TORQUE_FLUX mode, the problem is that we discussed changing the sin-cos table to seven pairs of poles, causing the boot motor to fail to rotate.

best regards
Jason