Maximum frequency 375 kHz.

[lex27087]

Dear friend, you have done a great job.
Thank you for that.
I would really like to know why it is possible to generate the maximum 375 kHz?
And this is at a FPga frequency of 50 MHz.
I tried to set the maximum frequency to 55 MHz - 200 kHz.
60 MHz - 200 kHz
70MHz -200KHz
80MHz - 306 kHz
100 MHz - 200 kHz.
I would really like to know what the limitation is?
Thank you.

[lex27087]

[Peter-van-Tol]

To be sure: you are talking about the PWM module, or is this the stepgen module, as both use a frequency.

If it is the PWM module, I have to dive into it, as the frequency is not limited in the source code. Also, whilst testing at different frequencies, I don't see any sign that is has been caused by overflow of the period counter.

If it is the stepgen module, there are two possibilities:

• either your HAL-configuration does not allow for faster timings. This is due to the params stepspace and steplen. The maximum frequency is determined by 1 / ((stepspace + steplen) * 10e-9). The values of stepspace and steplen are in nanoseconds. If these values are set to be 2500 ns each, you'll get a maximum frequency of 200 kHz.
• the stepgen it self is limited in speed, to ensure resolution in steps. This should be however 400 kHz, which are very fast steppers.

Can you share me your HAL-file or HAL commands you used to generate your data?

[lex27087]

40Mhz chip
tried 200ns-
steplen
200ns-
step-space

max 306khz
then a mismatch error is displayed

[lex27087]

Is it possible to remove the frequency limit?

[romanetz]

Please clarify exactly what does not work. From our conversation in a local telegram group I assume that you cannot set maximum velocity over than that produces specified output frequency because it causes "following error" вт, 20 февр. 2024 г., 15:28 lex27087 ***@***.***>:

…

at 40 MHz more than 306 kHz does not work. staplen 200ns — Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABP7HCCIY3ZT45OIGDXJADTYUR3D3AVCNFSM6AAAAABDQYNQXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTHEYTAMJYGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lex27087]

[Peter-van-Tol]

Just to acknowledge: the combination of steplen and stepspace should be able to give you 500 kHz, which is limited in the software to 400 kHz. I will check whether the scaling takes a value above 400 kHz or the first value below 400 kHz. Should be set to the value just above 400 kHz.

You have also found a bug: the maximum frequency of the FPGA is not taken into account in the driver. So it is possible to push the FPGA harder then it can count from LinuxCNC. This will cause all kind of issues on its own and thus lead to a possible Joint following error.

EDIT:
The maximum frequency is correctly calculated. For 50 MHz, the maximum frequency is actual closer to 800 kHz then it is to 400 kHz. For 40 MHz it will be roughly 600 kHz. However, anything above 400 kHz is not recommended, so I will put a hard limit on this in a patch, as it may lead to overflow.

Still has to check why at 306 kHz an error occurs. These are frequencies beyond my equipment.

[lex27087]

Thank you very much)
I would like to get higher frequencies.
For controlling servomotors.

[hmnijp]

Still has to check why at 306 kHz an error occurs. These are frequencies beyond my equipment.

when I tested - the limit is set to 312500kHz(1/3200E-9) for 40MHz clock and 390625(1/2560E-9)kHz for 50MHz clock.

[lex27087]

@Peter-van-Tol
if your equipment cannot see above frequency.
You can send me corrections and edits.
I'll give you feedback quickly.
Thank you

[Peter-van-Tol]

When using 40 MHz, overflow in the speed register occurs. Sending a value of 0 to the FPGA.

The FPGA uses fixed point math. To determine the location of the decimal point, a value shift is calculated. In this calculation, I forgot that the data range for a signed integer is smaller.

Which version of LitexCNC are you using? In the current version (1.2.4) it actually prohibits you from setting the frequency this high (also a bug, but the effects cancel each other out).

[lex27087]

@Peter-van-Tol
1.2.4

[Peter-van-Tol]

