[katti]

I am planning to use BLDC servo motors with EMC2.
The BLDC controllet itself has some microcontroller
doing the controll task.

Easiest way may be just do stepper step/dir emulation and connect it
to printer port but then we are loosing most of servo advantages.

Other way is just emulate DC-servo amplifier and connect it with
analog interface to some proprietary DC-servo interface board and
then connect encoder to same board and use existing DC-servo HAL drivers.

This looks just too much extra complexity just unecessary converting
the motor command to analog and back to digital and all other
side efects come with it and of cource extra price of DC-servo
board.

I had in my mind idea that the inner servo loop can be moved to the
microcontroller so that the microcontroller runs this 20Khz PID loop
and reads the encoder. It just gets the 1Khz positioning commands
from PC and returns encoder position. For this speed USB isochronous
or Ethernet can be used.

There is still possibility to also run the inner 20Khz loop in ENC2 and
then use 100Mbit/s ethernet to send 20K command packets to controller.

Then there is third, more complex and expensive solution that is
still better than analog conversion. Make FPGA based PCI board
using www.opencores.org PCI core, implement encoder input and
SPI output for motor command. So, replacing DA->AD just simple
SPI. There is also possibility still interface encoder to microcontroller
and then use same SPI to read encoder position back.

Ethernet, USB and SPI all needs to have new HAL driver.
I have experience of linux kernel and driver writting but
not yet any HAL experience.

Katti

[Xerxes]

Monolithic control for drives is a tempting idea, I would want one too. Some time ago I was planning to make drives that could share single RS-232 line for position controlling and feedback. It would be very cheap and might perform well. PC serial ports have FIFO buffers that could produce very steady command timing even on non-RT system.

However, the real bottlenecks of machine accuracy or performance typically lie in some other place than PC<->drive communication.

[katti]

Monolithic control for drives is a tempting idea, I would want one too. Some time ago I was planning to make drives that could share single RS-232 line for position controlling and feedback. It would be very cheap and might perform well. PC serial ports have FIFO buffers that could produce very steady command timing even on non-RT system.

However, the real bottlenecks of machine accuracy or performance typically lie in some other place than PC<->drive communication.

Serialport at 115200 can transfer 10 characters in 1ms position controll cyckle.
That is too little even inner controll loop is implemented by microcontroller.

Isochoronous transferin USB or 100Mbit Ethernet can offer 100..1000times performance and still price tag in 5..10Euro ( Some AT91SAM7 series chip).
If you are not using SAM7 for actual BLDC, you can as example use
SAM7 to communicate with PC and send commands via SPI to
motorcontroller chips.

I agree that The PC-Drive communication is not the bottleneck but at the
moment it looks alike to be last link in chain missing because there is
not yet any kind of communication method expect step/dir etc out
from EMC2/HAL.

It is not even so hard to write i am familiar Linux driver coding and RTOS
but not yet HAL internals.

Katti

[andy55]

Then there is third, more complex and expensive solution that is
still better than analog conversion. Make FPGA based PCI board
using www.opencores.org PCI core, implement encoder input and
SPI output for motor command. So, replacing DA->AD just simple
SPI. There is also possibility still interface encoder to microcontroller
and then use same SPI to read encoder position back.

this would be the most interesting option I think.

There's an FPGA card sold by mesa electronics (www.mesanet.com) called "5I20 FPGA based PCI Anything I/O card " which sells for $199.
It has a 200kgate FPGA and 72 general purpose I/O pins
It will probably be hard to come to this price range for a DIY design - or it would require production of 100s of boards.

There's an FPGA configuration for the 5i20 that has an EMC2 driver. it's called HOSTMOT-4. It provides 4 "analog" outputs and up to 8 encoder counters + about 24+16 bit general purpose I/O.

the "analog" output for controlling a motor consists of a direction pin and a PWM output pin.

The FPGA code in VHDL format is opensource and can be found in the EMC2 CVS.

I emailed the guy who works at Mesa electronics who wrote the fpga configuration and he confirmed that they had also tried direct control of BLDC or 3-phase AC motors with the FPGA.

One problem is that direct control requires lots and lots of pins. For 3-phase H-bridge driver you need 6 outputs. Then something for detecting the phase currents etc.

Still, I think it would be a nice way to do motor control. Have all the "smart" bits of the control in FPGA/VHDL meaning they can be reconfigured anytime someone finds a way to improve the code.
The power electronics would be "dumb" powerstages + current sensing amplifiers (IR2175 provides current sensing with PWM output, suitable for a digital-input-only solution).

