Comments on the DRO-350

For over a year, Scott Shumate has displayed the following doomsday comment regarding the DRO-350 on his web site (Shumatech.com).

"WARNING!!! The DRO-350 is an old design that uses obsolete parts. The DRO-350 has a number of problems including scale jitter, rounding errors, and axes that won't display. These problems will not be fixed and all future development activity will concentrate on the DPU-550 and DRO-550. The DRO-550 completely solves all of these problems and adds a huge list of new features."

With over 6 years to solve these problems (2003-2009) one might wonder why, with basically the same circuitry, the DRO-550 is providing a miraculous solution to this problems.

At Wildhorse Innovations we have had many inquiries regarding the dire warnings and extreme statements contained in that post. This blog post is an attempt to bring to light the true status and nature of the the DRO-350. Whenever opinions are expressed in this post, they will be clearly labeled as such. However, even the opinions are not lacking in facts. They are based upon over 40 years of experience in the field of electronics and an earnest effort has been made to exclude personal prejudices from the opinions stated.

"The DRO-350 is an old design": True. The DRO-350 was originally designed around 2003 and not much has changed in the meantime. It was, and is, a stable well designed DRO for use with what are commonly referred to as "Chinese" scales. The DRO-350 is so well designed that the most critical portions of the design are DIRECTLY imported into the DRO-550 (the scale interfaces and the AUX/TACH interfaces). A side by side comparison of the schematics of the DRO-350 and the DRO-550 will show that the primary differences occur in the power supply section (providing 3.3vdc for the MPU) and the various additional interfaces added. It might be noted that many of the "New" interfaces are non-functional because no software has been developed for them.


"WARNING!!! The DRO-350 is an old design that uses obsolete parts.": Partly True. To paraphrase the infamous words of President Bill Clinton, "It depends on the meaning of obselete.". Have you ever gone to an auto parts store with a part number only to discover that the part has been superseded by a new part? Is your old part "number" obselete? Yes. Is there a new part that bolts in place, performs the same function and allows you car to function in exactly the same manner as with the "old" part? Yes.

So it is with electronics. Manufacturers will change part numbers for a number of reasons. Over the past dozen or so years, EPA regulations and the ECM's ROHS standards have forced manufacturers to redesign parts to eliminate what have been deemed hazardous substances. Some manufacturers have merely made minor changes to parts to meet the new regulations and stuck an additional prefix or suffix on the part number. Others have taken the opportunity to increase the overall functionality of the part and relabeled the part with a totally new part number.

So what is the bottom line for the DRO-350. ALL PARTS FOR THE DRO-350 ARE CURRENTLY IN PRODUCTION. Have part numbers changed? Yes. But we at Wildhorse Innovations continue to provide our customers with all necessary cross-references so you can readily identify any parts on which the identifying numbers have changed.

"The DRO-350 has a number of problems including scale jitter": This issue has been a thorn in the side of "Chinese" scales since day one. Little, if any of the problem can be solved in the design of the DRO-350 (or the DRO-550) or the software. The problem lies in several areas.

First, the "Chinese" scales are not really designed to be used with a remote head (the DRO-350 or DRO-550). They are not designed to use an external power supply. They are designed to receive their power from the 1.5vdc "button" batteries that are inserted into them.

Second, the "Chinese" scales determine "position" by measuring the varying capacitance that is present between the scale readout and the rail as the readout moves along the scale.

These conditions make up the bulk of the jitter issue.

When we provide the power for the scale from an "outside" source (such as the DRO-350), we are sending this power through a rather lengthy cable which is subject to all manner of EMF influences. Couple that with the fact that the power transmitted through the cable is VERY low (1.5vdc at a few milliamps) and you have a perfect formula for disturbing influences from outside EMF. As mentioned above, the circuitry in the scale readout is "expecting" to receive rather stable power from a battery mounted just a fraction of an inch away. The circuitry is not designed to cope with the possibility of fluctuating supply voltages.

Another influence on the jitter issue is that the "Chinese" scales determine position by measuring the capacitance between the readout (sliding portion of the scale) and the scale rail. Obviously anything that influences that capacitance will alter the scale reading and introduce jitter. These influences can include improper grounding of the scales (or creating ground loops), introducing vibration into the scale as the machine is running or ANY source of EMF acting upon the scale itself or the cables connecting the scale to the DRO head.

