Szia,

OK, így már értem.
Az Altgr = Ctrl + Alt, vagyis két kódot is visszaad, a 17-eset és asszem a 18-asat vagy a 16-osat, most ebben nem vagyok biztos, hogy melyiket...

Előzmény: dezsoe, 2014-11-03 16:21:00 [1478]

Szia!
A sorkapocs azért is praktikus, mert a méreténél fogva elférnek a nem SMD alkatrészek is. Az SMD nekem már túl kicsi, nem látom... Persze, ha kész lesz és beválik a teszteken, akkor még mindig át lehet tervezni picire.
Az AltGr példa arra utal, hogy pl. egy funkciót a @-ra konfigolok, akkor az magyar billentyűzeten AltGr-V. Az UCCNC-ben az AltGr-ig jutsz el, kapsz egy 17-es kódot és kész. A #1434-ben már írtam, hogy ugyanígy kiesett a Ctrl-O kombináció is. (Most vettem észre, hogy a Ctrl és az AltGr egyformán 17-et ad vissza.)

Előzmény: n/a (inaktív), 2014-11-03 14:18:00 [1477]

Szia,

Jól hangzik a dolog.
A SW szűrés is nagyon jó, de hardveres is legyen benne szerintem mindenképpen 1 soros ellenállat + egy kis kerámia kondi a jel és föld közé minden bemenetre.
A panelt ha van rá mód SMD-re tervezd, ha már az olcsóságnál tartunk, akkor az olcsón akár tömeggyártható is, de kis szériában is olcsóbbak az SMD alkatrészek általában.

Talán 2 oldalt volna érdemes rakni sorkapcsokat és hosszúkásra tervezni a panelt és akkor egy alj lemezzel és egy DIN hüvellyel akár DIN sínre is kényelmesen felpattintható, sorolható lehet.

A szoftver új verziót most már tényleg hamarosan kiadjuk.
Az AltGr dolgot amit írtál azt nem teljesen értem.

Előzmény: dezsoe, 2014-11-03 12:25:00 [1476]

Szia!
Igen, HID billentyűzet lesz, megfelelő HW és SW szűréssel. Azért is várom a hotkey kezelés módosítását, amit korábban írtál, mert egy gombhoz akár AltGr-es kódot is lehet rendelni (egy fizikai gomb, de kettőt lát a gép), így a normál billentyűket lehet arra használni, amire valók, nem ütköznek a vezérlővel.
A cél az, hogy megbízható legyen, de pici-ócó alkatrészekből is össze lehessen rakni, elvégre hobbizunk.

Előzmény: n/a (inaktív), 2014-11-03 11:23:00 [1475]

Sziasztok,

Svejk: Igen, UC100-nál is használható a 48db hotkey.

Dezsoe: gondolom olyan mikrovezérlővel csinálod, aminek van beépített USB portja és HID eszközként ismerteted fel a PC-vel és úgy külöd át a billentyű kódokat?
Majd ne felejts el a bemenetekre egy-egy RC tagot felpakolni zavarszürés, áram korlátozás és prellmentesítés miatt. A pokeys megbízhatósága végülis ezen bukott el, hogy ezen akartak spórolni...
Kíváncsian várom a fejleményeket, ha alakul majd a projekt.

Előzmény: svejk, 2014-11-03 11:16:00 [1474]

Nem semmi!

Biztos vagyok benne, hogy lesz rá fizetőképes kereslet, mert azért az UC300 48 trigger bemenete is gyorsan el tud fogyni.

Balázséktól kérdezem, hogy ugye jól gondolom, hogy az UC100-hoz is használható lenne ez a 48 Softkey funkció?

Előzmény: dezsoe, 2014-11-03 10:17:00 [1472]

Bocs Úgy értelmeztem hogy el lett halasztva . Írok magánban legföljebb este látod . üdv

Előzmény: dezsoe, 2014-11-03 10:17:00 [1472]

Szia! Nem futott spam-re, elvileg #1436-ban válaszoltam is rá. Azóta annyi változott, hogy Balázs írta, hogy a Pokeys nem az igazi, így mégis elővettem a feladatot. Tegnap este próbapanelon odáig jutottam, hogy egy jobbra és egy shift már remekül működik. Már "csak" annyi van hátra, hogy a megfelelő zavarszűréssel a Svejk által kért (#1398) 48 bemenetet tudjam kezelni. Kitartás, dolgozom rajta!

