we/wy DI USB-4751 inicjowanie

[wojmalpoz]

Próbuję wykorzystać moduł we/wy dwustanowych USB-4751 do odczytywania wyjść TTL w kodzie BCD z urządzeń pomiarowych wzorując się na kodzie podanym w Examples dla środowiska Borland Builder.
Wyjścia BCD w urządzeniach są obciążane przez moduł USB do momentu ustawienia stanów wysokich (logiczne 1) w portach modułu.
Dla portów A i B po przejściu do trybu Input odczyt działa poprawnie, ale dla portu C nie - w dalszym ciągu port C obciąża wyjście BCD urządzenia. Wyświetlacz urządzenia na dekadach odczytywanych przez port C migoce, a odczytywane wartości są czasami poprawne, a czasami same jedynki.
Zaznaczam, że taka sytuacja ma miejsce tylko dla niektórych urządzeń, z innymi moduł USB-4751 i mój program współpracują całkowicie poprawnie.

Po wykonaniu najpierw testu odczytu programem fabrycznym Advantech Device Manager odczyt moim programem zaczyna działać poprawnie także dla portu C.

Czy jest jakaś operacja nie ujęta w podanych przykładach programowania w C++, którą dla portu C należy jeszcze zawsze dodatkowo wykonać?

[Jacek Bonecki]

A Pan w swoim programie ustawia kierunek portów?
A jeśli tak to w jaki sposób?
Ja próbowałem tego kiedyś akurat w Delphi i nie było z tym problemów - opis poniżej.
Jeśli nie uwzględnił Pan tego w programie to proszę spróbować.

Korzystać należy z funkcji DRV_DeviceSetProperty():
- pierwszy parametr to wskaźnik otwartego urządzenia (devicehandle)
- drugi parametr to stała CFG_DioChannelDirection (0x3006)
- trzeci parametr to adres bufora
- czwarty parametr to jego rozmiar

Bufor powinien zawierać dane typu DWORD.
Ponieważ na USB-4751 mamy 6 ośmiobitoych portów to możemy go sobie zadeklarować jako

var bufor:array[1..6] of DWORD;
ile:longint;

Przed wywołaniem tablicę wypełniamy kolejnymi wartościami:
0x0000 dla 8 x input
0x00FF dla 8 x output
0x00F0 dla 4 x output + 4 x input (tylko porty dzielone - C)
0x000F dla 4 x input + 4 x output (j.w.)

Kolejność:
bufor[1] - grupa 1, port A
bufor[2] - grupa 1, port B
bufor[3] - grupa 1, port C
bufor[4] - grupa 2, port A
bufor[5] - grupa 2, port B
bufor[6] - grupa 2, port C

Po odpowiednim wypełnieniu tablicy i ustawieniu zmiennej ile (ile:=6) wywyłujemy funkcję:

status:=DRV_DeviceSetProperty(devicehandle,CFG_DioChannelDirection,@bufor,ile);

Ustawienie warto sobie później jeszcze sprawdzić analogocznie przez DRV_DeviceGetproperty().

[wojmalpoz]

Kierunek działania portów ustawiałem,
ptDioPortMode.port = 2;
ptDioPortMode.dir = OUTPORT;
ptDioWritePortByte.mask = 0xFF;
ptDioWritePortByte.state= 0xFF;
ErrCde = DRV_DioWritePortByte( DriverHandle ,(LPT_DioWritePortByte)&ptDioWritePortByte);

jednak port C pomimo, że może być dzielony ustawiałem jako całość. Być może z tego wynikał problem.

[Jacek Bonecki]

Strukturę "DioPortMode" jak widzę Pan wypełniał.
Tylko nie widze wywołania funkcji "DRV_DioSetPortMode".
W każdym bądź razie z wykorzystaniem DRV_DeviceSetProperty jest już OK?

[wojmalpoz]

Dopiero za 2 tygodnie będę miał okazję sprawdzić.
Moduł jest obecnie w laboratorium z którym współpracuję w innym mieście.
Z funkcji DRV_DeviceSetProperty nie korzystałem, nie było jej użycia w Examples.
Samo nadanie wartości elementom struktury skutkowało użyciem jej parametrów przez DRV_DioWritePortByte i DRV_DioReadPortByte.
Dla portów A i B wykonując program krokami sprawdzałem na bieżąco rezultaty wpisywania wartości do rejestrów. Tylko port C ...
Dziękuję za poradę, odezwę się po sprawdzeniu skutków. Pozdrawiam.

[Jacek Bonecki]

Parametrem dla funkcji "DRV_DioWritePortByte" jest wypełniona struktura "PT_DioWritePortByte". I tylko ona.
Bo przecież nijak nie odwołuje się do niczego poza trzema wartościami "USHORT port;USHORT mask;USHORT state;".
Proszę więc wypróbować "DRV_DeviceSetProperty" lub dołożyć wywołania "DRV_DioSetPortMode".