There have been many "solutions" to the jitter issue. (Any belief that the jitter issue was solved with the DRO-550 is quickly disspelled by a quick perusal of the ShumaTech forum.) Some have involved leaving the battery in the scale. Some involve installing capacitors in the battery compartment of the scale. At Wildhorse Innovations we have found the following steps solve 99% of the jitter problem.

1. Keep cable runs as short as possible.
2. Route the cables inside the DRO-350 case in areas away from the display section of the PCB.
3. If using shielded cable, ground the shield ONLY at the scale end of the cable.
4. Route cables so as to avoid EMF interference. NEVER run scale cables parallel to high voltage cables. Also, NEVER run scale cables parallel to stepper motor cables.
5. Most scale head bodies are connected to the negative side of the power supply. When mounting the scales, insulate the bodies from the machine. Failure to properly insulate the scale head bodies can result in ground loops.
6. Mount the scales to the machine so as to minimize the transmission of vibration from the machine to the scale.

"rounding errors": True. You carry your calculations past 5-6 decimal points, the DRO-350 has rounding problems. So you guys that are working with tolerances in the 0.00001" range probably need a different DRO.

"axes that won't display": To be honest, we at Wildhorse Innovations have never seen this problem in a standard DRO-350. We have seen it in DRO-350 with DPU-550 daughter boards, but it is rare and since the DPU-550 is no longer produced, it appears to be a non-issue for the new purchaser.

"These problems will not be fixed": Easy solution Scott. Release the source of for the DRO-350 as Open-Source. Let the market place find the solutions. There is a new drop in replacement for the PIC16F MPU used in the DRO-350 (the PIC18F) that has over 3-1/2 times the memory of the PIC16F and an improved, more powerful instruction set. It costs only about $1.00 more than the PIC16F, so any increase in cost of the DRO-350 would be minimal. Additionally, since it is a literal drop in replacement, every DRO-350 in existance could be upgraded for under $15.00.

"The DRO-550 completely solves all of these problems": Sorry, but to be blunt, this is a total falsehood. I'm not saying the DRO-550 does not have it's up side, but 10 minutes on the ShumaTech forum will show that the DRO-550 has its share of problems and solutions are sometimes slow in coming. Scott has a stranglehold on the software and it almost seems that if it is not Scott's idea, it doesn't make it into the code. And after over 2 years, we have yet to reach release 1.0.

"and adds a huge list of new features.": Absolutely true! And if they are features you need/want and are willing to pay for, then there is no reason to not purchase a DRO-550 (when you can find one). The ability to mix and match different protocols is a hugh advantage for those that need it. (Did we mention that this same feature could be an upgrade to the DRO-350 if Scott were to release the source code?) And the advertized features that don't yet work will be a real plus when they go live. I'm sure target dates will be announced soon.

Now for an opinion. The DRO-550 is a throw away board. By this I mean, when something goes wrong, (borrowing from "Ghost Busters") "Who ya gonna call?". The DRO-550 is a 4 layer, surface mount board. If you look at the repair services, only the most expensive multilayer SMT boards are repaired. It's time consuming, requires special equipment and expensive to repair these types of boards. Plus, with the small number of DRO-550 boards produced, no repair house can afford to set up the "line" and train personnel to repair the small number of repairs that would come in. But when it's your board that needs repair, one is not a "small" number.

We get emails virtually every week asking about repairs for the DRO-550. The only advise we can give is "buy a new board".

This is not Scott's fault. But he could set up an exchange program to ease the pain for the customer. Yes, he will most likely junk the old board, but at least he has acknowledged the value of the customer for having purchased the DRO-550 in the first place.

BOTTOM LINE:

The DRO-350 is alive and well. It's a workable, inexpensive solution for the home machinist on a budget. Wildhorse Innovations is dedicated to supporting it for as long as possible, which we expect to be years into the future.

When used with the "Chinese" scales, it's a bargain. When used with quadrature scales, including the Igaging scales, the DRO-550 is probably a better buy, until and unless, Scott will release the source code for the DRO-350. We can then produce a low cost upgrade. It won't be a DRO-550, but it will meet the needs of many customers.