Előzmény: ANTAL GÁBOR, 2014-11-03 06:26:00 [1471]

Dezsoe!A napokban ment egy mail . Lehet hogy spamra futott? Légy szives klickelj rám és adj egy elérhetőséget .

Előzmény: dezsoe, 2014-11-02 14:50:00 [1468]

Ezt a charge pump kezdeti bekapcsolást is amit leírtál megfogom hamarosan vizsgálni.

Előzmény: dezsoe, 2014-11-02 14:50:00 [1468]

Megtaláltam a hiba okát. Valóban UC100-nál nem jól volt lekezelve az enable jel a felső biteken, vagyis a 14., 16., 17. lábon csak bekapcsolni kapcsolta be és úgy is maradt, ahogy leírtad. Ezt most javítottam. A következő kiadásban már jól fog működni.

Előzmény: dezsoe, 2014-11-01 15:40:00 [1458]

Annyi haszna mindenképpen volt a hibának, hogy megépítettem egy charge pump érzékelőt, így végre nem okoznak problémát a beragadt szintek.
Megfigyeltem, hogy induláskor egy pillanatra bekapcsolja a cp-t akkor is, ha nincs bejelölve a charge pump always on. Utána már a Reset-tel kapcsolható rendesen. (Szerencsére ilyenkor már a többi jel - főleg a marómotoré - jó szinten van, így nem okoz bajt.)

Előzmény: n/a (inaktív), 2014-11-01 18:12:00 [1461]

Köszi! Az ötlet jó, de az M0/M6 előnye, hogy Cycle start-tal tudok továbbmenni.

Előzmény: csewe, 2014-11-01 20:14:00 [1466]

Tedd ezt a makróba az exec.stop helyett.

MessageBox.Show("Továbblépéshez nyomja meg az OK gombot.");

Amíg nem kattintassz a felugró ablakban az OK gombra,addig állni fog a programod futása.

Előzmény: dezsoe, 2014-11-01 19:15:00 [1465]

Előre is köszönöm!
Kicsit a #1460-hoz is kapcsolódva, már akartam kérdezni, hogy az M0 nincs tervbe véve? Most M6-tal pause-olok, de a pause az mégsem szerszámcsere. (Próbáltam M0 makróból exec.Stop-ot, de nem az igazi a kérdései miatt.)

Előzmény: n/a (inaktív), 2014-11-01 18:12:00 [1461]

Mach3 -nál csak kipróbálásig jutottam, nekem ennyi elég volt…
Mint már írtam, nekem csak pár ipari vezérléssel volt dolgom, és
Linux CNC -vel. UCCNC – is egy ígéretes Windows -os rendszernek
tűnik, és remélem így is lesz !

Előzmény: n/a (inaktív), 2014-11-01 18:20:00 [1463]

Igen, ez valóban így van, illetve Mach3-nál is így van ... próbáld ki. És az aszinkron működésből adódik, illetve a pufferelés miatt van. Vagyis mert a programnak előre látnia kell a kódsorokat az előrenézés miatt, így előre betölti azokat, a változók értéke már előre megváltozik és ha megállítod a program futását, akkor visszafelé nem lehet ezeket visszaszámolni, annyi lesz az értékük, amennyi az előrenézett programban volt.
Szóval ez a működésből adódik, mach3-nál LPT porttal is így van.
Ílletve már kitaláltam rá a megoldást az UCCNC esetében a későbbiekben meg fogjuk csinálni, hogy ne így legyen. Mach3-nál viszont így van, annál nem lehet megcsinálni, hogy ne így legyen se LPT porttal, se UC100-al.

Előzmény: fektiforg, 2014-11-01 17:50:00 [1460]

Nincsen. A profil fáhlban át kell írni a screenset file nevét ahhoz, hogy a profil azt a screenet-et töltse be, így vannak összerendezve.

Előzmény: csewe, 2014-11-01 16:18:00 [1459]

megfogom nézni mi lehet.

Előzmény: dezsoe, 2014-11-01 15:40:00 [1458]

