2023. január 16., hétfő

New Arrival 9.

2023.01.05: It is kind of funny (or annoying you can judge).
My resin printer was ordered at the beginning of December in one single order.
Before Christmas arrived:
Shipment 1. - The printer itself
Shipment 2. - The wash & cure machine
Shipment 3. - 1l resin + air pure units
Yesterday arrived one single extra wash container (Shipment 4.). And still things are remaining. I don't know, how much this cost to AnyCubic.


2023.01.06: I was working a project previously. It is a replacement of the TCA530 IC what can be found in many FM radios before the era of the digital synthesis (PLL). It is a precision power supply for varicap diodes and AFC circuit. As it has an internal heated reference, but reside in a PDIP package, it intend to die after 30-40 years.
So I found a schematic for the replacement. I made some minimal adjustment on it, and shrink to fit two small PCBs, make it a pop in replacement (it is just higher than the original IC, but most of the cases it is not an issue).


This unit has some issues (questionable AFC performance, different reference voltage), so I intend to develop a v2 version, but now, from my own ideas and not a publicly available circuit diagram.
For this I was eagerly needing a working original IC.
I ordered two, it wasn't cheep. Arrived. One of my family members took the package.
It was put somewhere in the flat, so disappeared forever.
Ok, so ordered second time, now it is here


No, please don't even ask. It is not for sale. At least until, the v2 replacement is ready.
2023.01.09: The local government operated post are mostly a bunch of idiots. A package arrived for me to a post office, what is not the close one to the delivery address and not the central distribution center. They just put there (I guess) randomly.
Anyway. Picked it up:


Finally: spare screen protector, vats, fep foils arrived. With this my Anycubic order is complete. Five separate shipments of one single order. I think it is neither economical nor environment friendly. 😕
Anyway, I can start my resin experiments as soon I get there, to have time for it.
Same day. Currier came:


Big ass ESP32 board. Ordered it for some USB/Bluetooth HID experiments. I've an idea in my mind, so, we will see (as soon the current projects ready)
Same shipment:


Four different microphone module. I need it for my current project. I'll write about later. It has a same secrecy as my Melodyn project was - it can be presented when the surprise factor is over. In mid March.
2023.01.14: I was on the monthly HAM flea market as usual in the last few month.
As previously this time also picked up some interesting things.


AC milivoltmeter. Yes I know it is East-German, it is not the best quality. But it look clean, and I guess for $15 still worth it. I wanted to have an analog AC millivolt meter, but two channel dual needle configuration, but for a while, I can use this if needed.
A bonus thing (unfortunately, not mine):



It is a Bizerba weight scale large VFD display. Got it from a friend on the flea market, to do the hard work of reverse engineering, additional hardware design and driver writing for Arduino.


Bejegyezte: dátum: Nincsenek megjegyzések:
Címkék:

2023. január 9., hétfő

AS/400 and me

A friend of my contacted me a few days ago for some casual conversation what I really appreciate. Doesn't happen too frequently these days.
He was mentioning, that currently he is working on rewriting some old IBM AS/400 based software to modern Web 2.0 application. This reminded me a funny story regarding AS/400 from my rookie past, what I'd like to share here.
Alcoa has a facility in Hungary. Back that days they had a wide operation here. Manufacturing plastic bottles, operating aluminum smelter, building aluminum boxes for truck bases (like Coca-Cola trucks), and so on.
I was working for Hewlett-Packard that time. We had a worldwide  project at Alcoa for desktop PC provisioning. Sophisticated desktop management platforms (like SCCM) didn't exists that days.
So HP wrote some scripted MS Test based scripted platform for this, what, I can tell you, wasn't the best.
Actually the local Alcoa had some weird network configuration, mad this provisioning continuously fail.
So, my colleagues called me, to go onsite and try to resolve the issue.
I was sitting in the server room with a PC, for long time, and trying to figure out the issue.
It was a thick PC size black box under the table I was working on. 
Just illustration, not the exact unit

So I put my feet on the top of it.
A guy came into the room. When he seen what I'm doing, his face become white.
He said slowly: Please remove your feet from the AS/400. That unit controls the aluminum smelter. If you eventually switch it of, the smelter will cool down and can't be heated once more.
Bejegyezte: dátum: Nincsenek megjegyzések:
Címkék:

EPROM burning 21/25V 3. - Closing

The first two parts of this post:
Back in 2021 I was starting this project based on this ground:
  • The TL866II is unable to handle any device programable above 18V
  • My HP 8903B has 21V EPROMs and I wanted to refresh them
  • The T56 programmers cost are way above the amount I would pay for this
