Hofmann geodyna 6300 Wheel balancer

[Grouickman]

Ho crap... I just noticed the Line Freq input is missing a pad on the connector socket, it got ripped when I removed the connector from the board to put it on the hot plate.

Could it be... the pad was already damaged, and the "line Freq" signal was missing before.... causing the Vline to not be detected (or software not checking Vline if Line Freq is out of range) ??
There is a code (C93) to show line frequency, but it's not implemented on this model, I'm 100% sure I wanted to check this code and could not.

I' know I did check line Freq signal before, not sure I checked it on the connector or on the track that goes to the cpu... It was probably on the connector header itself, so no way to tell if the signal was properly routed to the cpu.

Now I'm wondering If I should re-solder the original CPU & connectors and run a wire to fix this and give it another try or wait for the new cpu... dang...

I think I'll refit everything and fix the track.

[Grouickman]

never mind I read it wrong it's X11 pin 13 not pin 14. It's a temperature measurement, so nothing to do with the line frequency...

Still need to fix it, but I won't refit anything until I got the new CPU.

[CapLeaker]

never mind I read it wrong it's X11 pin 13 not pin 14. It's a temperature measurement, so nothing to do with the line frequency...

Still need to fix it, but I won't refit anything until I got the new CPU.

If I count the pads on X11 the damaged pad is pin 14.
If I look at that pin out on the schematic, it also sez pin 14 for the frequency line!

[CapLeaker]

Cording to that paper Vline is on pin 18 and that would be a way different resistor pack. The pin out must be different from that schematic,

[Grouickman]

I'm positive that's pin 13.

Pin 1 is the round pin, all other pins are square. And the damaged pad is on the odd row.

[Grouickman]

Cording to that paper Vline is on pin 18 and that would be a way different resistor pack. The pin out must be different from that schematic,

yes, Vline is on pin 18, but pin 14 (that I tought was the ripped pad) is "Line Freq", which I supposed the absence could be a reason why the firmware would not check VLine and report it as 0V.
My assumption is that the firmware checks line frequency before line voltage, but it was just a guess from my side.

Anyway, not the case as it's definitely pad 13 that is ripped, so no matter how the firmware behaves, that does not explain anything.

I might be trying too hard to find an explanation to the CPU not being able to read VLine while it's definitely present on the CPU pin A/D input, and also the A/D working on other channels than channel 16.. I mean, I already played with other CPU/MCU and killed one of the A/D input but the pin would be held low or high and that would be measurable externally. here that explanation would only work if this pin is held low internally... I'm not really convinced but I don't see much more options, and I'm already committed to changing the cpu, so future will tell.

[CapLeaker]

I'm positive that's pin 13.

Pin 1 is the round pin, all other pins are square. And the damaged pad is on the odd row.

I guess my bad counting the pads now,

[CapLeaker]

Vline goes through that resistor array, that goes through that capacitor array (correct me if I am wrong) and then to that CPU pin. Well… that capacitor array blocks the DC to the CPU pin. So on one side of the capacitor array you should see the 3.8 something volts and on the other side to the CPU pin you get no volts. Makes sense the Vline pin on the CPU sees no voltage. Unless I am getting totally stupefied now.

[Grouickman]

