Offline PIC controlled lamps malfunction when plugged in near to power tools

[ocset]

Hello,
We have designed some 40W, offline 230VAC, non isolated LED lamps which have no AC input filter. (-because they are  based on linear current regulators). They  can be dimmed up and down by a microcontroller which receives DALI input signals. We had some builders in to our factory to do some work, and whenever they operated their heavy machinery such as drills and angle grinders, our LED lamps began to turn ON and OFF , -ie malfunction.

The micro  in the lamp is PIC16F18856.

The ones that malfunctioned had software in them which is written by our remote software contractor. We  actually loaded some of our own  simple software into the lamps, and this software did not malfunction. Our simple software simply repeatedly dims the lamp up and down.
Why did our software work fine, when our  contractor’s software malfunctioned?
Our simple software actually declares the ports to inputs or outputs  in just the same way as the contractor’s software…..the  difference was that our software does not  actually read from the ports declared as inputs.
There aren’t that many inputs to the microcontroller….just the DALI RX signal, the MCP9700 temperature sensor signal, and the SFH5711  light sensor signal.
Why did our contractors software malfunction, but our software did not malfunction?
Is there something about the universally available DALI software libraries which is overly noise sensitive? Maybe the DALI software libraries just read the DALI signal with one read per bit….instead of taking multiple reads during a bit  to really check that a bit is high or low…..ie, to check that a “high” or low  input isn’t just a noise-spike input.

Also, the builders have gone now, but we want to  buy something that will cause the problem again, so that we can  see how we can solve the problem….what equipment would you recommend to  get this kind of interference?…what about a laptop SMPS with its AC input filter removed?

[funkathustra]

We had some builders in to our factor to do some work, and whenever they operated their heavy machinery such as drills and angle grinders, our LED lamps began to turn ON and OFF , -ie malfunction.

That's not a sufficient problem description. Are the microcontrollers resetting? Or is the software running on the MCU intentionally causing them to turn on or off?

If the microcontroller is resetting, it's almost certainly an electrical problem. How are you powering the microcontroller? You should attach schematics of the device in question.

It sounds like you think it's a software issue, since you've loaded your own firmware on the board and you don't think they reset.

If it's a software issue, then you need to... look at the software and figure out what's going on?

As it stands, you haven't provided any sort of technical details about the electrical or software components of the system, so I'm not sure what you expect us to be able to help with.

Is there something about the universally available DALI software libraries which is overly noise sensitive? Maybe the DALI software libraries just read the DALI signal with one read per bit….instead of taking multiple reads during a bit  to really check that a bit is high or low…..ie, to check that a “high” or low  input isn’t just a noise-spike input.

Without knowing which "universally available DALI software libraries" you're talking about, there's little we can do to ascertain noise immunity for you. However, if you're getting that much noise on the DALI signal hitting the microcontroller, it sounds like you've got some major electrical issues you've got to work out. Again, where are the schematics of the design in question?

Also, the builders have gone now, but we want to  buy something that will cause the problem again, so that we can  see how we can solve the problem….what equipment would you recommend to  get this kind of interference?

...how about power tools?

[Ian.M]

All the tools you named would have universal motors and put out a lot of RFI due to arcing at the contactor. Additionally some would have PWM variable speed control.

The best bet would be a powerful variable speed drill, with a trigger that can be locked on and the speed adjusted with the trigger locked.  You'll also need a horizontal bench stand or clamp for it and a Prony brake or other load for it to get repeatable results.  Avoid side load on the drill output shaft - any brake that imposes a side load should have its own support bearings.  Another possibility is to brake it electrically e.g. use an adapter to square drive, then a socket onto the pulley nut of a small car alternator with its regulator removed. Some resilient sealant on the inside of the socket and its square drive hole will help cushion it.  Use a resistive load bank on the alternator DC out, and vary the load by driving the field coils with a variable PSU to vary the current through them.   Don't bog down the drill too much or you'll burn it out.

