czwartek, 6 kwietnia 2023 o 16:19:36 UTC+2 heby napisał(a):
> On 06/04/2023 16:09, Dawid Rutkowski wrote:
> > Trzymać w pamięci mirrora komplet rejestrów pieca - oczywiście jak najczęściej
> > odświeżany - i udawać piec i dla EW11 i dla "siebie".
> Zastanawiałem się nad tym na początku, czy nie zrobić emulatora. Ale tak
> sobie myślę, że tak arbiter byłby bardziej uniwersalny.
>
> Ja w ogóle nie wiem, czy go zrobie. Ale jak zrobie, to byłby open source.
>
> Wolałym aby producenci tych urządzeń mieli pojęcie o tym co się dzieje
> na rynku home automation. Ale chyba nie mają. Stąd te chmury, pralki z
> nfc, lampki na bluetooth i inne bezużyteczne guano na rynku "smart".
> Depresyjne klimaty.

Robią dla przeciętnego użyszkodnika, a nie dla fanów open source.
I pewnie im się sprzedaje.

W sumie taki arbiter to prosta rzecz - niewiele więcej niż np. konwerter prędkości RS
(sam robiłem na Atmega164, więc platforma na bogato - ale choć wygląda to prosto, to
trzeba było do różnych
systemów dodawać różne sztuczki, żeby dobrze działało - a najlepszą w tym temacie
rzeźbę widziałem na dwóch AT89C2051 - a może nawet to było AT89C1051U - które
odebrane bajty przekazywały sobie równolegle 8-bitowym portem ;) poza, jak
zwykle, "jedną raną stanowczo śmiertelną" - bo wracamy do tematu "gotowca",
czyli tego, jak zrobić interefejs do niewiadomego.
Czy ten arbiter ze strony powiedzmy TCP ma wyglądać jak abstrakcyjny model pieca?
Może oprogramowania HA mają takie "abstrakcyjne" modele - nigdy nie wnikałem,
więc kto wie, sam robiłem abstrakcyjny model źródła promieniowania laserowego...

do góry

On 06/04/2023 16:36, Dawid Rutkowski wrote:
> Czy ten arbiter ze strony powiedzmy TCP ma wyglądać jak abstrakcyjny model pieca?

Arbiter w ogóle nic by nie wiedział o typie urządzenia.

Wykrywał by ramkę modbusa, buforował i odsyłał na inny interfejs w/g
jakiegoś prostackiego priorytetowania. Może nawet ze zmianą parametrów
transmisji, jak ktoś się uprze.

Coś w rodzaju switcha ethernet store&forward.

Uniwersalność jest od osiągnięcia.

do góry

czwartek, 6 kwietnia 2023 o 16:54:04 UTC+2 heby napisał(a):
> On 06/04/2023 16:36, Dawid Rutkowski wrote:
> > Czy ten arbiter ze strony powiedzmy TCP ma wyglądać jak abstrakcyjny model pieca?
> Arbiter w ogóle nic by nie wiedział o typie urządzenia.
>
> Wykrywał by ramkę modbusa, buforował i odsyłał na inny interfejs w/g
> jakiegoś prostackiego priorytetowania. Może nawet ze zmianą parametrów
> transmisji, jak ktoś się uprze.
>
> Coś w rodzaju switcha ethernet store&forward.
>
> Uniwersalność jest od osiągnięcia.

Uniwersalny oznacza zwykle "do niczego konkretnego się nie nadający" (dziś
wyczytałem, że kacapy
wymyśliły "uniwersalny" reaktor jądrowy VVER-TOI - no to będzie znowu źle...).

Bo wciąż pytam o to, jaki chcesz mieć interfejs po TCP.
Czy:
- konwerter TCP<->RS485
- wysyłacz/odbieracz ramek modbus
- abstrakcja urządzenia wg schematu używanego przez jakiś system HA

No i jeszcze jedno mi przyszło do głowy - co z ramkami wysyłanymi przez y, czyli
piec?
Przecież na 100% nie wiadomo, komu odpowiada.
Wysyłać do obu masterów?
Do tego, który ostatnio nadał ramkę?
Pamiętać, o co który pytał?

do góry

