RTV forum PL | NewsGroups PL

Multiplekser/sniffer/arbiter modbus

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Multiplekser/sniffer/arbiter modbus

Goto page Previous  1, 2, 3  Next

heby
Guest

Thu Apr 06, 2023 2:33 pm   



On 06/04/2023 13:45, Dawid Rutkowski wrote:
Quote:
Wysyła na pałę, to zwykły Elfin EW11 ale ze zmienionym przez producenta
firmware (zgłasza się inna nazwa accesspointa i zahaślone wifi niż w
stockowym, kupowanym w sklepie). Bez względu na to czy da się coś z tym
zrobić - urządzenie nie bazujace na świadomości mastera będzie
bezpieczniejsze.
Hmm, skoro wyszło w końcu, że ten X to żaden "sterownik" (zapewne pieca),
tylko jakaś taka dokładka umożliwiająca ustawianie i odczyt parametrów przez wifi,

Z tego sterownika korzysta inna osoba "w internecie" w celu analizy
stanu, przez aplikację dostarczoną przez producenta.

Mam wyjscie:
1) Tylko apliakcja producenta (i brak automatyzacji)
2) Tylko moje HomeAssistant (i brak wglądu przez inną osobę)

A ja chcę obie.

Quote:
Ciekawostka że to w oryginale konwerter "wifi<-RS485", a ma AP, a nie klienta wifi

To działa tak:
1) Elfi resetujesz. Zamienia się w AP o konkretnej nazwie i ustalonym haśle.
2) Apliakcja wie jak się z nim połaczyć.
3) Aplikacja rekonfiguruje go do *twojej* sieci wifi
4) Apliacja (prawdopodobnie) wrzuca mu nakaz połaczenia się ze swoimi
serwerami/chmurą
5) Masz dostęp przez chmurę

Tam jest w środku bardzo duzop opcji do konfiguracji, dostęp przez panel
www, emulacja tcp->rs485, udp->rs485, jakieś vpny, autonomiczne
czytanie. Masa tego. Mam stockowy, gdzie mogę sobie pogrzebać po
konfiguracji i jest przytłaczająco bogata.

Ale w tym dostarczonym nie mogę. Zarówno AP jak i sama komunikacja po
konfiguracji jest szyfrowana, a jak patrzysz jakie ma otwarte porty po
podłaczeniu się do mojego wifi - to nie ma. Jest wyłacznie inicjującym
połaczenie z własną chmurą.

Pewnie częsciowo mógłbym zdekompilować aplikację w poszukiwaniu hasła
wifi, ale samo zdekompilowanie w celu znalezienia rejestrów mnie już
dobiło - takiej sieczki nie piszą nawet hindusi. Najwyczajniej mi się
nie chce, ponadto wątpliwe jest czy dzięki temu uzyskałbym cokolwiek.

Quote:
Zakładam więc, że jak odepniesz ten X to Y nadal będzie działał, tylko bez zdalnego
ustawiania i odczytu temperatury, bo Y - piec - ma wbudowany sterownik.

Ma. To tylko "sterownik chmurowy". Ma poza tym, normalny, fizyczny panel
kontrolny gdzie wszystko co chcę da się ustawić.

Quote:
Skoro komunikacja po modbus rozczajona, to możesz albo zmienić soft w tym EW11,
albo podłączyć ESP + konwerter RS485 - i będzie wifi.

Tak, ale stracę zewnątrznego obserwatora. Podczas awarii okazało się, że
ten "zewnątrzny obserwator", a konkretnie firma instalująca w/w
urządzenie, obserwujac parametry pracy, rozczaił w czym problem.

Nie chce mu dawać dostępu do mojego HomeAssistanta, ponadto on nie da
wiary że poprawnie je obliczam/wyświetlam.

Quote:
Czy jednak jest jakaś inna zasadzka?

Nie ma zasadzki. Zwykłe hobbystyczne wyzwanie, którego nie da się
obronić biznesowo. Coś jak kupowanię wędki za 1kzł kiedy w sklepie dorsz
mrożony za grosze.

Dawid Rutkowski
Guest

Thu Apr 06, 2023 2:47 pm   



czwartek, 6 kwietnia 2023 o 14:34:02 UTC+2 heby napisał(a):

Quote:
Nie ma zasadzki. Zwykłe hobbystyczne wyzwanie, którego nie da się
obronić biznesowo. Coś jak kupowanię wędki za 1kzł kiedy w sklepie dorsz
mrożony za grosze.

Nie no, zasadzką jest to, że ten obecny X jest potrzebny, a przynajmniej przydatny.
Zaś Y zapewne drugiego portu modbus nie ma.

No to dla podtrzymania rozmowy zadam jeszcze jedno pytanie,
które pewnie już przemyślałeś - czy nie wystarczy ci odczyt parametrów,
które i tak monitoruje ten X?
Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,
odchodzi problem nadawania multi-master.
Choć pewnie nie starcza, może za rzadko pyta, może nie o wszystko, o co byś chciał.
Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.

heby
Guest

Thu Apr 06, 2023 3:47 pm   