The capacitor array is just for filtering (C in // with cpu input pin), it not a dc-block (series).
Saying otherwise : the Vline signals goes trough the series resistor (10K) then directly to the CPU input pin, and the capacitor is in // for filtering the noise.

[CapLeaker]

So it's in parallel. O.k then… carry on. No short there, right?

[Grouickman]

Ok... I think you can call me stupid. Well, we still need to confirm my new theory, but you still can...

Remember when i said after some poking around the eeprom was corrupted and it started showing an error and asked to reconfigure the model number ?

yes... so.... I selected model 9300 (first option in the list) instead of 6300.
Not sure it can explain the issue, but for sure it would probably not work properly.

Now... should I wait few more days for the new cpu? If it is the cpu at least I will have a(hopefully) fully functional one and won't need to swap it again, or mount he old cpu (that maybe is perfectly fine.. or not...) I might have to swap it again (meaning I have to remove again all connectors to not melt them).

I'm not in a hurry... I'll wait.. maybe... I think... but I more interested in knowing if I'm really that stupid...

[CapLeaker]

Ok... I think you can call me stupid. Well, we still need to confirm my new theory, but you still can...

Remember when i said after some poking around the eeprom was corrupted and it started showing an error and asked to reconfigure the model number ?

yes... so.... I selected model 9300 (first option in the list) instead of 6300.
Not sure it can explain the issue, but for sure it would probably not work properly.

Now... should I wait few more days for the new cpu? If it is the cpu at least I will have a(hopefully) fully functional one and won't need to swap it again, or mount he old cpu (that maybe is perfectly fine.. or not...) I might have to swap it again (meaning I have to remove again all connectors to not melt them).

I'm not in a hurry... I'll wait.. maybe... I think... but I more interested in knowing if I'm really that stupid...

That's what happens if you look too long at it.
I would wait. I don't think a few days matter much.

[Grouickman]

I mean... a 6 is an upside down 9.. almost the same...

ok... I did not wait... because I can't see a valid reason why the CPU would be defective on only one of it's A/D input (well... there are reasons, and it could...) but... I need a justification here, because yeah... a few days would not matter but... reasons....

So.... it works. Setting the proper model helps (a lot !) ! funny that with the same board they do not use the same A/D input for V.line...

And finally all that work for nothing... well.. I least I have a pretty good idea of how the electronics work in this model now... but I'm happy to find the explanation because I was loosing my mind chasing a non-existing fault and making dubious assumptions...

But of course not everything is solved : it lost all calibration data... I have the service manual to re calibrate it but not the service tool, only the user tool and user calibration alone is not sufficient. I could not find the service tools to buy second hand (ebay, etc...) and I doubt snapon/hoffmann would sell them (and if they did not at a reasonable price).
So now I need to re-program one of the two eeprom (opto one is easier) with it's original data, use the service code to copy it to the other eeprom (cpu) and see if it would start now.
I doubt it will work... as it seems it was the original fault (invalid eeprom data). Maybe because the machine was worked by the previous owner who tried to repair it and someone removed one of the option, and during initialization it can't find the missing module and hang on this in a dead loop (I think that was the original beep codes meaning).
But maybe with some luck... Maybe ?

I still have some work to do, like changing the relays and a minor issue on the LCD (could be the LCD driver chip, one segment is missing and I can't see any issues on the contacts), checking the two piezzo transducers, some adjustments/calibration of the arms are needed, and few other ....

But all in all there were no real electronic/electrical fault apart maybe some bad contacts on some connectors and the relays, but that is more some normal maintenance.

[CapLeaker]

You would have to recalibrate that thing anyway one way or the other. Compare the corrupted and a working eeprom data and see what the differences are.

[Grouickman]

You would have to recalibrate that thing anyway one way or the other. Compare the corrupted and a working eeprom data and see what the differences are.

If I could keep the original eeprom content I think the factory calibration could have survived.

Anyway I tried, copied the original content to the eeprom and the machine is back to the error : 3S-3L beeps, which means communication issue with : KBC/LCD/Motor/BRAKE.
So... either it's looking for the optional brake that is indeed not present (was removed by the previous owner(s))?
or.. I have a new theory : it's looking for the KBD/LCD board which also has his own eeprom, and this eeprom contains only 5 or 6 bytes of data, and (theory intensify) this is the serial number and (theory at it's maximum) the kbd/lcd board was changed and the serial number no longer match with the serial number registred in the original CPU eeprom.

maybe..

Anyway I tested all arms and transducers, everything works, during tests I can read some values that are read and it doses not show any error reading anything.
The only thing is that it seems that without a valid factory calibration the machine will not give any values (always read 000) even after the user calibration. I think that's normal.
So I need a way to either have the machine calibrated by a representative (that must be expansive) or find a way to retrieve the data from the original eeprom dump and modify the current ("working") eeprom content.

I want to explore this KBD/LCD theory, see if I can find this serie of 5-6 bytes in the cpu eeprom and make a working "old eeeprom content" with this.

to be continued...

[Grouickman]

I think I made something...

So first, my theory about serial number was wrong, not much surprise here.

But, I did compare the original eeprom content to the eeprom content I get after reseting the machine.

I ignored the first part of the eeprom, there are indeed few different bytes, but I assume that the "header" is where all the options are stored.

then lower (arround @ 0630) I found a section of 144 bytes that is empty on the "reseted state" eeprom vs the orginal eeprom.
I suppose that's enough data to store some calibration data..
So I copied it and made a "patched" eeprom version and flashed it.
Start the machine, copy the opto-eeprom to the cpu-eeprom and the machine restarts and no longer complains about missing calibration data.

Now running with a wheel I do get some readings instead of "000 - 000", so it could confirm my theory that the machine will not display any value until it has valid calibration.
But are those valid values ? that's what I'm going to check. My son will balance a wheel at work with a properly calibrated balancer and we'll test it see if we get the same readings (or close enough).

I might also have copied just one part of the calibration, so maybe i'll try again by copying everything after adress 0630 instead of just the 144 bytes (that's a 4Kbytes eeprom).
There few different bytes here and there further down, but it might as well be the user settings/profiles/customization area.

It might be it finally !

[CapLeaker]

What is the difference between those 2 EEPROM dumps in the HEX editor? Compare them and see what the difference is.
Edit: LOL you just posted a couple of minutes before me. That is exactly what I wanted you to do... Carry on! Your doing good!