Multiplekser/sniffer/arbiter modbus

A ja masz zamiar generować tą "wtrącaną" ramkę? Czy zawsze taka sama, triggerowana guziczkiem? A odpowiedź potrzebujesz? W sumie nie wiem czy w modbus jest jakkolwiek zestandaryzowany multi-master...

To mało istotne. Po prostu coś wrzuci jakieś zapytanie w środek bałaganu.

Tak.

Nie ma, muszę go zrobić na kolanie.

A rzeczywisie musisz? Nie możesz sobie zrobić "man in the middle" na przykład używając tego:

Piotrek

Dokładnie to chcę sobie zrobić. Z tą róznicą, że nie pasywny sniffer, ale aktywny arbiter, co sprowadza się do trochę większej algroytmiki buforowania. Ale to tylko kwestia programistyczna, do ogarnięcia.

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

Tak, mogę zrobić sam, modbus jest prosty jak budowa cepa od strony firmware. Tu chodzi o pytanie, czy całośc (hardware+firmware) nie została już raz zrobiona przez kogoś, na przykład od IoT, strasznie lubię dowiedywac się pod koniec projektu, że ktoś już go zrobił lepiej, a ja straciłem czas na wynajdywanie kwadratowego koła.

Osadzone we FreeRTOS - zasadniczo samo się pisze ;-)

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

"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

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:

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.

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.

GPT twierdzi, że to, jak jest najszybsza furmanka na świecie, zależy od pojemności silnika. Nie dodał, czy jelit.

A kto by tam się przykładał do roboty za darmo? ;-)

Ale wracając do naszych baranów ... będąc ciekawym czego można oczekiwać od GPT, odświeżyłem sobie swój projekt sprzed lat.

Let's go back to the freemodbus library.

I need a client that waits for incoming write coil commands and performs a specific action depending on the coil number.

Could you give me a code sample to implement such requirements.

" To create a Modbus RTU Slave (client) using the FreeModbus library, which waits for incoming Write Coil commands and takes specific actions based on the coil number, you can follow the example below:

#include <stdio.h>

#include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "semphr.h" #include "mb.h" #include "mbport.h"

#define MB_USART_PORT_NUM (1) // Change this to the correct USART port number #define MB_SLAVE_ADDRESS (1) // Change this to the correct slave address #define MB_COIL_START_ADDRESS (0) // Starting address of the coil #define MB_COIL_COUNT (10) // Number of coils

static UCHAR ucCoilBuf[MB_COIL_COUNT / 8 + 1]; // Coil buffer

eMBErrorCode eMBRegCoilsCB(UCHAR *pucRegBuffer, USHORT usAddress, USHORT usNCoils, eMBRegisterMode eMode) { eMBErrorCode eStatus = MB_ENOERR; int iNCoils = (int)usNCoils; USHORT usCoilStart = usAddress - MB_COIL_START_ADDRESS;

if ((usCoilStart + usNCoils) <= MB_COIL_COUNT) { if (eMode == MB_REG_WRITE) { while (iNCoils > 0) { USHORT usByteOffset = usCoilStart / 8; UCHAR ucBitOffset = 1 << (usCoilStart % 8); UCHAR ucByte = pucRegBuffer[usByteOffset];

if (ucByte & ucBitOffset) { ucCoilBuf[usByteOffset] |= ucBitOffset; } else { ucCoilBuf[usByteOffset] &= ~ucBitOffset; }

// Implement specific actions depending on the coil number switch (usCoilStart) { case 0: // Perform action for coil 0 break;

case 1: // Perform action for coil 1 break;

// Add more cases for other coils as needed

default: break; }

iNCoils--; usCoilStart++; } } else { eStatus = MB_ENOREG; } } else { eStatus = MB_ENOREG; }

return eStatus; }