On 06/04/2023 17:24, Dawid Rutkowski wrote:
> Uniwersalny oznacza zwykle "do niczego konkretnego się nie nadający" (dziś
wyczytałem, że kacapy
> wymyśliły "uniwersalny" reaktor jądrowy VVER-TOI - no to będzie znowu źle...).

Nie przesadzajmy. Switch ethernetowy jest uniwersalny, czy przerzuca
dane z Hubbla, czy pornole, wszystko jedno.

> Bo wciąż pytam o to, jaki chcesz mieć interfejs po TCP.
> Czy:
> - konwerter TCP<->RS485
> - wysyłacz/odbieracz ramek modbus
> - abstrakcja urządzenia wg schematu używanego przez jakiś system HA

Standardem jest to najgłupsze rozwiązanie: TCP->RS485 bez jakiejkowliek
formy, bazujące tylko na timeoutach. Uważam jest za najgorsze, ale z
jakiejś przyczyny jest "profesjonalne" i już na tej grupie kiedyś
dowiedziałem się, że mam z tym nie dyskutować bo przemysł wybrał jak
zwykle to najgłupsze ;)

> No i jeszcze jedno mi przyszło do głowy - co z ramkami wysyłanymi przez y, czyli
piec?
> Przecież na 100% nie wiadomo, komu odpowiada.

Wiadomo:

1) wysyłam ramkę od master1 (master2 czeka w buforze z blokadą)
2) slave dopowiada, przesyłam do master1, zwalniam blokadę

albo:

1) wysyłam ramkę od master1 (master2 czeka w buforze z blokadą)
2) slave nie odpowiada po określonym w konfiguracji czasie.
3) zwalniam blokadę nie odpowiadajac master1, on też sobie zrobi timeout
sam z siebie

> Do tego, który ostatnio nadał ramkę?

Do tego, który jest obecnie uznany za rozmawiajacego. To określony slot
czasowy, określany przeze mnie.

> Pamiętać, o co który pytał?

Nie trzeba. Timeout w master jest zazwyczaj przesadnie duży, a timeout w
slave zazwyczaj absurdalnie krótki. To daje przestrzeń na implemetancję
normalnego, konfigurowalnego timeoutu w arbitrze.

do góry

czwartek, 6 kwietnia 2023 o 18:49:09 UTC+2 heby napisał(a):
> On 06/04/2023 17:24, Dawid Rutkowski wrote:
> > Uniwersalny oznacza zwykle "do niczego konkretnego się nie nadający" (dziś
wyczytałem, że kacapy
> > wymyśliły "uniwersalny" reaktor jądrowy VVER-TOI - no to będzie znowu źle...).
> Nie przesadzajmy. Switch ethernetowy jest uniwersalny, czy przerzuca
> dane z Hubbla, czy pornole, wszystko jedno.

Ale sam ethernet to za mało na zrobienie newsa na usenecie czy też przesłanie zdjęcia
- czy to galaktyki w Andromedzie czy też czegoś innego w innej Andromedzie.

> > Bo wciąż pytam o to, jaki chcesz mieć interfejs po TCP.
> > Czy:
> > - konwerter TCP<->RS485
> > - wysyłacz/odbieracz ramek modbus
> > - abstrakcja urządzenia wg schematu używanego przez jakiś system HA
> Standardem jest to najgłupsze rozwiązanie: TCP->RS485 bez jakiejkowliek
> formy, bazujące tylko na timeoutach. Uważam jest za najgorsze, ale z
> jakiejś przyczyny jest "profesjonalne" i już na tej grupie kiedyś
> dowiedziałem się, że mam z tym nie dyskutować bo przemysł wybrał jak
> zwykle to najgłupsze ;)

A w ogóle da się zrobić modbus RTU na konwerterze RS485?
Coś podejrzewam, że ten EW11 to coś wyżej jednak, np. konwerter modbus TCP<-> modbus
RTU.

I coś takiego byłoby przydatne w tym "arbitrze".

No bo "uniwersalność" upada, gdy chcemy konkretne zastosowanie i trzeba adaptować.
Niech będzie do jakiegoś HA.
Z czym to HA, którego używasz, współpracuje po TCP?
Z konwerterem na RS485 (multum ustawiania)?
Z bramką modbus TCP<->modbus RTU (sporo ustawiania)?
Z urządzeniem modbus TCP (też sporo)?
Z abstrakcją pieca (sporo rzeźbienia po drugiej stronie)?

