Dimag - PowerShell

Remélem ezért nem leszek keresztre feszítve.

Szóval: Használom a Dimag-ot, előfizetéses elektronikus újságok olvasására, de nem szeretem. Az alkalmazás is a hozzáállás is csapnivaló.

Szeretem, ha az éveken évtizedeken keresztül olvasott szaklapok megvannak a gépemen pdf-ben. Ez amolyan gyűjtőszenvedély féle (biztos orvoshoz kéne fordulnom).

Persze a Dimag-ból kiszedni a dolgokat nem igazán lehet. Elvégre arra szántak rengeteg energiát, hogy a holnapi napot is titkosítsák, arra meg nullát, hogy egy értelmezhető felhasználói élményt nyújtsanak.

Arra jutottam, hogy képernyőfotóként lementem az oldalakat, majd ebből csinálok pdf-et.

Ennek az első része mechanikus, igényel némi rendszeres precizitást. Szóval:

• Dimag Chrome-ban megnyit.
• Bal oldali oldalankénti navigáció kikapcsol
• Teljes képernyőre kirak (F11)

Így minden oldal, minden esetben ugyanoda kerül a képernyőn (az egyes oldalak középre, az oldalpárok két oldalra). A képeket egyes oldalnál <oldalszám>.jpg, oldalpárnál <páros oldal>-<páratlan oldal>.jpg néven mentem. Minden oldalszám szigorúan három számjegy.

Na eddig van a mechanikus munka (még gondolkozom, tudom-e tovább automatizálni). A lementett jpeg-ekre megy ez a PowerShell + ImageMagick script, és már kész is a friss ropogós pdf:

$srcfiles = Get-ChildItem "./*.jpg" | Sort-Object -Property Name

$dstlist = ''

foreach($jpg in $srcfiles) {

    if($jpg.Name -match '[0-9]{3}-[0-9]{3}\.jpg') {

        magick $jpg.Name -crop '1483x2081+436+7' "p$($jpg.Name.Substring(0,3)).jpg"

        $dstlist += "p" + $jpg.Name.Substring(0,3) + ".jpg "

        magick $jpg.Name -crop '1483x2081+1920+7' "p$($jpg.Name.Substring(4,3)).jpg"

        $dstlist += "p" + $jpg.Name.Substring(4,3) + ".jpg "

    }

    else {

        if($jpg.Name -match '[0-9]{3}\.jpg') {

            magick $jpg.Name -crop '1483x2081+1178+7' "p$($jpg.Name.Substring(0,3)).jpg"

            $dstlist += "p" + $jpg.Name.Substring(0,3) + ".jpg "

        }

    }

}

$dstlist += "result.pdf"

Start-Process -NoNewWindow -FilePath "magick.exe" -ArgumentList $dstlist -Wait

Remove-Item p*.jpg

A fenti kód az én 4K monitorommal működik. Más monitorhoz át kell írni a méreteket.

Továbbá:

• Nem árulom el, melyik magazinnál használom.
• A saját infrastruktúrám az elkészült pdf-ek nem hagyják el.
• Amivel dolgozom, azt előfizettem, nincs benne semmi hack

Műszervezérlés - irányok

 

A dolgok változnak.

Amikor újrakezdtem a műszervezérlő projectemet, világos volt az irány előttem. Majd rájöttem pár dologra, ami arra késztetett, hogy újragondoljam a projectet, és hogy az egészet én hogyan látom.

Először is, ezt találtam: https://github.com/xyphro/UsbGpib

Ez pontosan az amire szükségem van. 90%-ban biztos vagyok, hogy a firmware amit fejlesztettem a saját panelemhez szükségtelen (meglepetések persze érhetnek, amikor ezt a saját panelemre a és a szoftverkörnyezetemhez próbálom adaptálni, de ennek kicsi az esélye).

A vezérlő szoftverembe bekerült egy plusz réteg a VISA fölé (alapvetően a soros-GPIB megoldásom miatt). Gondolkodtam rajta, hogy ez esetleg most kidobható lenne, de rájöttem, hogy vannak eszközök amik HID-t, vagy saját protokolt használnak, amiket nem tudok a VISA esernyő alá begyömöszölni.

Van egy nagy dilemmám a további fejlesztéssel kapcsolatban. A desktop műszervezérlő alkalmazásra gondolok itt.

A helyzet:

Ma a szoftver fejlesztés világában minden a mobilról a webről és a felhőről szól. Teljesen tiszta, hogy a világ ebbe az irányba halad. Még én is DevOps szakiként, felhő alapú web projecteken dolgozom, már jó pár éve.

De...

Mindig az a zavaró "de".

De a műszervezérlés világa, egy kicsit különbözik. Amit látok, érzek a műszer vezérlő és megjelenítő szoftverekről, hogy elsősorban nem web technológiák köré épültek. Ezek, változatlanul desktop alkalmazások. Én ezt nem akarom megváltoztatni. Kényelmesebb ezeket így használni, egyszerűbb közvetlenül kommunikálni a hardverrel, stb.

A saját szoftverem C#-ban kezdtem el fejleszteni .NET Framework-ön Visual Studioban, WinForms-al. Ez az a platform, amiben a legtöbb saját tapasztalatom van. Ha megtartom a lusta hozzáállásom, csak egyszerűen folytatom ezt és elfelejtem a dilemmám. Alapvetően magamnak fejlesztek, így nem igazán kell törődnöm ezzel.

De valami állandóan viszket a fejemben. A fenti technológia kezd túlhaladott lenni. A saját projectjeimet (a feladat megoldása mellett) tanulásra is használom. Szóval a kérdés: Milyen irányba menjek?

A másik dolog ami izgat ebben, a Linux. Kéne egy több platformon futó eszközt írnom? Saját magamnak, nem feltétlenül. Ha más is akarja használni ezt, akkor ez szükségessé válhat.

A lehetőségek, amiket látok:

