Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Rather flummoxed now

Status
Not open for further replies.

throbscottle

Well-Known Member
I refer to this design: https://www.electro-tech-online.com/threads/drill-feed-controller-mostly-works.143771.

So, I discovered the modification to U7a D input caused more issues than it solved. I modified the bit that feeds pulses to wind up the dig-pot so it has a small delay - big improvement, the pot gets a chance to be set to go the right way now!

But what is really baffling me is this. It will run fine for a dozen or so down/up transits, but then it will shoot to the top, and the feed motor remains powered, holding it up there. Digi-pot shows to be at minimum value, I have to press the reset switch, then the "top" limit switch to set it correctly again, and off it goes. AFAICT, the digi-pot is failing to be reversed at the bottom of the travel. Can't work out why. It gets a noticeable rest / over-run period at the bottom, and a reliable pulse from the monostable. Maybe it needs a wider pulse, though it's not very narrow.

So any suggestions, anyone?
 
I had a quick look at your schematic, but it was too complex for me to attempt to try to trace out. So, I'll just offer a few general suggestions.

1. You're using 555 & 556 timers which are notorious for putting horrendous glitches on the power bus. Do you have sufficient bypass caps across the 555 and 556 power pins?

2. You mention that you're using some micro-switches. Is it possible that contact bounce is causing a problem?

3. The clock inputs to your D flipflops have large value capacitors to ground that will limit the signal rise/fall time. You may be exceeding the maximum allowable rise/fall time of clock input.
 
U7b clock input should have a resistor to ground so that it doesn't float when both diode connected inputs are low. (I'm assuming 74x74 is CMOS logic.) Ditto on the large capacitors at clock inputs -- max rise/fall time is definitely exceeded. That is no way to create a delay for contact bounce, or otherwise, if that is the idea there.
 
I had a quick look at your schematic, but it was too complex for me to attempt to try to trace out. So, I'll just offer a few general suggestions.

1. You're using 555 & 556 timers which are notorious for putting horrendous glitches on the power bus. Do you have sufficient bypass caps across the 555 and 556 power pins?

2. You mention that you're using some micro-switches. Is it possible that contact bounce is causing a problem?

3. The clock inputs to your D flipflops have large value capacitors to ground that will limit the signal rise/fall time. You may be exceeding the maximum allowable rise/fall time of clock input.

Sorry! I find it hard to follow what's going on myself!
1. Ok I'll try bigger de-coupling caps. I thought 1uF ceramic would be enough.
2. Unlikely. The micro-switches are purely there as end-stops. When it's working properly, apart from the first cycle when the top one gets hit for calibration, they should never be touched. The up/down signals come from the op-amps (here used as comparators, though I think I might re-jig it to use an LM393)
3. The 74hc74 has Schmidt trigger clock inputs, so it should be able to handle the slow rise. Seems to work ok.

