GRT: Gordon's Reloading Tool (QL-alternativ)

[lone_wolf]

En QL licens kostar ca 160 EUR. En ganska liten summa ifall man är intresserad av handladdning. Har aldirg förstått de som kör piratversioner.

GRT var/är ett fantastiskt initiav Kanske inte på QL nivå ännu men den har ett nytt koncept med samarbete och diskussion kring mjukvaran. Det skulle vara verkligen synd om det stoppar.

Man får avvakta och om det visar dig att GRT är en återvändsgränd så blir det att köpa en QL licens.

Var det inte så att också QL är ganska mycket drivet ev en person endast?

[koenig]

Din första och sista mening gör mig förbryllad. Gör att jag spenderar mer pengar mig till en bättre människa?
Vore skitbra, då är jag stenklar för himlen..
GRT all the way..

[Ingvar]

Din första och sista mening gör mig förbryllad.
Gör att jag spenderar mer pengar mig till en bättre människa?
Vore skitbra, då är jag stenklar för himlen..
GRT all the way.

Vilken slutsats men lycka till i livet.

[Katjing]

Det verkar lite oklart, rättigheterna verkar ligga helt hos Gordon så det måste redas ut om någon skall ha nytta av hans arbete.

Det finns ett development team, men det verkar som om metoder och utvecklingsmiljö är lite ovanliga och att Gordon var viktig för att få någonting gjort. Jag tolkar det som om han var enda utvecklaren. Som det är nu så vill alla avvakta.

Jag kikade in på Discorden och där skrev någon att Gordon skrivit ett eget språk, kompilator, länkare och standardbibliotek. Så ganska hög tröskel för att ta sig an projektet. Förmodligen är det lättare, i alla fall långsiktigt, att göra en nyimplementation av själva appen men rädda databaser m.m.

[koenig]

Haha, Ingvar. Såg nu att du skrev piratversioner.. Trodde du menade GRT..
Mitt förbryllande var inte meningen att irritera dig.
Klart man ska betala för sig.

[malx]

Det verkar lite oklart, rättigheterna verkar ligga helt hos Gordon så det måste redas ut om någon skall ha nytta av hans arbete.

Det finns ett development team, men det verkar som om metoder och utvecklingsmiljö är lite ovanliga och att Gordon var viktig för att få någonting gjort. Jag tolkar det som om han var enda utvecklaren. Som det är nu så vill alla avvakta.

Jag kikade in på Discorden och där skrev någon att Gordon skrivit ett eget språk, kompilator, länkare och standardbibliotek. Så ganska hög tröskel för att ta sig an projektet. Förmodligen är det lättare, i alla fall långsiktigt, att göra en nyimplementation av själva appen men rädda databaser m.m.

Själva beräkningsmodulen kan nog också vara bra att porta. Men det är ju upp till efterlevande att bestämma, Gordon själv var ju tydligen lite emot open source av princip så det är nog inte så lätt att se vad han skulle velat. Hur som helst så lär de ha annat att tänka på närmsta tiden.

[Beretta56e]

Var herr Gordon äldre? Har bara namnet Gordon.

[darkness]

Finns nu en ny uppdatering till GRT som går ut 2048 för windowsburkar.

Operations announcement

February 2, 2022 - There are newer updated versions now available to everyone. The Windows version has an End Date for the year 2048.

February 4,2022 - A new Linux version is available today with the end date set to the year 2038 similar to the Windows version.
This version is listed as V2040. It Shows V2040 on the File menu / About screen.
I was able to revive a VMWare Player, Linux implementation, locally after not having used it for a couple of years.
I was able to run the V2040 Linux version on it, and manually advance the system date to Jan. 18, 2038 before I received any out of date message on screen,
so it appears the single byte patch is working. I was able to perform a Save As to a .grtload file, and then open the original file.
Therefore, I believe the patched V2040 version for Linux is working as before.

Project Relations
Gordons Reloading Tool
Berlin, Germany

[lasse-a]

Finns nu en ny uppdatering till GRT som går ut 2048 för windowsburkar.

Operations announcement

February 2, 2022 - There are newer updated versions now available to everyone. The Windows version has an End Date for the year 2048.