Changing this bug will lead to a required recompilation of the firmware. Otherwise re-installing the driver will cause the stepper to move too slow with respect to the commanded speed if user do update the driver, but not their firmware. Therefore, changing this will be done in the upcoming version 1.3.0. This release is estimated to be available beginning of March.

As an intermediate solution I'm going to cap the frequency on the driver side. Such an error may lead to dangerous situations, how unlikely they are to happen. Capping the frequency is driver side only, so can be safely done. I'll can test this on my own setup.

Proposed solution:

• make maximum frequency a parameter of the config. Users can make a trade-off between resolution and speed.
• this parameter is locked in the firmware and is read during the config-phase.
• the calculation of the shift is removed from the driver.

[lex27087]

compilation is not a problem.
are we waiting for 1.3.0?
I didn’t understand a little what to do.
Thank you

[Peter-van-Tol]

Will make a new version you can test. As soon as finished, I give instructions on how to install. When testing is OK, the branch will be merged and released as 1.3.0. With some luck, you can test tomorrow.

[lex27087]

Thank you very much.

[Peter-van-Tol]

The maximum frequency is now correctly reported in the HAL. The maximum frequency is determined based on the config on the FPGA.

Could you please test whether you can achieve higher speeds with this modification?

To install this version:

pip install git+https://github.com/Peter-van-Tol/LiteX-CNC/issues/87@87-maximum-frequency-375-khz
sudo env "PATH=$PATH" litexcnc install_driver

You have to recompile your firmware and upload it to the card.

[lex27087]

@Peter-van-Tol
Okay, we'll check it out a little later.
Thank you

[lex27087]

@Peter-van-Tol
Do I understand you correctly?
Will the generation frequency depend on the configuration file?
40 MHz
50 MHz
What is the maximum FPGA frequency you can set?

[Peter-van-Tol]

@lex27087:

In the config there are two parameters:

• clockfrequency: this is the frequency of the FPGA. If set too high, timing constraints won't be met. Normally a value between 30 and 50 Mhz is good.
• max_frequency: a new parameter set on the stepgen instances. Default value is 400 kHz. This max frequency is the minimum frequency the stepgen can reach.

The actual frequency depends on the FPGA clock and the scaling. For example: when using a 50 Mhz clock and 400 kHz max frequency, the scale factor is 2^5 and the actual maximum frequency is 790 kHz.

If you want to obtain a specific frequency, you should set the max_frequency parameter in the JSON configuration. So feel free to put it at 750 kHz if you want to. Do not alter the clock of the FPGA, it is not designed for that.

I will add a snippet with an example configuration later.

[lex27087]

@Peter-van-Tol
Everything is fine.
Let's check it out now.
Thank you for answering so quickly.

[Peter-van-Tol]

Just committed some more code:

• timings are now indvidual per stepgen. Making it easy to mix different drivers within a machine
• the maximum frequency of a stepgen channel, as reported in the HAL, is now also dependent on the steplen and stepspace
• warning when stepping too fast is reinstated

The changed module does compile and run my machine. @lex27087 : could you do some more high speed testing. If the system is working, then I will merge this into main.

[Peter-van-Tol]

An example of a stepgen which supports 800 kHz stepping:

{
            "module_type": "stepgen",
            "instances": [
                {
                    "pins" : {
                        "stepgen_type": "step_dir",
                        "step_pin": "j1:1",
                        "dir_pin": "j1:2"
                    },
                    "max_frequency": 800000
                    "soft_stop": true
                },
...
}

[lex27087]

@Peter-van-Tol
I'll definitely check it in a few hours.
It's still late at night.
And I'll check it on an oscilloscope.
We managed to generate 774 kHz.
We haven’t gone any further yet.
When I'm at work, I'll definitely check it at frequencies from 40 to 60.
Thank you

[lex27087]

@Peter-van-Tol
update the same?

pip install git+https://github.com/Peter-van-Tol/LiteX-CNC/issues/87@87-maximum-frequency-375-khz sudo env "PATH=$PATH" litexcnc install_driver

[hmnijp]

I checked commit 35d5607
And these are wonderful changes. I don’t notice any problems with step generation; the frequency ≈<1.5 MHz works fine.

At a higher frequency, you need to select timings more carefully.
Perhaps we should study more about jitter, and frequency constancy in reality. Later I could tweak everything and look at it in more detail by plotting speed graphs from the recorded samples.

Although there are some problems...

here it seems bool and not float?

is max_frequency always a multiple of clock_frequency?

Then I tried timings individual per stepgen instances, but this commit broke step generation)
In hal the timings are different, the driver calculates the speed and receives feedback, but there is no pulse on the physical pins... we missed something, but I don’t have time to look for the error now...

