I was wondering if it would be possible to make a circuit that would control a victor with a pot from full reverse to full forward? If possible using a 555 timer?
Googling “servo 555” turns up a few pages.
About half way down, that one has a circuit that uses a pot to adjust it. I haven’t tried that circuit myself, but I did use a 555 to control a servo a few years back. I was looking for specific positions, so I used resistors then a small pot to fine tune it. However, I don’t see any reason that you couldn’t get the full range.
Oh, and the victors use the same signal as servos.
I didn’t think was possible (until sciguy’s post), but I have seen on some combat robot site somewhere in the past a device that can create a PWM signal. If you can find it (for some reason, USC’s network can’t connect to Google right now), it may be a starting point.
Here you go. I’m currently making one.
That’s the link with assembly directions.
Thanks I will build the second one. I was just looking for a schematic ran a search and all it was was discussions about the topic no schematics
absolutely. The control signal is very simple. All you need to do is supply it with the necessary voltage on the power lines and a 1-2 ms pulse periodically on the signal line. 1ms corresponds to full rev while 1.5ms is neutral and 2 is full forward.
555 timers are like using ‘GOTO’ statements in C
in fact, I had one professor in college who would give you an automatic F if you used a 555 timer (or any other one shot timer) in any type of project or assignment.
a better solution would be one of the 8 pin PIC Microchip uCs. You could hook a pot to one of the ADC inputs, and use the PWM output to generate the control to the victor.
I like your professor
For my senior project this past quarter, we controlled Victors with a Motorola 68HC12. It worked quite well overall. Just remember you only need to connect the signal and ground wires (not +5V).
The 555 is one of the most important pieces of standard hardware on the planet (KenWittlief’s prof’s opinion not withstanding). Bias against it may well be justified, but it does not take away from the fact that the world as we know it would simply (and literally) grind to a halt if the anti-555 snobs waved a wand and made all the 555’s in the world disappear.
I take the more practical approach of Steve Ciarcia, who said, “Solder is my favorite programming language.”
Driving a Victor with 2 555’s is a piece of cake (use a 556 - it has 2 555’s in one package). Go HEREfor some easy examples of how to make useful 555 circuits. The basic idea is to have one 555 set to make a 50Hz signal and have that repeatedly trigger a “one shot” that will give you the pulse for the Victor (roughly .5ms - 2.5ms pulse).
Did he say 555 timers and their ilk had no place in the world or did he simply think they were a slam dunk to use and wanted the students to have to put some more thought and effort into the projects? :rolleyes:
I thought the automatic F made his intentions pretty clear. It was the same deal with ‘goto’ statements in any high level programming class, instant F.
The problem with one shot timers is, they are temperature dependant, voltage dependant, and rely on the RC time constant, which also can create a wide range of tolerance issues.
The real problem with one-shot timers is they act sort of like digital circuits, in that they have two states: on and off. BUT real digital logic is controlled and regulated by a clock. Every state should be registered relative to a well defined clock
a one shot timer by contrast is more like lighting a fuse. Asychronous logic is one of the fundemental causes of system instability, design bugs, and system failures. Its better in the long run to design a good, deterministic digital solution (with a clock) than to mess around with asychronous logic. You end up spending more time and money designing and debugging asynch circuits than just doing it right the first time.
hence, the automatic F :^)
Guilty as charged, but even so it is silly to argue that they don’t have a place in the world.
Point 1: Last week, I needed to exercise a curcuit as I debugged some design issues. I literally built a 555 circuit, had my scope hooked up and was solving the problem in about the same time it would typically take to boot up a PC and open an IDE like MPLab, yet alone designed and debugged a PIC circuit, written code for it, and downloaded and debugged that code.
Point 2: Many applications can live with temperature & voltage dependency as well as wide tolerancing issues.
Point 3: The claim that “real” digital circuits require a clock is a blanket generization that just doesn’t hold up to serious evaluation. 1000’s of chips, useful ones that even the purest of the pure Digital Gurus could not argue is not a “Digital,” have no such clock but depend on internal, well planned logic races to function as designed.
Point 4: The 555 is dirt cheap. The reason that Programming Purists have been able to hold the line on the “GOTO’s ARE EVIL” mantra is that (1) you can (almost) always make cleaner, easier to maintain code without them and (2) these work arounds do not cost more. I can tell you right now, the 1000’s of engineers that put the 555 in the millions of commercial products that ship each year are not ALL stupid. They are being driven by cost. Professors can argue all they want about inelegant solutions. Jonh Q. Public doesn’t pay for elegance, he pays for features. If 555’s provide the feature at a lower cost, 555’s win the day. If not, they don’t.
Point 5: Sometimes Programming, Electronic Engineering and Computer Engineering Purist really get my blood boiling Perhaps it is just a reflection of the relative youth of these fields, but I can’t think of similar analogs in the fields of Civil Engineering, Mechanical Engineering or Industrial Engineering. Have you ever heard a Civil Engineering guru argue that only the only way to cross a valley is with a suspension bridge - all other methods are beneath consideration? Or a Mechanical Engineer ever insist that the only REAL heat engines are based on the Stirling Cycle? I see this kind of borderline religious zealotry all the time in the electronics & computer engineeing worlds and it drives me nuts.
I have already said more than I should have. I will end by just saying that there is no such thing as an ideal solution. All solutions involve tradeoffs. I urge folks to understand advantage and disadvantage not to memorize a set of rules (“don’t use gotos,” “never use 555s,” etc.). In the former you can choose a solution that optimizes your Performance Index. In the latter, you may be able to keep a Prof from giving you an automatic F, but I don’t think life is likely to give you an A.
the thing is, a 555 timer may be cheaper than an 8 pin PIC chip, and if you need to rig something up quickly then who cares about anything else?
But if you are designing a product, that will be produced by the thousands or millions, then you must consider the entire engineering and life product cycle.
One shot timers are the simplist form of asynchronous logic - but if you open the door to these, then you allow asychronous logic into the designers toolbox, and then where do you draw the line?
Looking at SW again, if a subroutine has one entry point, and one exit point, its easy to understand the flow of your code - but if you have goto statements allowing your code to jump all over the place, you quickly end up with spagetti algorithms
same with digital HW. With one system clock the only parameters you have to worry about are setup time and hold time - what happens between the rising edges of the system clock become irrelavant, as long as everything settles down to meet setup and hold.
But if you allow one shots, or async clears, or you gate your clocks, then your timing becomes complex, and simple things like changing a chip from TLL to CMOS, or even from one supplier to another will make your system stop working, or worse yet, will make it unstable, so it fails under certain temp or application conditions.
There are golden rules to designing digital logic:
No asynchronous logic (including one shots - everything must be registered by a clock)
no circuits that can glitch
no gating of clocks (one master clock for the system)
asynchronous inputs must be double registered (to prevent metastability)
if you take a short cut and break one of the golden rules you will pay for it sooner or later: when you try to make a simple modification to the system, when a part goes end of life and must be replaced, when the system is used outside its normal environment, when you need to upgrade, when you need to interface to something new or different, or when someone else has to work on something you designed.
that 60 year old Professor really knew his stuff. From my experience over the years, the golden rules remain untarnished.
Couldn’t agree more with this. I think an important aspect of being an engineer is being able to evaluate lots of different solutions to a problem and pick the one that best meets all the requirements (including things like cost, time to implement, robustness, how easy it is to understand for future engineers who may need to modify it, etc.). And hopefully you don’t feel that all computer engineering people are zealots .
Shouldn’t it be the burden of the engineer designing the solution to know where to draw the line? He/she should understand the risks/rewards of such a solution and should be able to understand where to draw the line given the needs of the project/product (which are not constant from one project to another - as Joe pointed out, sometimes the tradeoffs are acceptable given the project requirements).
Hard and fast rules such as “absolutely no gotos” can sometimes do as much damage as using gotos all over the place. While rare, there ARE times when the use of a well-placed goto (or break, or continue, or early return, etc.) can greatly simplify code and therefore increase readability and maintainability, or be necessitated for performance reasons in small embedded systems, etc. Enforcing the “no gotos” rule in college might make sense such that the students don’t develop a bad habit of using them, but in my opinion it should be explained like this: “Sometimes, using a goto may be necessary or appropriate. This will be your job as an engineer to make that determination. However, the assignments for this class are not sufficiently complex to justify the use of a goto statement. Hence, use of goto is not acceptable in your solutions.”
A goto statement in a subroutine is kinda like the hyperspace button on a video game - you have coded yourself into a deadend, and there is no other way out
thats not good. The golden rules that each discipline of engineering have come up with over the years are the result of many painfull and expensive blunders and mistakes.
When you find yourself tempted to break one, its a red flag that you didnt think things through before you started writing code, or drawing schematics, or designing your logic.
On military projects they have many of the same rules. If you dont follow them your project will be rejected at your next design review, and they dont grant exceptions either :^)
We prefer to call them waivers.
You can’t possibly understand all the different situations that come up so I don’t understand how you can make blanket statements such as “it’s a red flag that you didn’t think things through”. I would agree that any time you think you need to use a goto it should be a red flag to reevaluate the problem to make sure there isn’t a better way of doing things, but I can’t claim that there is never a situation where it would be appropriate. And besides, if the person writing the software hasn’t thought through the program before starting, “golden rules” such as no gotos won’t save him - it’ll be a spaghetti-code mess either way.
I personally have never encountered a good reason to use a goto in my own work. I have, however, seen enough cases where even the best, most well-thought out designs will run into certain practical limitations that sometimes cause us to have to do things in a way that is less than ideal. This can often be the case, for example, when writing code that interacts directly with hardware. Tight timing constraints or poorly-done hardware interfaces (on external chips) can put you in a corner where a nice elegant software design just won’t work. This tells me that there most likely are cases that I have not seen yet where the use of a goto might be justified.
(Sorry to original poster for continuing to take this tread off topic… :o )
thats what drives the need for golden rules, and thats why they are instituted very carefully (and thats why they are golden). When the situation comes up, there it is!
It has amazed me that engineers from all over the world somehow know the golden rules that apply to their profession, and they are not afraid to point out to you (during a design review) that ‘this is a problem, you should never do this’. Seriously, I though Dr Eric Schmidt at Suny Buffalo came up with “Dr Schmidts Golden rules of digital design”, because he shared them with us as if they were his own children, in a hushed tone, almost as if they were sacred.
but somehow, everyone seems to know them :^)
You are just plain wrong. According the the Wikipedia’s entry on the 555,
Ken that is BILLION with a B.
You don’t get to a Billion units with yahoos and hobbyists.
Can you mis-use the 555? **Yes, of course. **
Would it be unacceptable to use a 555 in a billion dollar satellite project? Yes, of course.
Can they be put to great use by hobbyist, toy manufacturers, and others who are willing to live with their inherent limitations? Yes, of course.
Is a blanket condemnation of using 555s anywhere under any circumstances just plain silly? Yes, of course.
This is not to say that “golden rules” are not useful. But if I have the choice between understanding the reasons for rules and blind adherance, I am going to advocate understanding the rules.
I am going to go even further. In answer the the question that started this this thread, it is hard to argue that the best solution for the problem as presented is anything other than heading down to the local Radio Shack with $10*, buying a 555 and a few extra goodies and building a circuit that works as desired within 15 minutes of arriving home.
I am getting my undies all in a bunch because I believe with every fiber of my being that Engineering is an Art. It is a beautiful, wonderful, delightful art.
There are laws of physics, useful rules of thumb, and cold hard economics that come into play to be sure but at its core Engineering is Art. For these artists, there is no substute for sound engineering judgement.
*For an additional few buck he could have put in all in a nice pretty box to boot!