On 06/04/2023 14:47, Dawid Rutkowski wrote:
Quote:
No to dla podtrzymania rozmowy zadam jeszcze jedno pytanie,
które pewnie już przemyślałeś - czy nie wystarczy ci odczyt parametrów,
które i tak monitoruje ten X?

Nie ;)

Brakuje około 1/3 rejestrów w których znajduje sie bardzo ważny dla mnie
parametr.

Quote:
Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,
odchodzi problem nadawania multi-master.

Mam tak zrobione teraz. Podpięty jestem pod modbusa i sniffuję wlasnym
kawałkiem kodu ramki zwrotne.

Quote:
Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.

To też. Kontrola jest drugim waznym elementem. Obecnie mam możliwośc
przez applkę producenta, ale ja chcę to zautomatyzować z HA.

Dawid Rutkowski
Guest

Thu Apr 06, 2023 4:09 pm   



czwartek, 6 kwietnia 2023 o 15:47:26 UTC+2 heby napisał(a):
Quote:
On 06/04/2023 14:47, Dawid Rutkowski wrote:
No to dla podtrzymania rozmowy zadam jeszcze jedno pytanie,
które pewnie już przemyślałeś - czy nie wystarczy ci odczyt parametrów,
które i tak monitoruje ten X?
Nie ;)

Brakuje około 1/3 rejestrów w których znajduje sie bardzo ważny dla mnie
parametr.
Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,
odchodzi problem nadawania multi-master.
Mam tak zrobione teraz. Podpięty jestem pod modbusa i sniffuję wlasnym
kawałkiem kodu ramki zwrotne.
Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.
To też. Kontrola jest drugim waznym elementem. Obecnie mam możliwośc
przez applkę producenta, ale ja chcę to zautomatyzować z HA.

Tak sądziłem.
Jedno, co mi przyszło na myśl, to inna organizacja tego "arbitra"..
Zamiast karuzeli z przekazywaniem ramek - która i tak się może skończyć padem
komunikacji przy awarii arbitra - może zrobić coś w rodzaju mirrora,
czyli urządzenie z trzema niezależnymi RS485 - ew. jeden z nich "wirtualny".
Jeden RS485 do komunikacji z piecem, drugi RS485 do komunikacji z EW11,
a trzeci dla siebie.

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".
Czyli jak idzie odczyt z EW11 to od razu mirror od razu odpowiada kopią ze swojej pamięci,
tak sam jak idzie odczyt od "siebie" - a do pieca w tym czasie lecą zupełnie inne komendy
odczytu w kółeczku odświeżania.

No jedynie jak będzie zapis to trzeba przerwać kółeczko odświeżania i ten zapis zrobić.

heby
Guest

Thu Apr 06, 2023 4:19 pm   



On 06/04/2023 16:09, Dawid Rutkowski wrote:
Quote:
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.

Dawid Rutkowski
Guest

Thu Apr 06, 2023 4:36 pm   



czwartek, 6 kwietnia 2023 o 16:19:36 UTC+2 heby napisał(a):
Quote:
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 Wink 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...

heby
Guest

Thu Apr 06, 2023 4:53 pm   



On 06/04/2023 16:36, Dawid Rutkowski wrote:
Quote:
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.

Dawid Rutkowski
Guest

Thu Apr 06, 2023 5:24 pm   



czwartek, 6 kwietnia 2023 o 16:54:04 UTC+2 heby napisał(a):
Quote:
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ł?

heby
Guest

Thu Apr 06, 2023 6:49 pm   



On 06/04/2023 17:24, Dawid Rutkowski wrote:
Quote:
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.

Quote:
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 ;)

Quote:
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

Quote:
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.

Quote:
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.

Dawid Rutkowski
Guest

Fri Apr 07, 2023 6:00 pm   



czwartek, 6 kwietnia 2023 o 18:49:09 UTC+2 heby napisał(a):
Quote:
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.

Quote:
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 Wink

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)?

heby
Guest

Fri Apr 07, 2023 6:22 pm   



On 07/04/2023 18:00, Dawid Rutkowski wrote:
Quote:
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.

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

Tak.

Quote:
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.

Quote:
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]
[...]

Quote:
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.

Quote:
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.

Quote:
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.

J.F
Guest

Sat Apr 08, 2023 9:40 am   



On Wed, 5 Apr 2023 22:28:10 +0200, Piotrek wrote:
Quote:
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 ? :-)

Quote:
"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/ttyS0")
)
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 ?

Quote:
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.

Dawid Rutkowski
Guest

Sat Apr 08, 2023 4:07 pm   



piątek, 7 kwietnia 2023 o 18:22:32 UTC+2 heby napisał(a):
Quote:
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.

Quote:
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 ;>

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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ł?

Quote:
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...

heby
Guest

Sat Apr 08, 2023 4:39 pm   



On 08/04/2023 16:07, Dawid Rutkowski wrote:
Quote:
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.

Quote:
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.

Quote:
Jest na AVR?

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

Quote:
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ł.

heby
Guest

Sat Apr 08, 2023 4:40 pm   



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

Arbitra.

Goto page Previous  1, 2, 3  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Multiplekser/sniffer/arbiter modbus

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map