If I would be competent in VHDL I would probably pursue this option further right away but unfortunately I think I don't have time to learn VHDL right now...

I understand the Xilinx compiler needed to compile the VHDL for the FPGA is available freely from Xilinx.

AW

PS. At work we have national instruments FPGA cards which can be programmed with LabView - soo much easier than VHDL. Well they cost about 3-5k /card + software ....

[katti]

this would be the most interesting option I think.

There's an FPGA card sold by mesa electronics (www.mesanet.com) called "5I20 FPGA based PCI Anything I/O card " which sells for $199.
It has a 200kgate FPGA and 72 general purpose I/O pins
It will probably be hard to come to this price range for a DIY design - or it would require production of 100s of boards.

Producing comercial assembled, tested ready boards are expensive.
For just hobby you can order 2-layer 100x160 board based on Eagle CAD
files from www.olimex.com in single quantities $33

Of cource in hobby you don't count price for assembling and design.

One thing that i don't like in Mesa board is that it uses Paralax PLX9030
for PCI and i prefer using open cores PCI implementation directly
for PCI. I have used the opencores PCI with Xilinx Spartan 2 PCI
evaluation board andit is good and versatile block.

For hobby board the 208 Pin QFP Spartan-IIE XC2S200E in dual layes
board will be good choice.

There's an FPGA configuration for the 5i20 that has an EMC2 driver. it's called HOSTMOT-4. It provides 4 "analog" outputs and up to 8 encoder counters + about 24+16 bit general purpose I/O.

the "analog" output for controlling a motor consists of a direction pin and a PWM output pin.

The FPGA code in VHDL format is opensource and can be found in the EMC2 CVS.

This FPGA VHDL code can beused for BLDC also just sending command out
with SPI to microcontroller instead of doing PWM.

I emailed the guy who works at Mesa electronics who wrote the fpga configuration and he confirmed that they had also tried direct control of BLDC or 3-phase AC motors with the FPGA.

One problem is that direct control requires lots and lots of pins. For 3-phase H-bridge driver you need 6 outputs. Then something for detecting the phase currents etc.

I have had same thing in my mind. As addition of pins, it needs a lot of
macrosels if you try to make it switching phases using encoder or back-ENF
sensing ( sensorles). The HAL sensor based can be done much easier.

Still, I think it would be a nice way to do motor control. Have all the "smart" bits of the control in FPGA/VHDL meaning they can be reconfigured anytime someone finds a way to improve the code.
The power electronics would be "dumb" powerstages + current sensing amplifiers (IR2175 provides current sensing with PWM output, suitable for a digital-input-only solution).

If I would be competent in VHDL I would probably pursue this option further right away but unfortunately I think I don't have time to learn VHDL right now...

I understand the Xilinx compiler needed to compile the VHDL for the FPGA is available freely from Xilinx.

AW

Replasing microcontoller with FPGA in sensorless BLDC controll will need
alotofmacrocells or then using expensive FPGA that has internal CPU core
like some Xiling ones has PPC core. These high end FPGA's are also
PGA that requires expensive multilayer board and special assembly
equipments.

So,at the moment i think that cheaper FPGA in QFP and chep microcontroller
is cost optimumin hobby quantities.

The xilinx low end tools are freely downloadable. I have used them directly
compile Opencores PCI.

Katti

[Xerxes]

Serialport at 115200 can transfer 10 characters in 1ms position controll cyckle.
That is too little even inner controll loop is implemented by microcontroller.

My current protocol uses 32 bit commands. That would equal 2880 Hz command rate at 115.2 kbps. If there were 16 bit commands too, it would be possible to command 5 drives on single 115.2 kbps line at little over 1 kHz command rate.

Andy, you really don't want to do everything on PC. It could even be bit dangerous since failure would mean uncontrolled power stage.

[Xerxes]

One could implement lots of serial interfaces with that Mesa card, 1 for each drive. Or just get enough RS-232 ports to rule them all.

[katti]

My current protocol uses 32 bit commands. That would equal 2880 Hz command rate at 115.2 kbps. If there were 16 bit commands too, it would be possible to command 5 drives on single 115.2 kbps line at little over 1 kHz command rate.

You need also have least checksum or something equivalen+least one character
resync pause between frames. Also, still you will get more laency than
USB or Ethernet.

