Hofmann geodyna 6300 Wheel balancer

[Grouickman]

Hi there,

First, I'm not sure it's the right section to post for this type of device, but could not think of something better.

Ok, so my son (a mechanic) bought a faulty Hofmann Geodyna 6300 wheel balancer (which appears to be mostly a re-branded Snap-on wheel balancer).

I'm looking for any resources (doc, manuals, schematics) that would be available for this device or anyone that would have any knowledge on this particular device (or its Snap-On equivalent).

I'm trying to diagnose the fault(s ?), but I can't find any schematic (appart from the electrical schematic from the user manual, which is already a start) or anything really useful.
I found a service manual for all wheel balancer from Snapon, hoffmann, and few other brands, but it seems it does not apply to this model.

When powering up the unit, no display, only a series of beeps (2 shorts, one long, one pause, 5 long). Unfortunately nothing matches this in the service manual I found (which again might not apply to these old models).

I've spend maybe 10 hours trying to figure out what the fault could be.
Started with the obvious : power supply, but all is fine on this side. All boards are powered from a single +5V (+5.24V according to the service manual).
No power rail is shorted on any board.
the I&C bus reaches all boards and signal seems clean.

I also found that I can connect a serial port to a computer, which I did. It seems to confirm the board is fine:

M00 IPL V01.10
M02 Hardware Restart.
M17 Board testing...
M18 Board is Ok.
M03 Waiting for Pc link...
??????????
M05 Pc not present.
M06 Looking for an Eprom application...
M08 No Eprom application found.
M14 Looking for a Flash application...
M15 Flash application found.

note : connecting a PC is not mandatory for the device to operate.

Since there are no display at all, I suspect the issue is with the boot phase/preliminary checks, that prevent the CPU board to go any further.

I was questioning the flash memory, but without any way to check if the content is valid, I assumed so as : IPLV1.10 is engraved on the flash, and the serial console log shows same version "M00 IPL V01.10" and later shows "M15 Flash application found.", makes me believe the cpu is able to access the flash and found at least some content.
It might still be corrupted, which I don't know how to check. But I'll park this for now.

I checked several ICs to see if output matched what was expected based on input signal (mostly 74HC ICs), So far I could not find any issue on the CPU board, except :
- the CPU does not enable the +4.5V Vref (which is used all over this board and some other) to power up sensors and some opamp.I checked the +4.5V LDO does work fine and if I pull the enable pin high, the +4.5VGoutput is present.
- one of the ouput pin of the CPU, connected to a 74HC08 seems to be "floating" (+2V at the output). I'm not sure if the pin is disabled (floating) or damaged. I removed the HC08 IC and replaced it with a known good one, but the voltage remains at 2V. It's bothering me as all of the other input pin of the HC08 receives either a 5V or 0V signal, which makes me question the CPU itself.
- I traced the I²C lines going to the external A/D chip (AK5351), I found no data being exchanged with the CPU at any time. I removed the chip and the serial port console message remains unchanged. this may indicate that the CPU is not yet trying to "talk" to the A/D chip, However in the service manual there are beep code signaling issues detected on boot, and one of the beep code concerns the external A/D chip (same code used for several causes). Not sure if this is significant or not since the beep codes are not referenced in the service manual I found, but I ordered one just in case.

I tried some "silly" things : removing the jumper on the +5V power one of the two ram chip, and indeed the serial console log shows an error on the ram chip. It does not confirm 100% the ram chips are fine but at least they pass the self test.
I extracted the I²C eeproms content on all pcb (CPU, display and optical board). I can read the content properly (tried several time each chip and got each time the same readings). I can't tell if the content is valid or not, but on two of them (CPU and display) I can identify some message in plain text making me believe the content should be ok. On the optical board the epprom contains calibration data, and at least there are few bytes used, but can't teally say if it's valid or not, but I'll assume it is.

It should not be any sensor as in case of error with one of the sensor, there is a dedicated error code that should be displayed on the screen, but I tested them all and they are all is specs.

And when the CPU reaches this "stop" phase, I can still see some activities on the I²C bus and ram data/address lines, which would mean the CPU is not halted.

