sparkybg / unisolder-5.2 Goto Github PK

I used mplab-v6.1.5 xc32-v4.35(free) and the compilation failed. What version do you use?

A lot of components have gone up in price and/or are no longer available. Currently it is almost impossible to make a unisolder.
By open sourcing the PCBs, updates to the BOMs and footprints would bring the project back, as well as add new features (rotary encoder, larger displays, tip grounding with a GPIO instead of an IR system).

Dear Unisolderers, can you please explain to me what makes a Meanwell RPS-120-24 a worse power supply than a toroidal transformer? Thanks you!

We have an elusive problem on our FabLab with Unisolder where the wrong tip is detected, and this resulted in a burned tip. Troubleshooting has not been successfull. We would like to implement a software workaround, and I open this issue for advice.

I was thinking to add a parameter to disable the auto-detection in IronIdentify() function, with a logic as follows:

1. if a new tip is detected, different from the last model saved in EEPROM
2. check if the auto-detect parameter is enabled, if YES -> keep the existing logic
3. if NO, set a global variable to flash on the screen the "auto-detect disabled" message and keep old tip ID

Other changes required:

• Edit pars / eprom accordingly
• Add saving in EPROM at poweroff of the last valid tip

Potential design issue:

• Behaviour in case of this sequence : old tip -> 0x1919 -> new tip . Should we keep the old tip ? Allow autodetect if tip has been disconnected? Maybe we will have spurious changes anyways.

Alternative design:

• add a parameter to allow setup a fixed IronID and bypass detection ?

Thanks for your feedback about the kind of solution to this problem would you be open to merge as pull request.

Hi,

Any chance you could compile a list of other processors the code will run on. For instance are any of these OK ?

All are TQFP64 but from higher up the family tree.

PIC32MX575F256H
PIC32MX575F512H

PIC32MX664F128H
PIC32MX675F256H
PIC32MX675F512H
PIC32MX695F512H

PIC32MX764F128H
PIC32MX775F256H
PIC32MX775F512H
PIC32MX795F512H

Thanks.

Problem appeared in 2020.06 release, but I'm observing it in current master as well.
The tip quickly goes red, but the controller still thinks it's at room temperature.
It works correctly after reverting back to previous release.
Using C210, MX564F128H.

Can be useful show the loaded firmware version somewhere, maybe in the calibration or in the info menu. In this way not only it's easy to know which firmware is currently running, but also aknowledge a correct firmware update.

Is this a fault code? Do you have the corresponding documents?

Hi there, I'm working on a controller of my own (nothing wrong with unisolder, just too complex for me :) ) and wanted to find what exact thermocouple type is on the C245 series cartridges by JBC. I've done quite a bit of research I finally think it's a so-called type M thermocouple (Ni/Mo - Ni/Co), because at the temperature these cartridges were calibrated at (I understand that would be 183ºC for 63/37 solder) this type of thermocouple has the exact same EMF output as unisolder would expect (using 43,5uV/ºC). It would also fit all the descriptions of the materials I've been able to find. Attached is a graph I made for reference.

What I wanted to ask, seeing that you worked with both pure lead and 63/37, is whether the TC output was observed to be strictly linear or if when calibrated at 183 °C the station displayed a temperature higher than real at 327,5 °C (melting lead).

I'm happy to close this issue if deemed inappropriate, thanks in advance.

5.2C front schematic shows 100nF power decoupling cap ganged together downstream, across all of the uC inputs.

PCB shows caps dedicated to each of the pins 10, 19, 26, 38, 57 as would be expected.

Please confirm the schem should be corrected.

This is actual code
if(DisplaySetup.SH1106){
PreUpdateBuff.PreRowUpdate.ColLow = 2; //SSH1106 is 131x64 - shift right by 2
mcuSPISendByte(0x8D); //charge pump control
mcuSPISendByte(DisplaySetup.InternalChargePump ? 0x14 : 0x10);
}
else{
PreUpdateBuff.PreRowUpdate.ColLow = 0; //SSD1306 is 128x64 - no need to shift
mcuSPISendByte(0xAD); //charge pump control
mcuSPISendByte(DisplaySetup.InternalChargePump ? 0x8B : 0x8A);
}

Correct is
if(DisplaySetup.SH1106){
PreUpdateBuff.PreRowUpdate.ColLow = 2; //SSH1106 is 131x64 - shift right by 2
mcuSPISendByte(0xAD); //charge pump control
mcuSPISendByte(DisplaySetup.InternalChargePump ? 0x8B : 0x8A);
}
else{
PreUpdateBuff.PreRowUpdate.ColLow = 0; //SSD1306 is 128x64 - no need to shift
mcuSPISendByte(0x8D); //charge pump control
mcuSPISendByte(DisplaySetup.InternalChargePump ? 0x14 : 0x10);
}