• Tartsam ezt meg, folytassam a fejlesztést és csak felejtsem el a dilemmám?
• Költöztessem át a .NET 6, WPF, MVVM megoldásra, hogy újabb platformom legyen? Ez még mindige nem jelent Linux platformot, csak remélhetem, hogy valaki csinál egy használható verziót a MAUI-ból Linuxra.
• Költözzek át .NET 6-ra és használjak valami harmadik gyártó UI-t (Avalonia, UNO Platform, QT, vagy más)?
• Felejtsem el az egész C# és .NET vonalat és használjak mást?
• A Python-hoz van a PyVISA műszervezérló könyvtár. Nem igazán szeretem a Python-t és még mindig kell találnom valami UI-t.
• A Java-hoz vannak desktop framework-ök, de mi lesz a műszerekkel?
• A Node.js-hez ott az Electron, de a VISA-t támogató könyvtárak minősége, eléggé kérdőjeles.
• Bármi más ami nem jutott eszembe?

Próbáltam összegyűjteni (legalább részben) a követelményeket:

• Natív desktop alkalmazás
• Hardver kommunikáció (Soros, USB-HID, IVI réteg, mint a Keysight IO Library Suite, USB-TMC, stb.)
• Grafikai elemek - Dialógus ablakok, Data grid, szöveg mezők/vezérlők, és ami a legfontosabb, diagrammok.
• Valami plug-in architektúra (plugin kell a műszerekhez, kommunikációs platformokhoz, stb. - az egésznek bővíthetőnek kell maradnia)
• Hálózat kezelés
• Fájl rendszer kezelés

Biztos van még más is. Egyenlőre ezeket látom.

Szóval, ha vannak gondolataid erről, kérlek oszd meg velem!

USB-GPIB csatoló V2.1

 

Ez egy némi javítás, hibakezelés a korábbi ATMEGA32U4 alapú USB-GPIB csatolómhoz. Az előzőnek volt néhány baja. Ütközött a bootloader LED-jeinek a konfigurációja a GPIB jelekkel. Teljesen újradefiniáltam az eredeti Arduino jelekhez képest, hogy ki tudjam használni az interrupt kezelést. Továbbá egy teljes 8 bites portot használtam adatbuszként, hogy egyben írható/olvasható legyen és ne bitenként.

Az új verzióban kicsit más lett a megközelítés:

• Próbáltam az Arduino Leonardo lábkonfigurációjánál maradni, amennyire tudtam.
• Feladtam az interrupt kezelést az SRQ vonalat leszámítva
• Megtartottam a 8 bit adatbuszt
• Konfigurálhatóvá tettem - lehet választani az AR488 által használt konfiguráció és a fenti 8 bites egybe adatbusz között (az AR488 verziónak nem kell speciális bootloader)
• Megtartottam az állapot LEDeket
• Hozzáadtam egy hibakeresésre használható soros portot

Később ez a terv lesz az alapja a teljes GPIB csatolónak, megfelelő vonalmeghajtókkal együtt. Ez a verzió, csak egy műszer vezérlésére használható (lehet, bírna többet is, de inkább nem próbálom ki). 

A kapcsolási rajz:

A nyák terv:

A robbantott 3D model:

Igen tudom, hogy a csatlakozó neme, nem a megfelelő (bár ki tudja ma már, hogy mi a megfelelő nem), de sajnos nem találtam megfelelő 3D modellt, és annyira nem volt fontos, annyi volt a lényeg, hogy reprezentálja a megfelelő méretet a 3D modell tervezéshez.

A teljes terv itt található:

https://gitlab.com/measurementcontrol/gpibinterfacehardware

Ezzel az a témában elkészült új tervek száma kettőre emelkedett, szóval itt az ideje, hogy megrendeljem a paneleket.

Új műhely

Végre hivatalos. Nagy harc volt a helyi önkormányzat bürokráciájával, hogy ezt sikerüljön elérni. Van egy új műhelyem. Még rengeteg pénz és munka lesz vele, amíg be tudok költözni (jópár hónapra számítok).

USB-RS232 Csatoló

 

A műszervezérlés tervem megvalósításaként, először megterveztem az USB-RS232 csatolómat. Lehet, hogy ez még nem az utolsó verziója, de egyenlőre végeztem a tervezési fázissal.

A szerkezet a CH340G chipen alapul, amit korábban az ESP8266-os programozómon is sikeresen használtam, ugyanez van egy rakás kínai USB-Soros kábelben, Arduino-kban, 3D nyomtató vezérlőkben. Sosem volt semmi bajom ezekkel az eszközökkel. A megfelelő jelszintek előállítására hozzáadtam még egy MAX232-es tokot.

Valószínüleg ez a megoldás nem optimális, miután nincs meg rajta az összes RS232 jel, de azt hiszem, egyenlőre jó lesz így (nem igazán akarok most több energiát belerakni ebbe).

A kapcsolási rajz:

A nyák terv:

Esetleg észreveheted a kapcsolási rajzon és a nyák terven, hogy "kettős" USB csatlakozás van rajta. Ez azt jelenti, hogy az USB jelek mind egy mikro USB csatlakozón, mind pár forszemen elérhetőek. Ez a megoldás azt a lehetőséget kínálja, hogy akár USB csatlakozóval, akár kábellel szereljük össze az eszközt.

Ennek a koncepciónak megfelelően két különböző dobozkát terveztem hozzá.

USB csatlakozóhoz:

Kábelhez:

Megfigyelhető, hogy a panel maga a 3D terven szürke. Az ok, hogy nem tudtam a színes 3D modellt beimportálni az OpenSCAD-be, amit a 3D modellezéshez használok (lehet, nem is tud ilyet).

Az eredeti 3D nézet, ilyen:

Jelenleg még nem akarom a panelt legyártani, mert a GPIB csatoló következő verzióján dolgozom és össze akarom montírozni egy panelre a gyártási költségek csökkentése miatt.

A tervek itt találhatóak:

https://gitlab.com/measurementcontrol/rs232interfacehardware

Nekiálltam a mindenféle műszervezérlős dolgom átszervezésének is. A kapcsolódó repók itt lesznek majd elérhetőek:

https://gitlab.com/measurementcontrol

Műszervezérlés - újrakezdve

 

Bevezető

Az elmúlt években rengeteg munkát raktam a különböző műszereim számítógépes vezérlésébe. A terv az volt, hogy valami hozzáadott értéket teremtsek vele, úgy mint logolás, jobb láthatóság, több - integrált - funkció, stb.

Úgy néz ki, hogy ezzel kicsit megbuktam, miután semmi sem jutott el, a használhatósági állapotba.

Az egészet, hónapokkal ezelőtt félretettem. Most úgy érzem, ideje leporolnom és újrakezdenem, hogy valami "működő" állapotig eljussak vele.

Tervek

A forrás repók újraszervezése

Ez azért szükséges, mert rengeteg dolgot tanultam az elmúlt években a munkám kapcsán a gitről (branch stratégiák, release kezelés, etc.)

USB-RS232 interfész tervezés

Van egy pár eszközöm ami RS232 interfésszel rendelkezik a GPIB helyett/mellett. Igen, vehetsz USB-Soros átalakítót gombokért. Miért kell egy másik? A legtöbb darab amit kapsz, nem tudja a megfelelő jelszinteket. TTL szintet használnak RS232 helyett. A legtöbb professzionális műszernek szüksége van a megfelelő jelszintekre. A megfelelő csatoló nem olcsó, vagy azt kockáztatod, hogy veszel valami vackot az Aliexpressen ami azt állítja magáról, hogy megfelelő, közben nem.

USB-GPIB hardver újratervezése

Az ATMEGA32U4 alapú interfészem tökéletesem működik. Az elmúlt években ugyanakkor kiderült pár dolog ami arra késztet, hogy szükség van pár módosításra:

• Olyan fizikai terv kialakítása, hogy 3D nyomtatott dobozba lehessen tenni.
• Elhagyni azokat a csatlakozókat amiket későbbi továbbfejlesztésre terveztem bele mint kijelző plusz eszközök vezérlése, stb.
• Soros debug lehetőség (az AR488-nak megfelelően)
• Az Arduino Leonardo bootloaderrel való kompatibilitás
• Megtartani a teljes 8bites buszból adódó adat transzfer előnyöket (módosított bootloader szükséges)
• Az AR488 szoftverrel való kompatibilitás megtartása (https://github.com/Twilight-Logic/AR488)
• Aktivitás LED-ek hozzáadása (az eredeti Arduino Leonardo-nak megfelelően)
• Teljes GPIB meghajtó TI ICkkel (másik hardver verzió szükséges)

Az AR488 kompatibilitás megtartása nem jelenti azt, hogy a saját firmware-emet ki tervezném dobni. Változatlanul nem békéltem megy a 3000+ sor kóddal egyetlen forrásfájlban. Az AR488 még mindíg nem támogatja a GPIB másodlagos címzést. Van egy rakás eszközöm (VXI keretek, moduláris labortáp keret), amiknek szüksége van erre. A másik oldalon támogatja a device üzemmódot, a TI GPIB IC-it, amik az enyémből hiányoznak, továbbá megvan a szoftver támogatása olyan eszközökben mint a sigrok.

Proper bootloader for USB-GPIB

Csináltam egy bootloadert a v2.0-ás panelhez. Ez egy annak a mellényúlásnak az eredménye volt, hogy újrahasznosítottam az Arduino Leonardo USB visszajelző LEDjeit, ami megölte a GPIB kommunikációt. A problémát akkor megoldottam, de az eredménye egy rosszul dokumentált (https://it-pro-hu.blogspot.com/2020/04/gp-ib-5-v20-panel.html), nehezen reprodukálható állapot lett. Ráadásul ez kinyírja a LED-eket és nem áthelyezi más uC lábakra. Most létre akarok hozni egy karbantartható, újrafordítható, megfelelően telepíthető megoldást. Ezen túl szeretnék a szabályoknak megfelelő PID/VID páros kérni a pid.codes-tól.

Tápegység vezérlő szoftver

A virtuális műszer szoftverem sok dologra lenne alkalmas, de rájöttem, hogy túl magasra tettem a lécet, első nekifutásra. Sok mindent megcsináltam már benne, a jelenlegi újrakezdéshez kisebbet akarok fogni.

Tehát megtartva a cserélhető driver támogatást akarok csinálni egy tápegység vezérlő szoftvert a rengeteg tápegységemhez (ráadásul a HP 66000A moduláris tápegység nem is használható szoftver nélkül, mert nincs hozzá meg a saját billentyűzete). Ebbe egyenlőre nem akarom magasabb szintű funkciókat rakni.

Továbbiak...

Természetesen, nem akarok itt megállni, újra akarom indítani a virtuális műszer fejlesztésem, a karakterisztika rajzolót, stb.

Ezek a dolgok egyenlőre homályosak, és ha elveszítem a fókuszt ezem megint, annak csak egy polcra rakott project hegy lesz az eredménye. Megint.

Terraform, Cloudformation és Cognito

Némi IT és némi felhő újra

IaC eszközökkel dolgozom már nem is igazán tudom mióta. Az AWS CloudFormation-nel kezdtem valamikor 2014 körül (nem biztos, ez a ködös múltba vész)

Amikor elkezdtem a Terraformról tanulni, bennem volt a félelem, hogy nem fogok teljes AWS funkcionalitást kapni. A CloudFormation natív AWS eszköz. Valami amit egy külső gyártó fejleszt - elméletben - csak követheti a szolgáltató natív eszközét.

Elkezdtem Terraformot használni, mert ez volt az ügyfél elvárása, tehát a váltás nem az én döntésem volt. A fenti félelmem akkor vált kicsit valósággá amikor az ügyfél nem követte az AWS Provider verzióit megfelelően a saját deployment agent-jein (tehát ez nem róható fel sem a HashiCorpnak, sem a Terraform közösségnek). Tehát tulajdonképpen nem látszott valós lemaradás a Terraform oldalán. Emellett Terraform kódot írni sokkal kényelmesebb, sokkal több lehetőséget nyújt amikor feldolgozni, konvertálni kell, a rendelkezésre álló információt.

Egy pár hete, kb. három év kizárólagos Terraform munka után belecsöppentem újra egy CloudFormation projectbe.

Van egy - azt hittem - szuper egyszerű feladat. Publikálni egy Cognito User Pool Client titkos kulcsot az SSM Parameter Store-ba, titkosítva.

Terraformban ez így néz ki:

// Create Cognito User Pool
resource "aws_cognito_user_pool" "pool" {
  name = "pool"
}

// Create Cognito User Pool Client
resource "aws_cognito_user_pool_client" "client" {
  name = "client"
  user_pool_id = aws_cognito_user_pool.pool.id
  generate_secret     = true
}

// Publish to SSM Parameter Store
resource "aws_ssm_parameter" "secret" {
  name        = "/production/cognito/clientSecret"
  type        = "SecureString"
  value       = ${aws_cognito_user_pool_client.client.client_secret}
}

És kész is vagyunk.

Próbáljuk meg ugyanezt a CloudFormation-ben.

Vajon a AWS::Cognito::UserPoolClient objektum, ki tudja-e exportálni a titkos kulcsot? Nem. Forrás: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cognito-userpoolclient.html

Vajon a AWS::SSM::Parameter objektum tud-e SecureString értéket létrehozni? Nem. Forrás: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html

Itt van ahol a fenti teóriám "A CloudFormation-nek előrébb kell járnia mint a Terraformnak" megbukik.

Sok mindennel próbálkoztam sikertelenül, hogy megoldjam ezt. Végülis a következő kódrészlet működött (egy megjegyzés: a Python kódban, az import cfnresponse nem az én trehányságom miatt van külön sorban. Ez kell az AWS lambdának, hogy észrevegye, kell neki a cfnresponse.py és belerakja a deployment során a zip fájlba, ugyanis nem része a pip repónak):

Resources:
  # Create Cognito User Pool
  UserPool:
    Type: "AWS::Cognito::UserPool"
    Properties:
      UserPoolName: pool

  # Create Cognito User Pool Client
  UserPoolClient:
    Type: "AWS::Cognito::UserPoolClient"
    Properties:
      AccessTokenValidity: 15
      AllowedOAuthFlowsUserPoolClient: false
      ClientName: client
      GenerateSecret: true

  # You need a lambda to
  #     - read from the cognito user pool client
  #     - write to the parameter store
  #     - report back to the CloudFormation when finished
  CognitoSecretExporterLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: CognitoSecretExporter
      Runtime: python3.9
      Role: !GetAtt CognitoSecretExporterExecutionRole.Arn
      Handler: index.handler
      Timeout: 30
      Environment:
        Variables:
          CognitoUserPoolId: !Ref UserPool
          CognitoUserPoolClientId: !Ref UserPoolClient
          ssmParameterName: /production/cognito/ClientSecret
      Code:
        ZipFile: |
          import boto3, os
          import cfnresponse

          def handler(event, context):
              CognitoUserPoolId = os.environ['CognitoUserPoolId']
              CognitoUserPoolClientId = os.environ['CognitoUserPoolClientId']
              ssmParameterName = os.environ['ssmParameterName']

              # Read Cognito
              cognito = boto3.client('cognito-idp')
              response = cognito.describe_user_pool_client(
                  UserPoolId = CognitoUserPoolId,
                  ClientId = CognitoUserPoolClientId
              )
              cognitoClientSecret = response['UserPoolClient']['ClientSecret']
              print(cognitoClientSecret)
              ssm = boto3.client('ssm')

              # Write to parameter store
              response = ssm.put_parameter(
                  Name = ssmParameterName,
                  Description = '[CF] Cognito Client Secret used by the WebApp',
                  Value = cognitoClientSecret,
                  Type = 'SecureString',
                  KeyId = 'alias/aws/ssm',
                  Overwrite = True,
                  Tier='Standard'
              )

              # Report success to CloudFormation
              responseData = {}
              responseData['Data'] = 120
              cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData) 

  # Trigger the lambda from the CloudFormation stack
  CognitoSecretExporterInvoke:
    Type: AWS::CloudFormation::CustomResource
    DependsOn: CognitoSecretExporterLambda
    Version: "1.0"
    Properties:
      ServiceToken: !GetAtt CognitoSecretExporterLambda.Arn 

  # IAM Role for the lambda above
  CognitoSecretExporterExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: CognitoSecretExporterExecutionRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Principal:
            Service:
              - lambda.amazonaws.com
          Action:
            - sts:AssumeRole
      Path: "/"
      Policies:
      - PolicyName: root
      PolicyDocument:
          Version: '2012-10-17'
          Statement:
            - Sid: EnablePutLogEvents
              Effect: Allow
              Action:
                - logs:CreateLogGroup
                - logs:CreateLogStream
                - logs:PutLogEvents
              Resource:
                - '*'
            - Sid: ReadCognito
              Effect: Allow
              Action:
                - cognito-idp:DescribeUserPoolClient
              Resource:
                - !GetAtt UserPool.Arn
            - Sid: ParamStore
              Effect: Allow
              Action:
                - ssm:DeleteParameter
                - ssm:PutParameter
                - ssm:GetParameter
              Resource: 
                - !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/production/cognito/ClientSecret

Gigabyte és a moduláris tápegységek

A CNC maró mellett (mint mindig), elkezdtem egy másik projectet is. Egy egy sima PC építés. Össze akarok rakni egy NAS dobozt, abból ami itthon van (padlás takarítás 😂).

A hosszú évek alatt több - úgynevezett moduláris - ATX tápegységet használtam. Ezek a cuccok lehetővé teszik, hogy kicsit csökkentsd a PC házon belül uralkodó kábeldzsungelt, azzal, hogy a szükségtelen periféria kábeleket le tudod választani a tápegységről. Ezek a háttértárolók, grafikus kártyák, stb. kábelei.

A tápokon található moduláris csatlakozók nincsenek szabványosítva, és általában azonos típusok a különböző gyártóknál (2 soros, 6 vagy 8 érintkezős Molex Mini Fit).

Igen, vettem tápokat különböző gyártóktól (Gigabyte, Chieftec, stb.). Igen, sosem címkéztem fel ezeket. És igen, egy dobozban tartom az egészet. Ez azt jelenti, hogy halvány fogalmam sincs, melyik kábel, melyik táphoz tartozik.

A NAS tápjához, szükségem van jópár kábelre (mindenféle keretekben, összesen 14 HDDt, SSDt tervezek használni). Ha ezeket összekavarom, el tudom képzelni, milyen tűzijáték lesz belőle.

Az alanyunk aktuálisan egy 550W-os Gigabyte Odin (valahol van belőle egy 800W-os is, csak még nem került elő a padlásról). Letöltöttem a doksiját. Benne is van a kérdéses csatlakozó kiosztása. (Azért húztam át pirossal, nehogy valaki használja, mert rossz)

Elkezdtem vakarni a fejem. A dobozban lévő kábelek egyike sem rendelkezik ezzel a kiosztással.

Multiméter bekapcs. Mér.

A gyanúm beigazolódott. A doksi hulladék.

Ez a jó kiosztás (a csatlakozó rajz a Molex-től van és a tápon magán lévő csatit mutatja), és megegyezik a dobozban található kábelekkel (lehet, hogy véletlen, de a Gigabyte, és a Chieftec ugyanazt a kiosztást használja):

Azure BB 2. - Allowed (inherited) ~ != Allowed

Van két git repo az Azure DevOps-ban. Két különböző org, két különböző project.

Az egyik a másik másolata. Írtam egy pipeline scriptet ami egy irányban szinkronban tartja.

Pár branch (kb. 10) szinkronja szétesett az elején, mert nem ezzel a scripttel történt az eredeti szinkron.

Rendbe akartam rakni. Azt tudom a fejlesztőktől, hogy a forrással a cél nyugodtan felülírható. Szóval forrás checkout cél push --force.

Ez ment is, két branch kivételével, ahol is közölte őnagysága, hogy nincs a baranch-re force update jogom.

Mi vaaaaan????

Túrom a jogosultságokat. Egyetlen csoportnak vagyok a tagja a cél projecten. Megnézem branch-re lebontva. Azt írja a GUI, hogy a csoportnak van öröklött force update joga.

Ok, de akkor miért nem megy? Adok a csoportnak közvetlen force update jogot, és csodák csodája, lefutnak a parancsaim. Nem, nincs valami deny ami bekavar, hiszen ez az egyetlen csoporttagságom és nincs közvetlen jogom. Továbbá, minden branch-nél be van kapcsolva az öröklődés, szóval ennél a kettőnél miért más az eredmény.

Csak nem mert BB?

Azure BB 1.

Tegnap kiírtam az FBn, hogy a BB az Azure szempontjából nem Balatonboglár vagy Budapest Bank, hanem Bugos Bmeg.

Volt aki kérdezte, hogy mi a bajom vele, mit nem tud amit az AWS igen. Egy dolgot: Az AWS működik.

Arra gondoltam, hogy leírom most már, amibe belefutok. Jelzem, ez a mostani, kb. az ötödik az elmúlt két hétben, csak most szakadt el a cérna végképp.

Na szóval. Tegnap este 6 körül próbáltam egy fura npm autentikációs hibát javítani az újonnan épülő Azure Pipelines környezetünkben. Még jó, hogy a jobokat egyenlőre senki sem használja, így el lehetett napolni a hibajavítást.

A jelenség a következő: egyszercsak az összes automatikus jobunk meghalt. Hibaüzenet nincs, mind cancel-re fut. Debug bekacs, a hibaüzenetek száma jelentősen nő. Nulláról, nullára.

Remek. Az össz dolog ami egyszer valahol a 15 körüli pipeline valamelyikében egy pillanatra bevillant, hogy a key vault hátterű variable group-ban használt service connection nem tudja olvasni a key vault-ot.

Végig is néztem, kibogarásztam a kapcsolódó service principalt, megnézetm a key vault-on a jogait, ott minden rendben. A variable group sem jelez hibát. Kb. ezzel hagytam ott tegnap. Hátha valami intermittent azsúr marhaság és mára megjavul.

Nem javult meg.

Nyomozok a neten, kugli a barátunk. Találok egy ilyet:

https://developercommunity.visualstudio.com/t/azure-devops-pipeline-job-cancelled-with-no-obviou/980961

Ebben a két dolog összevág. A key vaultos variable group, meg a canceled pipeline.

Na, újra is gyártom a service connection-t, berakom a helyére és láss csodát, elindul.

'95-ben érzem magam. Értelmetlen hibaüzenet (vagy még az se), újraindítom, ha nem javúl meg, újratelepítem.

CNC maró újjászületés 1.

2014-ben vettem egy CNC marót az Aliexpressen. Megtanultam használni. Volt vele egy rakás probléma, amit meg akartam (és el is kezdtem) oldani.

Lecseréltem az alulméretezett tápegységet két kapcsolóüzeműre, terveztem (és rengeteg munkát tettem bele) egy új maró motor vezérlőt. Elkövettem közben rengeteg hibát (leégettem az az egyik új tápegységet, majd később, a javítási kísérlet közben véglegesen kinyírtam). Még egy porleválasztót is terveztem hozzá (az is félkész).

A végén rájöttem, hogy sosem fog megfelelni az igényeimnek. Feladtam. Egyszer összeszedtem hozzá vezérlő alkatrészeket, hogy "csak úgy" működjön, de a végén hagytam az egészet ott kallódni a műhelyben.

Az alapvető problémák, amik miatt végül is feladtam:

• Rájöttem, hogy a 3040-es méret kicsi nekem. Sokkal inkább kellene egy 6040 vagy méginkább egy 6090
• A 300W-os (később 400W-osra cserélt) maró motor túl kicsi nekem. A felhasznált szénkefés DC motornak alacsony a nyomatéka alacsony fordulaton. Alumínium maráshoz alacsony fordulaton nagy nyomaték lenne az ideális. Nem tudok nagyobb motort (vagy akár egy kisteljesítményű BLDC motort) belerakni az 52mm-es tartóba. Ahhoz, hogy nagyobb motor kerüljön bele, a komplett Z tengelyt cserélni kéne miután az egészet (motor kengyel, lineáris csapágytartó, golyós orsó tartó) egyetlen darab aluból marták ki.

Végül arra jutottam, hogy az átalakítás túl sokba kerülne, és a végén a méret így is túl kicsi maradna.

Itt tartok most. Öt éve hozzá sem nyúltam.

Folyamatosan piszkálom a fiam, hogy csináljunk valami közös projektet, és ne csak a gépén játszon a szabadidejében. Néhány hete, előjött valami ötlettel. Arra jutottunk, hogy a megvalósításhoz kellene a működő CNC maró (próbáltam meggyőzni, hogy 3D nyomtassuk, de nem volt rá vevő).

Úgy éreztem, hogy ez egy jó alkalom, hogy újáépítsem a CNC marót, és ez engem is talán újra sínre tesz.

A terv:

Építek egy új vezérlődobozt a CNC maróhoz és összerakom a teljes munkafolyamatot a tervezéstől a marásig. Alapvetően azokból az alkatrészekből akarok építkezni, amik már most is megvannak. A cél, hogy a végén (a fiam projektjének befejezése után) eladjam a CNC3040-et és tudjak egy nagyobbat építeni.

A vezérlődoboz:

Egy régi PC midi torony. Ilyesmi mindig kallódik nálam, miután a 30 éve informatikából élek. :-)

• Egy mini-ITX alaplap: Gigabyte GA-E6010N - ezt most újonnan vettem, ehhez a projekthez
• 8GB DDR-3 RAM - volt otthon
• 60GB SSD - volt otthon
• 600W 48V tápegység a maró motorhoz - az előző CNC próbálkozásból maradt
• 100W 24V tápegység a léptetőmotorokhoz - az előző CNC próbálkozásból maradt
• 350W Chieftec PC tápegység az alaplaphoz és a GRBL vezérlőhöz - már megvolt
• Szilárdtest relé - volt otthon
• GRBL vezérlő kártya - évekkel ezelőtt megvettem a CNChez
• TB6600 léptetőmotor vezérlők - évekkel ezelőtt megvettem a CNChez
• Maró motor fordulatszám szabályozó - évekkel ezelőtt megvettem a CNChez
• Csatlakozók - a korábbi vezérlőből bontottam

1. Összeraktam a PCt az asztalomon, hogy a vezérlő szoftvert felrakjam rá

Egy Ubuntu Desktop 20.04 LTS került rá. Az ablakkezelőt lecseréltem az LXQt-re, hogy csökkentsem az előforrásigényt. Felraktam a Dockert rá (a munkámból adódóan az utóbbi években Docker függő lettem), és egy CNC.js konténert rá. Némi javítgatás még szükséges, de ez már csak akkor lesz lehetséges, ha a GRBL vezérlő a helyére kerül.

Az első feladat teljesítve a CNC.js elindult.

2. Rakjuk össze a vezérlődobozt

Kifúrtam pár popszegecset a PC doboz hátából. Kivettem a PC kártya tartó/alaplap ATX kitörés teljes acélszerelvényét. Kettévágtam az első kártyahely után (az első kártyahely még a mini-ITX alaplapon is rajta van). Amint megvoltam ezzel, visszaszegecseltem az egészet.

Levágtam pár merevlemez tartó fület a 3,5"-es helyeknél. Ez a 100W-os táp elhelyezéséhez volt szükséges. Szerencsére a találtam pár lyukat a doboz alján aminél fel tudtam fogatni a tápot csavarozás nélkül.

Vágtam két L alu profilt a 600W-os táphoz, hogy be tudjam rakni az 5,25"-ös helyre. Némi fúrás, menetvágás, csiszolás után, a helyére is került.

Csináltam egy papa tápcsatiból (a régi ata cuccokhoz valóból, ami volt otthon szereletlen) egy kábelt a szilárdtest reléhez, és beszereltem a relét a helyére (a doboz felső ventilátor lyukjai pont jók voltak).

Az az elképzelésem, hogy a relé majd elindítja a két plusz tápot, ha megnyomom az előlapi tápkapcsolót.

Módosítottam a PC tápot kicsit.

• Kicseréltem a hátlapi főkapcsolót nagyobbra, hogy kibírja a plusz két tápegység áramát
• Kivezettem egy sorkapocsra a hálózati feszültséget - Nem akarok még plusz hálózati aljzatot látni a doboz hátán.
• Kicseréltem a zajos (haldokló) ventilátort

Összeraktam a fentieket, valamint az alaplap, az SSD meghajtó is a helyére került.

Tudom, hogy ez most még nem látszik többnek, mint egy szokásos PC (semmi érdekes sincs benne, építettünk ilyet többszázszor), de a folytatás következik.

Újrakezdés

Talán észrevetted, hogy nem írtam semmit március óta. Nem voltam túl aktív az elmúlt két évben sem.

Sok dolog történik most körülöttem, ami kapcsolódik a blogoláshoz, a hobbijaimhoz, és akár a munkámhoz.

Azt tervezem, hogy sűrűbben fogok írni mostantól. Újrakezdek korábban félbehagyott projecteket. Meglátjuk, hogy ez a terv, mennyire vállik valósággá.

9/11

Hagy mondjak el egy történetet. Az én történetemet.

1996 December

New Yorkba látogattam, édesanyámmal. Nagymamám egy barátja hívott meg. Három hétig voltunk ott. Nem akarom az egész utat részletezni, csak két eseményt kiemelni.

Elmentünk az Empire States Building-hez (a tetejére). 5 órát álltunk sorba, hogy a liftekhez jussunk. Mire feljutottunk a tetőre már besötétedett. Megnéztük a várost felülről.

Az utazás utolsó napján láttam valahol a városban egy táblát, hogy a 86-os mólónál áll a USS Intrepid, múzeummá alakítva. Miután már csak pár óránk maradt, nem volt elég időnk meglátogatni. Ez volt a fejemben: Legközelebb.

2000

