Build thread, 100 pin STM Arm Cortex board with driver chips.

I've been over in the "beyond the Sanguino" thread, but what I'm working on is gelling, and so, to avoid distractions to those of you still looking at other directions to develop in, I'm putting my progress under this thread heading.

Basically, I have researched the current public reprap motherboards, and decided I want for my first machine, something with more memory, more highly integrated motor control, and more capacity for add on features.

STM do an ARM Cortex-M3 microcontroller in various packages, and I happened to get 20 from my distributor, for what I suspect was quite a good, introductory price.

It's 32/16 bit, and has plenty of grunt. If you run "difficult" code in RAM, it's about twice as fast as in Flash, but even so, it's going to storm past the 8 bit Atmels, it has memory management, and a much faster clock rate, as well as the extra bits for maths ops. From memory, it has a barrel shifter too, so you can do bit shifts of arbitary length.

Where I'm up to, at the start of this thread, is making best use of the available 100 pins.

These are the features I'm incorporating, some of which don't actually have to be populated, if someone has minimal requirements and wants to scrimp on cost:

----------------Essentials:--------------------------
>JTAG programming interface. (I'm not using the trace connections, those are for WIMPS) ><

>USB

>X,Y,Z limits (the ends of an axis are not differentiated)
4'th axis input, it's an analogue input, so it could be connected to a potentiometer.

>Extrusion Heater, PWM. I know it's a luxury to use PWM for such a slow changing device, but it could also be used, for alternate power control where the resolution is more of benefit (i.e. milling motor speed contro etc)

>Extruder head temperature monitoring


>3 x Servo drive, PWM, to reduce the main controller workload.

>8 x stepper motor coil drive enables. (all dedicated PWM)
>16 x Stepper motor wire polarity controls (we get rid of the L297 s this way)
>8 x Coil current monitoring Analogue inputs. (hopefully, this allows us to shut down misbehaving motors before a serious problem develops)

>status piezo, wired to a PWM, so it can play tunes, basically, give a range of audible messages.

>2 x status LEDs. These are also really useful when you want to debug something, pop the LED control into your problem subroutine, and check for action- or not.

----------------Luxuries, need not be populated:--------------------------
+ Extruder cold zone temperature.

+ 3 x LCD control pins + 8 x LCD data pins. Yes, I know about 4 wire data bus mode, and I've written drivers for it before, but some graphics LCDs need 8 data lines, and considering that CNC machines work in at least 2 dimensions, I figure we may want a larger dot matrix display, to preview part "recipes"

+ One analogue pin reserved for push button controls, i.e. , each button pused gives a different feedback voltage. Wait for a stable reading, and take the action.

+ I2C, 2 pins. This is purely for I2C off chip expansion, I'm not intending on board I2C memory. (shudders) We have a PC for that, or an SD card for stand alone mode, or to allow the PC to be switched off while the machine is not being attended, but is left running.

+ 6 x general purpose darlington transistor pull-down outputs (6/7 of ULN2003 package)

+ SD card socket and connections via SPI on 4 dedicated pins.

I'm working on fitting all these in the freeware version of Eagle, so space is limited. The main processor is a fine pitch SMD chip, and it's beyond the capability of non experts to solder by hand. You need considerable experience in hand soldering fine pitch packages to be able to reliably solder one of these by hand, but if there is a lot of interest in this type of board, the practical way to do it, is to order the board with all the difficult chips pre-soldered.

I welcome ideas, and hope to keep this open, but I don't know how feasible it will be to parcel out parts of the project to any other interested people. I can do the whole project by myself, but for a simple implementation, and working only in my spare time, I expect to be busy for at least 3 months before I have interesting results. I may get a bit bogged down in the software initially, because I haven't programmed in C, or on the ARM in assembler before.

These are the steps:

*Selection of chipset.
Microcontroller is the most influential here, I've chosen the one above. For the driver chips, I'm using L298 for 4 x channels of dual full bridge driving. I may put extra pins on the connectors though, so that each plug carries axis limit and motor drive connections. Standardisation is the thing here, use the common large size, and stick with it. The footprint is good, the sustained current is a couple of amps. I'm using the vertical SIL full wave bridge rectifier package for capturing transients, and only in the 1.5 amp size. It's running a low duty cycle.
I will see if it's fast enough... If I "Scope" problems, then I may have to put a transorb across each coil in addition, to clip any nasties that the FWB aren't fast enough to contain.

*Pin assignments.
Done, unless I need to amend anything.

*Draw the schematic. (partially done.)

*Draw the PCB (auto routing in Eagle with SMD packages seems more "problematic" than I've experienced in Protel)

*Check all connections against chip manuals and intended connection paths.

*Order a batch of prototype board to these plans

*Inspect prototype boards for trace, via integrity, check no traces are joined where they shouldn't be
*Assemble and check.

*blink the LEDs.
*write an LCD driver
*get really stuck in, to writing the main software, testing stepper motors, Gcode interpreter, stepper motor control layers, etc, etc.

Graham Daniel.

Hi there grael.

I've thought for a while that instead of grudgingly moving up a single processor size whenever we hit a limit is not the best idea - the non-recoverable expenses aren't too hot. Moving to a nice big ARM will give plenty of elbow room for future development.

I also suggest an RS232 port for debugging work - they have been very very very helpful for me in the past.

Motor drivers:
As you're doing the work, the actual development is up to you, but might I suggest that if you're having space problems you consider moving the motor drive boards onto a sub-board? This will let you keep the high current stuff away from the micro and not risk the expensive main board if you tinker with the motors.

Additionally, you mention suppressing transients coming back from the motors using diode bridges. If you're using PWM at frequencies above a few hundred Hz (and who wouldn't), you need to use fast diodes with low reverse recovery charge or they will get hot and bothered!

Finally, keep the tracks around the motor drivers nice and short - they carry high frequency current from the PWM switching and will act like inductors if they're too long! Decouple power supplies carefully: a 100nF capacitor should be placed across each chip's power rails, plus a 10uF or so next to each L298 to help with the low frequency currents.

Hope this helps.

jbb

Thanks for the advice JBB,

I admit I've only done stepper motor control once before, and that was for an EFTPOS receipt printer I did. I ended up having to place some parallel jumpers on the board, because I'd not allowed enough copper width on some critical lines. The problems were very intermittant glitches, and the jumpers fixed it.

I may have to do some testing, and check suppliers for a faster FWB package in DIL. I suspect it's a big ask. I really like the footprint I have at the moment though, as it's very compact. Regarding putting them on another board... I may have to, but I'm somewhat shocked at the piecemeal approach of the current versions, and I'm trying hard to make it work on one board. Electrically, it's possible, it's more the constraints of working with the free version of Eagle. Else, I may use the very old free version of Protel.

The cost of the driver chips is higher than that of the microcontroller, so I'm not convinced that adding the cost of more connectors and a second board, with mounts is worth it. Once the power outputs are created for a stepper motor, it only needs 4 cores per connector, so it's one of my goals, to reduce overall complexity of the machine.

Graham.

Graham,
I have a few comments for you which I hope will be useful.
1) Instead of eagle, if you have a linux box available, try gEDA. I haven't had much chance to play with it yet, but it seems to be a very full featured, completely free electronics CAD package. It has import capability from a lot of other tools, so you might even be able to pull in the work you've done.

