Home     Contact     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS     Terms of services     Privacy policy  
   
 Home      Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science   

26 January 2010
Author: Giorgos Lazaridis
PC System Health Monitor



Worklog - It's a decentralized system (January 26 2010)
What i mean by "decentralized system" is that there will not be a single HUGE micro-controller that will check all the temperatures and the fans. That would be impossible with just one PIC. First of all, i need one PWM output dedicated to one fan. And if this PIC fails, the whole system will fail. Instead, i plan to use multiple small (and cheap) PICs that each one will do a certain job. Implementing a decentralized system, will give me the following profits:

  • Increased system reliability
  • Ease of system upgrading
  • Faster sampling rate for each module
  • Easier trouble-shooting


Look at the following chart of this system. Please note that this chart may change AND more modules will be added in the near future:





Now you've got a better view of the "Decentralized system". The PIC 16F1937 reads the data from the other modules through the Local BUS or directly from the A/D inputs of the PIC. Each module will take care of itself and will answer to the Master ( PIC 16F1937 ) when it is asked. The fan module for example will receive once the speed to set the fan and will not occupy the LCB (Local BUS) any more, unless the master asks for example the speed of the fan or send a new speed setting. In case of emergency (fan failure for example), the fan module will request the master attention and will send the error number.





BANIS?? Where are the bunnies??

If you have seen the above photo, you may have notice a "BANIS" BUS. I am not going to extensively describe this bus, as this has nothing to do with this project (almost nothing). This BUS is a completely insulated BUS that runs Between All Negotiating Identifiable Subscribers (A.K.A. BANIS). An Identifiable Subscribers is a device with a unique ID. One device is the PC System Health Monitor for example. Each device will be able to negotiate with another device bi-directional.

Let me give you a quick example. There are 3 subscribers in the BANIS, a weather station (ID=1), the PC Health Monitor (ID=2) and a color monitor (ID=3). Each one is acting as a stand-alone device and may have no interference with the other subscribers. But through the BANIS, the monitor for example may request data from the other two subscribers, and then display them in a neat color monitor on the desktop... Neat? Moreover, all subscribers are powered through the BANIS network! Here is a graphical example of a BANIS network:





For my production capability and free research time, this is a rather HUGE network, but hey, "A journey of a thousand miles begins with a single step" (Lao Tse)












Comments

  Name

  Email (shall not be published)

  Website

Notify me of new posts via email


Write your comments below:
BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.


      

  • At 14 February 2010, 17:23:23 user Kammenos wrote:   [reply @ Kammenos]
      • I should have mention it in the article. I may add it later on. I add the cap because i could not drive with PWM this fan and get rpm feedback at low rpms. I have face the stall problem myself using other fans. But this fan has not any particular problem by reducing the voltage. After all, i will never drive them below 800rpms. And this circuit can go even lower w/o stalling the fan.
      Actually, the problem with PWM was that (maybe you have face it also) from lower to higher rpms, the duty cycle was changed only a couple of steps %. I tried from very low frequencies up to very high frequencies, still the regulation was terrible. That's the reason for this cap.

  • At 14 February 2010, 16:41:19 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
      • I have not even had time to build your initial circuit - I\'m too busy supporting our original speed controller and designing a new temperature controller right now but will get to this soon. And when I do I\'ll send you the results.

      I see that you have added a 470uF cap across your FET, converting your PWM back to a noisy switching power supply. Can you explain why you added the cap?

      We tried a cap across our switching tansistor but found that the motor tended to stall at lower RPMs. But we did come up with a design using a smaller cap & second resistor in the power transisitor drive circuit that stretches the transistor on ramp and reduces the on-pulse kick from a loud growl to very soft pulses. This change would not work with your circuit because you are running at a much higher frequency than we are.

  • At 14 February 2010, 12:35:41 user Kammenos wrote:   [reply @ Kammenos]
      • Tom, i posted the new circuit. Will you test it with your fans? I look forward to hear the results.

  • At 13 February 2010, 14:37:54 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
      • I realized after my last post that my logic behind sampling only when the fan is on flawed. With your higher frequency design, your RPM pulse train is slower than your drive frequency. To make this design work for you, you would need to convert the incoming RPM pulse into a shutter or gate then count the number of PWM pulses riding in on the pulse. And since the PWM frequency is a constant, you can translate the PWM pulse count into RPM.

  • At 13 February 2010, 7:40:56 user Kammenos wrote:   [reply @ Kammenos]
      • Yes, i changes the 4049 with an 741 that i have in stock. The reason for the 741, is that i have a lot of them to foll around. I will post the circuit or course.
      As for the second post, i suppose that this would work as well. This will dramatically reduce of course the signal reading interval(i read about once a second) because then it would be very hard to keep the rpm low.
      Will you try this? If you do, please post the results.

  • At 13 February 2010, 2:57:29 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
      • I was sitting here looking at my O'Scope and eating my Dominos Pizza when the real solution just came to me!

      Instead of trying to condition the short pulses that occur when the fan is off, you should restrict your speed measurements to only when the fan is on. I'm assuming you can trigger a internal loop on the rising edge of the PWM on pulse? Then you can count incoming tach pulses across a fixed time window and calculate the fan's RPM from the pulse count. You may end up slowing your frequency back down in order to provide a wide enough window to measure your fan speed at all settings. You can even use a tach output pull-up resistor that's tied to your controller's 5V rail, possibly eliminating any need for signal conditioning.

  • At 13 February 2010, 1:33:32 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
      • You don't state in the text but I assume you replace the circuit you built around the 4049N with your LM741 based trigger circuit? At least the components on your board supports this.

      It's been a long time since I designed anything around a LM741 OP Amp and the design is getting old. Maybe you can design the entire analog side around one LM324 OP Amp or if you want to stay with two 8 pin packages, something more efficient like a TLE2021?



    delicious
    digg
    reddit this Reddit this
    Faves



     HOT in heaven!


    NEW in heaven!



    New Theory: AC electric motor working principle


     Contact     Forum     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS   

    Site design: Giorgos Lazaridis
    © Copyright 2008
    Please read the Terms of services and the Privacy policy