DISCONNECT Saves the Day

I had some unanticipated drama in wrapping up a robotic 08M2 project in the wee hours of this morning on a tight deadline. My 08M2 was maxxed out; I was using all pins, including C.5 serin and C.0 serout. C.5 was wired to an active-high limit switch a foot away from the board. My scratchbuilt board worked fine until either of the DC motors turned on. The drive motor was switched on (not even PWM) through an IRF510 mosfet, the steering motor through a pair of relays & limit switch in my bidirectional homing circuit. When either motor turned on, the 08M2 would freak out, reset, lock up, you name it. I already had 3-cap delta filters on both motors, flyback diodes on the relays, two bypass caps right at the Picaxe (0.1 and 10 uF), and big beefy wiring throughout. Checked & double checked the board, swapped 08M2 chips, tested everything. Single battery supply BTW, five AA batteries and a 78L05 5V regulator for the Picaxe.

I should add this was the first time I've tried using serial input pin C.5, I needed that one extra input. Around 2 AM and out of options, I figured the best solution would be to use a "real" input pin and decided to build a similar board using a 14M2. I had only soldered on the socket when I realized that perhaps the foot-long wire attached to serin pin C.5 was acting like an antenna and picking up enough noise to reset the chip. I did another test after adding a DISCONNECT command at the start of the program. Boom, instantly everything worked perfectly. Now I have to do a hard reset at each new download, but that was a small price to pay and certainly easier than building another entire board. It felt good to get my money's worth out of that 08M2. Resorting to a 14M2 for just one input pin felt like cheating.

So I learned my lesson, when in doubt, DISCONNECT!

Thanks erco. Good to know.

Good work and information erco.


IMHO erco's post epitomises what there should be more of.
That is, rather than ask whether a particular piece of code will work, give it a try!

Other than setting an IO as an output and driving into another output at the opposing state leading to an effective short circuit with possible dire consequences, there is little that will damage the PICAXE chips.
There is the PE simulator as a first method of trying a new piece of code. Then try with an actual PICACE chip.
The worst that can happen is that the trial does not work - at which point raise the topic on the forum to solicit help from the pother members.

Also, as erco has done here, share your experiences and solutions/projects so that others may learn by the posted examples/information.

Turning a PICAXE input into an antenna can be problematic, and a bit of a nuisance when that's the Download Serial In; it can take while to figure out why a program is just freezing, restarting or generally only half behaving as expected.

A good bit of advice, which is what erco seems to have done, is to step away from it. That often allows the mind to reflect on why it isn't working free from the distraction and frustrations of trying to make it work. Going to solder that socket probably allowed the time for thoughts to trickle through and the light bulb moment to occur.

And if it's not going anywhere, post to forum. It sometimes only takes an instant for someone else to see something you have been looking straight past for ages, or provokes a look in the right place. Even just typing the problem out and explaining it can help the mind see what the problem is.

And if the answer comes just after you hit send, don't worry about it. And never be embarrassed about it being 'something silly'. We've all been there or will be there one day.

And who doesn't enjoy a heroic tale of woe, trials and tribulations, with a happy outcome ?

On the issue of 'DISCONNECT means Hard Reset'; if there is enough program space it may be possible to use the button on Serial In to act as a signal for short presses, and have it jump to a RECONNECT to allow downloads with a longer held push.

DISCONNECT has also saved my bacon.

For me, it was a logger project. The 14M2 had also been maxed out and I required to use all available ports. If I connected or disconnected the serial plug while logging, the Picaxe would reset and although the information was still there on the EEPROM, I would lose the indexing.

Hi,

westaust55 said:

rather than ask whether a particular piece of code will work, give it a try!

Click to expand...

+1 from me, and there is another "Do It Yourself" method: Does it pass the Syntax Checker?

Sometimes there are forum questions: "Can I do ..... on Pinx.y of a particular PICaxe chip? So write a "one line" program and check it ! For example, try PULLUP 1 on most M2s or PULLUP %100000 on an 08M2, which I don't think is in any of the formal documentation. Although, I don't really "like" the responses that the Syntax Checker gives for these particular commands.

But personally, I try to avoid "designing in" a Hard Reset whenever possible, because it's not always a trivial task and there can be several "gotchas". For example "phantom power" may creep into any PICaxe pin, then via the "electrostatic protection" diode to the supply rail, can keep the PICaxe running even if the power supply is disconnected.

So, when I do need to use a DISCONNECT, I try to include a SERRXD (with a suitable timeout) in a main polling loop and then issue a RECONNECT if/when an appropriate character is received.

Cheers, Alan.

In my case it was the brushed DC motor noise which caused a problem, even with 3 filter caps soldered directly to the motor terminals and case.

In contrast, I have modified enough servos for continuous rotation to know that the brushed DC motors inside the servos never have ANY filter caps soldered directly to the motor terminals and case. Yet they don't emit enough EMI/RFI that has ever shut me down like this, even with all those PWM signals surging through their components.

Baffling IMO. The magic smoke wafting around inside those servo controller chips must be doing some real magic. I emailed Hitec servos to ask why and their very vague reply was "proprietary circuitry".

erco said:

In my case it was the brushed DC motor noise which caused a problem, even with 3 filter caps soldered directly to the motor terminals and case.

In contrast, I have modified enough servos for continuous rotation to know that the brushed DC motors inside the servos never have ANY filter caps soldered directly to the motor terminals and case. Yet they don't emit enough EMI/RFI that has ever shut me down like this, even with all those PWM signals surging through their components.

Baffling IMO. The magic smoke wafting around inside those servo controller chips must be doing some real magic. I emailed Hitec servos to ask why and their very vague reply was "proprietary circuitry".

Click to expand...

Well, it's less "proprietary circuitry" than just a neat design "trick". The circuits within the servo itself are all running synchronously with the noise that the servo motor generates.When the internal servo chip says "go high", the motor gets a pulse of current. The control chip doesn't really "see" the motor noise because it "sees" exactly what it expects to see.

But, when you are running motor control from a Picaxe off the board to a motor, the poor Picaxe is constantly running at some clock rate generally MUCH faster than the motor response time, so it is ready, willing, and able to respond to any glitches or spikes that the motor may generate. Adding lots of bypass caps at the motor generally won't help, because you're just moving the noise through the cap to another unwanted place (say, from the motor supply to the motor ground). It then runs down the ground line to the Picaxe board, which is where it really should have been bypassed to begin with.

High current, noisy devices like motors are perfectly capable of banging the GROUND side of the Picaxe circuit up and down several volts, which is equivalent to a perfectly good logic signal as far as the microprocessor is concerned. That's why a good, low impedance ground plane, with good, low impedance bypassing across a range of frequencies at the Picaxe end, is critical.

One other thing to keep in mind is that most servos were designed to run from batteries capable of providing pretty ferocious pulses of current. In other words, the battery itself acts as a pretty darn good, VERY low impedance capacitor all by itself. And generally, the servo cable to the battery is pretty short, and dedicated just to the servo, which doesn't hurt at all.