WYŁĄCZNIE pomysły na poprawę działania i funkcjnalność softu

Przyznam że nie mam żadnych doświadczeń z PLC. Zakładam że obowiązują elementarne reguły przeciętnego języka programowania więc w pytaniach będę się posługiwał "normalnymi" pojęciami języków programowania
No to jedziemy :
1. czy program PLC jest jednorazowo ładowany z PC do sterownika (FLASH) a potem wykonywany autonomicznie, czy
program PLC jest każdorazowo ładowany z PC do sterownika (RAM) a potem wykonywany autonomicznie, czy
program PLC jest wykonywany przez sterownik przy współpracy z oprogramowaniem na PC
dlaczego to ważne
dlatego, że zarządzanie krytycznymi sygnałami powinno mieć charakter jak najbardziej sprzętowy w przeciwnym razie może być sporo szkód
2. rozumiem że cykl rozkazowy trwa 1ms
3. jest instrukcja warunkowa ale brak informacji o instrukcjach skoków, czy ich jeszcze nie ma czy to błąd w opisie
4. w zasadzie powiązane z 3; czy możliwe będzie zapętlenie programu (skoki bezwarunkowe). A może zapętlenie jest robione automatycznie. Jeśli zapętlenia nie ma i program cały czas nie chodzi "w tle" to KIEDY KONKRETNIE jest wykonywany
5. rozumiem że konkretny program musi zmieścić całą logikę działania systemu na raz
6. czy wcześniej obsługa czujników położenia także była realizowana programowo w pętli 1kHz a nie sprzętowo (błędy pozycjonowania osi w punkcie 0,0,0)

Jak widać z powyższych pytań, nie jest dla mnie jasny tryb działania programu z komendami PLC i nie znalazłem an to odpowiedzi w manualu.
Jeśli to ma charakter konfiguratora logiki, to wówczas wystarczy pojedyncze wykonanie a późniejsza realizacja rozkazów jest (jak sądzę) szybka. Jeśli to ma charakter mikroprogramu, to przy 100 liniach kodu opóźnienie między poszczególnymi przebiegami będzie wynosiło aż 0,1s więc dłużej niż czas percepcji człowieka, co uniemożliwia wykorzystanie w trybie real time.

1. czy program PLC jest jednorazowo ładowany z PC do sterownika (FLASH)...

Program jest ładowany do RAM za każdym razem jak naciśniesz „Połącz”. Jest całkowicie autonomicznie wykonywany przez kontroler. Oczywiście współpraca z PC musi być choćby wtedy gdy zapalisz bit START.

2. rozumiem że cykl rozkazowy trwa 1ms

Nie wiem co masz na myśli pisząc „cykl rozkazowy”, ale cały program – jest powtarzany 1000 razy na sekundę o ile pamiętam program składający się ze 100 instrukcji trwa do 170 us – oczywiście działa w tle generatorów kroku i w żaden sposób ich nie zakłóca.

3. jest instrukcja warunkowa ale brak informacji o instrukcjach skoków, czy ich jeszcze nie ma czy to błąd w opisie

Są warunki IF ELSE ENDIF ale o jakie skoki chodzi ?. Co do pętli na pewno tego nie będzie – choćby z tego powodu, że można by zawiesić program pętlą bez końca..

A może zapętlenie jest robione automatycznie...

Tak! cały program to jedna wielka pętla wykonywana automatycznie 1000 razy na sek.

rozumiem że konkretny program musi zmieścić całą logikę działania systemu na raz

Tak.

czy wcześniej obsługa czujników położenia także była realizowana programowo w pętli 1kHz

Chodzi Ci o odczyt np. HOME i precyzję bazowania... (bo reszta wejść była zawsze 1Khz) Tu faktycznie się zmieniło. Do tej pory stan wejść HOME był odczytywany praktycznie przy każdym kroku a więc jeśli ktoś miał duży podział to „samplowanie” mogło być szybsze. Jednak zważywszy, że np. przy jeździe 300 mm/min w czasie 0,001s przejazd jest 0,005mm - czyli maksymalnie taki błąd (przy takiej prędkości) może być tym spowodowany nie ma chyba tragedii (x).

Na obrazku przykład IF-a w programie do obsługi impuslatora dla "F" (enkoder mechaniczny 24 imp/obr.)

Czy wszystko zostanie przeniesione do tego czyli na przykład sterowanie zmieniarką?
Czy będzie można tez poruszyć silnikmi z tego poziomu czy np zmienić ustawienia związane z kolejnością jazd referencyjnych?

Ok, rozumiem. Krótko mówiąc jest to struktura logiczna która pracuje z taktowaniem 1kHz.
O jakie skoki chodzi? Twoja odpowiedź czyni moje pytanie częściowo nietrafionym. Ale chodzi o skoki bezwarunkowe. One umożliwiają stworzenie nieskończonej pętli, ale są na to sposoby. Prostszy jest taki, że można pozwolić skakać tylko do przodu. Drugi jest taki, że np na wykonanie programu można ustawić maksymalny czas np 200us i zawsze przerywać egzekucję na wykonanie pozostałych procesów a w następnym cyklu milisekundowym kontynuować. Czyli kontrola procesów. To tak na marginesie. Przy przyjętej koncepcji można się ewentualnie obyć bez skoków.