February 4,2022 - A new Linux version is available today with the end date set to the year 2038 similar to the Windows version.
This version is listed as V2040. It Shows V2040 on the File menu / About screen.
I was able to revive a VMWare Player, Linux implementation, locally after not having used it for a couple of years.
I was able to run the V2040 Linux version on it, and manually advance the system date to Jan. 18, 2038 before I received any out of date message on screen,
so it appears the single byte patch is working. I was able to perform a Save As to a .grtload file, and then open the original file.
Therefore, I believe the patched V2040 version for Linux is working as before.

Project Relations
Gordons Reloading Tool
Berlin, Germany

Tack för tipset! Står i begrepp att OBT-a lite nya laddningar och tänkte just på om min GRT gått ut, och hur det skulle hanterats.

Men då har vi iaf den senaste versionen tillgänglig ett (bra) tag framöver.

[fugazi]

Tips på [sudo apt-get install ] mottages tacksamt!
Alltså... finns det ett paket och vad heter det?

[NiKKEE]

Tips på [sudo apt-get install ] mottages tacksamt!
Alltså... finns det ett paket och vad heter det?

Längst ned sidan 16
https://www.grtools.de/lib/exe/fetch.ph ... -29-en.pdf

[nissan92]

RIP Gordon
Händelsen fick mig i a f att uppgradera min QL-snurra via den "danska länken"

Danska länken?

[ahlbjo]

Någon som sitter på kuldata till Norma DL 105 gr .243"? Att ta data för en omollad Berger blir lite missvisande

[BuuB]

Jag tycker GRT är lättare att tuna in till sin laddning genom OBTfunktonen .
Även om man är troende på OBT/OCW så är den funtionen väldigt bra .

Och än så länge är GRT gratis , men kommer att köpa direkt om det blir betalversion .

Väcker liv i tråden.

Ang. att kalibrera krutet m.h.a. OBT-funktionen. Hur bör man tänka där?

Jag menar, man får olika k och Ba värden beroende på vilken hastighetsdata man väljer att utgå ifrån i OBT-funktionen. Dessutom, vilket redan nämnts i tråden, så är ju inte hastighetskurvan linjär (men GRT utgår från en linjär hastighetsökning) vilket torde kunna ge "fel" krutvärden.

Ett teoretiskt exempel. Jag gör en laddstege mellan A, B och C. A är minsta laddning och C är högsta. B ligger något grain under C. Jag provskjuter laddstegen och matar in mätvärdena i GRT (hastighet, temp, träffbild etc)

Mellan A och B stiger grafen någorlunda linjärt men efter B så planar den ut och blir vågrät fram till C.

Perfekt tänker jag ett spann där jag kan hitta en OCW MEN blir det rätt i GRT om jag skulle kalibrera krutet efter någon av de hastigheter som kronografen registrerat mellan B och C?

Jag menar, jag ökar ju krutmängd men får ingen hastighetsökning, så dom värdena borde "lura" GRT (jag gör antagandet att GRT hanterar hastighet linjärt kopplat mot krutmängd)..?

Det är kanske så små skillnader att det inte spelar någon större roll men jag noterade iaf att jag får olika krutvärden beroende på vilken laddning/hastighet jag väljer att göra OBT på...

Kom på ytterligare en fråga. Är kalibrerade krutvärden överförbara på likvärdig bössa, t.ex. samma låda men annan pipa? Eller blir värdet specifikt för bössan som genererat det?

[Anders Ö]

Det är ju bara ett räkneprogram...
Det kan inte förutse ev variationer

Det du kan göra är att kalibrera runt hastigheten du får i verkligheten med en viss laddning , sedan kalibrera fram en OBT-laddning/Hastighet .
Det är alltså OBT-hastigheten du skall söka efter när du laddar , inte laddvikten .

Stämmer sedan inte laddvikten i verkligheten med vad GRT fått fram vid OBT-hastighet så kan du göra en ny kalibrering för att få en ny hastighet som max kommer vara ett fåtal meter ifrån den första förutsägelsen.

Ofta är det laborering med starttryck som måste till på en del kulor , särskilt kopparkulor.

Edit.
Såg inte sista frågan

Att överföra värden från en bössa till en annan är en tveksam åtgärd ...
Men om det är samma piplängd och laddningen ger samma hastighet så är det troligen överförbart , iallafall i fråga om att ligga i en OBT-zon .

Edit 2

Hastighetsökningen av krutladdning är oftast relativt linjär om man skjuter fler skott per laddning och har små steg och tar ett medel av hastigheter.
Som exempel , att ta hastighet från ett skott där kanske ES är på 10m/s kan ge felaktig indata

