I finally reached the point where I needed to fix my Laser Printer. My Kyocera FS-1030DN has been serving me well for years and whilst the print quality is as good as they day I bought it I have had a problem with the page alignment. I have been loosing the top and bottom of pages which has been irritating.
Just fixed mine tonight with the help of Google Translate and a german printer forum...
The cause is small piece of foam rubber tape on the registration clutch solenoid, which gets slightly sticky with age and affects the timing of the paper mechanism.
If you're reasonably comfortable dismantling stuff (and reassembling successfully!) it's not hard to fix. It helps to get the service manual, which has nice diagrams of how the parts can be removed - Google "fs-1020d service manual".
Lift out the "process unit" (toner and drum).
Remove the top cover - 2 screws.
Remove the thumbscrews from the rear to get at the option slots.
Remove the right side cover - about 6 or 8 plastic clips (service manual shows where).
Disconnect the 12 cables from the engine board (the one with 12 cables 😉
Remove the engine board - 3 screws.
Unclip a few wires and remove the light-grey plastic cover (1 screw).
You'll now see 3 solenoids (coils with metal levers attached; mine had the coils wrapped in blue tape). Top right one is likely the main culprit, but probably worth looking at all of them. Take the solenoids off one at a time - 1 screw each.
There's a small piece of 0.5mm foam tape that's supposed to stop the solenoid from clicking too loudly when the magnet pulls the lever in, and it's probably very gooey. I scraped off the goo and replaced it with some foam tape I cut down thin with a razor blade. You could probably just omit it altogether or cover the goo with some adhesive tape.
Reverse to reassemble - good luck!
Well I tried out the method described and it worked a treat. I did indeed have sticky residue on the solenoids which I cleaned off. I reassembled the unit and ran a few print tests.The following pictures show the results, before print on the left, after print on the right.
How long this secondary issue has been present I am unsure. Over the summer I had been using the machine but turning it off after use as it was keeping the room a little too warm. I probably didn’t notice the idle issue as I wasn’t leaving it idle. Any occasional occurrences of problems I attributed to the old CPU.
The current workaround has been to disable the C-States in the BIOS. It appears when the system is idle it is going into a low power mode but for some reason this isn’t happening correctly. At this time I’m unsure if this is related to the BIOS itself or Fedora 26 running a 4.13 kernel.
I have upgraded both BIOS (AGESA 220.127.116.11b) and kernel over the past few months so I will have to test again when one of them changes. Next week Fedora 27 is released, it will likely ship with a 4.13 kernel but 4.14 should follow shortly after. A BIOS with AGESA 18.104.22.168 might arrive before the end of the year.
For the time being I will settle for a little additional power usage and no crashing.
I finally decided to perform a backup of my new Ryzen PC running Fedora 26. Normally I wouldn’t leave it too long between backups especially if I have made significant changes. My new PC presented me with a little bit of an issue, I couldn’t run my backup software.
I tend to use Clonezilla to take/restore system images. I’ve used it for years and it has been working well for me. That was until I tried to boot it on my Ryzen system. It was hanging with tpm_tis and tpm_crb errors.
The arch wiki states that “Support for TPM 2.0 is still incomplete (both on the kernel and in userspace), and no known work flow for TPM2 exists at the moment.”
It would appear that I had enabled the TPM option in the bios and I have TPM 2.0 hardware.
This evening I arrived home from work and began to update my machines to the latest version of Fedora. I am pleased to say the update has gone smoothly. This has been the easiest update I think I have had in recent years.
Now the bad. Wayland has become the default display server replacing X11. It works, by which I mean I have a usable display. The bad is that it has broken my workflow. I have a few simple scripts that tweak my environment. These have always loaded when the display server starts. Ok, how do I do this with Wayland? I did some reading. The issue has been known about for 2 years, Bug 736660. The workaround for the moment is to logout and then log in with an X11 session. Logging into the X11 session everything works again and I can continue. Hopefully issues like this will get resolved quickly.
This week I have been updating my machines to run Fedora 24. Two out of 3 updated without any issues and continue to run normally. One machine however has decided to cause me some issues.
My old Toshiba X200 laptop had followed the upgrade instructions to the point where it needed to reboot. So I rebooted the machine and left it to do its work. Returning some time later expecting it to have completed I was disappointed to see it stuck doing nothing. After some investigation it appeared I was getting an error to do with an Invalid PCI ROM Header, the value didn't match what was expected. I couldn't boot the machine without this occurring and left me scratching my head for a bit. There doesn't appear to be an obvious solution online. Others have reported similar issues but apart from seeing the error their machines have fully booted.
I decided to try adding a few flags to my kernel boot parameters. Finally I go one to work. Adding "pci=norom" seems to have done the trick and allowed the machine to continue to update. I won't know until the upgrade is complete if I will need to add this option back in permanently. But hopefully it won't be anything more than that.
In my previous post at the end of July I had resorted to calling in the Rat Man to assist me in my struggle. When that failed to show results I detailed my nuclear option of removing all of my loft insulation and denying the rodents access.
The button was pushed. I have spent many hours removing all the insulation. It's not an easy or pleasant task but there is no place left to hide. The entry points were filled with steel wool held in place by more expanding foam. You do get some funny looks bulk buying expanding foam but it all got used.
All has been quiet in the loft for the past few weeks. All that is left to do is have a proper clean up of rodent droppings, repair of eaten network cable and re-insulating before winter.
Everything has been going to plan.
Until today. I was sat at the computer catching up on a few podcasts when I heard the noise. The noise that has kept me awake at night, the noise that caused the pressing of the nuclear button. The sound of the rodent scratching about. The precise location I am uncertain about. I suspect that it is not from the loft, unless it has been enjoying its diet of steel and foam. By my estimation the noise is from the cavity wall above the window. I am guessing that little Ratty not being able to ascend to loft level has decided to compromise by setting up home atop the lintel over the window.
How I proceed at this point is uncertain. I need to insulate the loft for winter provided it is still secure. But it appears that a peaceful nights sleeps is not going to be an option in the short term. A new plan of attack is required.
I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.
All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.
Only one solution for this situation; single malt.
This month I finally called in the Rat Man to rid me of the menace in the loft. He managed to attend 2 out of the 3 scheduled visits. Having time off work and his no show did not go down well. In any case the traps are being avoided but they do like the additional bait they are being provided with. So after 2 visits and not hearing any movement above me I was a little happier. This evening however, following yesterdays no show, I hear scurrying once again. So in summary I have had 3 afternoons off work for no improvement in the situation whatsoever.
I am getting very close to the nuclear option of stripping out all the loft insulation and permanently denying them access by any means necessary (even if it means taking the roof off). It nibbled though my network cable and I have a zero tolerance approach to network intrusion.
To battle the rodent menace I have 7 traps in my loft. Yesterday I went up to check them; 6 were full. Of the 6, 5 suffered a quick demise through a direct head strike. One unfortunate victim was caught by the tail and eventually passed away from probable starvation/dehydration after a struggle with its surroundings.
In an additional observation one of the head strike victims appeared to have had its hind leg eaten off.
This image is the result of a week of pulling my hair out. It is a simple read of a register on a device connected to a micro controller over an SPI bus. The protocol was simple, the code driving it was simple, but until today it refused to work. I had checked the connections, the component values, changed some of the hardware but wasn't having much luck.
The time came to get it onto the oscilloscope. I treated myself to a Rigol DS1054Z a few months ago and it has proved its worth already. Having access to a 4 channel scope with protocol decoding has allowed me monitor the bus and find my fault. The scope revealed that the SPI MISO line was signalling the same as the SPI Clock. It turned out I had a tiny solder bridge between some header pins on a break out board, never would have thought to look there. After removing the solder bridge I now have a working SPI bus. Now time to do something with it.