Still, it looks a like that there is needed some command-channel HAL driver for EMC
that sends out velosity or position command via some command interface ( Ethernet, USB
or even Serial ). It looks a like that there is none yet in EMC2.

Having this kind of command channel block in EMC allows then expanding
system with multiple diferent ways.

May be i should look inside some "stepgen" module, take all stepgen code
out and istead send packet out by Linux network interface. Network just
because it is easiest way to implement and test. Then may be put same driver
in other PC, just receiving packets and driving them to stepgen.

When it works, then the other end can be implemented by microcontroller
and other transport layers ( USB, Serial can be implemented )

Katti

[katti]

One could implement lots of serial interfaces with that Mesa card, 1 for each drive. Or just get enough RS-232 ports to rule them all.

These multi-port serial boards just are not cheap at all. USB or ethernet
can be implemented with 10Euro components and with 100 lines of C,
i know, i have done it many times. At the moment my AD-converter sensor
box for Nokia 770 uses Atmel AT91SAM7S USB and Uart emulation. Uart emulation
allows to use normal Uart api in user programs but is not limited by
any uart speed limits. I think that this Uart emulation is enough for
1Khw command channel but if someone likes to get 20Khz channel, then
isochronous mode is needed.

Some other places i have used some other microcontroller like MPC555
with ethernet chip. If i would do it again, i would use SAM7X chip.

Katti

[unterhaus]

unfortunately, usb isn't suitable for feedback control because the spec has massive latency built into it.

If the feedback control loop is just being fed commands over USB, it will work. Ethernet is probably better. People also use firewire, because it doesn't have the latency.

Anyone that has written kernel drivers should be able to write hal drivers with no problems.

[Xerxes]

There are cheap serial port cards as well. I guess couple of these would do the job:
http://www.usbgear.com/1x-Serial-PCI.html

The default trajectory planner and PID period in EMC is 0.001 seconds (1 kHz) so I guess it is sufficient update rate for motion control. 20 kHz is used only in motor torque regulation loop, not position loop. There is no point of running 20 kHz position loop when mechanical bandwidth of machine may be under 100 Hz.

[andy55]

May be i should look inside some "stepgen" module, take all stepgen code out and istead send packet out by Linux network interface. Network just because it is easiest way to implement and test. Then may be put same driver in other PC, just receiving packets and driving them to stepgen.
Katti

That's a good idea. You should write down what you want to do and send it to one of the emc mailing lists. There are lots of experienced people there who might have valuable things to comment and suggest.

what kind of hardware is needed in the servodrive end to be able to receive and transmit on ethernet (I'm guessing UDP packets?)

would it requre one network card per motion axis, or could many axes share one network port ? (100/1000 MBit hub in-between ?)

[tbyrd0918]

I'm using Mach3 with ncPod, but as you know it's Windows based. What is available for EMC2 for USB, Firewire, Ethernet, etc. (par is obsolete) that will give me enuf for 6 axis and a good handful of IO for tool changing? ncPod is fast enuf for my apps but limits the number of available IO pins.

T. Byrd

[andy55]

There is nothing for USB/FireWire/Ethernet as far as I know. The problem with USB is latency, I don't know about FireWire/Ethernet.

A lot of people are using the Mesa M5i20 (www.mesanet.com). It's a PCI card so you'll need a desktop computer (not a laptop).

It's FPGA based so you can configure how many pins you use for motion control and how many for I/O. With the 4-axis setup you get two sets of 16-in 8-out I/O.
If you need 6-axis then you can use the 8-axis FPGA config and that will leave you with one set of 16-in and 8-out I/O.

AW

[Coyote73]

I dont know if I understood well, but I think that EMC2 uses all cards like servo-to-go,mesa,.. in the same manner. That is that FPGA doesnt run PID at all, only counters are true real-time. PID loops are calculated in EMCMOT routine in rt-linux. This gives a compatibility of choosing different motion boards, which in fact become a I/O board with high speed counters. If you indend to use FPGA to compute PID you should make new code for FPGA and for EMC2.
The best way would be to have a servo driver with standard communications protocol and let do the driver all necessary regulation loops. EMC2 could only work the trajectory and send servos position setpoints. A normal USB or ethernet communication would not be the best, since TCP, UDP cannot be used as real-time communication. There exists SERCOS III protocol, it is very similar to ethernet (hardware layer) but its real-time isochronous communication, build for servo communication.
It would be great if someone could write drivers to use a some standard communication board (sercos, profibus, devicenet,..) to use with EMC2.