Na tle tego co Tuxc zasygnalizował pozwolę sobie dopisać.
Wszystkie systemy oparte na Windows nigdy nie dadzą dokładnego pomiaru, jedynie przybliżony którego
błąd może być bardziej lub mniej zmniejszany.
Jeżeli masz rejestr danej w postaci więcej niż jednobajtowej (XP to 4 bajty) to aby pobrać wartość
współrzędnej np X trzeba kolejno te bajty skopiować do pamięci. I to wystarcza aby była różnica w
momencie impulsu i pobrania pierwszego bajtu a kolejnym pobieraniem następnych. Bo licznik idzie i
ostatni skopiowany bajt określa już inną pozycję niż ta w momencie impulsu.
W Machu zorganizowali to tak że czytanie wartości licznika następuje po zatrzymaniu osi. Widocznie
uznali że stałe parametry skanowania pozwolą zachować stały błąd sprzętowy i go albo pominąć jako
niewielki ( bo faktycznie mały ) albo go wyznaczyć i wynik o tą powtarzalną wartość korygować.
Łatwo to sprawdzić skanując ściankę z np różnymi prędkościami najazdowymi albo z różnymi ustawieniami
silników (rozruch /hamowanie) To są wartości powtarzalne dla których można wymacać optymalne ustawiania.
Tak wygląda przy Machu na LPT.
Ale robi się katastrofa gdy stosujesz rozszerzenia komunikujące się przez kabel bo taka komunikacja
zawsze wprowadza opóźnienia których nie masz jak oszacować ani mieć pewność że są powtarzalne.
Bo kluczowa jest tutaj szybkość odpowiedzi do Macha z zacisku na sprzęcie Csimo. Buforowanie informacji wyklucza taki sens pracy.
Dlatego Csimo napisało własną procedurę skanowania która przebiega w ich sprzęcie a tylko gotowy wynik
jest zwrotnie udostępniany.
Dlatego w tym makrze które wrzuciłeś wcześniej na drugiej stronie jest G38.2.3.4 itd bo są to
wewnętrzne kody Csimo.
Oraz polecenie:
NotifiPlugins(010010)
które uruchamiają procedurę zewnętrzną (plugin) obsługującą zewnętrzny sprzęt fizycznie realizujacy
pomiar (dlatego Ci nie zadziałało bo nie skopiowałeś go do katalogu. Pomijam już fakt braku podłaczenia
sondy tam gdzie trzeba).
Jak to się odbywa? Autorzy wiedzą, może powiedzą.
Natomiast zawsze będą działać wszelkie makra napisane w składni Macha które sobie uruchomisz i działać będą bez względu na to czy Lepi pozwoli im działać czy nie.
Oczywiście uwzględnieniem ograniczeń tych warunków w prędkości odczytu.
Co więc dalej:
1) pomijamy rewelacyjne podpowiedzi eunuchów
2) wyznacz błąd skanowania czy wartość jest pomijalna lub powtarzalna (podpowiem jak)
3) jeżeli są do zaakceptowania to jak wcześniej pisałem - makro będziesz miał.
Tylko jeszcze trochę rozmowy w której wyjdą możliwe inne kwiatki typu błąd podłączenia (jakoś to krytykom umknęło przy zwalaniu na wadliwe kody i groźbę łamania sondy)
lepi pisze: ↑01 cze 2024, 13:39
ogarnięty programista napisał makro
nie znajac struktury sprzętowej czyli w ciemno, Oczywiście kol Lepi, oczywiście
Udostępnił dwa w tym z użyciem wspomnianego pluginu
A skanowanie też jest z błędem (chyba) bo nie wiadomo czy wynik to jest skanowania czy końca ścieżki - Mach tego nie rozróżnia, może wpisali taką analizę.
Dodane 1 godzina 27 minuty 45 sekundy:
zajrzałem na stronę CSmio do treści makra.
Sondowanie wysokości Z nie jest w żadnym miejscu inne niż by było dla Macha w LPT. Coś Lepi tu wlepia że nie jest przydatne, może nie widział.
Drugie makro - skanowanie XYZ z użyciem pluginu to jak ono działa to nie mogę się zorientować pomimo zamieszczonego opisu bloków jego działania. Ktoś pokaże gdzie jest fragment że ma szukać w osi X? Że jak
tu ustawię i jadę stąd
tam to trafię w ściankę i zobaczę gdzie ona? No nie widać miejsca w którym mogę wprowadzić ścieżkę poszukiwania. Może plugin po uruchomieniu wyświetla okienko z parametrami i to jest tam?
Ale gdyby było okienko na początku to dlaczego wynik jest w message a nie w nowym okienku?
Uwagi o szybkości przekazania do Macha miejsca kontaktu sondy pozostają bez zmian.
