Multiplekser/sniffer/arbiter modbus

Wed Apr 05, 2023 11:26 am   

Cześć.

Sytuacja:

1) Jest urządzenie X
2) Jest podpięty do niego, przez RS486/modbus sterownik Y
3) Rejestry i komunikacja rozpracowane
4) chciałbym *nie* odpinać oryginalnego sterownika, ale czasami wysłać
własne polecenie, niejako "wtrącając" się do rozmowy.

Potrzebuję coś w rodzaju arbitera/multipleksera do modbus na rs485.

Wyobrażam sobie to tak, że arbier ma 2 porty dla rs485 i zapewnia prawie
normalną komunikację miedzy nimi (metodą store&forward). Sterowanikowi
wszystko jedno, czy dostanie ramkę odpowiedzi wprost z X czy będzie ona
wygenerowana identyczna przez moje urządzenie z bufora.

Raz na jakiś czas mogę zbuforować zapytanie Y i wysłać priorytetowo
moje, po czym wznowić komunikację z bufora jak gdby nic się nie stało. X
dostanie stwoją odpowiedź, tylko minimalnie później. Przypuszczalnie,
jeśli zmieszczę się w timeout w Y to nie powinno mieć problemu.
Ostatecznie mogę przyczaić się aż urządzenie zakończy komunikację i
natychmiast wysłać swoją ramkę. Można mieć rózne strategie.

Czyli problem softwareowy, store&forward i kolejka z priorytetem.

W zasadzie to jest łatwe do zrobienia na uC, ale zanim wyciągnę
lutownicę: widział ktoś może taki projekt albo gotowe urządzenie? Nie
chcę nic drogiego - w ramach hobby mogę sobie je zrobić sam, ale może
ktoś już takie popełnił. W sumie to uC z dwoma UARTami i z tysiąc lini kodu.

Wed Apr 05, 2023 8:26 pm   

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

Wed Apr 05, 2023 8:40 pm   

On 05/04/2023 20:26, Dawid Rutkowski wrote:

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


Tak.


Nie ma, muszę go zrobić na kolanie.

Wed Apr 05, 2023 9:31 pm   

On 05.04.2023 20:40, heby wrote:

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

https://github.com/cwalter-at/freemodbus

Przy czym mogę rekomendować wyłącznie slave - działa od ładnych kilku
lat bez przerwy. Z master się nie bawiłem.

Piotrek

Wed Apr 05, 2023 9:58 pm   

On 05/04/2023 21:31, Piotrek wrote:

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.

Wed Apr 05, 2023 10:28 pm   

On 05.04.2023 21:58, heby wrote:

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

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.

Wed Apr 05, 2023 10:44 pm   

On 05/04/2023 22:28, Piotrek wrote:

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

Wed Apr 05, 2023 11:02 pm   

On 05.04.2023 22:44, heby wrote:

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 % ;
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,
9600, MB_PAR_NONE);
if (eStatus != MB_ENOERR) {
printf("Modbus initialization failed.\n");
vTaskDelete(NULL);
}

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

Thu Apr 06, 2023 8:47 am   

środa, 5 kwietnia 2023 o 20:43:13 UTC+2 heby napisał(a):

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

Thu Apr 06, 2023 9:28 am   

On 06/04/2023 08:47, Dawid Rutkowski wrote:

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.

Thu Apr 06, 2023 11:17 am   

czwartek, 6 kwietnia 2023 o 09:28:29 UTC+2 heby napisał(a):

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.

Thu Apr 06, 2023 11:23 am   

On 06/04/2023 11:17, Dawid Rutkowski wrote:

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

Thu Apr 06, 2023 11:56 am   

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

Thu Apr 06, 2023 12:12 pm   

On 06/04/2023 11:56, Dawid Rutkowski wrote:

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.

Thu Apr 06, 2023 1:45 pm   

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?