U7b clock input should have a resistor to ground so that it doesn't float when both diode connected inputs are low. (I'm assuming 74x74 is CMOS logic.) Ditto on the large capacitors at clock inputs -- max rise/fall time is definitely exceeded. That is no way to create a delay for contact bounce, or otherwise, if that is the idea there.
Oh, I thought I'd changed that, it should say 74HC74. But all the 7474 series AFAICT have Schmidt trigger clock inputs. Only one of the caps is for debouncing, and that is C3, combined with R6 and R4. The other two are for timing: C17 creates a delay when the head gets to the bottom of it's travel, to allow for over-shoot, (whilst Q is over-ridden by the op-amp's output (U2b)) and C1 is to create a delay whilst the digi-pot, U3, gets some pulses to wind it up to the top, though I made a mistake there and didn't allow for it's direction to be set (corrected now with yet another timing cap...)

I'll put a pull-down on U7b clock input anyway, there could be some false triggering going on.

BUT the whole flip-flop/timing thing works perfectly, the problem definitely seems to be with how the digi-pot is being set at the point when U7a gets it's clock pulse (or ramp in this case). What is supposed to happen there is, the monostable, U5(1) gets triggered when U7b changes state, provides a brief pulse to U3 c/s, so it will get the correct direction from whether u/d is low or high. The pulse also blocks input from the opto-interrupter, so that Q3 will reflect the state of U7a Q output on it's collector (since it's input comes from !Q). C22 ensures this signal is delayed long enough for C/S to get the falling edge of the pulse. So I'm really thinking the failure is occurring here somewhere, I just can't work out where.
 
Oh, I thought I'd changed that, it should say 74HC74. But all the 7474 series AFAICT have Schmidt trigger clock inputs. .

Okay. The 74C74 datasheet I looked at does not have a Schmitt clock input, but you're using HC which does.

The trigger input of U5 may need a resistor to ground (or to Vcc) as it may be floating at times too -- possibly causing your problem. Only a timing diagram will help to determine. As a general rule these sorts of asynchronous circuits with "mickey mouse" logic and capacitor delays are prone to problems. But it is what it is.
 
Last edited:
I agree with ccurtis's comments.
I had also checked the 74C74 specs which have a very specific maximum rise time for the clock input. If the 74HCxx series uses schmitt trigger inputs, then that's not likely the problem.

However, the fact that it works correctly most of the time and then suddenly fails, indicates that there isn't any error in basic logic, but obviously an error in implementation that leaves it susceptible to glitches or borderline timing problems. As Ccurtis mentioned, make sure that you don't have any floating inputs.

Since you believe that the problem is centred around the digi-pot, I would put a scope on that and check for correct timing of signals.
 
The cluster of parts around D4, D6, and D7 is particularly "intriguing". All they could every do is pull the U5 trigger input high or leave it floating (and floating is never good). The trigger input should always be held (pulled) high and is active when the Q2 forces it low. I can't see how the circuit would operate any differently if you connected the trigger input to Vcc through a resistor and removed D6 and all the parts connected to D6. And may even be improved because the trigger input then would never temporarily float.
 
Last edited:
"Mickey Mouse logic" - what an excellent phrase, I'll try to remember that one :) I did really want to make this completely analogue, but I think that's a bit beyond me at the moment!

I have to clear my bench at the moment to get the 'scope onto it! Things are getting vertical... But yes, only way to really see what is going on.

Ok, explanation of what is going on around D6.
D4 and D7 are connected to the Q and !Q outputs of U7b. Since one of those outputs is always high, either C13 or C14 is charged. D6 acts as an OR gate. Now, when U7b changes state, whichever of C14 or C13 was charged, is discharged very quickly, and the other one of the pair is going to take a bit of time to charge via it's resistor, so U5 gets its trigger pulse. Ah, and I now see how a pull down resistor is needed, the trigger pulse is really a trigger float! Something of an oversight, that. But anyway, it is there so that U5 gets triggered by either output of U7b going low, corresponding to either a clock event or a reset event. I couldn't see another (simple-ish) way to do it.

Q2 should only ever be pulling the trigger input low at power-on, or if the reset button if pressed. The reason I connected U5 to it, is because I found that as long as trigger is held low, the output remains high, which via R21 increases the voltage at the gate of Q6 enough that the drain stays low irrespective of the state of the photo-interrupter. Rather a marginal arrangement but it works.

*sigh* and now I have to read stuff for work. Blehg.
 
Now, when U7b changes state, whichever of C14 or C13 was charged, is discharged very quickly, and the other one of the pair is going to take a bit of time to charge via it's resistor, so U5 gets its trigger pulse. Ah, and I now see how a pull down resistor is needed, the trigger pulse is really a trigger float!

Hi. It's a miracle that U5 triggers when U7b changes state. The U5 trigger input is not active until its voltage falls to less than 1/3 of Vcc and I can't see how the D6 arrangement could ever make that to happen. If not triggering from Q2, U5 is triggering on a whim and a prayer from U7 best I can tell. I would look to determine if your problem could be related to U5 failing to trigger when U7 changes state, or triggering multiple times when it's not supposed to from noise.
 
Last edited:
All I can say is it works! I tried it first with 1N4148's, which worked, but in LTSpice I got a much stronger trigger pulse using Schottky diodes, so I put those in. When I get the 'scope on it I'll try to get a photo so we can see how strong the trigger pulse is.
 
All I can say is it works! I tried it first with 1N4148's, which worked, but in LTSpice I got a much stronger trigger pulse using Schottky diodes, so I put those in. When I get the 'scope on it I'll try to get a photo so we can see how strong the trigger pulse is.

Oh, I fully believe you when you say it works. I have seen CMOS circuits work without power applied, even though they are not designed to.
 
Now that's a whole new interpretation of "low power"!
 
Well, I tried putting in pullup resistors, and the problem I described in first post disappeared, so very pleased there, big thanks!
The "top" switch function is far too primitive though, doesn't work as it should. It was pretty marginal anyway. So a bit of re-design there. Still getting upwards "creep" of the mechanism. Weird because the overshoot allowance is working correctly - ie the digi-pot doesn't get reversed until motion is triggered.
 
Well, I tried putting in pullup resistors, and the problem I described in first post disappeared, so very pleased there, big thanks!
The "top" switch function is far too primitive though, doesn't work as it should. It was pretty marginal anyway. So a bit of re-design there. Still getting upwards "creep" of the mechanism. Weird because the overshoot allowance is working correctly - ie the digi-pot doesn't get reversed until motion is triggered.

Hi. The reliability of the cluster of parts around D6 is still "iffy" with just pull-up resistors (and I'm not sure where you put the pull-ups anyway). That might help with false triggering, but intentional triggering is still questionable. I suggest something reliable like the attached. I'm not sure what you mean by the top switch function.
Untitled picture.png
 
Scope shows pulse going all the way down to 0v as it is, thanks :) I meant pull-down's when I said pull-up's. Duh. Dyslexia affects strange things. I put them on U5(1) trigger and U7b clock, 100k to gnd on each.

The "top" switch is a micro-switch at the top of the head's travel, so the power-on cycle sends the head to the top, which operates the switch. It is supposed to calibrate the mechanism but I made a huge mistake in sending pulses to the digi-pot before it's been set up. Putting a delay there has helped but it still doesn't do it's job properly. As I say,needs revising so don't pay it any attention for now!
 
Well, I got rid of the auto-calibration stuff, put in a switch (PL1 calibration-ground) instead to disable the motor and digi-pot so you can manually move the head to some kind of mid-point. (see revised schematic) Found that the cause of the original problem in this thread was a combination of:
  • R20 - I'd obviously decided it should be 15k at some time when experimenting and used that value, however discovered it needs to be lower, my calculated 4k7 worked ok, but experimentation with a preset pot gave a better value of about 7k, so I'll be putting a 6k8 in there. So that proved to be the main culprit in failure to reverse the digi-pot.
  • Some signals from the opto-interrupter were occasionally over-riding the direction change signal, due to some slots in the gear it detects the teeth of. I thought I could tune this out, but there were some tiny spots I couldn't. So I've stuck a sticker over it now so just the teeth show. That was causing a lot of problems.
  • The auto calibration routine was just too flakey. I couldn't make it reliably bring the digi-pot up to its maximum value every time the device was turned on.
  • The bracket I'd mounted the opto-interrupter on kept moving. Duh.

It works pretty well now. There's still slight creep, but it tends to go one way and then the other, so cancels out, and not important for a PCB drill anyway, and the calibration switch can be used to stop the digi-pot updating so the head can be re-positioned at it's upper set point if need be. Pleased with it so far.

BUT - and it's a massive but - I fried it's H-bridge today (DMHC3025LSD). I found the mechanism to be really underpowered, and when I tried to slow it right down it wouldn't run, so I put a bigger motor on it. This is a CDROM drive mechanism, btw, and it now has a small motor from a printer, quite a bit more grunt there, but it was still pretty feeble. Then I realised I had put a current limiting resistor in series with the supply to the H-bridge, so I shorted it. Great, motor now was much more powerful, could go slower. But I found if I slowed it down too much it would still stop. Messing about I managed to get it jammed against the end stop. Anyway a very hot H-bridge chip followed, then deadness. The lowest rating part of the H-bridge are its P-type mosfets, which are rated at 2.5A continuous @ 70C with 4.5v Vgs. All the internal diodes are rated for 2.5A too.

I don't want to have to keep replacing fuses, so I reckon if I put in a 4 ohm WW resistor, it will be able to stop the H-bridge from cooking in the event of a jam, and won't limit motor current too much. Any thoughts on this strategy?
 

Attachments

  • Schematic_Design__auto-separated-gates-v2_sch_ed_files.pdf
    81.4 KB · Views: 198
Well, it looks like you did better with the different design than the original.

Thoughts:
Find a better H-bridge.

Not saying this https://www.canakit.com/dual-motor-l298-h-bridge-control-ck1122-uk1122.html is better, but it does allow current monitoring. Way back when, I used one where you placed resistors and they would take care of the overloads, etc.

So for more complication, you could do a current limit on the motor and actually shut it off if it hits a "brick wall".
 
Good point - I hadn't thought of that. I do have a few more **broken link removed** so I'll use another of those. Also if I get really desperate I can bump up the gate drive voltage and get rid of those zeners, it should handle another amp that way. Current monitor could trip a relay and reset the power. Wonder if it's a good idea to do an interlock that so it turns on in calibration mode - you just press a Ready! button when the head is re-positioned. More what I wanted anyway, just hadn't thought about implementation.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top