iced98lx
New member
Display or not...
That is where I am torn. I flunder back and forth between embedded solutions and PC based solutions and with a hybrid solution in between . I am still leaning toward individual autonoums controllers for dosing, lighting, top-off, all reporting to the PC based solution for logging and/or user initiated updates or overrides. The idea of a single "life support" controller is not something I have ever been comfortable with.
The alure of the netduino is the event driven .NET foundation and the ease of allowing it to communicate via TCP/IP to the host controller.
I've toyed with the idea of a PC based solution more and more after you started running ideas around here
I keep coming back to the following realizations:
- My return pump is on a 'normally on' relay, i feel better knowing that with the controller off the pump runs
- ATO function is based on a normally closed relay, has a few fall backs and is pulling from a limited volume
- if the heat was out, my T4 return pump will likely keep things mostly alive
- the LED's default to off with resistors inline on the PWM lines
Controller off = dark, cooling tank with return flow still flowing.
I did solve my LCD + LED issues by putting the LED power supply not on a relay. I'll try a loop and adding a ground to the power supply, see if I can isolate it enough to stop behaving badly. I'd rather have the LED power supply in an 'always off' relay vs counting on the resistors onboard to sink the PWM pins.
As for the display- I added it primarily because I wanted to play with one and an i2c based one seemed ideal (it's functioned well). I also figured if I added it to see the basic current status I wouldn't feel the need to setup a webserver on the Netdunio (headache for me, I prefer not to) and could focus on generating web requests that had the payload data vs responding to requests. This simplified things a bunch, frankly. If I do anything I'll probably create a windows desktop program that does 2 way communication on a low level to get status and command changes. I can get 'commanded' changes from a webserver on a timed basis within the response of a webrequest without the added overhead of running a web server, so If I really wanted to turn off the skimmer remotely for instance, I could.