I tested also the KBD/LCD board, and found that at least for the KBD part, when pressing the keys, some data are send to the I²C bus, so I'll assume the KBD (and the I&C bus chip, PCF8574, on this board) is fine.
I still have to test the I²C-LCD chip (PCF8576C), as it could be that the device starts and try to display an error code but the LCD driver/LCD is dead ?

Any help would be appreciated.
Thanks, Manu.

The only sort of schematic I found for the device is this :



And a view of the board with some annotation I added for my tests.
Note the rom socket is used only for software updates and is normally empty.

[CapLeaker]

Did you check the wiring that connects to the board? Not that there is a broken or grounded out wire somewhere… specifically display and the keyboard.

something for U here… very bottom sound like your beep code.

[Grouickman]

I did already check the two boards connected to the cpu board which have some form of communication (I²C) :
- the kbd/lcd has an eeprom, an lcd driver and an 8 bit I/O chip for the kbd, all on I²C bus
- the opto board hasan I²C eeprom.
I checked the signals (SDA and SCL) reaches both board. Cant' tell if the eeproms are read by the cpu, but I was able to extract their content, so I guess they're fine.
I checked the LCD driver, but found no activity, which I believe is normal as the CPU board does not pass the initialization phase (halts on errors with beep codes).
The KBD chip seems to work : when I press keys indeed I see some activity on the I²C bus.

So I would say the connections to the boards looks fine to me.

But you're right the beep codes looks very much like the example given. Not sure how I missed that. Actually I thought those were Long beeps not Short beeps.
Not sure if it's specifically the opto board which would be a bad news, as the only active component that could be tested by the CPU is the eeprom, the other components is a 74HC14 and an optical sensor (led +photo-led).
But it could be the other board, aka KBD+Display. I need to test that again.

[CapLeaker]

I had some run ins with tire balancers before. But never had one that had this behaviour. You did so far same thing I how would have approached it. Keep on digging!

[CapLeaker]

I should have posted the page before it too… so it makes more sense.

[Grouickman]

Ok, so some progress :you were right about the first error code, it was the opto board.
Well not the opto board itself, but the cabling.
I did solder wire directly from the opto board to the cpu board and now the initial fault has gone... but I have a new fault.
Anyway I carefully cleaned the connectores on both side and re-flown the connector pin header on both boards, the fault did not come back when I removed my wires.. not sure what was the issue here (dirty/corroded connectors or cracked solder joints ?), but I'll take it.

Anyway there is some progress !!! Now the +4.5Vref is active which is probably a good sign as it's used to power some sensor and opamp. At least it seems the CPU goes one step further.

new BEEP codes is 3S and 3L, which translates to :
KBD/display, SAPE, Brake, motor, drive system (3S)
KBD/display, SAPE, Brake, motor (3L)

So I checked the SAPE (3 axis measurements), which is done by 3x 10k pots, all are fine measured out of circuit and in-circuit (on the connector header).
The motor windings looks fine to me, measured on the connector header.
Then I thought about the basics I did not check : the relay contacts. One measure fine (around 20mohms on both contacts), but 3 were bad (one had around 0.3ohms and 2 had over hundreds of ohms). After some cleaning they all are back to normal (15-25mohms). I'll change them later but for the test it should be fine.
I believe the Motor and brake are all managed by the relays and some capacitors (20uF and 10uF, both checks good).
I checked the IGBT, they all look fine. the IGBT driver looks fine as well.
I still have to figure out how the motor and brake are tested by the CPU. I found some opto-coupler, but not sure they are used for that. i have to trace the signal see where it comes from/where it goes
For good measure I've also reflown all connectors on all boards and cleaned them (header+connector)

I started to trace the sensor paths on the CPU pcb, all component in the path looks good (few opamp for filtering/signal conditioning) up to the CPU A/D input and the external A/D converted.
But I'm thinking more and more that the board is fine.

I would suppose both A/D (CPU and external) to be fine, as there are dedicated error codes for this and I suppose (hope) the program would test them first before trying to read any sensor or anything connected to them.

Initially I focused on the CPU board as the seller told my son that some technician had the machine checked and told the guy it was the CPU board and since it's expensive he just sold the machine "as-is".
I tried to find something that would indeed explain a fault on the CPU board... now I'm not sure anymore that was the right diagnostic.

I think I'll focus on the KBD/Display module.

I still find the SDA line dirty on as soon as I plug the ribbon cable that goes to the KBD/LCD.
It looks like a capacitive (or R/C) load on the line:

(sorry for bad quality, for some reason I can no longer make screen capture via USB..)

Strange thing is the SCL line is not affected, only SDA.

I tried removing the 3x ICs connected to SDA on this PCB and the issue remains, so it could as well be normal.
I can't test with the ribbon connected on CPU side and not on the KBD side, as in this case no I&C activity happens (which would mean... the I²C devices on the KBD/LCD side are "talking" to the CPU ??? maybe ?)
The issue could be with the cable itself. Like a 2.5m long ribbon cable sure has some parasitic capacitance... but it was designed this way, so it must be normal... I guess (????)
For good measure I'll make a new cable, but for now I don't have the connectors. i'll probably run a shielded cable separately for SDA in the meantime, see if it changes anything, and disconnect the SDA wire from the ribbon cable.

Anyway, at this point I already ordered the 2 main component on this board.
One looks like it's working : I/O chip that handles the KBD (as it sends some data on the bus when a key is pressed), and the LCD driver chip.
As I have no easy way to test it appart from connecting some MCU on the I²C bus and try to make it display something with some custom program... but I find it easier to just change the chip.


to be continued...

[Grouickman]

ok, so it seems that the I²C waveform could be a case of reduce de value of the "pull up resistors" according to several information I found here and there.

I tried to change the value to 5K but nothing changed.
Then 1K, but at 1K something strange happens: the Low level is not always at the right voltage. Sometime the signal goes down to 0V, sometimes it goes down to ~2V for a low level.
It seems to me that 2x I²C devices are trrying to "talk" at the same time, and the signal gets jammed. Might be wrong, but I find the waveform suspicious.




Interestingly, on the CPU board, the SDA line goes from the CPU through 2 nand gates (74HC03) in // (2 gates output connected together) to the headers. Not sure if it's to increase the output current or for some other reasons they did that.... I'll start by this one I guess.

[CapLeaker]

So you got the keyboard verified working, but no display yet? That's where I would concentrate on first and see why it isn't working.

[CapLeaker]

Why does your i2c wave form have so many spikes in it? Doesn't look clean?

[Grouickman]

Ok, so I have some progress and the machine seems to work. There is still a fault, but should be an easy fix.


First, yes this I²C waveform has been bothering me for some times and in fact it's thanks to a "mistake" I made while I was trying to understand why the I²C signal was so dirty that I "repaired" the board.

So, I was poking around the board with a scope while plugin/unplugging the ribbon cables on which the I²C are going (one to the KBD/LCD, one to the main PSU board and one to the opto board) to see which board was causing this.
First I found that unplugging the LCD/KBD ribbon cable would make things better (and by the way if you unplug the ribbons after the cpu has started it will continue to send data on the I²C bus, while if the cables are not connected when you start the cpu board it will not even attempt to send any data past the first attempt), the signal was better but still "dirty".
I disconnected the opto board as well, it was slightly better, but still not clean.
Then I disconnected the main PSU board (the cpu board was directly powered by the bench power supply), and the signal was clean.
So i reconnected the Opto board, it was still "clean". then I decided to test agin by plugging back the main PSU board and then something strange happened. the signal stopped.
I powered off the board, reconnected everything and then I was greeted with a single beep and an error on the LCD screen:




So... I corrupted the eeprom content. It was not a big deal as I always take a dump of all eeproms before working on a board.
After reprogramming the eeprom I was back to previous state (beeps : 3S - 3L)...

I then decided to repeat what I did before : unplugging an re-plugging the main PSU board ribbon cable, same thing happened, again error 145 after restart.

And that was finally a good thing as, in this state you have access to the service mode where you can select the model number (sort of factory reset) and it will automatically re-generate the eeprom content.
And since then the board seems to work perfectly fine.

So... as I was suspecting, there is probably nothing wrong with this board and corrupting the eeprom solved the issue, apparently. I'm still confused how dirty the I²C signal is, but it works and honestly I can't find a clear "fault" that would explain why the signal is like this.
Some capacitive load on the SDA line because of the ribbon cables and pcb ? maybe, but the SCL line is much more clean and goes trough the same paths... for good measure I'll replace all components I already ordered, but that will probably not change anything.


But there is still an issue : the machine does not want to start operating normally because there is an error on the voltage detection part ("300 800" main voltage below 170V).
So at least there really is something to fix, it's probably on the main PSU board, I found some circuits with few opamps and logical gates that provides an image of the input voltage, frequency and the current in the motor.

Since there are not so many component on this board I'll try to make a full schematic of the board, but I already started tracing where the V.line signal is coming from.

Also the "Overcurrent" led is lit on the PSU board now that the CPU board has started activating some relays and igbt drivers on the primary side. It could be the same cause as the "low voltage" issue.

[CapLeaker]

Well, you made very good progress! You said the i2c waveform was good with the bench PSU. Maybe the PSU from the machine needs recapping too? How does it sense the voltage?

[Grouickman]

ok, so... I was wrong again !
The Vline is present on the pin header, read ~3.89V. not sure whether or not it's a correct value for ~230VAC, so I tied forcing the voltage to 0V and to 4.5V (after the 10K series resistor, which sits between the header and the cpu AN13 pin) and in all cases the cpu reports error "line voltage low".
4.5V is the VREF used by the A/D, so it's safe.
I found a service code that will display the line voltage (C 55) and it always reads "0" no matter what, it's supposed to read the live voltage.

i was suspecting the internal A/D but running other service code I found the 3 potentiometers connected to the "SAPE" arms read proper values (I mean values that makes sense and measurements are repeatable).
So the A/D itself is fine, but since it's a multiplexed input, probably this particular input is held low internally...

I was hopping to find some analog multiplexer in-between the inputs and the cpu (there are, at other places on the board, but apparently only for the external A/D IC), but no luck. An nothing in-between (appart from the 10K series resistor, but it's fine)

Looks like I will have to change the CPU. hopefully this model (SAK-C167SR-LM) does not have rom/eeprom and it relies on external flash memory for the program.
unfortunately I could only find it on Ali (Mouser, farnell and radiospares are out of stock)... hope it's not some fake chips. Otherwise I'll have to search for some donor boards that uses this same cpu...

[CapLeaker]

There must be something before at the primary side of the PSU where it picks the AC to measure off… I mean it cannot say here is 240VAC out of thin air, similar like an AC Detect. I see it on the X1 connector, but doesn't say where it comes from.

[Grouickman]

yes indeed, there is some circuit driving an optocoupler (HCNR200, one led illuminating 2 photo-leds) which one of the output goes into some opamps for filtering and signal conditioning generating the V.line voltage. That's the voltage I measure @ around 3.89V.
I'm working on making a schematic of the board, but here's a photo with some annotations.
- the HCNR200 diode is driven by the LMC6001 opamp. One of the photodiode goes on secondary side for Vline and LineFreq measurements. one photodiode is in the loop gain of the opamp. The opamp input comes from the two resistors below the bottom IRFBE20 mosfet
- the mosfet driver is controlled by the two optocoupler above the HCNR200. For now I don't see what those mosfet are used for, except providing the input of the opamp that drives the photo-diode to generate the V.Line, but there must be some other use
- the current transformer (C.T. on the photo) goes to some opamp and some logic gates, but I don't see any signal (yet) going to X1/CPU board
- IGBT driver input comes from a logic gate 74AC74 (Dual D flip-flop)
- the relays are controlled by a TPIC2701 which input comes from X1
the IGBT are under the heatsink.

I've not found yet what the two SMD mosffet are for, I guess something related to the electromagnetic brake or the optional powerclamp.

The line freq. signal is a 5V square form signal which is right on the money (exactly the line freq, not sweeping or anything). So I'm quite confident that part works, for V.Line I will just assume that the voltage is also what is expected for a 230V Ac input
But since whatever the voltage I inject on the A/D input of the CPU (AN13 which is connected to "V.Line" pin of X1 through a 10K res) it always read "0", I concluded the issue is not with the circuit that generates "V.line" but rather the A/D input of the CPU that is stuck to 0, hence the idea of changing the CPU.

Not related but the 5.24V supply is the top left part of the board and the output is very smooth, the spikes on the I²C waveform does not come from here.

[CapLeaker]

So the Frequency Line and the Voltage line on X1 have some voltage of 3.89VDC on it. If you take a variac and change the power mains input voltage that should voltage line should go up and down, right?
Maybe there is nothing wrong with the PSU and we are just barking at the wrong tree?

However this mentioned it is a power supply problem. Weird.
It would be true, if there isn't anything from the V line. But there is voltage on it.

Now C110 is about motor speed and the 5V power supply. The 5V VCC has to be between 5.1VDC and 5.35VDC, Otherwise it will complain.

[Grouickman]

Ok, I gave it another try this morning,
C110 show 5.24, right what my DMM says


C55 still says 0



I did some measurements again, on X11 V.Line pin (18), I read 3.86V (slightly lower than yesterday, which is not surprising as mains will always vary from one day to another).
But now, when I measure on the other side of the 10K resistor pack (AN15), I find a (not perfectly) square wave signal at 25hz (tried to capture it with a portable scope, but I have again some driver issue and can't extract the waveform..)
And if I measure the adjacent track (AN6) I find the same signal. But on the other side of the 10K resistor for this track, on pin 19 "Analog-1", I don't have the signal but a DC voltage close to 0V.

I measured the resistor between AN15 and AN6 and find ~2.8ohms, so it's not a dead short. and pin header 18-19 shows around 20k, so the issue is on the cpu side of things... right... ?



Or is it ? I removed the pin header (mainly not to burn it when removing to 10K res pack) and the 10K res pack, only to find.. the 3ohms short has disappeared and now I find 1Meg between AN15 and AN6 which seems much more healthy.



Measuring the res pack, there is no short whatsoever between each resistor on any side.

Could have been some corrosion behind the res pack? a solder ball ? I could not see anything apparent before/after removing the parts.

What Is strange is that yesterday I did the same measurement I did have 3.89V on both side of the 10K resistor for V.Line (Pin 18 and AN15) and there were no sign of this weird square wave signal.
And that's not a signal i would expect on AN6 as Pin 19,20,21 are analog 1,2,3 inputs used for the measurements arms, it's supposed to be a dc signal.

So I'm definitely inclined to think there is some sort of internal short in the CPU. heating the PCB and the 10K res pack which is close to the CPU might have done something to the CPU itself.

I'll refit everything and give it another go, but it's getting weirder and weirder..

[CapLeaker]

Yes refit everything, but swap em out. Just to see if something changes. There the same chips just in different positions.
Sometimes SMD devices behave weird after they have been heated up again. Just had a brain fart. Maybe instead of the resistor pack just solder some individual resistors in for the time being.
Do the same with the capacitor array. Swap em out.

[Grouickman]

So, I refitted everything and gave it another go.
now the situation "back to normal" : ~3.8V on both side of the V.Line 10K res, so the "short" is gone, and there are no more shorts between A15 and AN6....


but still input voltage (C55) read as 0.
I should receive the spares CPUs in few days, I'll see then as for now I can't see anything else.

[CapLeaker]

Dang! For some reason it's hard pill for me to swallow that it is the CPU's fault. But time will tell, once you fit the new CPU.
AN15 goes through that resistor array, but it also goes through a capacitor array (second one from the bottom up, before it goes to the CPU? Swap it out?

[Grouickman]

I have the same reading before/after the resistor array, and on the AN15 pin of the cpu.
At some point I was hoping for the cap array to be cracked/shorted, that would pull the voltage to 0, but no.

I agree, cpu being faulty, on that input (maybe other ?) seems a bit odd. Especially because I have (apparently) correct readings on other A/D channels
but since there is nothing else in-between the V.Line input and the cpu... must be the CPU...

The only other explanation I would see is that some sort of software issue that would cause the reading to be 0, but there no hope fixing that.