[ocset]

Or is the software running on the MCU intentionally causing them to turn on or off?

Thanks, no the lamps shoudl just be sitting at max power (40W), since we are not actually sending them DALI signals in this episode. They are turning on and off, kind of stuttering on and off, and they shold be on all the time, the stuttering was only happening when the builders were using the power drills etc.
Apparently power tools which use universal motors with contactor arcing are the best at recreating this kind of noise, but i wonder  how you know whether a drill has a universal motor in it or not..the datasheets dont tell  of this.

[Ian.M]

Universal motors are pretty much standard in drills, angle grinders, belt sanders etc.  Some fixed speed bench tools use induction motors. and some of the latest fanciest tools *may* use electronically commutated brushless motors.

For quick testing, drill a cross-hole a few inches from end of a length of wood,  such that a smooth steel shaft (that fits in the chuck)  is a very close sliding fit in the hole. Slit the end of the wood down through the centerline (axis) of the hole, and carrying on a couple of inches past it with a saw, and cross drill at right angles to the slit between the existing hole and the end to fit a coach bolt, washer and wing nut to clamp up the split so you can alter the friction on the shaft.  Don't run it too long as the steel shaft will get hot, eventually hot enough to burn the wood, and the heat conducted up the shaft may eventually damage the chuck.

For very quick testing drill a deep hole no more than 2/3 of the way through a block of wood with a large cheap bit (its going to get trashed), then reverse the drill so the bit is rubbing not cutting.  Same cautions about heat buildup apply.

Retail returns legal rights in the UK are fairly generous, so if your first choice of drill doesn't put out enough interference, or turns out not to have adjustable speed with the trigger locked on, take it back and get a different one.

N.B. you need a mains powered drill, not a battery one.

[cv007]

PIC16F18856

How is the contractor's software delivered to you? as a MPLBAX project, as a hex file?
I would be surprised if this was the case, but there is a compiler stack option that can cause problems (stack option - Reentrant, the Compiled option is normal and works). A quick check wouldn't hurt. If you have just the hex file, look for the sequence 7F08F000 in the first couple lines, and search for 7108FF00 which is the actual problem. If you have the MPLABX project, look at the project options, XC8 global options, Options Categories, stack options.

Like I said, it most likely is not the case, but if it is you could be hunting bugs forever.

If not, hire the builders to write your software, hire your contractor to run the heavy machinery

[KL27x]

the  difference was that our software does not  actually read from the ports declared as inputs.

This is something you might be able to check. If you're lucky, the lamp will stay on when you disconnect these inputs. And then you can try running the power drill to see if the flickering thing still happens.

It might be that one of the IC's that is outputting to the micro is being affected/reset/latched by the noise, and not the PIC. In this case it might be worth (in addition to fixing the hardware problem) having the firmware upgraded to handle such a potential issue without "wigging out."

[MarkF]

THIS SAME LAMP MALFUNCTION IS DISCUSSED IN ANOTHER THREAD BY THE SAME AUTHOR:

   PIC16F18856...small programs are less noise susceptible?

[forrestc]

The micro  in the lamp is PIC16F18856.

So these are some of the things which *may* cause a PIC to reset spontaneously, if that is what is occuring:

Voltage brownouts.  Incorrect MCLR circuitry.   Not disabling MCLR in software config bits if it isn't used.   

The ones that malfunctioned had software in them which is written by our remote software contractor. We  actually loaded some of our own  simple software into the lamps, and this software did not malfunction. Our simple software simply repeatedly dims the lamp up and down.
Why did our software work fine, when our  contractor’s software malfunctioned?

If the micro is resetting, there is a good chance that your code is simple enough that you don't notice the issues.   Or the config bits are misconfigured.  Or dozens of different options.