Since then a few things happened. First I lost the ordered boards of this project. During the moving to my new lab, I was unable to find, where are those. Actually just 2-3 month ago showed up from one of my boxes. I was ordering the parts needed to build it, but had other projects to work on, so put it aside second time.
Bit later I realized that the XGECU (the manufacturer of the TL866II and T56) come out with a new programmer model the T48. It has reasonable price and the plugin modules I already bought for the TL866II are compatible with it.



Ordered it, programmed the EPROMs for my HP 8903B. So the story ends here from my perspective.
This project shelved, I not intend to build it. Maybe once, I'll try. Actually, I not even now if it id work. Anybody want to experiment with it, welcome. I can give a board for this.
Also my original TL866II will be on sale soon.


On the side of it, I planed to build a proper EPROM eraser. I ordered one, with the T48. It has mechanical timer, and not something, what I really like, but it does its job, so the EPROM eraser project also canceled.
Bejegyezte: dátum: Nincsenek megjegyzések:
Címkék: ,

2023. január 3., kedd

Azure, AKS, Terraform, proxy


Happy New Year to everybody!

It maybe unexpected, but I start the year with some professional content and not my hobbies.

When you try to deploy an Azure Kubernetes Cluster from Terraform, and the cluster has proxy configuration, on any terraform apply on the cluster will cause redeployment, what is not what you expect.

The reason is that the Azure mechanism add a few addresses to the no_proxy list in addition to the ones you set. Changing the no_proxy list will force recreation. The list stored in the state will always be different from the list on the AKS resource itself.

First let check, what are those addresses:

The values above, can be known before the cluster creation, except the last one. This is created during the deployment of the cluster, so adding all of the items to your no_proxy list before the cluster creation will not help, if you have a private cluster.

What you can do:

Add lifecycle management to the cluster. It will look like this:

resource "azurerm_kubernetes_cluster" "aks" {
  lifecycle {
    ignore_changes = [http_proxy_config.no_proxy]
  }
    .
    .
    .

This would work, but you just half way to the solution.

When you reapply your plan, it will not recreate the AKS cluster. But what if you willingly change the no_proxy parameters? In this case this will still ignored and the AKS doesn't recreate, what is not the expected behavior.

Lets assume, you heave the user provided no_proxy parameters in a no_proxy variable:

variable "no_proxy" {
    type = list
    default = []
}

The lifecycle management is able to trigger recreation of the resource with replace_triggered_by property. The problem with it, that the variable above, can't be the source of the trigger. But for example a resource can.

Here comes a dirty trick. How convert a variable list into a resource?

Hashicorp has a Terraform provider named tfcoremock (https://registry.terraform.io/providers/hashicorp/tfcoremock/latest/docs). I'll use it here.

First add it to the providers list:

provider "tfcoremock" {
  use_only_state     = true
}

Now, we can store the list above into the state:

resource "tfcoremock_simple_resource" "user-noproxy" {
  count = var.no_proxy
  string = var.no_proxy[count.index]
}

Now, we can reference it from the replace_triggered_by:

resource "azurerm_kubernetes_cluster" "aks" {
  lifecycle {
    replace_triggered_by = [tfcoremock_simple_resource.user-noproxy]
    ignore_changes = [http_proxy_config.no_proxy]
  }
  http_proxy_config {
    http_proxy = var.http_proxy
    https_proxy = var.http_proxy
    no_proxy = var.no_proxy
  }
    .
    .
    .

}

This is almost perfect, but not completely.

When you change any element in the no_proxy variable list, it will trigger the replacement, but if you add, or remove element from the list, it will ignore it.

One last step. Make the length of the list into work:

resource "tfcoremock_simple_resource" "user-noproxy" {
  count = length(var.no_proxy)
  string = var.no_proxy[count.index]
}

resource "tfcoremock_simple_resource" "user-noproxy-count" {
  number = length(var.no_proxy)
}

resource "azurerm_kubernetes_cluster" "aks" {
  lifecycle {
    replace_triggered_by = [tfcoremock_simple_resource.user-noproxy,
tfcoremock_simple_resource.user-noproxy-count]
    ignore_changes = [http_proxy_config[0].no_proxy]
  }
  http_proxy_config {
    http_proxy = var.http_proxy
    https_proxy = var.http_proxy
    no_proxy = var.no_proxy
  }
    .
    .
    .

}

Now, it is replace the AKS on any change in the no_proxy variable list, but keep it intact otherwise.

Bejegyezte: dátum: Nincsenek megjegyzések:
Feliratkozás: Bejegyzések (Atom)