As usual your comments are welcome. Visit us at http://www.wildhorse-innovations.com.

A Redesign of the DRO-350/DPU-550 Case

Let me begin by stating that the comments and analysis contained herein are in noway a critism of the original design for the DRO-350 case. At the time that case was designed, the DPU-550 was not even a dream. But my experience with the DPU-550 has convinced be that a redesign of the DRO-350/DPU-550 case is in order.

The construction of the DRO-350/DPU-550 differs from a "Plain Jane" DRO-350 in several ways.

First, there can be up to four Aux/Tach/Edge inputs. The DRO-350 has only one. Next, although not a change, the DB-9 connector, although changing from a connector for the JDM programmer to a connector for a true RS-232 connection, still occupies "real estate" on the case.

We then add the capability to increase the number of possible scale (Mini-Din) inputs from 3 to 5. Then we have added the openings for the USB connector and the programming switch. And of course, we have to have the power jack.

The additional openings unto themselves would not be a particular problem if we still had all the room that is available inside the "Plain Jane" DRO-350 case. But the DPU-550 occupies space inside the case and restricts the potential locations for the additional openings. Plus, the position of the USB and Programming Switch openings are dictated by the location of these components on the DPU-550.

The instructions on the ShumaTech web site assume that a DPU-550 is being added to an existing DRO-350, and that the original DRO-350 case will be retained. If shows the locations for the USB and Programming Switch openings, but makes no suggestions for the expansion allowed by a DPU-550 Full daughter board.

I have taken the approach that rather than dealing with an upgrade to an existing DRO-350, we are building a DRO-350/DPU-550 from the ground up. Variations of my design can be used to expand the capabilities of the original DRO-350 case when upgrading to a DPU-550.

The primary driving force behind my belief that a redesign was in order, was the crowding of the scale input cables that occurs beneath the DPU-550 daughter board. Because of the location and orientation of the X, Y and Z input connectors on the DRO-350 processor board, coupled with the placement of the openings for the Mini-Din connectors along the bottom edge of the rear of the case, it is difficult to route the scale cables away from the area of the LED displays. Although there has been debate on whether moving the scale cables away from the LED displays and the associated circuitry, reduces jitter, there has been no evidence that routing the scale cables away from that area presents any problems in the operation of the DRO-350 or DRO-350/DPU-550. So my design errs on the side of caution.

The photo above shows the new design with three scale connector openings located over the keypad area of the DRO-350 processor board and two Aux/Tach/Edge connector openings along the top rear of the case. This design allows for easier routing of the scale cables away from display area of the DRO-350 processor board and the higher frequency (40 mhz) ARM7 MPU on the DPU-550 daughter board.  The power receptacle remains in approximately the same location.  Also seen are the openings for the USB connector and the programming switch.

 

The next photo shows the rear case cover from the inside. Visible in this photo are the pilot holes and reliefs milled for the purpose of expanding the number of scales and/or Aux/Tach/Edge connectors. These additional openings can be created with a simple drill and utility knife. Cases delivered without the RS-232 DB-9 opening also have this opening outlined and piloted.

(Please excuse the lack of clarity in these photos.)

The Aux/Tach/Edge connectors delivered with the Wildhorse Innovations kits are slightly different from those specified in the ShumaTech BOM. These connectors (both Wildhorse's and ShumaTech's) are merely 10mm Stereo Jacks.  Their jacks have the nut on the inside so the wires must be soldered with the assembly in the case.  Ours (Wildhorse) have the nuts on the outside so the soldering can be done before installing into the case.

The threaded "neck" of the Wildhorse jacks are slightly short for the thickness of the case.  They can be installed, but the number of threads engaged by the nut is insufficient.  The nut can be tightened down with pliers, compressing into the plastic.

Our cases have a relief milled into the inside of the cover for the stereo jacks, allowing more threads to be exposed.  These reliefs are also milled for the "piloted" areas provided for additional Aux/Edge/Tach openings.

An additional difference is that our jacks have a slightly smaller neck than the ones specified in the BOM.  Ours require a  0.250" opening.  The ones called for in the BOM require using an "O" letter size drill.

Some additional dimensions:
Bolt holes for Mini-Din connectors and RS-232 jack - 0.125".
Openings for Mini-Din connectors - 0.500"