2) Stepper control. I'm finalizing a stepper/BLDC motor controller which has some techniques in it that might work for you. It uses an L293 to drive N+P MOSFET H-Bridge. The only inputs to it are direction control and PWM setpoint current. The cost on it is pretty good. I'm anticipating that it should be cheaper than Zach's stepper controller, but it will allow for microstepping, and up to 5A/phase motors. The down side is it will take a little more space because it is not an integrated solution.

3) Please provide a modular expansion port. I think that most everyone has now agreed that RS-485 is the thing to use. I'd make it full-duplex, with a transmitter enable. I still think that SATA cables are an excellent choice because they come pre-made in lengths up to about one meter, they are very cheap, small, flexible and they have the option of locking connectors. I could also see an argument for using CAT5 cable. Both are designed with twisted pairs. SATA is also shielded.

If you do decide to put an RS-485 modular expansion port (or two) onto your board, your development and mine will be interoperable.

While we do disagree on whether the base build should be capable of doing everything on one board, I think we do agree that interoperability and expansion are nice features. If the cost for that is an optional RS485 driver and a connector, it would seem a shame to lose those possibilities.

4) I think it's a good idea to try to keep the body of your code platform independent. I do this by separating all architecture and chip specific operations into functions which I define in an arch.h/arch.c module. This means that when someone comes to port your code to another microcontroller, all they have to do is rewrite those two files. Everything else should work as planned.

Brendan

Edited 1 time(s). Last edit at 02/02/2009 01:47PM by Annirak.

Hi Annirak/Brendan,

in reply to your items:

1. I also have "PCB", which is free, and runs on Linux. Just checking, it's also known as the gEda that you mention. I had a bit of a play on it about 2 years back, but haven't actually built a board with it. Worth another look at though, as I may need the extra footprint space to properly incorporate the high speed freewheeling motor diodes.

2. I've used the L293D before on the printer I designed.(inbuilt diode version) I don't think the L298 are much more expensive, but they are double the current, and it's nice to have more, rather than less, than you actually need. I was thinking that for serious power, to have an add-on board that has the NPN high, PNP low configuration with load sharing resistor from the tied bases to the tied emitters. It's an easy circuit, and would need the diodes too. I have some limited stock of the L293D, but I think my machine will need a bit more current than they can supply. Not a bad choice though if they are just there to give current boost and prevent driving a high and low at the same time, on the same side of a winding (smoke rising...)

3.I agree about the modular expansion port, but I'm doing RS485, which is 2 wire, not RS422, which is 4. The practicalities of using RS422 to best advantage, involve making your software take advantage of duplex coms via interrupt, and dual buffers. Generally, you don't need a lot of traffic both ways at any given time, it's more like:
TX:"Z axis: coordinates over next 10 mS",RX:"yes" TX:"extruder: profile for next 10 mS",RX:"yes", TX:"Fan set speed to n",RX:"yes",TX:"all channels: synch"...(repeat)

Mostly, the traffic is one way, and once you make an expansion module with local intelligence, you have the power to set remote abstract tasks, rather than just having a bigger address bus.

Where that might differ, is if you have a sensing head, which is reading a lot of high resolution data. I believe though, that it's easy to buffer moves ahead, and use global synchronisation.
The other good thing about RS485, is that it can run in your proposed SATA leads, AND share with power, just like a SATA drive.

4. I think without working for the same company, under one dictator overseer, it's hard to get everyone following the same rules. I did find though, in my 4'th year of business, I was starting to make my code much more modular, and so I didn't have the same need to debug sections that had previously worked, when writing new code. I'll keep what you said in mind, but I have some catchup to do in C yet anyway, if I don't code it in ASM !
I do tend to seperate my code out into a lot of different function modules already.

Graham.

Edited 1 time(s). Last edit at 02/02/2009 11:40PM by grael.

grael Wrote:
-------------------------------------------------------
> 2. I've used the L293D before on the printer I
> designed.(inbuilt diode version) I don't think the
> L298 are much more expensive, but they are double
> the current, and it's nice to have more, rather
> than less, than you actually need. I was thinking
> that for serious power, to have an add-on board
> that has the NPN high, PNP low configuration with
> load sharing resistor from the tied bases to the
> tied emitters. It's an easy circuit, and would
> need the diodes too. I have some limited stock of
> the L293D, but I think my machine will need a bit
> more current than they can supply. Not a bad
> choice though if they are just there to give
> current boost and prevent driving a high and low
> at the same time, on the same side of a winding
> (smoke rising...)

The L298 is over double the price of the L293. My plan is to use the L293 as a MOSFET driver.

>
> 3.I agree about the modular expansion port, but
> I'm doing RS485, which is 2 wire, not RS422, which
> is 4.
It's not that simple. RS-485 specifies a bus in which both sides use transmitter enables, and can therefore be more than a point-to-point connection. RS-422 specifies a bus with always-on transceivers. This difference makes it possible for RS-485 to be run in half-duplex mode, but it doesn't guarantee that it must be.

There is a full duplex version of RS-485. But this is not the point. The point is that using half-duplex is limiting for no good reason. There's very limited benefit to insisting on a half-duplex physical layer. The protocol can still be half-duplex even if the physical layer is full duplex. In fact, this is the case with SATA.
> The other good thing about RS485, is that it can
> run in your proposed SATA leads, AND share with
> power, just like a SATA drive.

SATA drives DO NOT run power and data on the same cable, and the cables are not built to handle enough current to make that practical, so let's drop that idea before it even gets started.

