Temperature, Again, with Project Zip Archive!

Update: I had neglected to include the project archive. It is downloadable here.  

I created a new temperature back case to be 3d printed, and printed a new cover in white, with less “rough” settings for the printer. It came out quite nicely. I moved the temperature unit into another room, and let it work with my AC/Heat Pump unit. Since it is winter here, at night I dial it down to 65, and during the day up to 71 or so. So far, so good. (Later, I hope to add the Real Time Clock and change temperature automatically.)

I printed a new white front and back, for another room. I also made a few changes to the code for issues I saw during testing. I only send 20 or so down or up commands when switching from OK to “Temp Too High” or “Temp Too Low.” If the temperature remains too high or low, it only sends one up or down pulse after the timeout period. This keeps people in the room from being distracted, and yet allows recovery from “blocked” IR pulses. People walking through a room or modifying the unit’s settings can upset the control function, so it sends a single pulse out from time to time to slowly take back control of the unit.

Heat Mode, OOPS!

I also found that the “heat” mode in the controller was not working right. I traced the problem to an incorrect variable in the state machine when setting temperature on the Nextion. I had set the state machine variable to 4, which started the state machine at updating the cool temperature. It should have started a 3, which updated both. With that one line change in the up and down arrow sections in the Nextion IDE, that part of the unit works now. You can see the change under the comment “update the PSOC now” in the code following:

Now Sending Heat Temperature (global config state 3) as well as Cool Temperature

Solder Flux Cleaning Trick

About 3 years ago, I was able to pick up a significant (in my mind) tip from a assembly guru. She showed me that to properly clean flux off of a board by hand, you needed to put a thin, strong, tissue on the board after the flux cleaning solution was applied. You then scrub the board with your brush, through the tissue. Magic! The tissue absorbs the flux and cleaning solution.

Enter the world of 2020. Hand sanitizer is everywhere. Most flux cleaning solutions are solvent based, and Hand sanitizer is alcohol with a gel binding agent. Hmm. I tested it, and it works!

Here is a photo of my board building setup in just a few inches of workspace. It is sitting on 8 1/2 by 11 inch printer paper. (Also good for taking notes):

Board Workspace with flux Cleaner

It turns out that the hand sanitizer in the photo (with the fresh fruit smell) works well. With testing, I found that the residue left over DOES NOT conduct electricity. Infinite ohms.

The toothbrush is used to clean through the tissue. For my tissue, I use Bounty half-sheet paper towels! Hmm, maybe thin tissue is not a requirement. Regardless, it worked well. This discovery allows me to solder pins onto the PSOC and end up with no messy flux left over once cleaned. Nice.

Temperature Code Modifications

I started this unit up, and found that it started at 154 degrees, and immediately decided the temperature was too high. No Good!

After some experimentation, I set up to read the temperature in the init_TemperatureControl() function:

//----------------------------------------------------------
// initialize for operation
//----------------------------------------------------------
void init_TemperatureControl(){
    
    ACControlState=StateTemperatureStart;
    temperatureOffset= 0.5f;
    temperatureRange = 0.5f; // 0.5 makes 71 setting toggle at 70 or 72 due to offset.   
    debugPrint=YES;// during debug
    // fix unusual beginning high temperature
    sendCountDownTextToNextion(decisionTimer);
    do {
        temperature=
              getTemperatureF(&TemperatureReadingAvailable);
    } while (!TemperatureReadingAvailable);
    
    extern void sendTemperatureToNextion();
    sendTemperatureToNextion();
}

I also re-arranged the startup code in main() in order to get the temperature taken care of soon, and to update the Nextion when it was appropriate. I also changed the blink rate of the LED on the PSOC. At night, you can see it blink, so a rate of once a second is better for me:

int main(void)
{
    int16 bufNum;
    USBSerialMessage *USBRxPtr;
    temperature=70.0;
    init_leds();// do any led setup
    init_milliseconds();// setup the millisecond timer

    seconds=30;
    extern int32 decisionTimer;// TemperatureControl.c
    decisionTimer=1;  // only wait 30 secs after power up.

    CyGlobalIntEnable;  /* Uncomment this line to enable global interrupts. */
     initialize_1_wire_device();// set up the temperature device
    
    Nextion_interface_init();// intialize RS232 for nextion
    init_TemperatureControl();
    initUSBSerial();// setup the USB serial interface.
    
    init_capture();// set up the I/R Capture hardware
    init_playIR(); // initialize the ir playback
    
    for(;;)
    {
        //======================
        // status led
        //======================
       if (OneWireResetResults==0xff){
          Blue_LED_Write(1);// one wire device is bad
        } else {
            BlinkLed1(1000);//
        }
        
        //===========================
        // if the user has chosen to 
        // read the I/R controller.
        //===========================
        handle_capture();
        
        //======================
        // usb serial port
        //======================
        if ((bufNum=handleUSBSerial())>=0){
            USBRxPtr=&USBRxBuffer[bufNum];
           parse((char*)(USBRxPtr->msg),&(USBRxPtr->size)); // handle possible command   
        }
        
           
        //======================
        // nextion
        //======================
        handle_Nextion_interface(); // update the display if needed

        handle_playIR(); // handles scheduling of ir commands
        
        handle_TemperatureControl(); // in this code, we actually control the A/C unit
        }
      
    
}

In addition, I created a FlipLed() function and put a call to it in the IR transmit code. Now you can see from the PSOC side when the IR is active (the light blinks quite a bit faster).

Future Time

I plan to put the code on GitHub, along with the updated files for the case. I will update via this blog when that happens.

3d Printer Note

I will continue on with the 3d printer project. I have version 1.1 of the CY8CKit-059 to Ramps 1.4 carrier board done, and am working on the code for it. Once that board is at the right point in the process, I will put it on GitHub.

This project is slowly progressing, mainly because writing a 3d printer from scratch is difficult. Thousands of details. There are several reasons for a re-write:

First the current 3d printer code was written by people way smarter than me. It is convoluted, obtuse, and written by experts in C/C++. They proved their intelligence in the code, using compiler functions that I have never needed to know or research. I tend to look at that code sideways.

Second, the code is heavily tied to the Atmel device. That is not a problem. It *has* to be! There are some attempts to divorce the code from a specific MCU, but the results are strange to me, and may have issues.

Third, the code has so many #ifdef’s in it that it is very difficult to wade through the code while reading and determine exactly which code is being used at any point in time. This is in addition to the special compiler features.

Fourth, the code is trying to perform many of the same functions as an RTOS would perform, but using a main loop and function calls. (I wrote a multitasking system using a main loop about 30 years ago. In the decade previous to that, I ported a real time OS (Vertex) to DOS and into Protected Mode, and created simple compilers for data transformation in the Telecommunication Industry.)

When I saw what had organically grown in the 3d printer space, I groaned. Don’t misunderstand me. The 3d printer code works, and works well! It is also extremely difficult to maintain and port.

Therefore, I am basing this code FreeRTOS. I am also re-writing the code to be more clear and more linear in each subsection. I have also transformed the design to a message based design.

Messages or events cause messages to be processed or sent. Messages cause things to happen. The FreeRTOS facilities, which include Queues, Semaphores, Task Management, and Memory Management allow the use of native MCU Interrupts and other features of the MCU the code is embedded into.

Finally, I am using no code from any GPL’d project. I am using MIT and apache code when it makes sense. It will be a long process, but in the end, I believe it will be worth it.

Personally, I want to be able to use this code in other projects, commercially. I will release it as GPL v3, however, so that 3d printer people can enjoy using with a PSOC. The possibilities for modification after that are enormous, due to the Digital and Analog Fabric inside the PSOC 5 family.

Current 3d Printer Status

I currently have the platform heater working well enough to use (it uses PID Controller technology), as well as the extruder heater.

In addition, the PSOC Digital fabric control circuitry for the stepper motors is where I want it to be, and has been logic analyzer tested. The Speed Ramp code for the Steppers is done and partially tested. Next step is to attache to the RAMPS v1.4 board and test with a very old printer that is sitting around (a Mosaic).

Most of the G-Code interpreter commands are written, and partially tested.

One of the difficult parts of this project is allowing the use of the CY8CKit-059 without modification with a Ramps v1.4 board. Several capacitors are soldered onto the CY8CKit-059 board, and those lines cannot be used for digital functions.

Next Time

I hope to start laying out the information for using the CY8CKit-059 on a Ramps v1.4 board.

Enjoy!

Add a Comment

Your email address will not be published.