LabVIEW ken ik niet. Maar dat is jou probleem. Ik zie in de Engelstalige wikipedia dat je er alle kanten mee uit kunt.
Je hebt je draadje gepost in de rubriek Analoge besturing.
Stroomdetectie wordt meer geassocieerd met digitale besturing, al hoeft dat niet per sé.
De keus tussen het een (puntmeting) of het ander (sectiemeting) bepaalt de logica: als-dan-anders (statisch, puntmeting), zolang (dynamisch, stroomdetectie).
Je eerste idee (met hall-sensors) lijkt het meest op puntmeting: 2 punten (begin en eind).
Daar zit diepgang in. Maar ook 2 beperkingen:
- Rijd je alleen met loks of ook met wagons achter die loks?
Want als de lok de eindsensor in een blok passeert, en dus vrijwel direct daarop de beginsensor van het 2e blok activeert, dan zitten de (eventuele) wagons nog in het vorige blok, en misschien ook nog een gedeelte van de lok (als die lang is, en het magneetje voorop zit). Een alternatief (bij 1-richtingsverkeer) is 1 sensor tussen de rails en 2 magneten in de trein (op kop en op staart). - Rijdt een trein altijd in 1 richting, of zijn beide richtingen toegestaan?
Als een trein altijd in maar 1 richting rijdt, dan is al duidelijk wat het volgende blok is, en wat de beginsensor is en wat de eindsensor.
Als een trein in beide richtingen rijdt, dan is niet bij voorbaat duidelijk wat het volgende blok is, en dus ook niet wat begin- en wat eindsensor is.
Dat zijn i.h.a. zaken waar je niet bij stil hoeft te staan bij de toepassing van stroomdetectie.
Stroomdetectie meet puur het verbruik in een geïsoleerd stuk rails (sectie, blok, segment).
Digitaal is dat simpeler: er staat altijd rijspanning op de rails, en een lok verbruikt ook stroom als hij stilstaat.
Analoog is dat minder simpel: er staat alleen rijspanning op de rails als de trein rijdt,
er wordt dus geen stroom gedetecteerd als de trein stil staat.
De vraag is in mijn ogen niet wat beter is, maar wat goedkoper is (hallsensoren) en wat makkelijker programmeerbaar is (stroomdetectie). Omdat labVIEW een grafische ontwikkelomgeving is, waarin grafische code wordt omgezet in compileerbare programmeercode, en omdat je zowel state machine als event driven processen kunt verwerken, al dan niet multithreaded, zou het niet uit moeten mogen maken voor welke van de twee detectievormen je kiest. Beide benaderingen kunnen.
Detectiekeus maakt uit voor de besturing van de modelbaan, en dat vormt onderdeel van je opdracht.
Bij beide detectiekeuzes moet je analoog een manier vinden om te detecteren welke richting een trein op rijdt (met de klok mee, tegen de klok in), en als een trein in een blok van richting kan veranderen, dan moet het besturingsprogramma daarmee rekening kunnen houden.
Er zijn grofweg 3 manieren om de rijrichting vast te leggen:
- Statisch: Rijrichtingwijziging mag alleen via een door het programma gestuurd en uitleesbaar relais per blok
- Dynamisch: Elk blok heeft een eigen rijrichtingmetingscel samengesteld uit 2 dicht bij elkaar liggende hall-sensors; het programma heeft toegang tot het resultaat, een timer al dan niet als hardware ingebouwd in de richtingsensor of als softwareregeltje in het programma bepaalt de rijrichting
- Dynamisch: per rijrichting leg je een sensor aan het blokbegin, asymmetrisch, dus links of rechts van het midden. Door dat consequent te doen, b.v. met de klok mee links van het midden, tegen de klok in links van het midden, gaat alleen die ene sensor af en niet de andere (van de tegenrichting)
Wat wil je zelf: een statische of een dynamische aanpak?