do góry

On 07/04/2023 18:00, Dawid Rutkowski wrote:
>> Nie przesadzajmy. Switch ethernetowy jest uniwersalny, czy przerzuca
>> dane z Hubbla, czy pornole, wszystko jedno.
> Ale sam ethernet to za mało na zrobienie newsa na usenecie

Bo tym zajmuje się zupełnie inna warstwa.

> A w ogóle da się zrobić modbus RTU na konwerterze RS485?

Tak.

> Coś podejrzewam, że ten EW11 to coś wyżej jednak, np. konwerter modbus TCP<->
modbus RTU.

Nie ma czegoś takiego jak "modbus TCP". Wysyłasz bajt do portu TCP i
wypada on po stronie RS485. Wpada bajt po stronie RS485 i wypada on z
portu TCP. Możesz taki konwerter "zrobić" na jednym poleceniu w Linuxie:
socat. Przez wiele lat miałem tak właśnie zrobione.

I to ze wszystkimi kosekwencjami tego kretynizmu braku opakowania. Jak
na przykład łamanie ramek TCP powodujące konfuzję i timeouty. Znowu
standard przemysłowy wymyślał ktoś bez pojęcia o sieciach.

> Z czym to HA, którego używasz, współpracuje po TCP?

Np. z innym EW11, sterującym rekuperacją. Ramki modbus są tworzone w HA
za pomocą stosowanego pluginu, ja okreslam jaki rejestr, jaki adres i
jakie ip:port i leci. Gołe bajty RTU. O, take:

modbus:
- name: recuperation
type: tcp
host: x.y.z.w
port: 8899
sensors:
- name: recuperation_gear
slave: 1
address: 4
scan_interval: 4

automation:
- alias: Set recuperation gear
trigger:
- platform: state
entity_id: input_number.recuperation_gear
action:
service: modbus.write_register
data:
hub: recuperation
unit: 1
address: 4
data_template:
value: ["{{states('input_number.recuperation_gear') | int}}",0]
[...]

> Z konwerterem na RS485 (multum ustawiania)?

EW11 w domyślnej konfiguracji jest dość prosty. Problem jak chcesz np.
automatyczne odpytywanie czy jakieś transporty, których nie sprawdzałem.

> Z bramką modbus TCP<->modbus RTU (sporo ustawiania)?

Nikt tego nie używa na poważnie. bajt tcp<->bajt uart jest "przemysłowym
standardem" ze wszystkimi konsekwencjami dziadostwa.

Jakoś kilka(naście?) lat temu była afera, że co więksi kretyni
wystawiali te zabawki do internetu, a mowa była o automatyce w dużych
obiektach przemysłowych.

> Z abstrakcją pieca (sporo rzeźbienia po drugiej stronie)?

Akurat abstrakcja pieca wymaga może z 50 linijek w pythonie. Nie
nazwałbym tego "sporo".

Ale to nie jest potrzebne. Arbiter nic nie wie o tym z kim się
komunikujesz. Ma tylko: baudrate, maksymalny timeout na odpowiedź i
maksymalny timeout między znakami. Te dwa/trzy parametry są
wystarczające. Skłaniam się nawet do tego, że sama wiedza "że to jest
modbus" jest zbędna. Dowolny, kompaktowy strumień bajtów, oczekujący
podobnej odpowiedzi, spełniajacy reguły timeoutu, się nada. Arbiter może
być jak switch - nic nie wie o danych.

do góry

On Wed, 5 Apr 2023 22:28:10 +0200, Piotrek wrote:
> On 05.04.2023 21:58, heby wrote:
>> Liczyłem na jakiś ... powiedzmy ... gotowiec z 3 dziurkami RS485,
>> obsługujący 2 masterów i 1 slave. Chyba nie jestem jedyny na świecie z
>> takim pomysłem ;)
>
> GPT twierdzi, że nie ma ;-)
>
> "[...]
>
> Unfortunately, there are no known open-source projects that implement a
> two-master, one-slave Modbus architecture. However, you can start with
> existing Modbus libraries (e.g., libmodbus, FreeModbus) and modify them
> according to the outlined approach to develop your custom solution."
>
> ale przyciśnięty do muru
>
> Are you sure there is no such open source project?
>
> zaczął programować w Python. LOL

