W celu lepszego zrozumienia kodu programu oraz komunikacji z innymi technologami, zalecane jest stosowanie się do umownych zasad dobrego programowania.

Niestosowanie zasad dobrego programowania często doprowadza do problemów oraz nieścisłości w opracowywanej technologii co przekłada się na braki, opóźnienia oraz błędy a niekiedy doprowadzić może do kolizji i kosztownego serwisu maszyny CNC.

W ramach niniejszego kursu stosowanie zasad dobrego programowania jest wymagane.

Pliki i struktura katalogów:

• Pliki i struktura katalogów:
• Nazwy plików wskazują na ich zawartość np. poprawna nazwa: "Kontur_wyspy.spf" niepoprawna nazwa: "Pszczółkamaja.spf" lub "kontur12345.spf"
• Brak polskich znaków w nazwach np. poprawna nazwa: "Wiercenie_szyku_otworow.spf" niepoprawna nazwa: "Wiercenie_szyku_otworów.spf"
• Oddzielanie nazw wieloczłonowych poprzez znak podkreślenia "_" lub wielkiej litery np. poprawna nazwa: "Kontur_wyspy.spf" lub "KonturWyspy.spf" niepoprawna nazwa: "konturwysypy.spf" lub "Kontur wyspy .spf" lub co gorsza "KoNtUrWysPy.spf" (nie zaleca się stosować spacji w nazwach plików).
• Stosowanie zbyt długich nazw plików, nazwa nie powinna przekraczać 28 znaków włącznie z białymi znakami (spacje- niezalecane) np. poprawna nazwa: "Kontur_wyspy.spf" niepoprawna nazwa: "To_ten_kontur_ktory_ma_byc_pierszy_a_nie_jako_ten_drugi_bo_tak_musi_byc_a_w_sumie_to_glodny_jestem.spf"
• Odpowiednie tworzenie struktury plików dla danego przedmiotu. Nie jest to bezpośrednia zasada odwołująca się do samego nazewnictwa a bardziej do katalogowania i utrzymywania porządku w strukturze plików. Dobrym nawykiem jest tworzenie hierarchicznej struktury plików dla każdego przedmiotu tzn:

1. Nazwa_części_numer_części(w naszym kursie np. Nazwisko_nr_Indeksu_grupa)[Katalog]
   1. Wersja_części_1(jeśli część występuje w wielu wersjach, w ramach naszego kursu wykonujemy jedną wersję detalu)[Katalog]
      1. Nazwa_programu_glownego.mpf(w naszym kursie np. nr_Indeksu.mpf)[Plik]
      2. Nazwa_podprogramu_1.spf [Plik]
      3. Nazwa_podprogramu_2.spf [Plik]
      4. Nazwa_podpgramu_3.spf [Plik]
   2. Wersja_części_2(jeśli część występuje w wielu wersjach, w ramach naszego kursu wykonujemy jedną wersję detalu)[Katalog]
      1. Nazwa_programu_glownego.mpf(w naszym kursie np. nr_Indeksu.mpf)[Plik]
      2. Nazwa_podprogramu_1.spf [Plik]
      3. Nazwa_podprogramu_2.spf [Plik]
      4. Nazwa_podpgramu_3.spf [Plik]

• Dzięki takiemu rozwiązaniu bez problemu odnajdziesz interesujący Cię plik i szybko wprowadzisz zmiany.
• Kod programu:

  • Dobrą praktyką jest umieszczanie nagłówka w programie głównym (.mpf) zawierający informacje o autorze, wersji programu oraz jego przeznaczeniu. W przypadku powrotu do programu po 5 miesiącach łatwo jest odnaleźć się w nim i przypomnieć sobie czego on dotyczył. Odpowiednia nazwa pliku również może być tu pomocna.

  • Numeracja bloków linii kodu (N10...N20...) nie jest wymagana jednak jest to dobra praktyka. Większość sterowań pozwala włączyć automatyczną numerację kodu w dowolnym momencie, nie jest więc konieczne numerowanie kodu podczas jego przygotowywania.

  • Używanie wielkich liter w całym programie. Wszystkie polecenia powinny być zapisane z wielkich liter np. poprawnie: "G1 X100 Y50" niepoprawnie "m1 X100 y50".

  • Umieszczanie posuwu w pierwszej linii gdzie ten posuw będzie wykorzystywany np.:

    [...] N750 G1 X146 Y-16 F382 ;Poprawnie [...] [...] N540 T="Frez_walcowy_10" F382 ;Niepoprawnie N550 M6 D1 N560 S3820 M3 N570 G54 G90 G94 N580 G0 X152 Y-20 [...]

  • Usuwanie zbędnych nieużywanych fragmentów kodu. Często popełnianym błędem jest pozostawianie zakomentowanych (lub co gorsza nie zakomentowanych) fragmentów kodu który nie jest w żaden sposób wykorzystywany.

  • Pozostawianie w podprogramie parametrów technologicznych (F...S...) oraz/lub funkcji modalnych takich jak MCALL, OFFN itd. W takim przypadku, ponowne wykorzystanie podprogramu jest niemożliwe i może doprowadzić do uszkodzenia maszyny. Wszelkie parametry technologiczne powinny znajdować się w programie głównym, tuż przed wywołaniem podprogramu.

  • Zagnieżdżanie podprogramu poprzez lokalne etykiety "LABEL". Oczywiście jest to możliwe do wykonania, jednak bardziej czytelnym i przejrzystym sposobem jest utworzenie osobnego pliku w postaci podprogramu (.spf) i wywołanie go wielokrotnie z wykorzystaniem etykiet jeśli jest to konieczne. Taki podprogram w postaci osobnego pliku można wykorzystać w wielu miejscach.

  • Ilość komentarzy w kodzie nie powinna przekraczać ilości kodu. Komentowanie każdej linii kodu jest błędem który utrudnia a czasami wręcz uniemożliwia analizę programu i jego modyfikację.

  • Tworzenie grup kodu i odpowiednie ich nazywanie. Na sterowaniu Sinumerik grupy kodu pozwalają rozwijać i zwijać fragmenty kodu. Jest to niezwykle przydatne podczas analizy i modyfikacji programu na maszynie. W przypadku kodu którego długość wynosi np. 2000 linii kodu, istnieje możliwość szybkiego przemieszczenia się do interesującego nas fragmentu programu. Ponadto odpowiednia nazwa np. "Szyk 6 otworów M12" bezpośrednio wskazuje na to jakich cech dotyczy dany fragment programu. W przypadku innych sterowań popularne jest oznaczanie fragmentów kodu jako grupy poprzez dodanie odpowiedniej linii kodu w formie komentarza np.:;

    ------------- PLANOWANIE ------------------ N10 [....] ;-------------- PLANOWANIE -KONIEC ------------------- (W naszym przypadku zgodnie z wymaganiami projektu należy korzystać z grupowania dostępnego w Sinumeriku.)

Ostatnia modyfikacja: piątek, 12 maja 2023, 15:02