Issues with new project - hardware or software ?

[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.