Moze od razu poprosic o kod na wybrany uC ? :-)

> "I apologize if my previous response may have been unclear. While it is
> challenging to be aware of every single open-source project available,
> to the best of my knowledge (as of the knowledge cutoff in September
> 2021), there was no specific open-source project that implements a
> two-master, one-slave Modbus architecture.
>
> However, you may find open-source projects that implement Modbus
> gateways or proxies, which you could adapt to achieve the desired
> two-master, one-slave communication. One such project is modbus-tk, a
> Python library that allows you to create Modbus masters and slaves, and
> it includes a TCP to Serial gateway implementation.
>
> Project Repository: https://github.com/ljean/modbus-tk
>
> Here's a basic example of how you can use modbus-tk to create a Modbus
> TCP to Serial gateway:
>
> python
>
> import modbus_tk
> import modbus_tk.defines as cst
> from modbus_tk import modbus_tcp
> from modbus_tk import modbus_rtu
>
> def main():
> # Configure Modbus RTU master
> master_rtu = modbus_rtu.RtuMaster(
> modbus_tk.utils.create_serial_handler(port="/dev/tty
S0")
> )
> master_rtu.set_timeout(5.0)
> master_rtu.set_verbose(True)
>
> # Configure Modbus TCP server
> server_tcp = modbus_tcp.TcpServer(address="0.0.0.0", port=502)
> server_tcp.start()
>
> # Main loop to process Modbus TCP requests and forward them to
> Modbus RTU
> while True:
> try:
> request = server_tcp.get_request(blocking=True)
> if request is not None:
> response = master_rtu.execute(
> request.slave_id,
> request.function_code,
> request.starting_address,
> request.quantity_of_x,
> request.output_value,
> )
> request.set_response(response)
>
> except modbus_tk.modbus.ModbusError as exc:
> print("Error processing request:", str(exc))
>
> if __name__ == "__main__":
> main()
>
> This example creates a Modbus TCP server that forwards incoming requests
> to a Modbus RTU master. You could extend this example to support two
> Modbus TCP masters and manage the communication with the single Modbus
> RTU slave.

I to jest przykład z powyzszego archiwum, czy GPT napisal sam ?

> Please note that this example uses Python, and you would need to adapt
> the code to your specific requirements, such as handling communication
> conflicts between the two masters."
>
> P.

J.

do góry

piątek, 7 kwietnia 2023 o 18:22:32 UTC+2 heby napisał(a):
> On 07/04/2023 18:00, Dawid Rutkowski wrote:
> >> Nie przesadzajmy. Switch ethernetowy jest uniwersalny, czy przerzuca
> >> dane z Hubbla, czy pornole, wszystko jedno.
> > Ale sam ethernet to za mało na zrobienie newsa na usenecie
> Bo tym zajmuje się zupełnie inna warstwa.

Jeśli jest, o co dalej pytałem.

> > A w ogóle da się zrobić modbus RTU na konwerterze RS485?
> Tak.

Tylko trzeba mieć bardzo dobre połączenia.
Inaczej nie będzie się opłacało rozbierać po śniadaniu ;>

> > Coś podejrzewam, że ten EW11 to coś wyżej jednak, np. konwerter modbus TCP<->
modbus RTU.
> Nie ma czegoś takiego jak "modbus TCP".

Jak nie ma jak jest - port 502 - i to nawet dwa.
Jeden bez CRC w ramce, "bo mają niższe warstwy", drugi z CRC, bo jednak niższe
warstwy mają tylko sumy kontrolne.
Chyba że nikt nie zaimplementował (ew. tylko do bramek, a może i to nie).
Może więc czas zacząć?
Choć to dziwne jest, jakieś 4 bajty z przodu: Transaction identifier i Protocol
identifier (ten zawsze 0) - nie wiem po co to może być potrzebne.

> Wysyłasz bajt do portu TCP i
> wypada on po stronie RS485. Wpada bajt po stronie RS485 i wypada on z
> portu TCP. Możesz taki konwerter "zrobić" na jednym poleceniu w Linuxie:
> socat. Przez wiele lat miałem tak właśnie zrobione.

Ja wolę nc.

> I to ze wszystkimi kosekwencjami tego kretynizmu braku opakowania. Jak
> na przykład łamanie ramek TCP powodujące konfuzję i timeouty.

O to właśnie pytałem "czy się da".
Widać "da się", pod warunkiem że nie musi dobrze działać.
Albo np. leci modbus ascii a nie modbus RTU.

> > Z bramką modbus TCP<->modbus RTU (sporo ustawiania)?
> Nikt tego nie używa na poważnie. bajt tcp<->bajt uart jest "przemysłowym
> standardem" ze wszystkimi konsekwencjami dziadostwa.

No to użyj.
Czy nikt nie zaimplementował?

> Jakoś kilka(naście?) lat temu była afera, że co więksi kretyni
> wystawiali te zabawki do internetu, a mowa była o automatyce w dużych
> obiektach przemysłowych.
> > Z abstrakcją pieca (sporo rzeźbienia po drugiej stronie)?
> Akurat abstrakcja pieca wymaga może z 50 linijek w pythonie. Nie
> nazwałbym tego "sporo".

Ale trzeba mieć pythona na tym urządzeniu, co robi abstrakcję pieca.
Jest na AVR?

Kiedyś dostałem do zabawy płytkę z renesas SuperH, z DRAM i złączem do kolorowego
wyświetlacza po równoległym RGB.
Nie wiem, ile zapłacił za to ten, od którego to dostałem, ale soft to był interpreter
TCL na eCos.
I podobno miało być tak, że będzie to umiał zaprogramować nawet tzw. grafik
komputerowy...

do góry

On 08/04/2023 16:07, Dawid Rutkowski wrote:
>> Nikt tego nie używa na poważnie. bajt tcp<->bajt uart jest "przemysłowym
>> standardem" ze wszystkimi konsekwencjami dziadostwa.
> No to użyj.
> Czy nikt nie zaimplementował?

Abitera nie widziałem. Gotowych urządzeń implementujących raw RTU jest
od groma.

Niektóre idą dalej w tym szlaleństwie i są wersje UDP zamiast TCP.

>> Akurat abstrakcja pieca wymaga może z 50 linijek w pythonie. Nie
>> nazwałbym tego "sporo".
> Ale trzeba mieć pythona na tym urządzeniu, co robi abstrakcję pieca.

Ta abstrakcja do niczego nie jest potrzebna w przypadku arbitera. Była
by uzyteczna, gdybym robił coś w rodzaju proxy. Ale nie wydaje mi się,
aby było to niezbędne. Arbiter jest ok, pod warunkiem, że przerwy w
komunikacji są statystycznie znacznie dłuższe niż transmisjie. U mnie
tak jest.

> Jest na AVR?

Python był jako wyznacznik minimum. Raczej narzęźbię to na C++.

> Kiedyś dostałem do zabawy płytkę z renesas SuperH, z DRAM i złączem do kolorowego
wyświetlacza po równoległym RGB.
> Nie wiem, ile zapłacił za to ten, od którego to dostałem, ale soft to był
interpreter TCL na eCos.
> I podobno miało być tak, że będzie to umiał zaprogramować nawet tzw. grafik
komputerowy...

Jestem raczej z daleka od "gotowców" o uproszczonej budowie. Skrajnym
przykładem jest LabView. Kolega w tym pracował zawodowo, robiąc bardzo
poważne rzeczy. Jego największym problemem refaktoringu nie było
programowanie, tylko jak przemieścić D'n'D kilka tysięcy elementów aby
dało się zmieścić pętlę i kilka drutów. Programowanie graficzne uważam
za znakomity żart, choc niewątpliwie wygląda świetnie na prezentacjach.

Innymi słowy, jesli to narzeźbię, to prawodpowodobnie na ESP8266 (ale on
ma niestety 1 i 1/2 uartu) albo ESP32. Tu nie ma wielkiego wyboru z
powodu komunikacji po wifi.

Swoją drogą: podobne urządzenie (do PV, ale tam są inne wymagania) od
kilku lat działa mi na teminalu Wyse Cx0 (normalny pecet wielkości 2
paczek papierosów) który kosztował mnie 20zł.

do góry

On 08/04/2023 16:39, heby wrote:
> Abitera

Arbitra.

do góry