> 4. I think without working for the same company,
> under one dictator overseer, it's hard to get
> everyone following the same rules. I did find
> though, in my 4'th year of business, I was
> starting to make my code much more modular, and so
> I didn't have the same need to debug sections that
> had previously worked, when writing new code. I'll
> keep what you said in mind, but I have some
> catchup to do in C yet anyway, if I don't code it
> in ASM !
> I do tend to seperate my code out into a lot of
> different function modules already.

That is absolutely not true. Why do you think that PC's took over the market? It's because a standards body said "if you want to play nice with all the other hardware, you have to adhere to this specification" and everyone did. More than that, you have the Linux kernel, where thousands of people all around the world have written code that works together without much of a specification at all.


Brendan

Annirak Wrote:
> The L298 is over double the price of the L293. My
> plan is to use the L293 as a MOSFET driver.

[parts.digikey.com]
[search.digikey.com]
Surprisingly, the higher current chip, is actually cheaper, even in the multiwatt package ! (I'm keeping the L298)

> It's not that simple. RS-485 specifies a bus in
> which both sides use transmitter enables, and can
> therefore be more than a point-to-point
> connection. RS-422 specifies a bus with always-on
> transceivers. This difference makes it possible
> for RS-485 to be run in half-duplex mode, but it
> doesn't guarantee that it must be.
OK, I've read up on it after you wrote that, and I see now that you're right.

> There is a full duplex version of RS-485. But
> this is not the point. The point is that using
> half-duplex is limiting for no good reason.
> There's very limited benefit to insisting on a
> half-duplex physical layer. The protocol can
> still be half-duplex even if the physical layer is
> full duplex. In fact, this is the case with
> SATA.

The "good reason", as stated, is simplicity. I haven't checked out cost comparisons, but RS485 2-wire is also far more common in my experience. I think when first introduced, a lot of the system designers shared your views. However, there was still a shift to half duplex comms. Why ? I think the reasons I expressed previously explain, but I'll try to sum it up again, a little differently:

*Typical* RS485 communications are of an unbalanced volumetric nature: Usually, there is only one master, and the master either spends most of it's time listening, or most of it's time talking. Also, as I wrote earlier, it's perfectly possible to buffer serial data, and synch globally. It's more likely that we would run into a bottle neck that required a baud rate increase to solve, than that we would run into a problem that full duplex comms alone was able to solve.

If speed is that much of an issue, then the other ways of dealing to it would be:
1) go parallel (use enable signals per tool head, but share control/data signals)
2) electrical rotary or linear contact set, mechanical tool swapping, with general purpose contacts that align with currently rotated tool head.
3) More I/O:
I'm hoping to make my LCD port available as a CPLD expansion route too.
I can use an enable signal, low for the LCD, high for the CPLD. Once the CPLD enable is active, all the LCD signals would become available to the CPLD, allowing 8 bit wide bidirectional transfers, and CPLD register select, read/write of CPLD pins, and operation of custom CPLD functions. I'm having another crack at PCB/GEDA, so space won't be a problem.

> SATA drives DO NOT run power and data on the same
> cable, and the cables are not built to handle
> enough current to make that practical, so let's
> drop that idea before it even gets started.

OK, I have SATA all wrong.
It appears to contain 2 x signal pairs well suited to full duplex RS485, as you say, and with 3 spare cores. Certainly, I agree, they wouldn't handle an "extra low voltage" element for extruder heating, but there are other options in which two of the cores might well be rated to carry the current.

> That is absolutely not true. Why do you think
> that PC's took over the market? It's because a
> standards body said "if you want to play nice with
> all the other hardware, you have to adhere to this
> specification" and everyone did. More than that,
> you have the Linux kernel, where thousands of
> people all around the world have written code that
> works together without much of a specification at
> all.
> Brendan

It's about the success of a modular approach, be that DOS/Windows(Microsoft) for an OS, 8088 backwards compatible successors(Intel) for computer microprocessors, or modularity of software, such that major functions, of different types, can be used according to general rule sets.

The case in point:
You want full duplex RS485 so you have the option of full speed transmissions in the other direction, simultaneously.
My argument, transmission in either one direction or the other, is typically underused anyway, and that full duplex is not a cost effective method of increasing communications speed.

Given that each of us believes ourself to be right, a joint project would now stall, or further split direction, and development efforts. Alternatively, provision is made for both, to satisfy both our egos, and the project wears the financial cost of that ego soothing, in the form of additional hardware/jumpers/connectors.

Graham

grael Wrote:
-------------------------------------------------------
> Annirak Wrote:
> > The L298 is over double the price of the L293.
> My
> > plan is to use the L293 as a MOSFET driver.
>
> [parts.digikey.com]-
> p-4ch-w-diodes-16-dip-l293d.html
> [search.digikey.com]
> ll?Detail&name=497-1395-5-ND
> Surprisingly, the higher current chip, is actually
> cheaper, even in the multiwatt package ! (I'm
> keeping the L298)

You missed the other one: [www.digikey.com]

> > There's very limited benefit to insisting on a
> > half-duplex physical layer. The protocol can
> > still be half-duplex even if the physical layer
> is
> > full duplex. In fact, this is the case with
> > SATA.
>
> The "good reason", as stated, is simplicity. I
> haven't checked out cost comparisons, but RS485
> 2-wire is also far more common in my experience. I
> think when first introduced, a lot of the system
> designers shared your views. However, there was
> still a shift to half duplex comms. Why ? I think
> the reasons I expressed previously explain, but
> I'll try to sum it up again, a little
> differently:

Let me put it to you another way, there are three points you need to consider:
1) Half-duplex protocols are more complex. All the nodes on the bus must implement collision detection and arbitration. In a half duplex bus, the protocol is much simpler.

2) If you have a full duplex comms bus where the master has one side dedicated to it, no slave can ever take over the bus. The master can always transmit when it needs to. This is important for timing, as the master can send a sync packet while a slave is transmitting. This is not the case in a half-duplex bus. There, the master must wait until the bus is free before it can sync.

3) If we use SATA cables, we have a free pair. I fail to see the difference in cost.

> > SATA drives DO NOT run power and data on the
> same
> > cable, and the cables are not built to handle
> > enough current to make that practical, so let's
> > drop that idea before it even gets started.
>
> OK, I have SATA all wrong.
> It appears to contain 2 x signal pairs well suited
> to full duplex RS485, as you say, and with 3 spare
> cores. Certainly, I agree, they wouldn't handle an
> "extra low voltage" element for extruder heating,
> but there are other options in which two of the
> cores might well be rated to carry the current.