Our simple software actually declares the ports to inputs or outputs  in just the same way as the contractor’s software…..the  difference was that our software does not  actually read from the ports declared as inputs.   There aren’t that many inputs to the microcontroller….just the DALI RX signal, the MCP9700 temperature sensor signal, and the SFH5711  light sensor signal.
Why did our contractors software malfunction, but our software did not malfunction?

How are the other inputs used?   The sensors you described seem like ones used to adjust the amount of drive given to the LED's.  I.E. if they get too hot, shut them down.   If the noise from the grinders affect the temperature sensor and it's used to control the led's, then that could be a cause.   But without knowing how the software is designed, then it's hard to tell if it's software or hardware.

Is there something about the universally available DALI software libraries which is overly noise sensitive? Maybe the DALI software libraries just read the DALI signal with one read per bit….instead of taking multiple reads during a bit  to really check that a bit is high or low…..ie, to check that a “high” or low  input isn’t just a noise-spike input.

Edit: Dali has checksums in it to avoid this issue (someone please correct me if I'm wrong here - couldn't find my DALI protocol spec to verify my sometimes faulty memory).  Assuming the checksums are being checked, this is the one thing which isn't likely to be the problem.  Apparently I'm wrong....   DALI doesn't have checksums (thank you NorthGuy, and I found the rough spec I had which confirms this)....   Which means noise coming in on the dali line could cause this issue....   See NorthGuy's response.

Also, the builders have gone now, but we want to  buy something that will cause the problem again, so that we can  see how we can solve the problem….what equipment would you recommend to  get this kind of interference?…what about a laptop SMPS with its AC input filter removed?

A laptop won't be putting out the level of EMI interference the heavy equipment was.   YOu may just want to find a used grinder or similar.   

[NorthGuy]

Thanks, no the lamps shoudl just be sitting at max power (40W), since we are not actually sending them DALI signals in this episode.

What do you mean by that? Are DALI inputs left floating picking up noise, or are they still connected to the DALI bus? Is there any noise on the DALI bus? If there's any noise, the program you use to interpret DALI commands will be interpreting the noise 24/7 and some of the noise will look like DALI commands to your software. DALI doesn't have CRC, so the random noise will eventually produce some valid commands and your lamp will react. You need to check your connection to the DALI bus, making sure it doesn't pick any noise. Also, you may need to make your software more robust rejecting all possible malfunctions on the DALI input except for very clean transmissions.

[Ian.M]

A laptop won't be putting out the level of EMI interference the heavy equipment was.   YOu may just want to find a used grinder or similar.   

As I said earlier, the best bet for comparable interference is a beefy contractor grade drill.   Its safer to set up in a bench jig with a mechanical load than an angle grinder would be, is more likely to have trigger lock and variable speed, and afterwards is likely to be more useful around the workshop.  To load an angle grinder you actually need to cut or grind something and that will make an incredible amount of mess.   If you don't load the tool, its universal motor will draw far less current and produce less interference.

[dmills]

Dali is SLOW, so one possibly diagnostic question is over what timescale were the lights changing?

If it was fast flicker then it probably was not getting in via the DALI serial interface, but may have been causing interference to the light sensor or the temperature sensor, can you tweak the real software to take these out of play temporarily? The way to debug such things is to disable bits of the functionality in software then rebuild, reprogram and retest, you only have a few peripherals so it should not take long.

Remember also that large power tools will cause the mains to sag as they start up, and the sag is limited to not impact tungsten lighting too badly, but I bet your LEDs don't have that kind of time constant, and depending on what your designed LED string voltage is, such sag may well take the diodes pretty much out of conduction....

Plenty of vacuum cleaners have universal motors, get one from a charity shop and dyke out the interference suppression cap, plenty of HF interference then, but before going bug hunting make sure you can reproduce the fault, that is always the first step. You may find that an EMC lab can do some susceptibility testing that may be helpful in this. 

Regards, Dan.

[ocset]

Thanks, the DALI input pin has a 10k pullup resistor.
The temp sensor is an MCP9700 which has a low Z buffered output.
The light sensor is SFH5711 and we put a 100p cap at the micro pin where it comes in.
The micro is well decoupled with 20uF ceramic..plus a 100n cermic SMD right at its Vdd pin.

