Issues with new project - hardware or software ?

[Scampy]

Guys, need some help.

I'm working on a project of a single channel pulse proportional thermostat. For those that may not know, I already have a four channel version which has been running in various versions since 2009 (the original never missed a beat in 5 years), so the original concept was to simply take a version of the 4 channel code and edit it to remove the references to channels 2,3, and 4, and after after a week or so I had a polished version of the code running on the EasyPIC5 development board. I left it running whils I drafted the schematic, produced a board layout and sent the gerbers off to China and received five of them back a week later. I built one of the boards and then tested it by using my bench top PSU built from a converted computer power supply - the board appeared to function OK - I got text on the LCD and so I removed the power and spent a day building the project in an ABS case and wiring it up (see attached).

On powering the device from a small switch mode power supply purchased from e-bay all I got on the LCD was DT to indicate it was in daytime mode, and a flashing asterisk that indicates the alarms are set. Resetting the PIC had no affect. Removed the PIC and tested it on the EP5 board - worked fine. So I spent a day messing about with power supplies from a standard linear regulator to another switch mode device - still no joy. One suggestion from a friend was that I need to make all unused pins outputs which I tried and still I had issues, so I thought it might be a grounding issue (the board doesn't have a ground plane) so I grounded all unused pins - still couldn't get it to work.

So I've just started again, with a fresh PIC - I've edited some code and now I'm getting less garbage on the LCD - and it's a little more stable ... but not usable. When it powers up now - it displays a splash screen stating the version of software loaded and then jumps to the main screen displaying the current temperature, DT or NT if the unit is in daytime or night time mode, flashing asterisk to indicate the alarms are on, and then on the second line, the set target temperature and current time from an RTC (ds1307). But this lasts for a variable length of time before the current temperature and time freeze but the flashing asterisk is still flashing. When the display of temperature and time become static the output to the heater is turned off, so at least the fail safe works. I have another 18F4620 running the same code on the easyPIC5 board, and reset both the unit and EP5 board at the same time. The PIC on the easyPIC5 board has been running for the past hour, but the one running in the unit lasted 11 minutes before the fault happened. I've also tried setting the time via the menu option and 3 out of 4 times the unit locked up, displaying 0:00: for the time ... I've reset the unit again, whilst I've been typing this post and we're up to 12 minutes and it's still running...

I've not posted the code here as it clearly works, and the failure seems to be at random periods...but would like to hear from anyone who has ideas on things to try in order to make this more stable

[Jerson]

Since the code seems to work for random periods of time, since you have already checked with different power supplies and since the code runs on an EP5 board, my guess is that there is something specific you have tweaked to run the code on this board. In the process, you may have unknowingly edited some inline assembler (most likely if you've used DTs code) and maybe missed an instruction or two somewhere. This seems like the 31 level stack is piling up but not unwinding leading to a gradual failure.

You might want to re-look at your code with this in mind.

[Scampy]

Thanks for the reply, most of which went straight over my head !

I've uncommented the sections that were commented out from the 4ch version, so now the only thing that is different from the original 4ch version I used in this instant is a change to the LCD routine that simply displays the first channel and ignore the rest, and the menu for setting time and values so that it only loops round one time and not four for things like setting the target temp. It's now been set running, so will see if it's still running on the EP5 board in the morning, and if it's still showing the correct time.

My gut feeling is one of the following :

• The code was developed using PID libraries written by two other forum members - Whilst it was written for four channels, and had a means of running with just one channel by setting the value of a constant between 1 and 4, it was never tested using a single channel setting - so possibly a bug exists in the library file.
• The code needs all four channels, and by editing the code to remove channels 2,3,4 in parts of the main program, the library files are still functioning as if it's running 4 channels and something somewhere is corrupting, it's as if one of the interrupts isn't resetting when it overflows, and its filling up, and when it reaches it no longer runs that part of the code... The actual PIC must still be running because of the code

If alarm=1 then LCDOUT $FE,$80 + 15,("*"&FlashStar*$FF)|(" "&~(FlashStar*$FF)) ; flash a star to show sample time, but used to indicate Alarm settings monitored
    FlashStar = !FlashStar 
endif

My theory is that if the PIC wasn't running then this flashing asterisk would also stop. Anyway I squirted the re-compiled code to the PIC and left it running on the development board at 1am last night. This morning it was still running so I've placed the chip in the unit and will see how it goes. One thing I noticed is that I currently don't have a switch on the unit so it powers up when the plug is pushed into the mains socket, it took three attempts to get it to run stable without the temp and time display freezing with just the asterisk flashing... on most cases it would display the firmware version splash screen, then clear the screen and display the temp / time etc, and then reboot... but once it came back I could press the reset button (MCLR) and it then came back and would run fine...The MCLR pin is tied high via a 10K resistor, with push button to reset via grounding the MCLR pin. Could there be any reason's why the PIC resets / freezes like this on first power up.

[HenrikOlsson]

Hi,
As the author of the PID code I will say that there might of course be an issue with it, especially when it's usel for what it wasn't intended.

It should work byt my suggestion is to use the original PID routine which IS single channel. It'll also be smaller and run faster since there's no convoluted array indexing.

/Henrik.

[Jerson]

Is it possible that decoupling capacitors are not installed?

[Scampy]

@Jerson - Decoupling caps are connected directly across the power pins at the PIC and across the DS1307.

@Henrik, I'll have to search through some old backups as I all the development versions I have are multi-channel.... I still have the original e-mails from DT relating to the project so there is a slim possibility the attachments are still available... I wasn't suggesting the PID routine was buggy, just that whilst I changed the CON setting from 4 to 1 in the main code - strange things were still occurring, and as I wanted 4 routines running at the same time I never thought to test that option..

I'm still getting resets and strange things happening to the clock (even though the clock routine is the same from code that works fine in the current vivarium controller) - like it changes to 08:00 hrs when it reaches 16:00 hrs and 10:00 when turning 17:00 - but so far it's still running the PID routine and has done for three hours now... but I still wouldn't use it to control the heaters !

[HenrikOlsson]

Hi,
Provided the hardware is sound I suspect you're writing outside of an array or something like that, corrupting whatever is there. You know that PBP doesn't verify the bounds of an array so it's perfectly valid to say myArray[6] =123 even though myArray is only 3 bytes long. It will then, obviously, overwrite something else - whatever is at that memory location.

It is of course possible that the multi channel PID routine, which IS using arrays, is doing just that (in error of course) but then I would suspect it misbehaving in when doing multiple channels as well.

Anyway, the single channel version is available on the in post #57 in this thread. I strongly suggest you read that thread as well since it covers a lot of details on how it's implemented, how it handles negative numbers, what to do when you don't want "negtative drive" (which is the case in your case) and so on.

Or, you're just getting bad reads from the clock chip.....there are a lot of DIP switches to configure those developmement boards. Are you sure you don't have something "cross connected" or whatever?

/Henrik.

[Scampy]

I've spent so many days now trying to resolve this that I went back to basics and wrote a basic bit of code that didn't rely on interupts or have any of the include files.. It powered up 1st time and seems very stable - I'll let it run for a day or so to confirm... but it did seem that it was a software issue that was causing my issues.

If I get time, I might look at the PID that's in post #57, but my deadline for this project is running out and I don't think I have enough of a window in which to complete a new PID based version.