I still wouldn't try to run more than about 100mA on those pairs.

> Given that each of us believes ourself to be
> right, a joint project would now stall, or further
> split direction, and development efforts.
> Alternatively, provision is made for both, to
> satisfy both our egos, and the project wears the
> financial cost of that ego soothing, in the form
> of additional hardware/jumpers/connectors.

Don't try to talk to me about my ego. That just weakens your argument by implying that you need to resort to name calling.

Lets talk about our two design perspectives from the point of view of relative merit, not ego.

Woah there... lets not get personal.

On the RS485: Annirak has a good point - you need tight timing on some of the master -> slave communications. Remember the RepRap gen 1 electronics had a synch line?

This isn't about bandwidth, it's about predictable timing, which is essential if we want to keep the build quality up. Going to a two lane connection will indeed increase the cost a little bit but it gives you deterministic master->slave timing. You can still bus up 31 slaves if you want, you'll just have to carry 5 wires instead of 3 (including earth).

To keep the signal quality up we'll need termination resistors at both ends of the RS485 bus. I suggest that each board should have two headers / sockets on it which are straight through connections and that these resistors should be mounted on a dummy plug like the old coax computer networks were.

On the SATA cable: they do come prebuilt and all and should have nice AC characteristics, but I'm not sure they'll thank you for subjecting them to repeated mechanical cycling. Only one thing to do: build it, test it, keep a spare cable by the RepRap. Good old stranded Cat 5 network cable is also great for this kind of thing and probably cheaper.

jbb

jbb,
CAT5 is definitely viable for this job, but it doesn't bend nearly as well. It might take the repeated mechanical cycling better, however.

Brendan

Annirak Wrote:
> Don't try to talk to me about my ego. That just
> weakens your argument by implying that you need to
> resort to name calling.

I have to call you out on this one Brendan:
Your words: "Don't try to talk to me about"...
Please avoid the "don't try to" phrase in this context, it's a personal attack, rather than on topic argument.
In case it's not perfectly clear, "try to" (in this context) implies that the person is trying something that they are not competent to do.

We are both human, we both have egos. I suspect, by now, that other visitors to this thread have found it rather hard not to observe them.

> Lets talk about our two design perspectives from
> the point of view of relative merit, not ego.

My parents used to live on a lighthouse station. Communications, were by letter, fortnightly. They were surprised at the amount of useful revision that could be done, on subjects initially warranting great passion.

It's correct to say that you and I are both passionate about our own views on development.

I'm not persuaded to your view yet.
*I still think that half duplex allows synchronisation just fine,
*I recognise the advantages of full duplex, but I think they are inconsequential in this application, as there are far more effective ways to ensure fast, synchronised response times. My idea of a CPLD expansion port as an alternate function of the LCD interface, for example, allows for a much better degree of synchronisation and rapid response, than either full duplex, or baud rate increase on RS485.

There are many many ways to implement a CPLD expansion, a simple one such as that I outlined in my above post, or, for example, one in which the CPLD is directly attached to the LCD, and to the uC, but where the LCD has no direct connection to the uC.
In such an implementation, the uC reads or writes registers in the CPLD, and can make state changes to switch which external device is being controlled. I've done this before, with a 68HC11, using the CPLD to respond to certain addresses on the micro, to perform bank select functions

*The L293D package incorporates protection diodes, but is only rated to 0.6 amps constant.

The issue here, is that I'm trying to build a machine that can potentially serve something like 95% of reprapper's typical needs.

I can see you have good ideas for alternative output stages, but I'm concerned that the L298N package, rated at 1 amp continous, (with heatsinking), is not going to meet the vast majority's needs. I know your mosfet expansion is meant to overcome this, but I'm trying to standardise at a higher unamplified power rating to make something that's less likely to need a boost board in the first place. That, to me, is worth the cost difference between an L298 versus an L293N.

I've glanced at your schematic for a toolhead controller, and I can see you have a time investment in doing things the way you've already decided on. There are going to be standisation issues if the main board only does full, or only does half duplex, and people want to design slave boards to the other standard. I don't have that particular investment in time, butt you have a conservative bias (conservation of your current design work's hours of effort, and/or personal investment of PCB costs)

On the other hand, I have these 20 x STM32FVBT103 chips sitting in my stock, and otherwise, I might be looking more seriously at other variants. We all have biases, and admitting, disclosing our biases to others, allows better understanding of other's motives, and more agreeable co-development effort.
------------------------------------------------------------------------------
JBB:
Synchronisation on half duplex should still be a global process, i.e. "Calling all devices, sync NOW", in which case the remaining issue is whether each device knows what it's tasks are, until it's next update moment. I suspect the operation of multiple toolheads concurrently is not going to complicate matters much, as the x, y & z axis are bound to a single working platform, and so the data transmitted is going to be of minimal complexity. I did have a lot of extra features from the standard reprap already assigned to the uC in this project... for example PWM outputs that could be utilised for servo motor valve control.

There comes a point, where trying to do everything with one machine, becomes counter productive, and it's better to have another machine, more specialised, for the additional tasks. I'm not trying to make something here that does CNC, extrusion, EDM, AND makes coffee !
Graham


Edited 1 time(s). Last edit at 02/05/2009 06:28AM by grael.

Re: CPLD extension of the base circuit board:

As a sample of what you can do with a CPLD, have a look at this AHDL code I wrote about 6 years back, it interfaced a 68HC11 to a battery backed SRAM and a realtime clock, with an arrangement that allowed for a big chunk of main memory, and two page registers to give access to the rest of a chip would otherwise have been out of the 68HC11's address space:
--------------------------------------------
Title "GDsample";



subdesign GDsample--Address map:

--0000-3f7f=unchanged

--0480-04ff=FPGA control window:



--0480-04BF=Window#1, applies: 2000-3fff, last 6 bits select 8 K page within 512k byte range

--04C0-04DF=Window#2, applies: C000-CFFF, last 5 bits select 4 K page within 128k byte range (low)



--04F8-output pin 1 =GND

--04F9-output pin 1 =VCC



--04FA-output pin 2 =GND

--04FB-output pin 2 =VCC



--3FFC --> write protect top 32k

--04FD --> allow writes to top 32k

--04FE --> write protect top 32k



--2000-3fff=Window#1, 16 K page within 512k byte range

--8000-bfff=unchanged

--C000-CFFF=Window#2, last 5 bits select 4 K page within 128k byte range (low)

--d000-ffff=unchanged



--last locations of external SRAM (7FFFFh-7FFF0h) are automatically diverted to access the SRAM /

--RTC controller chip, which also temporarily disables SRAM I/O.

(

AddrIn[15..0] : input; -- microprocessor address port

Eclk : input; -- sync address latching.

Read : input; -- Rd/Write HC11 output.

Rst : input; -- clr registers



AddrOut[18..12] : output; -- synthesised extra 3 address lines + remapped 4 to RAM

_Oe : output; -- Read inverted, drives /OE - output enable signal.

_We : output; -- /WE - /Write enable, masked areas.

Out1 : output; -- spare

Out2 : output; -- spare



)

variable

LoBank[5..0] : DFF; --8 k chunks

HiBank[4..0] : DFF; --4 k chunks

RamNRom : node; --upper area write lockout option.

OutN1 : node;

OutN2 : node;



begin

---RamNRom.CLRN=Rst; -- default lockout

LoBank[5..0].CLRN=Rst; --reset at all zeros

HiBank[4..0].CLRN=Rst; --reset at all zeros



LoBank[5..0].D=AddrIn[5..0]; --connection path, addr to #1 window latch

HiBank[4..0].D=AddrIn[4..0]; --connection path, addr to #2 window latch



Out1=OutN1;

Out2=OutN2;



if Rst==GND then

RamNRom=GND;

end if;



_Oe=!(Read and Eclk);



If (AddrIn[15] == B"1") & (RamNRom==gnd) then

_We=Vcc; --lock mode

ELSE

_We=!(!Read & Eclk); --unlocked mode

END IF;





IF (AddrIn[15..7] == (H"04",B"1")) & !Read then -- FPGA register address, low order 7 bits set action.

CASE AddrIn[6..0] IS

--RAM lockout control above $7FFF on HC11 bus:

WHEN B"1111110" => -- lock

RamNRom=gnd;

WHEN B"1111101" => -- unlock

RamNRom=vcc;

WHEN B"1111100" => -- lock

RamNRom=gnd;

--Spare outputs:

WHEN B"111100x" => -- Output pin #1

OutN1=AddrIn[0];

WHEN B"111101x" => -- Output pin #2

OutN2=AddrIn[0];

--Low bank select write:

WHEN B"0xxxxxx" => -- Window#1, 4000-7fff

LoBank[].CLK=Eclk;

--High bank select write:

WHEN B"10xxxxx" => -- Window#2, C000-CFFF

HiBank[].CLK=Eclk;

END CASE;

END IF;



CASE AddrIn[15..12] IS

WHEN B"001x" => --Substitute bank @ window#1 2000-3FFF

AddrOut[18..12] = (LoBank[5..0],AddrIn[12]);

WHEN B"1000" => --Substitute bank @ window#2 C000-CFFF

AddrOut[18..12] = (B"00",HiBank[4..0]);

WHEN OTHERS => -- feed through AddrIn[15..12]

AddrOut[18..12] = (B"000",AddrIn[15..12]); -- first block of 64k bytes

END CASE;



end;
--------------------------------------------

Now if I were to do a design for a CNC machine add on, there could be options like Servo PWM outputs, shaft encoders, with readable registers, stepper motor position registers, they are really very flexible devices.

> I'm not persuaded to your view yet.
> *I still think that half duplex allows
> synchronisation just fine,
> *I recognise the advantages of full duplex, but I
> think they are inconsequential in this
> application, as there are far more effective ways
> to ensure fast, synchronised response times. My
> idea of a CPLD expansion port as an alternate
> function of the LCD interface, for example, allows
> for a much better degree of synchronisation and
> rapid response, than either full duplex, or baud
> rate increase on RS485.

I appreciate that you said "yet." You still haven't addressed two issues with half-duplex communication.

1) Collision detection/arbitration. How do you propose to address these issues with deterministic timing?