void ModbusSlaveTask(void *pvParameters) { eMBErrorCode eStatus;

// Initialize Modbus stack eStatus = eMBInit(MB_RTU, MB_SLAVE_ADDRESS, MB_USART_PORT_NUM,

// Enable Modbus stack eStatus = eMBEnable(); if (eStatus != MB_ENOERR) { printf("Failed to enable Modbus stack.\n"); vTaskDelete(NULL); }

while (1) { // Poll the Modbus stack eMBPoll();

// Add any necessary application logic here } }

int main(void) { // Register the coil callback function eMBRegisterCB(MB_FUNC_WRITE_SINGLE_COIL, eMBRegCoilsCB); eMBRegisterCB(MB_FUNC_WRITE_MULTIPLE_COILS, eMBRegCoilsCB);

// Create Modbus Slave Task xTaskCreate(ModbusSlaveTask, "ModbusSlaveTask", configMINIMAL_STACK_SIZE * 2, NULL, tskIDLE_PRIORITY + 1, NULL);

// Start the FreeRTOS scheduler vTaskStartScheduler();

for (;;) { }

return 0; }

Ciekawe, ciekawe ...

P.

O tyle istotne - szczególnie w kontekście ew. gotowca - że musi skądś i przez coś brać to dodatkowe zapytanie i analogicznie dawać odpowiedź.

Hmm, już modbus zapomniałem nieco, ale czy tam da się odróżnić ramkę master->slave i slave->master po jej budowie? Czy jednak master spodziewa się widzieć tylko ramki slave->master? Choć w sumie slave musi umieć rozróżnić te typy... No ale chodzi o master, bo rozważamy klejony multi-master. Jak umie rozróżnić to jeszcze pytanie, czy sprawdza zajętość magistrali czy wysyła na pałę w interwałach. Inaczej pozostaje tylko man-in-the middle i wnoszone opóźnienia, które mogą uniemożliwić realizację.

To może być np. wbudowane w urządzenie TCP->serial, albo osobny port RS485. Ten mój "master2" jes wirtualny, fizyczny, jakibądź.

Da się, pamiętaj że to urządzenie "rozcina" przewód master<->slave. Urządznie wie, po której stronie przyszła ramka więc wszystko jest jasne.

Pierwszy znak, który nadchodzi po stronie master1 natychmiast przekierowuje master2 do bufora. Kiedy komunikacja na master1 zostanie zakończona, master2 zostanie wysłany z bufora o ile coś w buforze jest. I symetrycznie w drugą stronę.

Więc dziaął tu zasada "kto pierwszy, to do urządzenia, kto w trakcie, to do bufora".

Sprawdziłem, sterownik jest bardzo tolerancyjny na opóźnienie a urządzenie odpowiada prawie natychmiast.

Jakiś tam być musi, choćby guzik czy wyświetlacz (zależy czy chcesz wywołać akcję czy pokazać odczytany parametr). Bardziej chodzi o to, że integracja "gotowca" z jakimś UI przez ciebie wymarzonym może być równie pracochłonna jak zrobienie całości od początku.

To było rozważanie nie na sytuację "rozcięcia" tylko na próbę zrobienia multi-master na jednej magistrali.

Przy "rozcięciu" jak najbardziej - wtedy masz 2 magistrale, a nawet 3 (tak jak i milicjantów). To sprawdzanie zajętości przez obecny master - twoje urządzenie X - jest potrzebne na multi-masterze na jednej magistrali.

A jak częsta jest obecna komunikacja X<->Y? Jest jakoś regularna? "Man-in-the-middle" wymaga 2 (a nawet 3) RS-485, i uC - a oprócz tego pewnie jeszcze komputer (chyba że dodana funkcjonalność ma być tak prymitywna, że do UI wystarczy sam uC). Multi-master na jednej magistrali dałby radę po prostu z komputerem.

Docelowo to ma emulować TCP->MODBUS. Łącznośc po wifi. Tak że "master2" to wirtualny port podpięty pod stos IP. Urządzenie będzie miało wobec tego dwie dziury RS485: slave i master1 oraz jadną wirtualną master2, na TCP.

A czytać z tego bedzie jakiś HomeAssistant. To bez znaczenia.

Rzędu 2 sek. Masa miejsca na wciśnięcie własnej.

Tak.

Ale jest trudniejszy, bo wymaga sniffingu i odrobiny modlitwy jeśli jednak pojawi się ramka urządzenia, które wysłało ją dla beki wcześniej niż przewidziałem.

Interesuje mnie arbiter "rozcinający" połaczenie, jako podstawowa forma tego urządzenia. To rozwiązuje sporo problemów elegancko, kosztem zwiększenia czasu odpowiedzi w momencie "konfliktu".

czwartek, 6 kwietnia 2023 o 11:23:24 UTC+2 heby napisał(a):

Stąd moje rozważania, czy urządzenie X ma taką funkcjonalność, że: a) sprawdza czy magistrala jest wolna przed rozpoczęciem wysyłania i jednocześnie b) słucha wysyłanych przez siebie pakietów, by sprawdzić, czy nic się w czasie nadawania nie wcięło i nie pokaszaniło komunikatu czy też może c) po prostu wysyła na pałę.

Oraz groźby całkowitego padu komunikacji między X a Y w przypadku padu arbitra. Oczywiście komputer włączony jako drugi master w multi-master na jednej magistrali też może komunikację pokaszanić, ale tylko wtedy, gdy zacznie wysyłać bełkot albo padnie w czasie, gdy TXE jest załączone (no na to można dać attiny żeby pilnował max. czasu jednego nadawania).

Ogólne pytanie, co się stanie, jak X przestanie widzieć się z Y - i vice versa? Zapewne nie jest to reaktor jądrowy, ale kłopoty mogą się pojawić.

Wątpię.

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.

Tak, ale to nie steruje granatnikiem. Jak padnie to najwyżej nie będę miał mało ważnego sterowania i monitoringu.

Będę marzł ;) No chyba, że zejdę piętro niżej.

To nic specjalnie skomplikowanego, przemysłowego czy cokolwiek z tej ligi. Ale tak sobie pomyślałem, że taki "arbiter" z buforowaniem to rzecz, któa mogła by być przydatna nie tylko mi. Masa urządzeń na rynku ma RS485 i wyjątkowo gówniany sterownik, którego najczęsciej nie da się zespolić z własnym IoT, tylko trzeba używać dziadowskich mechanizmów producenta.

czwartek, 6 kwietnia 2023 o 12:12:49 UTC+2 heby napisał(a):

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, to możesz to sobie w całości zastąpić, zamiast kombinować z multi-masterem czy man-in-the-middle (oczywiście dla innych przypadków może to nadal mieć sens).

Ciekawostka że to w oryginale konwerter "wifi<-RS485", a ma AP, a nie klienta wifi (chyba że może oba - no cóż, ja mam konweter wifi<->RS232C, który ma tylko klienta)...

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. Skoro komunikacja po modbus rozczajona, to możesz albo zmienić soft w tym EW11, albo podłączyć ESP + konwerter RS485 - i będzie wifi. Odpada problem multi-master - a reszta oprogramowania do integracji z własnym HA dokładnie taka sama.

Czy jednak jest jakaś inna zasadzka?

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

Mam wyjscie:

A ja chcę obie.

To działa tak:

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.

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

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.

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.

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

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.

Nie ;)

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

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

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ć.

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.