I apologise for forwarding this to the list but my email to you bounced...
Subject: Re: 5i20 step generators, and other goodies On Thu, 15 Feb 2007 [EMAIL PROTECTED] wrote: > Date: Thu, 15 Feb 2007 19:33:30 +0000 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: 5i20 step generators, and other goodies > > Hi Peter: > > I'm one of the EMC developers, and one of the folks who bought 5i20 boards > back in December. I would like to work with you on HAL support for the > 5i20, both for the existing configurations, and for future even more > flexible variations. > > At present, EMC has a driver (by PeteV) that supports a single configuration. > That one config is stored as part of the EMC source code, in both VHDL and > binery form - binary because most people don't have the Xilinx software > installed, and even if they do, the translation from VHDL to bitfile is NOT > something you want to do every time you build the software. > > I don't know if you are at all familiar with EMC's HAL (Hardware Abstraction > Layer). It is basically a block oriented way to put together realtime > control systems, which may or may not include actual hardware blocks. For > example, we have software based step generators and encoder counters, which > can easily be replaced in a particular system configuration with the hardware > versions for higher count rates, etc. We also have a lot of blocks that are > software only, such as PID loops, summers, muxes, and other math/logic > blocks. > There are a couple of very complex blocks as well: EMC's motion controller is > implemented as a large HAL block, and we have a version of the ClassicLadder > software based PLC that is a realtime HAL block. If you would like to know > more, see http://www.linuxcnc.org/docs/HAL_Documentation.pdf, especially > chapters 1 and 2. (Chapter 6, section 6.5 documents the existing HAL driver > for the 5i20.) If you are totally unfamiliar with HAL, some of this email > may be a little confusing, but I'll be happy to explain further if needed. > > In general, a HAL driver for any hardware device "exports" HAL pins, > paremeters, and functions as appropriate for the device. For example, the > 5i20 driver exports HAL pins for each encoder and DAC channel. Then the > user can connect HAL signals to those pins in software. The ultimate HAL > driver for a multi-function and reconfigurable hardware device like the 5i20 > should be able to discover the available I/O functionality and export the > appropriate HAL items automatically. If you load an FPGA config that has > 4 encoder counter, three step generators, and 8 dacs, the driver should > export a matching set of HAL pins, parameters, and functions. > > One way to do that is to have a single value in some register that identifies > the configuration. Then the driver looks that value up in a hard-coded table > and exports the appropriate stuff. But that approach limits you to configs > that are in the table. My long term goal is to come up with something that > is more flexible. > > I want the casual user to be able to pick from several pre-built configs, > which can be done using the lookup table approach. But I also want a more > sophisticated user who has the Xilinx software installed to be able to build > a custom config. > > Ideally they would edit only the top level VHDL file, to say "give me four > step/dir, siz encoder counters, two interleaved PWM (for DACs), three > triangle wave based PWMs, four serial ADCs, one 32-bit serial I/O port > (for a shift register based I/O expander), and 12 general purpose I/O". > > Assuming that they can fit (place and route) all that stuff, I'd like the > HAL driver to be able to "discover" what they have and export the needed > items without re-writing the driver or adding yet another entry to some > lookup table. > > That capability requires a framework: On the VHDL side, a bus interface > and address decode unit that can easily be expanded, standard conventions > about what blocks will be at which addresses, and the low-level VHDL > implementations for each kind of block. On the software side, the driver > needs to be able to read a standard register or registers to find out what > blocks (and how many of each) are in the configuration. > If you have some suggested structure, I could use a couple of the currently unused block RAMs to create a hardware capability descriptor. In Spartan 2, 2 block RAMS (out of 14) will give you a 256x32 memory. This can be a ROM... > I suspect that you already have most of the neccessary framework in place, > although it isn't neccessarily documented well enough to let us build a > completely self-discovering driver. Certainly the addition of your new > step pulse generator is a great step forward (although I have some issues > with the FIFO concept, as I mentioned in my meail to the users list). I > have a few other blocks that I'd like to add: I can make a non buffered step gen, maybe tommorow (real work intrudes unfortunately). I would probably use a larger DDS (maybe 48 -64 bits) where the step pulse is taken from bit 31 and the upper bits get you a step count. Because this DDS would free run and DIR -> STEP setup time could not be guaranteed (it can be guaranteed in the buffered case by tweaking the rates) I would have to add a post processor to buffer the step outputs (accumulate in dead time after a direction change and decumulate at some maximum step rate after dir change dead time) > > PWM with deadtime (separate high and low transistor drive signals) > > Triangle based PWM with deadtime (for a three phase bridge, triangle > based PWM gives half the motor ripple current compared to sawtooth PWM > with the same switching frequency and switching loss) We already do that in our SoftDMC PWMs(triangle), for driving 3 phase (7I39), no deadtime since we need minimum signals and the bridge does it by itself. Triangle would just be an option in the PWM reference counter. Ill think about dead zone... > > Serial ADC interface (12 bits or better, multi-KHz sample rate, multiple > channels, either one after another, or with one data line per channel > and a common clock and strobe line) SPI, should have that done soon > > Serial I/O expander (from your last email to the list it sounds like you > already have such a thing) Working on it (24 ins 24 1A outs all isolated 10Mb/S SPI, watchdog option for all off on communication timeout) Also can use differential SPI for longer distance. > > Many of those requirements come from my own CNC project. (Slow progress > visible here: http://jmkasunich.dyndns.org/cgi-bin/blosxom/index.html) > The basic machine is pretty simple, but once it is working I intend to > build a three phase AC motor drive for the spindle motors, using the > 5i20 for PWM generation and I/O, and HAL blocks (existing plua a few > new ones) for the actual field oriented motor control. > > I have the 5i20 boards (one for my CNC project, one installed in my > development system). I have the Xilinx webpack software installed. I'm > new to VHDL (the last time I did FPGA work was in the mid-90's and we > used shematic capture) but I learn fairly fast. I'm very familiar with > HAL (I'm the original architect of HAL). I'm familiar with DDS, serial > ADCs, and other hardware stuff (I'm a hardware engineer in real life, > I only do software at home). I have the power electronics experience > (I design 400-1000HP 480V drives for a living). The main thing I lack > at this point is time - my progress tends to be sporadic. At the moment > I'm trying to get the machine running before I dive into FPGA work. I > know full well that when I do start on the FPGA, I'll find it far more > interesting than wiring up steppers, so if I don't do the steppers first > I'll be in trouble. > > Sorry, I'm rambling... Back to the reason for this email: > I'd like to establish a dialog with you to make sure I reinvent as little > of the wheel as possible, and to ensure that your new configurations > work well with EMC. I also hope that the HAL concept and the 5i20 HAL > driver might prove usefull to your non-EMC customers. Sure. Sounds good. > > Regards, > > John Kasunich > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