2) The master wants to transmit a sync packet, but there is a slave transmitting a data packet (for example, a mouse sensor has the option of transmitting a pixel-by-pixel image of what the sensor currently sees. This is 484 1-byte pixels, for ~512 byte packet. That's quite a big wait time for a sync packet. So do we interrupt the data packet? If so, what does that look like? If not, how do we guarantee a sync packet with guaranteed timing?


> There are many many ways to implement a CPLD
> expansion, a simple one such as that I outlined in
> my above post, or, for example, one in which the
> CPLD is directly attached to the LCD, and to the
> uC, but where the LCD has no direct connection to
> the uC.
> In such an implementation, the uC reads or writes
> registers in the CPLD, and can make state changes
> to switch which external device is being
> controlled. I've done this before, with a 68HC11,
> using the CPLD to respond to certain addresses on
> the micro, to perform bank select functions

These are really easy to implement, I agree. I have made quite a few CPLD interfaces for the ISA bus (It's still used a lot in the embedded computing industry. See PC/104).

I agree that CPLD's allow easy building of extra peripherals. The concern which has been brought up before is that not many people can either a) write HDL code, or b) debug HDL code.

> *The L293D package incorporates protection diodes,
> but is only rated to 0.6 amps constant.

Use whatever works for you. I would suggest, though, that you consider driving FETs instead of buying an expensive integrated FET driver. Check out my stepper driver thread for more information on how that works.

> The issue here, is that I'm trying to build a
> machine that can potentially serve something like
> 95% of reprapper's typical needs.
>
> I can see you have good ideas for alternative
> output stages, but I'm concerned that the L298N
> package, rated at 1 amp continous, (with
> heatsinking), is not going to meet the vast
> majority's needs. I know your mosfet expansion is
> meant to overcome this, but I'm trying to
> standardise at a higher unamplified power rating
> to make something that's less likely to need a
> boost board in the first place. That, to me, is
> worth the cost difference between an L298 versus
> an L293N.

The point was that it doesn't take much to drive a FET instead of a whole package. For the same price as the L298, you can drive four H-bridges at 5 A each.

> I've glanced at your schematic for a toolhead
> controller, and I can see you have a time
> investment in doing things the way you've already
> decided on. There are going to be standisation
> issues if the main board only does full, or only
> does half duplex, and people want to design slave
> boards to the other standard. I don't have that
> particular investment in time, butt you have a
> conservative bias (conservation of your current
> design work's hours of effort, and/or personal
> investment of PCB costs)

Frankly, I don't care about my time investment. I'm planning to make some changes to it already. I simply care that we make the right design decisions.

> On the other hand, I have these 20 x STM32FVBT103
> chips sitting in my stock, and otherwise, I might
> be looking more seriously at other variants. We
> all have biases, and admitting, disclosing our
> biases to others, allows better understanding of
> other's motives, and more agreeable co-development
> effort.

I understand your decision. I might even make the same one in your situation. It probably won't make a big difference in the long run. Maybe your next gen will be different.

I think the important point is that we decide on an interface standard. Once we've got this full duplex vs. half duplex argument settled, we can move on to the messaging protocol.

I often control motors, etc, over serial buses, RS485 usually. I always use half duplex and a master slave protocol. Each transaction is a command from the master and a response from the slave. For synchronisation I use broadcasts with no response. Simple and effective.

---

[www.hydraraptor.blogspot.com]

nophead: Is there a good reason to not use full duplex?

Yes more expensive drivers, more wires, more software complexity.

I really don't see any advantage to full duplex. You still can only have one slave talk at a time so you would have contention issues unless slaves only reply when asked by the master in which case how do make use of the duplex?

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> Yes more expensive drivers, more wires, more
> software complexity.

The wires aren't really an issue. CAT-5E is perfect for the job and has plenty of wires to carry both limited power and full duplex data. Software complexity isn't an issue: you don't have to make the logical link full duplex unless you need it to be. The drivers are not particularly more expensive.

Here are two equivalent transceivers, both supporting over 2.5Mbps, both from digikey, within $0.10 of each other. What is our budget for transceivers? Is $1.15 ok? (Maxim's 1k unit quantity for both of these)

fdx: [search.digikey.com]
hdx: [search.digikey.com]

> I really don't see any advantage to full duplex.
> You still can only have one slave talk at a time
> so you would have contention issues unless slaves
> only reply when asked by the master in which case
> how do make use of the duplex?

Here's what I envision: The master sends a command and, optionally data. The slave queues data to be returned. The master can then poll the slave for status information, and wait for the "command processing" bit to go low. When the master sends a command releasing the data, the slave transmits it back to the master.

This may seem like a complex way to handle the process, but there are a few advantages to doing it this way.

If the process in question is a complex process that takes time to execute, then the bus is released between the master transmission and the slave transmission, and other communication can take place. There are other ways to work around this, for each complex command, you write three commands: one to start a process, one to check the status of the process, and one to retrieve the data. I think this is simpler if it's in the protocol.

Commands to any slave can be sent out while data is being read back from any slave. This is particularly useful in the case of sync.

I never use anything so complex. All my commands return a reply quickly. The reply is either just an acknowledge or the data returned by the command.

If a command starts a slow process then yes, I have a second command to poll for the result.

I usually use slew rate limited drivers like these [www.analog.com] so that termination is not required for cables that are only a metre or two long. I have never needed more than 250Kb though. At these low baud rates even with full speed drivers the reflections have died down long before the UART samples the bit but the ringing is not nice from an EMC point of view.

For the data connection I would just twist some 7x0.2mm wires in a drill and use a two pin 0.1" connector. I can't see the fascination with bulky cat5 cables and connectors.

---

[www.hydraraptor.blogspot.com]

I don't know where to go on this. The price difference on the physical layer is sub-dollar. The coding difference is minimal, provided that a framed communication protocol is in use. I know we don't need a high baud rate, but it would provide for better timing. Of course, increasing the baud rate also means that half-duplex is more doable.

I know why you're against CAT-5. I don't like its bulk either, but it does provide for cheap cabling, cheap connectors, high-frequency data, and power. I don't know what its flex lifetime is like.

Given how much argument there is just over the use of half vs. full duplex communication, I'm not sure that I'm prepared for the time investment required to define a communication standard in this forum. I was trying to keep my electronics well defined and compatible with what other people are developing in parallel to me. Maybe it's time to take the genetic approach to the problem, lay out my system the way I want it without any regard for what anyone else is doing and see which system withstands the trial by fire.


Now is it time to pack up my bat and go home, nophead?

Well there never has been any agreement about the electronics. There are as many designs as there are electronics engineers, plus a few more.

Zach's 3rd attempt uses half duplex RS485 so if you want any compatibility that might be an argument against full duplex but I suppose you could just connect the two pairs together to get half duplex.

I don't think there is ever any point in trying to reach a consensus in these forums or in the core team, it never happens. I soon learnt to just go my own way and blog the results. Things that are successful sometimes get adopted by others but never electronics or firmware. Odd because those are the skills I bring to the project.

---

[www.hydraraptor.blogspot.com]

Well, I think I know what I'm going to do.

I'm going to write my protocol so that it can support fdx, but test it out completely in hdx. I'm going to maintain fdx cabling capability and use CAT-5E, mainly because of the existence of good connectors and widely available, cheap cabling.

I suggest that we use the green pair as the hdx communication pair.

Annirak Wrote:
> 1) Collision detection/arbitration. How do you
> propose to address these issues with deterministic
> timing?

Sample cases:
*Scanning head closely coupled with the z-axis in order to maintain a set height above the target surface. In such a case, the scanning head sends back information to raise or lower the z axis. The main controller board handles absolute position, so the raise/lower information is minimal bandwidth.
*Mouse optical sensor, as you suggest. I think you are going to be doing a custom serial interface to present this data, either that, or accept an OEM variant that is incompatible with any variant of RS485 AND sitting on a bus with other devices.
If you do your own variant, then keep in mind, that while a static view can usefully be 2-D, once you are moving the platform, you become more interested in changes, and the changes are defined most usefully by the minimum amount of data required to cover the whole viewable surface of the object. Put simply, you don't need to re-sense data that has already been recorded, and so, suppose you are moving in the x axis, you only need y axis information. If you are wanting to do some sort of binocular vision to obtain 3-D information, then you will need more grunt on the processing end, and it's probably wise to use a processor with off chip memory. In that case, the data path to the CNC control mainboard becomes less critical anyway, you could even run a small USB camera with fast aquisition times, and run your control software in a PC or even one of the embedded PCs that some manufacturers are selling as development kits. Linux will run on some of these.

>
> 2) The master wants to transmit a sync packet, but
> there is a slave transmitting a data packet (for
> example, a mouse sensor has the option of
> transmitting a pixel-by-pixel image of what the
> sensor currently sees. This is 484 1-byte pixels,
> for ~512 byte packet. That's quite a big wait
> time for a sync packet. So do we interrupt the
> data packet? If so, what does that look like? If
> not, how do we guarantee a sync packet with
> guaranteed timing?

Assuming you have the required bandwidth, you have to buffer the data sufficiently that you can "burst" it between the gaps in main board transmission.

Which ever is deemed to be in charge for the current usage case, there are plenty of ways to ensure collisions don't occur.

> I agree that CPLD's allow easy building of extra
> peripherals. The concern which has been brought
> up before is that not many people can either a)
> write HDL code, or b) debug HDL code.
>
That's why I want to make it available as an optional extra function of the external LCD interface. LCDs commonly come in 4 bit and 8 bit data paths, with mostly compatible control signals. So, those who aren't inclined to develop in an HDL format, aren't carrying the cost of it's implementation for others on the same board. So, there's huge flexibility in this !

