More problems, but maybe not my fault?

So I had to make a new heater core to accommodate a second heating resistor because of some problems with stabilizing the temperature, and that I think I had uneven heat distribution causing a clog that eventually burned a little making the old barrel very dirty. I then worked with my father to generate a new barrel/tip combination similar to that done by makerbot on their new MK5 extruder. I now have a steel barrel going to the heater block, and a brass tip made from a MIG welding tip that we retrofitted to fit our needs. The block is now more of an I-beam with the barrel running through the middle of the I and one resistor located within each of the side openings.

This then lead me to my test the new heater, which I discovered quickly could not be run through the extruder board but had to be run through the relay board, which I had been trying to use due to its own little problem. So I looked into that problem to see what was behind it. I found that it had to deal with the firmware update and how they were dealing with slowing the heater as it reached the set temperature by cycling the power on and off for shorter periods of time so that it wasn’t being constantly driven and overshooting the set temperature by a good deal. Either the waveform they decided to generate didn’t have high enough bounds or the signal was picking up a lot of static or interference, and this caused the signal to cross the working thresholds of the relay. This made the relay switch at very high speeds causing a loud and annoying screeching noise as well as never allowing the system to reach the set point before it gave up and allowed to go into the cooling cycle before kicking the heater on. This would be similar to using cheap push button and it seeming to have multiple presses when only pushed once by a phenomena known as “bouncing”. This can be solved in software or hardware and its much cheaper to solve this with software. To debounce the system allow the software to only send an output and/or receive and input within a set period of time before being allowed to react, this allows the signal to settle before the next test cycle occurs removing many of the erroneous signals that may become present.

Due to the fact that I know nothing of the software environment of the system I can’t readily solve this problem without learning a lot of about the system, but I could create a hardware solution to hopefully solve the problem. I’m hoping the folks over at makerbot will be able to send out a firmware update soon so I don’t need to buy components to make a solution with hardware to solve this minor shortcoming.