[lex27087]

@Peter-van-Tol

[lex27087]

@Peter-van-Tol
along the signal edges.
here it is not connected directly to fpga.
That's why I think there are distortions.

[lex27087]

@Peter-van-Tol

[Peter-van-Tol]

I think that the modification for the max frequency has been succesful. Thanks for testing. The edges are definitely due to the electric system. Reminds me of my old BOB called 1208. The opto-couplers were so damn slow, you could barely reach 10 kHz step frequency before the signal got lost. Running at 17 MHz step frequency is, let say it honest, insane. What frequency you are going to drive your servos?

@hmnijp : still some work to do to get the individual timings correct. Will look into that!

To answer your question: the clock frequency is always a multiple of the max frequency, because the max frequency is calculated with:

max_frequency = clock_frequency / 2**(shift+1)

The shift is determined so overflow of the velocity command, as sent to the FPGA, will not overflow. With 40 MHz clock frequency and a desired 400 kHz step frequency the shift equals 5. The leads to a theoretical maximum attainable step frequency of 625 kHz. Dividing it once more with a factor 2 would lead to a maximum step frequency then desired 400 kHz.

The practical step frequency is also limited by the steplen and stepspace parameters (both parameters in ns):

max_frequency = 1 / ((stepspace + steplen) * 10e-9)

My setup uses a drive with 5000 ns timing for both stepspace and steplen. This results in a 100 kHz stepping frequency for my stepper (DM422). To optimize the velocity resolution, I can opt to change the max_frequency in my config to 100000 Hz for an optimal system.

[lex27087]

@Peter-van-Tol
Well, the 1.5 m wire most likely plays a role here.
frequencies are high.
For me this is not critical.
500 kHz is enough for me.
thanks for the work you've done.
We are waiting for minor fixes and a new driver 1.3.0

[hmnijp]

Running at 17 MHz step frequency is, let say it honest, insane.

I and another friend have an idea for a simple lathe spindle but with servo step-dir and c-axis mode. (10000ppr)

Previously I thought that this was a hardware limitation of 400e3 hz. The ability to switch analog spindle/step-dir c-axis, or use a mesa 7i92 was suggested, but now I think the 5a-75 can handle this only in step-dir mode. This will be an interesting challenge)

Also, many servos, together with position feedback, require a high frequency. It will never be superfluous.

[lex27087]

@Peter-van-Tol

[Peter-van-Tol]

I just added a commit to this branch which solves the error of the broken stepgen when individual timings are applied. The stepper here was nicely spinning...

@hmnijp : if you can verify that it is also working in your setup, then this issue can be closed and merged into main.

[hmnijp]

no prob, I can check it little later )

[hmnijp]

Hello Peter. I tried to compile the firmware from the latest commit and configured the ini with different timings. gateware has new csr registers, but I still don’t see steps on all channels. The driver also transmits the position and receives feedback, but only Dir changes on the pins...

5a-75b-82-50mhzmaxfreq.zip

Later I tried to reduce the number of stepgens to 4 pieces and remove the remaining modules. This led to the board not being detected via ethernet.
yosys log:
Info: Max frequency for clock '$glbnet$eth_clocks_rx$TRELLIS_IO_IN': 125.23 MHz (PASS at 125.00 MHz)
Info: Max frequency for clock '$glbnet$soc_clkout0': 40.29 MHz (PASS at 40.00 MHz)
I tried several options, but I can't get it to work.

[Peter-van-Tol]

Thank you. Back to the drawing board it is