Design Con 2015
Breaking News
Engineering Investigations

The SED Problem

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 2   >   >>
kfield
User Rank
Blogger
Fixing someone else's mistake
kfield   9/25/2013 12:12:19 PM
NO RATINGS
I can't imagine anything more frustrating than having to step in and fix something that somebody else did wrong. Grrr!!

zeeglen
User Rank
Blogger
re: The SED Problem
zeeglen   10/29/2011 3:29:14 AM
NO RATINGS
There was an old engineering semi-joke "If it was difficult to design, it should be difficult to understand". Looking over some of the comments here, proper and complete documentation is wonderful to your successor. However, it does make the original designer more expendable...

WKetel
User Rank
Rookie
re: The SED Problem
WKetel   10/29/2011 2:44:18 AM
NO RATINGS
I have had to fix and repair other peoples work on many occasions, and sometimes it has been "interesting" indeed. The result is that I provide very good documentation of my work so that when it needs to be repaired either I, or somebody else, will be able to see how it should work, and understand what has failed. Besides that, really good documentation saves me from having to do many service calls, which is fine with me. The side benefit is that it can make the plant electricians look good, which assures that I get the help I need in the plants, when I need it.

Jerry.Brittingham
User Rank
Rookie
re: The SED Problem
Jerry.Brittingham   10/28/2011 9:52:02 PM
NO RATINGS
Any good (emphasis on good) assembly language programmer knows to document. Descriptions of subroutines, comments on most lines of code and descriptive labels are a good start And anybody doing real time interrupt driven code always counts the clock cycles (micro/nano seconds)to insure that it will work fast enough.

Sheetal.Pandey
User Rank
Manager
re: The SED Problem
Sheetal.Pandey   10/28/2011 9:40:54 AM
NO RATINGS
reminds me of my projects in early years of my career. Its always fun debugging. Its like a match winning.

sharps_eng
User Rank
Rookie
re: The SED Problem
sharps_eng   10/26/2011 5:48:51 PM
NO RATINGS
We tend to solve our own problems at someone else's expense. This story illustrated what a lot of 'real-time' programmers do; they find they can't do the job here and now (inside the ISR), so when interrupted with fresh data (frame), they store the data in some sort of queue and go back to munching away at the head of the queue, trying to keep up. So far so good, but note that it has actually used more (net) time and memory; and it relies on the interrupt rate slowing sometime to allow the queue to reduce. To prevent an ugly overflow in the middle of a packet, downstream code will have to monitor the queue and take a higher-level decision to dump some of the data in an orderly fashion. (This is why your TV set drops frames nowadays, when analog never did). So you can see that completing your data decoding on-the-fly is A Good Thing, while taking a bit more thought and maybe more horsepower, makes things much easier for downstream code because overflow can never happen. * disclaimer: many specific cases will not support this approach; they are not the ones I am talking about *

ndancer
User Rank
Rookie
re: The SED Problem
ndancer   10/26/2011 4:41:25 PM
NO RATINGS
Reminds me of the Story of Mel, a real programmer. http://www.cs.utah.edu/~elb/folklore/mel.html Old stuff should not be forgotten because there are useful lessons in old stuff, where we didn't have two hundred terabytes of RAM, a googleplex of hard drive, and clocks running at X-ray speed.

Sanjib.A
User Rank
CEO
re: The SED Problem
Sanjib.A   10/26/2011 3:36:26 PM
NO RATINGS
I think, we can not avoid troubeshooting somebody else's design and I agree that it is tougher than designing our own something new. To be positive we have to start liking trouble-shooting a problem, taking the same as a challenge...and slowly we will find it enjoyable...then we won't be bothered that we are trouble-shooting somebody else's mess.

Borges
User Rank
Rookie
re: The SED Problem
Borges   10/26/2011 8:20:10 AM
NO RATINGS
Thou shalt push as many times as thou popeth! I learned that the hard way too when I put a task switcher into my assembly code. But luckily for me it was my own code all the time.

David Ashton
User Rank
Blogger
re: The SED Problem
David Ashton   10/25/2011 9:05:09 PM
NO RATINGS
Much simpler stuff...but when I was about 20 a friend's girlfriend's father owned a nightclub. He refurbished it, and got a fancy light unit that had a few hundred watts of coloured lights above a huge milky perspex ceiling. The electronics was supposed to bright and dim each colour slowly creating mood lighting for the club. Trouble was the spikes generated by the SCRs controlling the bulbs interfered with the circuit and the result was a crazy flickering effect. And the club was reopening in 3 days time..... I got called in and first of all had to draw out the circuit diagram from the boards (there was no documentation whatsoever...no idea where he got it....). It had 3 triangle wave generators and these were (wrongly) syncing themselves to the interference, producing the flickering. By a combination of inductors on the SCR lamp circuits, and regulating the op-amp supplies, I got the thing working pretty well. The guy was really chuffed and gave me a free ticket to the opening. However I was a real nerd in those days and didn't go...I also got a nice wad of cash for it though and that was much appreciated.

Page 1 / 2   >   >>
More Blogs from Engineering Investigations
Sometimes, it's the mundane things in electrical and electronic devices that make the difference. The strain relief on an air conditioner's line cord saved the day when the unit fell out of the window.
A lack of information on a datasheet lead to system crashes from a hot-swap controller.
An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely unfamiliar.
You rarely get anything extra for free. Engineers who work on vision systems know this. But sometimes other people believe that just putting a camera on it constitutes an effective inspection setup.
It's really mind-boggling to think of what my hourly rate would be if I were paid for the actual time that I spent troubleshooting a problem to get to a fix. The challenge is to avoid going down a rathole.
Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll