Hi, I have two identical Glowforge Plus. One of the MBs has a problem and I have tried swapping the MB between the two units. The error stays with that defective MB and the GF will be stuck on “Scanning” with a red light on in both GFs. The other MB works in both GFs with no error.
I have tried to analyze the logs and find the following error on that bad MB. Please remember, that shows up in both the units, when I have the bad MB.
2025-07-02_08:05:36.08290 30922 ERROR: hw: laser supply current of 962 exceeds maximum of 12 (/usr/src/debug/glowforge-app-production/0.1-gitAUTOINC+f9eb63c036-r0/git/src/hw_task_errors.cpp:308)
2025-07-02_08:05:36.08293 30922 INFO: hw: error flag set: fault:hv_current_alert:set (53)
2025-07-02_08:05:36.08294 30922 DEBUG: hw: writing to /sys/glowforge/cnc/stop
2025-07-02_08:05:36.08295 30922 DEBUG: hw: writing to /sys/glowforge/cnc/disable
2025-07-02_08:05:36.08909 30923 DEBUG: hw: writing 1 to /sys/glowforge/cnc/laser_latch
2025-07-02_08:05:36.08912 30923 INFO: hw: clearing pulse data
2025-07-02_08:05:36.08913 30924 DEBUG: HWFSM: idle => unusable
2025-07-02_08:05:36.37570 31215 INFO: 8000 ms
2025-07-02_08:05:36.38062 31218 DEBUG: hw: driver state is now ‘disabled’, progress=0/0, pos=(1908,378,0)
2025-07-02_08:05:36.38065 31218 INFO: hw: error flag set: fault:cnc_disabled:set (44)
Has anyone ever seen this ?
According to the HW reenginieering document Pin 1 of the power supply connector seems to have this signal: HV Current TP_B2F
I measured the voltage on the good MB to be 0V (during the normal start phase) and 3.3V on the bad MB. So I just cut connection from pin 1 and grounded that pin.
Now the GF works.
Sorry, I don’t understand.
You mean red light on the button ? As long as the problem existed, the button started glowing red as soon as the GF reached “scanning” state. Now with the fix there is not red light anymore and I can print.
That would be the High Voltage current sense coming from the power supply to the main board.
It is connected to pin 17 on U9. U9 is a PIC16F1713. Pin 17 maps to the PIC’s ADC (AN18). The firmware talks to the PIC via SPI, and retrieves the ADC readings, and some outputs. It is used to measure temperatures, set stepper currents, measure HV voltage/current, and controls the LID and power button LED’s.
It’s possible that U9 is damaged and giving improper readings. If you want to replace that IC, you will need to reprogram it (you’ll need a Microchip programmer that is compatible). The in-circuit programming header is located just above the IC, and is connected with a Tag-Connect TC2030-IDC-NL cable.
This is the HEX file for programming the PIC (worth checking to see if this has changed in the years since - this version is from 2017): PIC16F1713.zip (2.9 KB)
@palmercr did a nice job reverse engineering what that device does:
So I have worked it all out now. This is the I/O: 10 ADC inputs, 2 DAC outputs and 4 PWM
2 RA0 A I AN0 Index 4 PWR_TEMP
3 RA1 D O OPA1OUT=DAC1 XVREF Index 9 X-CUR
4 RA2 A I AN2 Index 2 WTR TEMP 2
5 RA3 A I AN3 Index 1 WTR TEMP 1
6 RA4 A I
7 RA5 A I AN4 Index 3 TEC TEMP
10 RA6 D I SSP GPIO4_IO16 SS
9 RA7 A I
21 RB0 D O PWM4OUT Index 11 LID LED
22 RB1 D O OPA2OUT=DAC2 YVREF Index 10 Y-CUR
23 RB2 A I AN8 Index 5 LID 1
24 RB3 A I AN9 Index 6 LID 2
25 RB4 A I AN11 Index 7 LID 3
26 RB5 A I AN13 Index 8 LID 4
27 RB6 A I
28 RB7 A I
11 RC0 D O PWM3OUT Index 14 LED 3
12 RC1 D O CCP2 Index 13 LED 2
13 RC2 D O CCP1 Index 12 LED 1
14 RC3 D I SCK ECSPI2_SCLK
15 RC4 D I SDI ECSPI2_MOSI
16 RC5 D O SDO ECSPI2_MISO
17 RC6 A I AN18 Index 15 HV CURRENT
18 RC7 A I AN19 Index 16 HV VOLTAGE
The SPI comms is dead simple. Send slot index x 2 to get LSB, MSB sent back.
Set top bit to write followed by LSB, MSB
Slot 0 contains "SM". Must be a test.
Note the Y DAC is only 5 bits but X is 7. I thought the Y current values in the log looked too small!
There is a dummy 17th slot that seems to ramp PWM4 if you set it to 1.
Here are his annotated code files: PIC-Code.zip (26.6 KB)
Scott, thanks for the info.
But is that feedback actually used ? I tried both boards, the original without problems and the one where I just tied the input to GND. Both create the same output with the same design. Seems like that feedback is ignored ?