If you are install the RS-232 (DB-9) receptacle, using the pilot hole in the center of the DB-9 outline, drill a #10 or 25/64 hole.  Then use an exacto knife, following the outline milled into the case, to create the final shape.

As usual, all coments are welcome.  We hope our new case design meets with your approval.

A Bold Fresh Method of Mounting the Display LEDs

OK, so I borrowed a bit of the title from Bill O'Reilly.  I think a bit of poetic license is allowed since I have a Grand-Daughter named after him.  (No they didn't name her Bill, her name is Reilly.)

If you've received a DRO-350 or DRO-350+ kit from Wildhorse Innovations lately, you may have noticed the scraps of plastic from the display LED windows (in the case) included in the kit.  This isn't just a way for us to get rid of some plastic scraps.  These scraps can be used as spacers to raise the display LEDs so that they are closer to the faceplate.

Above is a picture of one of these scraps.  Note the lines embossed into the plastic.  They will be mentioned later.

The first step in our process is to alter slightly the order in which the DRO-350 components are installed.  As you will see later, this is an optional step, but IMHO makes the job a bit easier.  The area outlined in red in the picture below shows the area where no components should be installed until after the display LEDs have been installed.  These components include Y1, DS15, D2, D4, D5, D6, D7, R1, R2, R28, C1, C2, JP2 and U1.  If you are building a board for a DPU-550 many of these components will be omitted from your kit already.  In the case of U1 (when building a board for a DPU-550), do not install the headers that will be positioned at U1 until the final assembly.

The following components may be installed prior to installing the display LEDs, however you may find it convenient to leave them out until after the LEDs are installed. D3, JP1, C7, R27 and Q1.

The following picture shows the relationship of the spacer material to the LED when the LED is mounted on the board.  Due to variations in manufacturing, the spacer may be slightly wider than the spacing between the LED legs.  In this case, brief sanding to narrow the spacer will solve the problem.

The installation procedure is as follows:

Fill a single corner hole for each display LED mounting point with solder. The hole should be filled so that it domes slightly.  Having too little solder will make it more difficult to melt the solder in the following step.

It makes no difference with which row of LEDs you begin, but remember to begin with the LED that is closest to where the switches will be.  If you begin at the opposite end of the row of LEDs, you will have no easy way to remove the spacer after the final LED in the row is installed.  There should be three spacers included with each kit, so the spacer could remain in position under the LEDs if necessary.  I tend to be a bit of a "neat-nick" and prefer to have the spacers removed once the LEDs are installed.

Holding the spacer and the LED such that the spacer is between the board the the LED, engage as many of the remaining holes as possible.  While holding the spacer and the LED in this position, heat the solder in the corner hole.  As the solder becomes molten the LED should slip into position.  If it does not move into position easily, do not force it.  One of two things is occurring.  Either the solder is not yet molten, or the LED is not in the proper position.

BE SURE THAT THE LED IS PROPERLY ORIENTED!!!  I hate to admit that more than once I have soldered an LED into position, only to find that I have installed it upside down.

When the solder has become molten and the LED has slipped into place, carefully examine the relationship of the spacer, LED and board surface.  Be sure that the LED is level in all directions.  If adjustment is necessary, heat the solder just long enough to move the LED into position.

NOTE:  Raising the LEDs by this amount does not allow the legs of the LED to protrude completely through the PCB.  However, the end of the legs is typically at, or slightly below, the surface of the PCB.  Be sure to use sufficient solder that the solder wicks through the hole and "climbs" up the LED leg on the opposite side of the PCB.  In addition, there should be a slight "dome" on the side of the PCB from which you are soldering.

Now solder the leg if the LED that is diagonal from the leg just soldered.  Again examine the position of the LED and adjust as necessary. DO NOT solder any additional legs at this time.  By leaving the LED with only two legs soldered, further adjustments to position are easily made.

A NOTE AT THIS POINT:

As mentioned at the beginning of this article, one side of the spacer has a pattern of lines embossed into it while the other side, though somewhat textured, is basically level.  When installing the LEDs, having the side with the embossed lines up, or in other words, against the bottom of the LED makes installation easier.  If the embossed side is positioned against the surface of the PCB, the lines will have a tendency to catch on the slightly raised surfaces surrounding the holes in the PCB.  While moving the spacer with the lines against the PCB is not impossible, it is my preference that any "abuse" that might occur, occur against the bottom of the LED as opposed to the surface of the PCB.

You are now ready to install the next LED.  Slide the spacer in the direction of the next LED position so that only a quarter inch or so remains under the LED just installed.  The next picture shows the position of the spacer as the final LED in a row is being installed.  Note the generous amount of scrap with which to grab in order to remove the scrap.  Depending upon how tightly you hold the LEDs as you solder the initial two corners, the spacer may have a bit of resistance to being removed.  This is especially true if you have the embossed lines on the scrap against the PCB.

After installing all of the LEDs, make one last detailed examination of the installation.  Are the LEDs properly oriented?  Are they level with each other and reasonably well positioned in relationship to each other?  Once you are satisfied that all is correct, solder the remaining pins on all the LEDs.

You are now ready to complete the assembly of your DRO processor board.

One last task.  When the display LEDs are positioned flush against the surface of the PCB (no spacer used in the installation), the five indicator LEDs should be positioned so that they extened about 1/8" above the face of the display LEDs.  With the display LEDs raised as in this procedure, that rule of thumb no longer applies.  Again we can use our scraps of plastic.  Referencing the following picture, place the scrap on the surface of the display LEDs.  The top of the indicator LEDs should extend above the surface of the display LEDs a distance equal to about 1/2 the thickness of the plastic scrap.

Well, as Porky Pig use to say "Th, th, th, that's all foks".  I hope this article has been helpful and results in better display viability for your ShumaTech DRO.  Feel free to offer comments or suggestions, and as always, thanks for visiting us here at Wildhorse Innovations.

Gary

The Ins and Outs of the GPL (General Public License)

Since the software for the DPU-550 has been released under the General Public License (GPL) I thought a discussion regarding the ins and outs of the GPL would be a appropriate.

First, the GPL is not a copyright.  The author of a project may retain the copyright to his works.  Likewise any person who modifies the GPL program may hold a copyright on his modifications, although he must release them under the GPL.  The GPL is a contract between the copyright holder and the general public.  And like any other contract, it is binding upon all parties (in this case the copyright holder and the general public) and cannot be unilaterally modified by either party.  The implications of this are particularly significant to the copyright holder (author of the program).  Once he released a project under the GPL, he cannot withdraw that project from the terms of the GPL.  In addition, since all the terms of the GPL are binding upon the copyright holder as well as the general public, subsequent derivatives by the copyright holder from the original GPL work must also be released under the GPL.

If subsequent versions were not released under the GPL then copyright holder himself would be in violation of the GPL license, UNLESS there has been a total re-write.  Even then it would be hard to show that the re-write had none of it's origin in the original code, especially when done by the person who was the primary author of the original code, or "manager" of the project if the code was a collaborative effort.

One particularly damaging aspect to a violation of the GPL license is when a project is developed in a public forum (such as a Yahoo group) as a GPL project and the originator or coordinator of the project subsequently attempts to "close" the code.  This could not only be viewed as a violation of the GPL license, but also as a criminal violation called "Fraud by Inducement".   In other words, the originator has invited the public to contribute to the project under the "inducement" that the project is an GPL project.  Then when the venture is taken commercial, the originator withholds the source of the commercial version of the project.

Basically the GPL license says this:

1. The code is free to anyone for any purpose, even commercial.

2. Each file that is necessary to produce the finished product (in most cases the compiled binary or hex code) must be included and must be released under GPL.  This includes linker files and other "support" files.  The only files that can be excluded are files that are publicly available, such as header files from the MicroChip or Atmel library.

3. If any person distributes ANY derivative of the original project, that contains ANY of the GPL code, the entire derivative must also be issued under the GPL license and meet all the conditions of distribution found in that license.  No portion of a derivative of a GPL project may be "withheld" as proprietary code.

The exception to the entire "perpetuation" concept of the GPL license is when you develop a derivative and use it only for yourself. But if you share a copy with your buddy down the street, you've come under the provisions of the GPL license.