Ebben az időben a nyomdaiparban dolgoztam. Terveztünk egy céges látogatást a düsseldorfi Drupa kiállításra. Édesapám súlyosan megbetegedett, ezért töröltük az utat. A következő évre terveztek egy hasonló kiállítást, ezúttal Chicago-ba, a PRINT 01-et.

2001 September 6.

Édesapám meggyógyult, szóval irány Chicago. Az utat a Nyomdász Szakmai Szövetség szervezte. Összesen 10 emberel indultunk el. Azt terveztük, hogy a szakmai program után két napot New Yorkban töltünk.

2001 September 9.

Megérkeztünk New Yorkba. Tettünk egy buszos körtúrát, mert néhány embernek a csoportból ez volt az első New Yorki útja. Még a WTC-hez is elmentünk körülnézni.

2001 September 10.

Két kollégám másnap reggelre azt tervezte, hogy hajnalban korán felmegy a WTC tetejére, hogy megnézze a várost felülről. Engem is hívtak. Úgy döntöttem, hogy nem megyek. Először is öt évvel korábban már láttam a várost egy felhőkarcoló tetejéről, másodszor, meg akartam végre nézni a USS Intrepid-et, ami '96-ban lemaradt.

Miután a két kolléga nem beszélt angolul, úgy döntöttek, hogy velem jönnek másnap reggel a múzeumba ...

A véletlenek összjátéka, hogyan mentheti meg az életed.

Ma 20 éve történt.

Rádiótechnika - R.I.P.

 Ma olvastam a hírt. Bezár a Rádiótechnika:

http://qrp.hu/radioamator/elt-71-evfolyamot-lehuzza-a-rolot-a-radiotechnika/

Őszintén szólva, nem kár érte.

Nem vagyok rádióamatőr, így ebből a szempontból nem tudom megítélni. Elektronikai szempontból viszont igen. Az elmúlt évek cikkei színvonaltalanok voltak, láthatóan fogalmuk sem volt arról az irányról amit az amatőr (vagy hobbista) elektronika vett az elmúlt években (vagy talán már évtizedekben).

Mondom ezt annak ellenére, hogy még cikket is írtam benne.

Hozzá kell tennem, hogy amit az RT-vel kapcsolatban érzek, az nem egyedi. Eltöltöttem egy pár évet a médiában, specifikusan pont a szaksajtóban. Végigéltem azt az agóniát, útkeresést, a jelen meg nem értését amit a papír alapú szaksajtó produkált. Azt, hogy a mai napig nem értik az elektronikus csatornákat, nem értik, hogy ami magyarországon, digitális lapkiadás néven a Dimag nevű vicc keretei között zajlik, az minimum is elkeserítő.

Azt gondolom, hogy a magyar elektronikai közösség megérdemelne egy kiadványt, online teret, fórumot akármit. Igen, a világ tele van rajzokkal cikkekel, lapokkal, amikből lehet tájékozódni. Igen magam részéről úgy gondolom, hogy az idegen nyelvek ismerete elengedhetetlen. Ennek ellenére jó lenne valami helyi.

Azt gondolom van téma. Ez a nagy elektronikai hobbi, vagy mára divatosan, kicsit kibővítve hívhatjuk "Maker"-nek is, igen szerteágazó. Én magam is rengeteg különböző témával fogalakoztam az évek során, ami mind ide kapcsolódik. Viszont semmi olyat nem látok, ami ezt össze tudná fogni.

Színvonalas cikkeket, építési leírásokat szeretnék látni. Közösséget, amire építeni lehet. Jelenleg azt látom, csak haldoklik az egész, és a hobbista teljesen magára van utalva.

Azt gondolom, ennek a közösségnek az építése, vezetése, információval való ellátása lett volna a Rádiótechnika feladata. Ezt a feladatot jó ideje nem töltötte be. Így azt kell mondjam, csak a múltjáért kár.

EPROM égetés 21/25V 2.

Miután ez nem valami nagy dobás project, gyorsan összedobtam a rajzokat és megrendeltem a paneleket. Az feszültségszabályozóra sem akartam valami új csodát használni, így maradt a jó öreg MC34063, kapcsolható osztóval és ennyi.

A panel majd a JLCPCB-től jön, a legolcsóbb gyártási és szállítási opcióval. Ezt a projectet már egy jó ideje itt tologatom a gépemen, szóval semmi extrát nem vagyok hajlandó kifizetni, hogy a lustaságomat behozzam.

EPROM égetés 21/25V 1.

Az előző Fake in China bejegyzésem után, folytattam a munkát a 2716-os EPROM-ok írásával kapcsolatban. Rendeltem egy második adag EPROM-ot más forrásból. Ez a széria bíztatóbbnak tűnik:

Azonos chip méret, két különböző dátum kód. Erről is azt gondolom, hogy kínai másolat, de talán működik.

Van még egy probléma, ami nem egészen jött át a múltkor.

A TL866II programozó, amit használok, nem támogatja a a 21V-os programozó feszültséget ami a tokra van nyomtatva. Ráadásul az ST dokumentációja szerint, ennek 25V-nak kéne lennie. A programozó csak 18V-ot tud. Ez nem lenne elég, még akkor sem, ha az ICk eredetiek lennének.

Ezt a megoldást találtam: https://pinside.com/pinball/forum/topic/program-21v-25v-roms-in-lower-voltage-programmers

Ez remek, csak nem tetszik.

Ez nekem egy olyan vérbeli hack megoldás. Egy megfelelő adaptert szeretnék. Azt szeretném, ha a pin detect funkció változatlanul működne. Egy dugasztápot szeretnék használni és nem labortápot. Szeretném, ha a 21V/25V programozó feszültség kapcsolható lenne. Szeretném továbbá a TL866II-t megvédeni az esetlegesen hibás EPROM-októl.

Egy fórumon megkérdeztem, hogyan működik a pin detect funkció. Más részről, volt egy ködös elképzelés a fejemben:

Mi van, ha: az eredeti programozó lábat egy diódán keresztül hozzákötöm a programozandó chip-hez miközben a programozó oldalt egy nagyértékű ellenállással földre húzom. Ezt kiegészítve fogok egy n csatornás mosfet-et, egy zenerrel detektálva, ha a feszültség nagyobb mint - mondjuk - 12V. Ezzel az n csatornás mosfettel földre húzom egy p csatornás mosfet gatejét, ami a külső programozó feszültségre  és a programozandó chip Vpp-jére van kötve.

A fórumon, amellett, hogy mi a francért kellenek nekem ezek az IC-k, meg miért nem építek egy teljes programozót nulláról, jött két értelmes válasz is:

A TL866II kapcsolási rajza:

https://proghq.org/wiki/images/3/3c/TL866II_Schematic.pdf

Egy megoldás, egy német oldalról:

https://www.dr-bosch.com/volker/umbau/index.html?#VppAdapter

Ez a második, azt a kapcsolást tartalmazza, ami a fejemben volt azzal a változtatással, hogy bipoláris tranzisztorokat használ a mosfetek helyett.

Molnár Károly, Sümegi István - Köszi a linkeket.

Szóval, a project itt kezdődik. A valódi programozás ez esetben várhat.

Az említett áramkörön túl tervezek hozzáadni egy boost konvertert, kapcsolható kimenettel (21V/25V - 12V bemenetről), valamint egy zener-t és egy ellenállást minden lábhoz, a programozó védelmében.

Itt látható, hogyan indulnak el a későbbi félbehagyott projectjeim. :-D

A terv itt lesz elérhető, ha kész vagyok vele:

https://gitlab.com/suf/suf-electronics-TL866II-HV-EPROM

Hi-Fi állvány - Motoros lemezjátszó tálca 3.

Eldöntöttem, hogy idén a félbehagyott projectjeim befejezésére fogok fókuszálni. Minden hónapban be akarok fejezni egyet. Ez csak egy terv, nem fogadalom (nem akarok a be nem tartott újévi fogadalmak csapdájába esni).

Az első a sorban (Januárra) a motorizált lemezjátszó tálcám. A szerkezetről szóló korábbi bejegyzések itt találhatóak:

The first one in the row (for January) is my motorized turntable tray. The previous posts about it can be seen here:

• http://it-pro-hu.blogspot.com/2019/12/hi-fi-allvany-motoros-lemezjatszo-talca.html
• http://it-pro-hu.blogspot.com/2020/01/hi-fi-allvany-motoros-lemezjatszo-talca.html

Mióta nekikezdtem Január elején, sok minden történt vele:

Since I restarted January, many things happened with it:

• Beszereltem a végleges elektronikát
• Lecseréltem a TI DRV8825-ös léptetőmotor vezérlőt egy Trinamic TMC2209-re
• Majdnem teljesen újraírtam a programot, TMCDriver és AccelStepper alapon, miközben az eredeti érintőszenzor könyvtárat meghagytam.
• A tavalyi év során sikerült újra beüzemelnem a 3D nyomtatót, egy hosszabb, szenvedésekkel teli periódus után, most stabilan működik, tehát lehetőségem adódott, hogy a tálcába is 3D nyomtatott alkatrészek kerüljenek. Ezért egy új kábel vezető kar került a szerkezetbe a megbízhatatlan műanyag szalag helyére. Ezt végülis az érintőszenzor kábeléhez és a hálózati kábelhez használtam. Az audiohoz később tervezem, hogy készítek még egyet valamikor
• Szintén 3D nyomatként készült egy tartó a hátlapi csatlakozónak
• Csináltam egy táp dobozt (átmeneti megoldás amí a tápegység elkészül):
  Van benne:
• +12V - dugasztáppal
• +5V  - dugasztáppal
• Földelés (az érintő szenzorhoz kell)
• Soros csatoló
• Beszereltem a végleges helyére

Amikor a soros kommunikációs részét írtam, egy fura jelenséget tapasztaltam.

A PC-s kapcsolat, teljesen használhatatlan adatfolyamot generált. Teljes káosz. Amikor lecseréletm az USB-Soros átalakítót, az sem oldotta meg. Nem értettem, miért. Majd bevillant egy ötlet...

Igen, 12MHz-es kristályt használtam a 16MHz helyett. Ez azt jelenti, hogy minden korrektül működik, kivéve a soros kommunikációt. 115200 baud az Arduino oldalon 86400 baud-ot jelent a terminálban. Amint ezt átállítottam, el is kezdett normálisan működni.

Nem akartam így hagyni, szóval kicseréltem a kristályt:

A kész elektronika beszerelve, a motorral és a kábelvezető karral

A tápdoboz

Csak egy pár dolog maradt:

• Jobb tartó a bordásszíjhoz
• Egy második kábelvezető kar az audio kábelhez
• A Hi-Fi project következő fázisa, ami a tápegységet is tartalmazza

Működés közben az asztalomon:

Project kész, beszerelve a helyére:

A tervek és a kód megtalálható itt:
https://gitlab.com/suf/suf-hifi-rack

Fake in China (EPROMok)

Amikor kinyitottam a HP 8903B Audio Analizátor dobozát, kiderült, hogy a processzor panelen a rom memóriák eléggé szedett-vedett képet mutatnak. Össze-vissza mindenféle gyártótól. Nem igazán kedvelem azt. A megbízható működés érdekében úgy gondolom, hogy az EPROMokra pár évtizedente ráfér a frissítés, hogy a műszer stabil maradjon.

Az eredetieket nem akartam törölni, így az lett a terv, hogy egy teljesen új EPROM garnitúrát programozok hozzá. A 2716 és a 2516 EPROMok már nem elérhetőek a szokásos megbízható szállítóktól, így az eBay-en kerestem. Rendeltem is 20db-ot. Megjött Kínából:

Tudom, hogy a gyártók időnként cserélik a a gyártástechnológiát, a hosszú ideig piacon tartott eszközöknél. De ne már! Három különböző chip méret, azonos dátumkóddal?

Gyerekek, azért ennél tudtok ti jobbat! :-D

Ettől függetlenül, kipróbáltam. A 20-ból 1 viselkedett EPROMként a programozóban. Azt sem sikerült megírni.