Diverse issues
WillemKinzel opened this issue · comments
Ik ben bij het gebruik van TLCGen de volgende puntjes tegengekomen:
###reg.c
/* Bij nalopen op EG mag de volgrichting niet RR en FM
gestuurd worden indien de voedende richting groen is */
if (!R[fc29] || TNL[fc26]) { RR[fc26] &= ~BIT5; FM[fc26] &= ~BIT5; }
Dit blokje moet onder de FM-instructies staan in plaats van erboven
halfstar.c:
if (mlx == -1) for (ml = 0; ml < MLAMAX; ++ml) if (PRMLA[ml][fc]) { mlx = MLA; break; prml = PRMLA; mlmax = MLAMAX; }
Het break-commando moet volgens mij pas na 'mlmax = MLAMAX;'
De parameters prmaltghst## worden niet gebruikt
Er zijn 2 verschillende functies met bijna dezelfde naam: Alternatief_halfstar en alternatief_halfstar. Het enige verschil is de eerste letter: 'A' dan wel 'a'
Dit kan verwarrend zijn.
In ###reg.add, ###hst.add en extra_func.c zijn functie-definities van functies zonder argumenten in de aanroep, zoals
void KlokPerioden_Add()
{
}
Sommige compilers geven dan een warning. Met onderstaande wijziging kan je dat voorkomen:
void KlokPerioden_Add(void)
{
}
De parameter prmvolgmasterpl heeft een waarde (65.535) die veel hoger is dan de maximaal instelbare waarde in de parser (30.000/32.767).
Dit treedt op in regelingen met de halfstarre structuur (slave-regelingen).
Bij gebruikt van intergroentijden zou het handig zijn als bij het genereren van de projectfile ook de preprocessor definitie CCOLTIG wordt gegenereerd.
De geheugenelementen mmk## t.b.v. de dynamsche hiaattijden worden ten onrechte niet altijd gegenereerd.
Bij genereren van een projectfile voor ene regeling met halfstar en intergroentijden, wordt tigfunc.lib in de projectfile gezet i.p.v. trigfunc.lib.
Er worden soms koppelsignalen dubbel gebruikt. Dit betreft regelingen met de halfstarre structuur (master-regeling) en een uitgaande pelotonkoppeling.
In dat geval worden de uitgaande koppelsignalen 1 en 2 gebruikt door zowel de halfstarre module als de pelotonkoppeling.
Er is volgens mij ook niet een ander koppelsignaal te kiezen in de GUI van TLCGen, wat wel het geval is bij een inkomende pelotonkoppeling.
Ha Willem, dank voor de feedback. Morgen komt er nog een nieuwe versie met wat fixes.
- FM > gefixt op Github
- haflstar.c > gefixt
- prms altghst > deze worden wellicht ten onrechte aangemaakt. Ga ik na
- naamgeving functie hst_alt > eens. zet ik op de lijst
- () en (void) > gefixt
- prmvolgmasterpl > waarde 65535 betekent 15 bits op. de parser accepteert waarschijnlijk slechts 32767 omdat het een signed short is. zet ik op de lijst om eens te checken
- CCOLTIG en trigfunc.lib in projectifle > is bekend: staat op de lijst
- geheugen elems mmk## > kun je specificeren wat "niet altijd" is? hoe is dit te reproduceren?
- koppelsignalen > op github reeds enige fixes hiervoor van de afgelopen dagen. er komt tzt ook een wiki pagina. de signalen beginnen binnen TLCGen nu altijd bij 1. Hij telt inmiddels per kruising vanaf 1.
Inmiddels zit er in de versie op Github/appVeyor een nieuwe manier van omgang met koppelsignalen: zie tabblad Specials>PTP.
tigfunc/trigfunc is inmiddels ook verholpen.
Speelt het issue met mmk nog? Zo ja, stuur dan even direct een mail, of post het attachment op Github (niet via de mail). Het is in de eerdere mail weggevallen.
prmaltghst is inmiddels verwijderd, want deze wordt niet benut.
Is dit al verwerkt??