While the GPL requires that any GPL project be freely available to anyone who wants it, it does not require that the author (original or subsequent) provide the mechanism for distribution.  You don't need to maintain your own server, or have a web site.  You can use any public distribution forum (that does not charge for access) such as SourceForge, as the distribution mechanism.

If the GPL project must be free, how can it become a part of a commercial venture?  MySQL is a perfect example of a GPL program becoming a public venture.  MySQL can be downloaded for free from the MySQL web site (as well as other sources), but if for some reason you want it delivered on a CD, the MySQL group charges for this service.  Likewise they provide a wide range of for pay support services, from the installation of MySQL on your machine to annual contracts to manage your MySQL installation.

The DPU-550 is another good example.  The software for the DPU-550 is of little value with the DPU-550 itself.  The sale of the DPU-550 provides a source of revenue for Scott Shumate, the designer of the DPU-550 and author of the DPU-550 software.

Another source of revenue is providing coding services for someone who wants a particular feature added, but doesn't want to wait for it to come about through the public process.  A programmer may charge for the service of modifying the code.  This does not negate the GPL status of the resulting code.  The derivative project must also be GPL.

So can you modify a GPL program and withhold your modifications if all you distribute is the binary (executable) version of the program?  The answer is a resounding NO!  The binary is impossible to produce without the source code, therefore the entire project remains a GPL project.

Another question that might be ask is if running a GPL program in conjunction with your proprietary project will require your proprietary project be consider a GPL project.  The answer is generally no.  Linux is a GPL project.  Running your proprietary program on Linux does not require that your proprietary program be made GPL.

Likewise interfacing with a GPL project does not always require that the interfacing project be GPL.  If the GPL project has been designed with APIs (Application Program Interface) which do not require any portion of the code from the GPL program be included in applications using the API, the resulting program, using the APIs, is typically exempt from the GPL requirement.

A word of caution is warranted here.  Suppose you have an idea for an enhancement to a GPL project but you wish to retain the right to not disclose the source code of your work.  You decide that the way to do this is to create an API within the GPL program and have your project communicate through this API.  You would probably still be in violation of the GPL.  Much would depend upon the timing (does the history of your project precede the development of the GPL project?).  Also does your program have application to other programs, whether or not GPL?  How extensive were the modifications that were made to the GPL project?

Before embarking upon such a venture I would carefully weigh the potential rewards of keeping my program to myself against the potential cost of defending a lawsuit, not to mention that you might loose.  Remember the GPL is essentially a contract with the world.  Any person wanting access to your source code may have standing to bring suit against you.

The GPL license is a contract enforceable under the law and a violation of that contract is subject to various commercial contract laws. It's hard to conceive of a situation in which products developed and/or distributed using the Internet would not be considered Interstate and thus fall under Federal Statutes as well as State Statutes.

An interesting thing about this is since the 'P' in GPL stands for "Public", the entire population of the world could conceivably be considered members of a class action suit.  Actual damages would most likely be narrowly defined but punitive damages could be huge if a jury viewed the violation of the GPL license as a violation of the public trust.  I would hate to be a developer (standing in front of a jury) who has originally produced code under the GPL license, especially if he received input from the public, such as through a Yahoo group, and subsequently attempted to "close" the code when the product becomes a commercial venture.

In other words, it's best to abide by the GPL license and avoid the possibility of someone with deep pockets bringing suit.

I've pointed out the negative aspects of the GPL, although they are negative only if you violate the GPL.  But the real purpose of this column is to encourage anyone who wishes to use a GPL program to do so.  Modify it in any way you want.  Use it in any way you want.  You don't have to ask permission from anybody.  Many GPL programs have moderators or managers.  The purpose of this is to organize a group of people who want to contribute to a project into a cohesive unit.  But you don't have to participate in the group.  Managed or not, it's still a GPL project.  If you want the project to go a different way, strike out on your own.  Form your own group of like minded people.  You can even continue to use new code from the original group as you take the project in your chosen direction.  The only requirement is that if you distribute (or make public) your modifications, it must be released under the provisions of the GPL.

It is worth noting that not every project that is publicly released is a GPL project.  A developer may release the source to a project and still retain all copyright privileges.  In other words, he can withdraw the project from the public venue at any time he sees fit.  The rub here would be if he has incorporated contributions from the public into the code and then withheld it, especially if he goes on to earn commercial gain.  This again could be considered Fraud by Inducement.  If you plan on releasing something to the public but retain the right to withdraw it at a later time, it is advisable to disclose the terms of this up front.

In addition there is a big difference between a GPL project and something that is in the public domain.  Items in the public domain do not carry with them the requirement to acknowledge their "heritage" in derivatives.  There is no copyright associated with a public domain project.  The author of the program has "gifted" the copyright to the project to the entire world.

So why does GPL exist if a program can be "gifted" as a public domain program?  Because the GPL carries with it the requirement that you "pass it on".  No such requirement accompanies a public domain project.

So make the world a better place.  Go find a GPL program and improve it.  Better yet, invent a better mouse trap and give it to the world under the provisions of the GPL.

GFB

SO IS THE DRO-350 AND THE 16F876 PIC REALLY A DEAD-END STREET?

Several reasons for the DRO-350 being at a dead-end are given. I discuss some of them below.

A compiler for the PIC series of processors is too expensive.

While the “Official” compiler from MicroChip, the compiler with which the original code for the DRO-350 was developed (Scott had access to it at one of his employers/clients/friends), is very expensive, there are several high quality C compilers available for as little as several hundred dollars. These compilers utilize the same libraries as the MicroChip compiler (the libraries are free from MicroChip).

Several hundred dollars is not pocket change to most of us, but not particularly out of line when you are talking about keeping the DRO-350 alive in it’s present state (i.e. price).

In addition, MicroChip offers a very sophisticated Assembler as a part of it’s free Integrated Development Environment.

I have one of the third party C compilers as well as the free PIC IDE. I don’t think there is anything that can be done with the MicroChip version that can’t be done with the third party versions. Mine (the C compiler) even has support for the various In Circuit Debuggers that are available from MicroChip and other vendors.

Moving from one compiler to another is not an trivial task, but again, when we are talking about extending the life of the DRO-350 for what is probably 1000’s of existing users, a bit of effort is worth while. Portability, not just for moving from one platform (computer type, MPU type, etc) to another, but also moving from one compiler to another, is one of the reasons we use high level languages like C.

The 16F876 is “maxed” out.

Yes, the 16F876 is stretched to the limit when it comes to memory. But there is a bit of room available, and certainly enough room to correct bugs. And if the software were made Open Source (it’s supposedly been made obsolete by the DPU-550 which offers Open Source software), there would be many hands that would gladly apply their effort and imagination to getting the last few drops of functionality out of the current MPU. This has already been done by members of the group who have disassembled the DRO-350 code to make changes.

THE DPU-550, A MUST HAVE OR CAN YOU LIVE WITHOUT IT?

There has been much discussion about the “dead-end” status of the 16F876 MPU (the MPU currently found on the DRO-350). It has been stated that it is at EOL (End Of Life) for several reasons.

The DPU-550 extends the functionality, and thus the life of the DRO-350. It sports a 50mhz ARM7 processor (MPU) by Atmel and has a boxcar’s worth of memory when compared to the DRO-350’s PIC16F876A. It’s a 32 bit MPU (as compared to the PIC16F876A, which is 8 bit) which makes for much faster processing, especially when math operations are involved.

The DPU-550’s two variants give the user the option of a basic processor upgrade, with a bit of additional functionality, for a current price of around $50.00, which will include not only the DPU-550 board, but all the internal cables, etc., necessary to use the additional functionality.

The big increases in functionality come in the form of the ability to support four different scale protocols, two additional Auxiliary inputs (Edge and Tach) and the ability to communicate with a computer through a USB port.

The DPU-550 Lite can be field upgraded to a DPU-550 Full which will add two additional scale inputs, two more Aux inputs, true RS-232 and a souped up 5vdc power supply to power up to five glass scales.

Field upgrading is not for the faint of heart in that most of the components are surface mount (SMD). If you attempt it, you need very good soldering skills, the proper tools (an SMD repair station would be nice) and a bit of patience. Attempting it when the DPU-550 is “new”, that is none of the through hole components have been mounted, is “doable”. But if you’re attempting it after the DPU-550 Lite has been populated with the through hole components, you’re going to be working in some pretty tight quarters.