Jeśli chodzi o bazowanie, to tragedii może i nie ma, ale to nie jest dobra koncepcja. Sensory położenia powinny być jednak bezbłędne, czyli z dokładnością do kroku. Zawsze.

cosimo pisze:

Przydałaby się opcja korekcji geometrii związanej z prostopadłością osi X i Y.
...
Może autor znajdzie gdzieś na końcu swojej listy miejsce na taką propozycję?

Szacuje to na dwadzieścia linijek programu więc jak nie zapomnę to zrobię.

Super, to pozwolę sobie przypomnieć za jakiś czas

Mam jeszcze jeden pomysł na usprawnienie. Chodzi o menu odczytu i wyboru typu pliku. Czy można prosić o wstawienie tam maski [*.*] dla wszystkich plików? nie zawsze pamiętam jaki typ pliku miałem w konkretnym katalogu.

O to to *.* jest bardzo potrzebne przy wyborze typu plików.

Proszę Proszę Proszę

*.* podpisuję się


Z głupotek, może to działa, a ja nie umiem:

- feed overwrite powinien działać też na JOG/strzałki - czasami chce człowiek coś liznąć, a tu 2,5m/m
- domyślnie powinno jeździć dopóki trzymamy strzałkę, a z "altem" na zadaną odległość - tak jak np. w linuxcnc.
Teraz jak ustawisz skok na np. 1cm i klikniesz omyłkowo strzałkę to masz pozamiatane

Z błagań to ja przy opcji obracania gcodu chętnie bym zobaczył po prostu okienko do wpisania kąta

Po pierwsze bardzo dziękuję za zamieszczenie w najnowszej wersji moich postulatów o korekcję przekoszenia i wyboru maski plików

Teraz kolejne propozycje:
1. Prezentacja w symulacji szacunkowego czasu obróbki.
2. Zaznaczanie wykonanej ścieżki narzędzia w przypadku uruchamiania symulacji (na podglądzie ścieżek)
3. Łatwe ukrywanie zaznaczonej ścieżki w PikoCAM, na przykład za pomocą spacji lub innej kombinacji klawiszy. Wiem że jest opcja wyłączania z obróbki (tu też by się przydał skrót klawiaturowy), ale funkcja ukrywania służyłaby tylko do chwilowego ogarnięcia bałaganu ścieżek i nie powodowałaby wyłączenia z obróbki.
Coś na wzór ukrywania w GIMPie, po naciśnięciu spacji oczko by się zamykało i ścieżka znikała :

Propozycja a może pytanie.

Już się z tym nie raz wcześniej "szarpałem", ale nigdy nie było czasu zagłębić się w temat i zapytać na forum.
Otóż chodzi o obrabianie materiału POWYŻEJ ZERA MATERIAŁU.
W parametrach ścieżki w camie mamy "materiał" i "głębokość", dyskutowane wcześniej czy nazwy te są czy nie są szczęśliwe. Nie ważne. Ważne że ani w głębokość ani tym bardziej w materiał nie da się wpisać wartości ze znakiem "-", dzięki czemu można by obrabiać materiał ponad tym nieszczęsnym zerem materiału.
Oczywiście - można edytować ręcznie plik nc i można teoretycznie zastosować podkładkę podczas pomiaru referencyjnego. Tylko po co? Podkładkę można zgubić, w ręcznej edycji pliku można się pomylić. Poza tym edycję nc trzeba robić od nowa po każdej modyfikacji w cam. Pikocam mógłby to załatwić bez problemu i bez wysiłku. Wystarczyłoby żeby "materiał" dało się wprowadzić ujemny, i po kłopocie!

Dlaczego to ważne? Dlatego, że w przypadku obróbki prefabrykatów, bardzo często zachodzi potrzeba bazowania się do fragmentu który nie jest tym najbardziej wystającym. Taki prosty przypadek i od razu kłopot.

A może ja czegoś nie wiem, może to się da zrobić "automatycznie"?

Dlaczego to ważne? Dlatego, że w przypadku obróbki prefabrykatów, bardzo często zachodzi potrzeba bazowania się do fragmentu który nie jest tym najbardziej wystającym. Taki prosty przypadek i od razu kłopot.

Przecież nie musisz zerować „Z” materiału w tym miejscu tylko przypisać rzeczywistą pozycję. Załóżmy, że łapiesz poziom dojeżdżając frezem do powierzchni tego punktu – nie zerujesz wtedy materiału w osi Z tylko wchodzisz w okienko „USTAW” i dla zetki wpisujesz rzeczywistą pozycję tego punktu np. -20.5