> > *The L293D package incorporates protection
> diodes,
> > but is only rated to 0.6 amps constant.
>
> Use whatever works for you. I would suggest,
> though, that you consider driving FETs instead of
> buying an expensive integrated FET driver. Check

I'm not much interested in an expensive integrated FET driver either.
But, I think a lot of people are able to get away with a lower current integrated driver, and wouldn't need the mosfets, so long as the capacity of the standard board insufficient for their standard applications.

The question is, how much current do you need, to cover most people's applications ?

And then when 5 amps isn't enough either ?

> The point was that it doesn't take much to drive a
> FET instead of a whole package. For the same
> price as the L298, you can drive four H-bridges at
> 5 A each.
Have you factored in the L298N and the bigger PCB, and the bigger Build Of Materials list as well ?

Having been in business for myself previously, and doing procurement, and assembley all myself... I like to have a smaller BOM.

> I understand your decision. I might even make the
> same one in your situation. It probably won't
> make a big difference in the long run. Maybe your
> next gen will be different.

I think it is important to fully establish our priorities of the moment, and to take a peek into the future too. I hate designing with obsolete parts to someone else's spec.

>
> I think the important point is that we decide on
> an interface standard. Once we've got this full
> duplex vs. half duplex argument settled, we can
> move on to the messaging protocol.

I suspect the messaging protocol is going to be different for each application of the unit. For "EDM"?, you probably want extra care on data integrity, due to the very high ambient electrical noise, to error protection, CRCs, redundant data may be called for, AND lower data rates. For a machine vision head... higher speed, and/or local processing. For multiple heads, broadcast data transmission of common data. For routing... none required, unless part of a multiple tool head, same for extrusion, the board has enough grunt already.

-----------------------------------------------------------------------

Nophead:
You said Zach's third generation is using half duplex RS485,
Would you be able to summarise the features he's incorporating ?
Factors of interest to me, being how much would be duplication of what I'm intending on the mainboard? and how much utility there would be in the standalone functionality ?

If others like Zach's approach on these 3'rd generation RS485 modules, then I'm all for incorporating compatibility at my end.

It's not a nice position to be put in, to develop something really cool, but to find it's been obsoleted already, by factors outside one's own control.

I think Annirak has some great ideas, I just hope that he can see them as achievable on half duplex RS485, you know my position on that. It would be a shame to have that being the whole sticking point on integration on a whole new generation of reprap~ish CNC/deposition machines.
------------------------------------------------------------------------------

Graham.

grael Wrote:
> I think Annirak has some great ideas, I just hope
> that he can see them as achievable on half duplex
> RS485, you know my position on that. It would be a
> shame to have that being the whole sticking point
> on integration on a whole new generation of
> reprap~ish CNC/deposition machines.
> --------------------------------------------------

I'm not so arrogant as to say my way or the highway on a cabling spec. I see a lot of people with a lot of background supporting the hdx version in their hardware, so I'll let that be. My modules will work in hdx.

Have you gotten around to thinking about a communication spec yet? I've been working on one which I'll be posting up later for comments. It is a framed format, but it's low overhead. I'm aiming for a 4-byte header, with optional checksums.

Annirak Wrote:
> I'm not so arrogant as to say my way or the
> highway on a cabling spec. I see a lot of people
> with a lot of background supporting the hdx
> version in their hardware, so I'll let that be.
> My modules will work in hdx.

Thanks !

>
> Have you gotten around to thinking about a
> communication spec yet? I've been working on one
> which I'll be posting up later for comments. It
> is a framed format, but it's low overhead. I'm
> aiming for a 4-byte header, with optional
> checksums.

No, I haven't got that far at all. I have some experience, but I find each application works well with a different approach. I think the different applications we are envisaging are going to make that a possibility here too. Some of the add on possibilities simply aren't meant to work together anyway.. as I see it. The XYZ axis are a common positioning element, and to try a lot of other things at the same time would potentially duplicate something that already does the job, albeit in a serial positioning manner.

So, you may find that we are working in different communication modes, and even speeds too, if there is an electrically noisy EDM head in action.

At the moment, I'm more focussed on the hardware of the main board, and I'm putting together missing parts for the PCB-geda library, on the basis that I will have a bigger PCB than what can fit in the free version of Eagle.

CAN is almost useful... except I don't think anyone does the all in one dual H-bridge + micro chips in small quantities. I could probably convince a distributor to give me some samples... but I don't think ongoing small quantities are likely.

I saw on your tool head thread that even 2 amps is marginal for some of the reprappers (stepper current), so I still think that it's a starting figure. BUT... I may have to put in links for the high voltage supply to each dual FWB chip to allow off PCB power options.

Update:

I had thought that the serial bootloader for the STM32F series microcontrollers was a user programmed function, but in re-reading parts of the 504 page user manual, I've found that it's in system (read only) memory. As such, I am intending to drop the JTAG functions that previously occupied 5 pins.

In terms of an amateur builder, the advantage is no requirement for a JTAG programming interface. However, I now need to implement an RS232 port on those uC pins, which I had previously designated as servo #2 and #3

I've reallocated the resources, and now have the following:
* An RS232 boot loader port, which will also be available for debugging or other purposes after initialisation.
* an extra channel for servo control (total 4)
* Dedicated CPLD enable and irq signals. (this should speed the throughput of any programmable gate array interfacing via the LCD control and data path)