[BuuB]

Det är ju bara ett räkneprogram...
Det kan inte förutse ev variationer

Det du kan göra är att kalibrera runt hastigheten du får i verkligheten med en viss laddning , sedan kalibrera fram en OBT-laddning/Hastighet .
Det är alltså OBT-hastigheten du skall söka efter när du laddar , inte laddvikten .

Stämmer sedan inte laddvikten i verkligheten med vad GRT fått fram vid OBT-hastighet så kan du göra en ny kalibrering för att få en ny hastighet som max kommer vara ett fåtal meter ifrån den första förutsägelsen.

Ofta är det laborering med starttryck som måste till på en del kulor , särskilt kopparkulor.

Edit.
Såg inte sista frågan

Att överföra värden från en bössa till en annan är en tveksam åtgärd ...
Men om det är samma piplängd och laddningen ger samma hastighet så är det troligen överförbart , iallafall i fråga om att ligga i en OBT-zon .

Edit 2

Hastighetsökningen av krutladdning är oftast relativt linjär om man skjuter fler skott per laddning och har små steg och tar ett medel av hastigheter.
Som exempel , att ta hastighet från ett skott där kanske ES är på 10m/s kan ge felaktig indata

Ok! Jag tror att det är en bra inriktning att tänka hastighet och inte krutmängd. Kikade på mitt excelark med all data jag generat och filtrerade bara på bästa träffresultat för första gången. Det intressanta var att de sköts med kulor som snittade mellan 780-790m/s. Det hade jag inte reflekterat över tidigare. Dessutom finns det en OBT-laddningar som just genererar hastigheter i det spannet (oavsett vilken krutmängd + v0 jag utgår ifrån). Det var för övrigt en laddning jag identifierat som bra redan tidigare efter OCW och friflyktsstegar. Det ger ju en ökad trygghet i att det kan vara ett bra val.

[Anders Ö]

Det är ju bara ett räkneprogram...
Det kan inte förutse ev variationer

Det du kan göra är att kalibrera runt hastigheten du får i verkligheten med en viss laddning , sedan kalibrera fram en OBT-laddning/Hastighet .
Det är alltså OBT-hastigheten du skall söka efter när du laddar , inte laddvikten .

Stämmer sedan inte laddvikten i verkligheten med vad GRT fått fram vid OBT-hastighet så kan du göra en ny kalibrering för att få en ny hastighet som max kommer vara ett fåtal meter ifrån den första förutsägelsen.

Ofta är det laborering med starttryck som måste till på en del kulor , särskilt kopparkulor.

Edit.
Såg inte sista frågan

Att överföra värden från en bössa till en annan är en tveksam åtgärd ...
Men om det är samma piplängd och laddningen ger samma hastighet så är det troligen överförbart , iallafall i fråga om att ligga i en OBT-zon .

Edit 2

Hastighetsökningen av krutladdning är oftast relativt linjär om man skjuter fler skott per laddning och har små steg och tar ett medel av hastigheter.
Som exempel , att ta hastighet från ett skott där kanske ES är på 10m/s kan ge felaktig indata

Ok! Jag tror att det är en bra inriktning att tänka hastighet och inte krutmängd. Kikade på mitt excelark med all data jag generat och filtrerade bara på bästa träffresultat för första gången. Det intressanta var att de sköts med kulor som snittade mellan 780-790m/s. Det hade jag inte reflekterat över tidigare. Dessutom finns det en OBT-laddningar som just genererar hastigheter i det spannet (oavsett vilken krutmängd + v0 jag utgår ifrån). Det var för övrigt en laddning jag identifierat som bra redan tidigare efter OCW och friflyktsstegar. Det ger ju en ökad trygghet i att det kan vara ett bra val.

Ja , Jag själv har varit HardCore OCW-nerd genom åren , men när jag jämför data med OBTfunktionen så stämmer det oftast väldigt nära i hastighet

Jag gör nästan aldrig OCW mer utan kollar vilken
OBT-hastighet som är närmast min hastighet som jag vill ligga på , laddar sedan till den hastigheten och gör en friflykts-stege som är mitt NYA att nerda ner mig i , och har fått riktigt bra resultat med det
I min tråd om att mäta friflykt så finns det många bra exempel på detta