Még egy tapasztalás részemről : paraméteres programot futtatok, futásközben ciklusstopot
nyomok ( pl. kivágás közben félrebillen az anyag és útban van, muszáj megállítani a futást)
Újra ciklusstartra összevissza, kiszámíthatatlanul „koricál” , mintha az aktuális változók
törlődnének, ez szerintem így nem jó. Más általam ismert vezérlőknél, ez a dolog csak M30
hatására történik.

Van lehetőség őj profilhoz másik screenset betőltésére,anélkül,hogy a profil file-ba bele kellene írni?

Gondom van.

UC100-am van, UCCNC 1.0039, a leírtakat az X, Y és Z tengelyen is próbáltam. Ha az Enable a 14-es, 16-os vagy 17-es lábon van, akkor nem működik rendesen. A lábat 0-ból 1-re tudja váltani, ha előzőleg 0 volt, de vissza nem kapcsolja. Független az Active low kapcsolóktól. Más lábon ezt nem tapasztalom (O1, O8, O9-en próbáltam, a többin tengely van). Először az én elektronikámra tippeltem (az egész saját tervek alapján épült, ezért minden lehet...), de miután alaposabb tesztnek vetettem alá a programot, kiderült, hogy UC100 demó módban is így megy, a diagnosztika fülön lehet nézegetni.
(Természetesen az elektronika a 17-esen negálva várja az Enable jelet...)

A Getlabel tökéletesen működik.

Én viszont tényleg olyan drot akartam felraki,amit nem tud a felhastznló módosítan,mert ccsak kijelzésre hastználnám.
Úgy tűnik,hogy lényegében már minden utasításrt értek a screenset-ben.
A makróhoz meg az UCCNC.exe file-ból lesem ki a szükséges utasításokat,bár néha kell kicsit kísérletezni,és ojkor nem találom ami kell.

Előzmény: n/a (inaktív), 2014-11-01 12:13:00 [1454]

Mint friss uc 300 tulajdonos kérdezem, hogy miként lehet egy bemenetre Pl? 1 port 15 pin
több funkciót is hozzárendelni. x++,home,y--. stb.

Igen, a ToDouble a ludas, ahogy mondod, mert egy label-t töltesz fel a képernyőre és egy input mezőt olvasol ki. A kettő fajta objektum nem ugyanaz, így nem is jön létre 20000-es számú input mező. A Getinputlabel üres stringgel ("") tér vissza, ami nem konvetálható double értékké, ezért van a hiba.

Előzmény: csewe, 2014-11-01 12:10:00 [1453]

Egyetlen probléma van csak a kóddal, a screenset-re feltöltés a probléma, nem a double string konverzió.

A Sendlabeltoscreen az egy olyan címkét készít, ami a képernyőn csak olvasható, de nem szerkeszthető, ez a fajta teljesen más, mint az input mező. Ez a fajta mezőt a Getlabel(); függvénnyel tudnád kiolvasni, nem a Getinputlabal();-el, de szerintem neked nem ilyen mező kell, hanem amit a user tud szerkeszteni a képernyőn.

A következő függvényre cseréld ki a Sendlabeltoscreent:

public void Sendinputtoscreen(string labeltext, string labelfont, string textalign, int fontsize, int fontcolor, int posX, int posY, int intextboxwidth, string type, double min, double max, int labelnumber, int parentnumber)

Például:

AS3.Sendinputtoscreen(" ", "Arial", "center", 22, 0, 100, 100 , 80, "fieldnb", 0, 300, 20000, 36);

Előzmény: csewe, 2014-11-01 11:51:00 [1452]

Mikor csak ezt a sot hagytam a makróban,akkor is megékezett a hibaüzenet,tehát tévedtem,és nem a tostring függvény a ludas,hanem a todouble:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));

Tehát módosul a kérdésem.
Hogyan kérdezzem le és alakítsam számmá a dro-k értékét?

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Alap módon működik,de valódi dro kiolvasánál hibát ad.
A sreenset-ben így helyeztem el a dro-t:
AS3.Sendlabeltoscreen("1230", "Arial", "right", 25, 35535, 110, 520, 20000, 49);//

