Hi,
@Mex
Thanks for translating.
Mex píše:
Yes, I understand and confirm.
But - we are on the hobby CNC forum, so we love LinuxCNC, Mach, GRBL and other lower level control systems. And so we love STEP/DIR.
STEP/DIR is simple, everybody knows it, every system supports it ...
So the "market" for servodriver with this simple and problem-free interface is huge.
Thats why we support step/dir. But compared to quadrature it is not problem-free. A single peak on the step line will result in a wrong position.
But most LinuxCNC users i know try to find something better thats cheaper than EtherCAT hardware. And they often have Mesanet hardware laying around.
Other benefits are things like power usage feedback, runtime configuration, informative error messages, ...
As we use the drives our scara robot i want to try stuff like adaptive motion control with realtime force feedback.
GMAN píše:
It is not only about lines going in or out of the inverter, but also power rails should be protected. ...
The 12V rail will be gone. 3.3V and 5V will be clamped.
GMAN píše:
Take a look at hall effect based current sensors from Allegro, they are really good, it has almost no resistance, no inductance and the response is very fast. It is in a compact package and you can connect the output directly to your processor.
We use them on our discrete driver board (prototype, not on github, named troller). Phase current sensing does not really improve our current loop (more noise => lower gain ...). As they are not cheap in small quantities and you need three to cancel out the sensitivity for magnetic fields we will not include them in the "low price" irmax hardware. They will be on the high power discrete version.
GMAN píše:
OK, the timer will keep running, but that will not help you
. Now, imagine that you are controlling a servo motor at high speed and high load. Now your processors stalls and your PWM keeps running, but how? The processor can not change compare register values, the timer will keep running but will not generate rotary field. It will create a static EM field. The running servo definitely won't like it
Your over-current protection will probably kill the power and save the motor and driver.
That's why I'd put there a signal connected to the Enable input, this signal could be controlled from both processors(the F4 will need an optocoupler, but you can use some slow cheap one) and also external enable input, which should be connected to some ESTOP or whatever, so you can make sure that the drive is disabled.
The F4 should kill the power supply within 0.2s. But we think of using a larger SI to get that third redundancy.
We might just kill the 15V rail to disable the drive and reset the F1.
GMAN píše:
I didn't mean flexible high speed IOs, but simple slow optocouplers with classic transistor output. For such signals as Error out, enable in, driver ready etc is no need for high speed. You can find these in a package of four for price lower than 1€. I'd put there a header for expansion card where you can put some high speed IO if you need them. Signals for encoder don't need to be isolated when powered from the inverter.
Error and enable are on the cmd port (v3.3 has 2 I and 1 IO lines, v3.4 will have 4 IOs) and go to the breakout board. In the current v3.4 design i have 3 F4 pins left. I will see what is possible.
A first version of v3.4 should be on github in a few weeks.
GMAN píše:
Current controller implemented in the F1 is a must! You need as responsive current regulators as possible. Try to simulate the behaviour of the inverter when a low inductance motor is connected. It will not work, it will oscillate no matter what you do
I think that the current regulator should be triggered from PWM timer, ideally on the top and bottom(Up Down mode timer), so you can change your PWM duty very quickly.
I have done a lot of calculations and simulations of our control loops. As we have a big motor model we can do much more than you will find in an average motor control book. Our current loop is a PIFF0 with induction compensation. Stuff like deadtime correction and IGBT drop will be reimplemented in the near future.
The bandwdith is about 2kHz max (depends on motor, voltage and amplitude). We are aiming for 3-4kHz with the F1 doing parts of it.
GMAN píše:
That sounds interesting! But isn't it easier to put an ethernet module directly to each inverter and eliminate the need for breakout board? If you have closed network, the timing is pretty good. And if you want something really precise, you can send the data to all nodes and then broadcast a trigger packet to all nodes at once to keep them in sync.
Ne pins free. And our breakout board can do much more than decoding ethernet frames. It is based on the stm32f7 (;
Nice inverter you build there GMAN.
HonzaCh píše:
AFAIK, the IRC is not very popular here, or maybe better it has never gained a big market share in communities like this. Although I used to be involved in IT, I have never used it and I have only minimal info about it.
It is quite popular with the LinuxCNC guys and english retrofitting community. And we use it to stay in contact with most of our users and devs.
Thats why we try to focus discussions and development on IRC and github.
HonzaCh píše:
It would be great if you share your plans on github more publicly. The current todo list consists of items different from what you shared with us here.
I will upload it into our wiki as soon as i find some time to merge all of them and make them readable. I will notify you when it is done.
HonzaCh píše:
According to me, the driver (HV part) deserves an external watchdog forcing the EN/-FAULT pin of the IRAMX driver low on timeout. (Interface to the MCU would be a bonus.)
My idea was to kill the 15V rail. It disables the driver and resets the F1. On v3.4 an st viper06 will generate the 15V from the DC link.
HonzaCh píše:
Unfortunately I'm not an ESD expert either but my heart says add as much of ESD protection as possible (read: a reasonable amount) for working in such a harsh environment (high-voltage high-power switching). Using 3.6V (datasheet max) instead of 3.3V to power the MCU should also provide slightly better noise immunity.
There will be a bunch of st usblc6-4 for the analog stuff and 3.3V rail.
In our tests noise was never a problem.
HonzaCh píše:
I was convinced Hall-effect-based current sensors are relatively slow (~10kHz) -- 120kHz bandwidth found in contemporary Allegro devices sounds really good. There're 3 ADC channels on SV2 which are currently exploited only if the driver is compiled in the TROLLER mode (whatever it means).
We use a 4 channel allegro based PCB for testing. They are quite good sensors but expensive.
Troller is a prototype of a discrete driver with three allegros.
Nico