How is the contractor's software delivered to you? as a MPLBAX project, as a hex file?
I would be surprised if this was the case, but there is a compiler stack option that can cause problems (stack option - Reentrant, the Compiled option is normal and works). A quick check wouldn't hurt. If you have just the hex file, look for the sequence 7F08F000 in the first couple lines, and search for 7108FF00 which is the actual problem. If you have the MPLABX project, look at the project options, XC8 global options, Options Categories, stack options.

He sends us MPLABX  project, with code written in XC8 C.

[NorthGuy]

10K pullup? DALI voltage is supposed to be way higher than PIC can tolerate. Do you have any connecting circuit, optoisolator perhaps?

Do you have a scope? Or logic analyzer? Can you look at the DALI input pin and see if you have anything changing there during normal operation or when you operate power tools in the vicinity?

[ocset]

10K pullup? DALI voltage is supposed to be way higher than PIC can tolerate. Do you have any connecting circuit, optoisolator perhaps?

Thanks, yes theres an opto from the DALI bus

If you have the MPLABX project, look at the project options, XC8 global options, Options Categories, stack options.

Thanks, i have the MPLABX project, but dont see anywhere where i can examine "project options".?

A quick check wouldn't hurt. If you have just the hex file, look for the sequence 7F08F000 in the first couple lines, and search for 7108FF00 which is the actual problem.

Thanks, i cant find either of those in the hex
I can find "7F08FD00" as being the nearest to those....its in the second  line down.

[cv007]

Thanks, i have the MPLABX project, but dont see anywhere where i can examine "project options".?

File->Project Properties
XC8 global options (in Categories on left)
Stack options (selected in drop-down beside Option categories)
Stack type should be 'Compiled'

[NorthGuy]

Thanks, yes theres an opto from the DALI bus

Then you need to see if you get some noise on the bus first. Then look at the noise on the PIC's side of the isolator. If you don't have a scope, you can buy a really cheap toy scope for $30 - it'll be fine for 9600 baud.

[ocset]

If you don't have a scope, you can buy a really cheap toy scope for $30 - it'll be fine for 9600 baud.

Thanks, in UK, the cheapest "toy" scope you can get  is about £80.....there is nothing cheaper, woudl be very grateful for any links you may have?

[wraper]

Isn't there some I/O set as input without pull-up? Brown out detection set to higher voltage level than in your simple firmware? Or your firmware may have it not enabled at all. Also it could be how MCLR pin is enabled in contractor firmware but set as I/O in your firmware.

[wraper]

Or it could be that noise in received data makes some loop runing longer than normal or not exit because of the bug and watchdog resets the MCU.

[NorthGuy]

If you don't have a scope, you can buy a really cheap toy scope for $30 - it'll be fine for 9600 baud.

Thanks, in UK, the cheapest "toy" scope you can get  is about £80.....there is nothing cheaper, woudl be very grateful for any links you may have?

http://www.amazon.co.uk

Search for DSO138

[dmills]

  £60 or so would have gotten you a quite usable old Tek at the Kempton rally a few hours ago, and £30 would probably have gotten you an old Gould or Phillips instrument that would be just fine for this sort of thing.

That is less then a days wages for anyone working in this game, and is **BASIC** required instrumentation for developing anything.

As to your problem, start by making sure you can reproduce on demand, universal motor under load with the filter caps removed, should do it..., then disable inputs in software until you figure out where it is getting in, you only have a few inputs so this should only take an hour or so tops. 

You seem to have more RFI and EMC issues then any other three engineers I know put together!

regards,  Dan.

[wraper]

Frankly, I would never buy something from a company which does not even have a scope to check their design. What I'm wondering about is if you don't have a money for an oscilloscope or a half decent coder, then how are you supposed to certify those LED lamps for safety?