És így olvasom ki:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));//1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Őgy tűnik,hogy több paraméterel kellene ellátni a "Convert.ToString" függvényt,de nem találtam elég jó példát rá.

hibaüzenet.

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Szia, menet válasz.
Ide is bemásolom, hátha valaki mást is érdekel.
double szám konvertálása string-é makróban, példa:

double a = 1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Előzmény: csewe, 2014-11-01 10:42:00 [1450]

Szia Balázs,ment egy levél kérdéssel.

A "Jöszi" az "Köszi" akart volna lenni.

Előzmény: n/a (inaktív), 2014-10-31 21:08:00 [1448]

Szia,

Jöszi a hibajalentést.
Azt szeretném kérni, hogy most várjátok meg légyszi a következő kiadást. Addig most felesleges MPG további bugokat jelenteni, mert az MPG-ben a hibákat éppen javítjuk és így most mégegyszer át lesz nézve teljesen. Illetve a javításnál mindent újra tesztelünk. Szóval az új kiadás ami a 1.0040-es lesz (hamarosan), majd az után kérnénk szépen újra MPG-vel kapcsolatos hibajelentéseket.

Előzmény: lari, 2014-10-31 20:49:00 [1447]

Ma a következő hibajelenséggel találkoztam.MPG gomb bekapcsolva, Kézikereket forgatva, közben a Cont. gombot megnyomva a tengely bizonyos sebességgel tovább mozog.Reset gomb, vagy a végállás kapcsoló állítja meg.

Helyes, fő a minőség!
Igyekszem mielőbb tesztelhetőt alkotni.

Előzmény: svejk, 2014-10-31 16:31:00 [1444]

Ez viszont tényleg jó hír, legvégsősoron feltuningolok hardveresen egy billentyűzet elektronikát.

Előzmény: n/a (inaktív), 2014-10-31 09:30:00 [1435]

Az a Pokeys, meg a többiek ránézésre is tök gagyik.

Ha Te csinálsz egyet és valami probléma lesz, akkor lesz kihez fordulni segítségért.
És hidd el nem hagynánk, hogy vackot adj ki a kezedből!

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

2.) Igen, pontosan erre gondoltam, kapcsolhatóan. Akkor akár a színezés is kikapcsolató lehet, hogy ne zabálja a procit, hiszen elég akkor megnézni, hogy mi a gond, ha nem futtatható a kód.

Előzmény: n/a (inaktív), 2014-10-31 10:28:00 [1441]

Szia,

OK, köszi az infókat.
Kérlek majd ha használod többet a szoftvert és találsz bármi problémát még, vagy ami esetleg nem tetszik, akkor írd le ide vagy nekem e-mailben és akkor elgondolkodunk rajta.

Előzmény: xabi, 2014-10-31 06:24:00 [1433]

2.) Szóval arra gondolsz, hogy ha van hibás kód, akkor jelezze és semmi ne fusson, el se induljon ciklus start-ra? Vagy legalábbis választható legyen egy ilyen opció?

3.) Igen, amit leírtál megoldást, azzal a módszerrel kitudod olvasni a Z mérési eredményt és utána a változó értékét feltudod használni.

Előzmény: dezsoe, 2014-10-31 10:18:00 [1440]

Huh! Köszönöm a gyors választ!

1.) Ez durva...
2.) Ezt úgy gondoltam, hogy ha van a betöltött g-kódban legalább egy olyan mondat vagy bármi, ami hibás (tehát kihagyná), akkor ne lehessen az egészet futtatni.
3.) A számítások rendben vannak, csak az a fránya Z... Viszont a #1431 nagyon hasznos volt, mert kiderült belőle, hogy csak egyszer fordítja a makrókat, így most meg tudom oldani a Z kiolvasását egy M310 makróval, ami egy sor: exec.ivars[9]=exec.GetZpos();, majd használom a #9-et. Csak a sebessége miatt aggódtam, de #1431 megnyugtatott.:)

Előzmény: n/a (inaktív), 2014-10-31 09:55:00 [1439]

Szia,

Kérdésekre a válasz:

1.) A kód szinezését még az elején megcsináltuk, de sajnos a Flashplayer annyi proci időt zabál a szinezésre, hogy nem igazán jó. Utánaolvastam és arra jutottam, hogy nincsen rá egyelőre megoldás. Az, hogy csak pirosra szinezi a nem végrehajtható kódokat, gyakorlatilag ez a művelet zabálja fel a teljes proci idő (amit az UCCNC használ) kb. 30-40%-át ami azért eléggé durván sok. Ha minden szinezve lenne különböző szinekkel, akkor több proci időt eszik maga a szinezés, mint a program egész többi része. Ez szerintem nem működő megoldás így. Talán valamikor az Adobe a Flashpalyerben megoldja majd, hogy a szines sztringek ne zabáljanak ennyit.
2.) Ha hibás egy kód, akkor az nem futtatható, hiszen hibás.
3.) Van ilyen, ismeri a parametrikus programozást az UCCNC, az amit írsz, hogy # változókból vegye az adatokat, azt tudja a program, sőt képleteket is tud számolni, sőt sin, cos, tan, abs, stb. függvényeket is ismeri. Viszont a G31-nél nem teszi el változóba a mérés eredményét, ez még nincs megcsinálva.
Több infó a parametrikus programozásról, a rendelkezésre álló függvényekről stb. a dokumentációban.

Előzmény: dezsoe, 2014-10-31 09:44:00 [1438]

Nagyszerű, az jó lesz!

