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.

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