The JTAG has irked me, it's OK for a business situation, where there is volume and the justification for a dedicated programmer, but for the non-PCB person, it's a diabolical irritation.

I mentioned PCB geda before, I got confused I've migrated to kicad. It has some minor annoyances, but so far it's going reasonably well. I've figured out how to do multiple sheet schematics, and I'm busy giving pins global labels, and hooking up hardware. I have the stepper drivers on one sheet, similiar setup to the reprap version at:
[flickr.com]
However, less connectors, no L297 and less PCB space will be required due to the higher integration.

I think it's been a nice feature on those boards for people to be able to set the motor current with a potentiometer, but I'm not replicating it as such. My intention is that motor current will be via a PC front end program and/or the keyboard+LCD interface.

I would like to find a cheap source of polyswitch fuses at approx 2 amp rating, otherwise it's more likely that people will fry the L298 chips.
New Zealand would be good for me.

We have a local supplier (NZ)
[nz.farnell.com]
But I've previously sourced many components at much cheaper prices than there. They are a bit like a Euro version of Digikey.

For anybody looking to extend via the CPLD interface though, you WILL need a JTAG programmer.
!UNLESS! anyone wants to volunteer a setup to program CPLDs via the intended uC-CPLD interface, via file transfer from a PC, to the uC, to the CPLD. I'm thinking to dump that one in the "too hard basket", I don't think the usage of the feature would justify the extra development time.

Graham.

Graham

Just run the SPI port to the JTAG port of the CPLD. Xilinx has a tool that converts a programming sequence to a series of vectors. Then we just convert the playxsvf tool to run on your arm, over SPI.

Annirak Wrote:
-------------------------------------------------------
> Just run the SPI port to the JTAG port of the
> CPLD. Xilinx has a tool that converts a
> programming sequence to a series of vectors. Then
> we just convert the playxsvf tool to run on your
> arm, over SPI.

Thanks for that idea, I hadn't thought of JTAG as SPI, but I suppose it's compatible ?
I could probably use the SD card SPI port for that purpose.

If we make the provision that the CPLD may ONLY be configured when the SD card is absent, then it's a matter of controlling the boot mode of the CPLD,

Signals:
Clock
Data in
Data out
TMS = "JTAG state machine"

I've done a PCB with a CPLD and a Micro some years before, I used the Altera byteblaster cable to program that up, with a dedicated connector on the PCB

Do you know what has to be done with the JTAG interface signals after the device is programmed ?
I think I have to do a jumper disconnect of the clock line from the gate array, and take it low though.

Looking at the Altera data, it looks like you can pull TCLK low and the chip will go independent, I think TMS has to stay high then, but not sure...
[www.altera.com] (end of page #6)

So, I'm thinking a jumper on the clock output, to select either the CPLD, or the SD card. If a FPGA was used, and users were willing to wait for the configuration period, then config could be done either from attached PC, or from the STM32 flash memory.

The STM32 has a memory management unit on it, I'll have to check through the sheets, to see what the implications are, of meddling with usage of the NSS signal, that would be either connected to the JTAG, or the SDcard chip select.

Graham

This is just the stepper motor part of the schematic. The global labels (a dingy tan colour) tie in to microcontroller pins on the main sheet, which I'm still working on.

(c) 2008 Graham Daniel, Released under the terms of the GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html)
(re:attached steppers.pdf file)
This is the configuration I'm using for the stepper motor control, for each motor:
4 x control pins
2 x enable pins (1 per coil)
2 x analogue feedback pins
2 x sense resistors
2 x polyswitch fuses, or resistors can be used instead.


So, 32 pins, for 4 x dual full bridge driving.

Lucky I picked a microcontroller with lots !

The idea, is that 3 x channels are for x,y & z axis, with one spare for a stepper motor to drive the extruder. I don't know the torgue requirement, but stepper motors can have very high torque if you select the ones with small step size.

Graham

Latest news,
Have been working on schematic only slowly.

I've dropped the ULN2003.
I included 3 x MOSFET high current outputs, for use in heaters, CNC mill driving etc.

I've made a couple of the pins that were previously ULN2003 transistor driver outputs, general I/O, with their own connectors.

I incorporated a RS232 with flow control, for bootstrap code loading, and for general purposes. Also, I have USB.

As well as the alternate/additional function to the LCD interface of CPLD extension, I will have 4 pins available for programming the CPLD, but only available via jumper, as an alternate function of the SDcard port.

RS485 is available, in half duplex mode.

A basic reprap mechanical device ought to be able to be run off this board with considerable non-populated areas:

* LCD, buttons, SD CARD, CPLD, RS485, I2C aren't "must have" items
The 4'th complete axis electronics AND the 3 x power MOSFETs aren't BOTH required in a minimal implementation, but they make some more complex operations a lot easier, if required in any given implementation.


Graham.

Some progress finally.




I have dropped the onboard SD card capability, I found very little standardisation between footprints for the sockets, I have, however, included a 10 pin connector for connecting a custom memory interface onto. There's also I2C.

Once I got some time in at KiCad, I've actually found it pretty good. As with other packages, there are some quirks, and it sometimes pays to manually edit the net and brd files, for example I'd named 12v in oneplace, and StepperPwr in another, and it wouldn't let me join the nets until I edited the brd file with a search and replace of all the StepperPwr instances.

The board is pretty big, about 4/5 each way, of the dimensions of a piece of A4 paper.

I manually routed the tracks, and it was pretty close in several areas, I've only just completed the manual routing, so now all the rats nest is converted over.

KiCad draws the PCB wires and vias with a surround outline set at a clearance value, so you can see your clearances, but it also refuses to complete tracks if you drive over another net on the same side, or too close to a track or via.

I had several grouped functions, i.e. servo motor control plugs, power drive MOSFETS, Stepper drive, LCD etc, so I built up each in their own area, and then moved them as blocks until my confidence in routability got lower.

I haven't edited the 3D shapes in KiCad, but it still gives some idea of what the board looks like.


I'll be rechecking is for correctness, and at some stage I'll get some PCBs made up, most of the initial tracks were laid on the component side, to reduce the via (and holes) count, many manufacturers charge more for more holes.

I've also not put any fills on yet, they can reduce RF output, and sensitivity also, and cut down on noise on the PCB, but I used to do a lot of Protel designs, and the fills were extremely tiresome to undo if wrong, without a saved version of the original.

Edited 1 time(s). Last edit at 03/28/2009 07:05AM by grael.