Lenne viszont néhány kérdésem, észrevételem.
- A kód színezőbe nagy meló lenne belenyúlni? Az a gondom, hogy minden, amit nem hajt végre, az piros, de nem mind hiba. Nem lehetne az Nxx sorszám pl. sárga, a megjegyzések pl. zöld színnel? Akkor messziről látszik, hogy nem hiba, csak irreleváns a futtatás szempontjából.
- Már jóval korábban is kérdezte valaki, de nem rémlik, hogy lett volna állásfoglalás arról, hogy lehetne-e valahol egy pipa, hogy a hibás kód futtatható legyen-e. Én biztos bepipálnám.
- Lehet-e belső változókat olvasásni G-kódból (pl. G31 után #2002 a Mach3-ban)? Ha nincs ilyen funkció, akkor legalább a tengely pozíciókat meg lehetne-e oldani a változókhoz hasonlóan mondjuk #X, #Y stb. módszerrel? (A példában levő G31 utáni Z olvasás kéne nagyon.)

Előzmény: n/a (inaktív), 2014-10-31 09:30:00 [1435]

Pokeysből annakidején vettünk pár teszt példányt, vannak vele problémák. Egyik gond, hogy nagyon zavarérzékeny. A másik, hogy a mikrovezérlő lábait soros ellenállás nélkül kivezették a panelon a sorkapcsokra. Többször előfordult, hogy egyszerű érintéstől az ESD miatt szétment valamelyik bemenet vagy kimenet, mivel nem raktak még egy soros ellenállást sem ami korlátozná az ESD kisüléskor vagy hosszú kábel csatlakozásból adódó induktív túlfeszültségeket. Szóval nagyon érzékeny az áramkör, önmagában nem lehet biztonságosan használni. Amúgy funkcionálisan működött.

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

Köszönöm! A #1398 és #1434 egyelőre rövidre zárta a kérdést, de ha mégis szükség lesz rá, akkor még elő lehet venni a feladatot.

Előzmény: ANTAL GÁBOR, 2014-10-28 17:02:00 [1382]

Fogja tudni kezelni a ctrl, alt, shift módosító gombokat , ill. azok bármilyen kombinációit hamarosan. vagyis hogy pontos legyek már megcsináltam, de szoftver kiadás később lesz, mert még teszteljük az új, ill. javított funkciókat.

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

Volt egy ötletem, hogy mikrokontrollerrel hamar meg lehet csinálni, de amit javasoltak (PoKeys56U), az mindent tud, amire szükség lehet, kár lenne energiát fektetni bele. Csak az a probléma, hogy az UCCNC egyénileg értelmezi a gombokat, így nem lehet módosító billentyűt nyomni. (Én pl. a file betöltést szerettem volna a máshol megszokott Ctrl+O-ra rátenni, de a Ctrl-re beírt 17-et, az O már nem is érdekelte...)

Előzmény: svejk, 2014-10-29 12:42:00 [1398]

Szia,
- 0038-at használtam.
- A 3sec nempontosan gondoltam, lehet hogy csak 0,5 sec, csak zavaró hogy nem történik semmi kényszert érzek hogy újból megnyomjam-e a gombot vagy ne. A Mach3 rögtön reagált. Lehet hogy csak szoknom kell.
- A cycle start után is gondolkodik pár másodpercet, de utána tényleg hibátlanul és gyorsan fut, ez tetszett.

Még csak 1 napja hsználom, majd jövőhét végére kitapasztalom, ha gondom van írok.

Ja, még azt le akartam írni, hogy a 2800 soros progi nem szabadna, hogy gondot vagy bármilyen lassulást okozzon. Egyrészt mert a 2800 sor az nem sok, én többszázezer soros progikkal is teszteltem. A másik dolog, hogy ha tényleg olyan sok sorból áll a program, hogy az lassulást okozna, akkor automatikusan hozzá állítja a progi a frissi ciklusidejét például a 3D nézetnek, hogy ne legyen lassulás.
De a gyors hurkok, amik a mozgatást stb. végzik azok mindig 50Hz-el futnak, viszont azok nem "esznek" sokat.

Előzmény: xabi, 2014-10-30 20:30:00 [1430]

Szia,

Köszi a tesztelést.
Melyik szoftver verzió van feltelepítve?

Ezt a 3sec késést nem nagyon értem, nincsen valami felesleges várakozás beleírva a makróba. Olyan 300msec körüli késés a makró végrahajtásánál az előfordulhat ha hotkey-re van definiálva, mert a C# fordító valósidőben fordítja be mindig a makrót, csak így lehet azt megoldani, hogy szövegszerkesztővel bármikor át lehessen írni a makrókat és mindig a frissen átírt verziót futassa.
G-kód program futtatáskor ez a késés nem nagyon jelentkezik, mert olyankor a sorokat puffereli a progi és már előre befordítja a makrókat, de csak akkor futtatja, amikor odaért a végrehajtás, ilyenkor a késés nulla körül kell legyen.
A 3sec az nagyon sok, ott szerintem a makróban kell valami hiba legyen ami miatt várakozik.

Az egyetlen dolog amibe mesterségesen beépítettünk késleltetés, az a referenciára futás, ezt kollégám kérésére lassítottuk be, mert neki nem tetszett, ha rögtön ugranak egymás után a tengelyek.

Egyébként volt egy hiba a progiban, azért kérdezem melyik verziót használod, amit le is írtam, hogy a .stop eseménynél benne felejtettem a debuggoláskor használt pár dolgot, ami esetleg okozhat ilyen várakozgatást. A legutolsó verzióban ez már ki lett véve.

Azért is gondolom, hogy talán régi verziód lehet fent, mert a hotkeys definiálásánál nekem nem joggol a legújabb verzió, úgy látom, mintha már le lenne tiltva, bár a kódot még nem néztem át...

Előzmény: xabi, 2014-10-30 20:30:00 [1430]

A mai napra sikerült átírnom a mach3 makróimat UCCNC-re, így áttértem.

A hotkeys billentyűk konfigurálásánál össze vissza mozgott a gép itt is mindenképpen tiltani kellene a hotkeys billentyűket.

Ami tetszett :
- Első próbálkozásra egy 2800 soros (35.000 mm vágási hossz plazmán) programmal vágtam, hiba nélkül végig vágta.
- Sokkal jobb a kezelő felülete, főleg a szerszámpálya ablak.

Ami nem tetszett:
- valahogy lassú a program, vagy nem is a program hanem csak lassan reagál, vannak makróim amikhez hotkeys billentyű van rendelve, megnyomok egy gombot és 3 sec múlva történik csak meg az esemény. Mintha valami késleltetné..? Ha be volt töltve a 2800 soros program akkor még nehezebben reagált.
- Végig vágta a 2800 soros programot, de utána valami történt mert ref. home gombra csak a Z tengely állt referencia pontra. (újból kellett indítanom hogy megjavuljon.)
- Voltak még apró hibák amik nem voltak reprodukálhatóak (ha ki tudom szűrni mi okozta jelzem).