ST 에서는 Function block 기반으로 프로그램을 작성하여 C++ 의 class 와 유사한 형태의 프로그램 개발이 가능합니다. 다른 분들의 말씀처럼 대용량의 프로그램을 개발할 때 매우 용이합니다. 또한, 하나의 Function block 을 잘 만들어 놓으면 코드 재사용에 매우 좋습니다. 저의 경우, Beckhoff 의 TwinCAT3 를 이용하여 프로그램을 개발하고 있습니다. 일정한 형식의 Function block 을 기반으로 프로그램을 개발하기에 프로그램 가독성이 매우 뛰어납니다. 프로그램에 대해 세부적인 분석도 쉽고, 그리고 시스템 전체를 파악하는데에도 그리 어렵지가 않습니다. 참고로, 개발된 전체 프로그램의 사이즈가 큼에도 불구하고 팀동료들과의 분업이 어렵지 않습니다. 래더의 장점도 크지만, 제대로 ST 를 활용하면 대규모 프로젝트에서는 래더보다 훨씬 강점이 있다고 말씀드릴 수 있습니다.
맞습니다. 장점이 충분히 크기에 계속 발전을 하고 있겠죠. 단 하나, 인터록을 확실히 구현해야 하는 점 때문에 주의가 필요한 단점이 있는것 같아요. 텍스트 기반 또, 변수기반 프로그램 방식이 워낙 편하기는 하죠. 특히 통신이나 데이터 다루는 부분은 래더에서는 지옥이죠 ㅎㅎ
깹닙 잘 보고 있습니다 ST언어를 포함한 PC 언어는 기본적으로 SET, RESET로 동작하는게 약간 애로 사항인데 M0 := M1 OR M0 AND NOT M2; 자기유지 회로 써봤는데 이런식으로는 잘 안써요? C언어는 잘 모르고 옛날 마스터K 니모닉 핸디로더로 넣던 느낌으로 써봤어요 PC하시는 분들은 이런식으로 안하는거 같아서요
캡닙 늘 좋은 영상올려 주셔서 감사히 잘 보고 있습니다. 이번 영상에서 ST는 SET/RESET 방식으로만 사용 될 수 있다는 설명이 조금 오해가 될 수 있을것 같다는 생각이 들어서 의견 남깁니다. SET/RESET 방식만 지원하는것이 아니라 SET/RESET 방식으로 프로그램을 해서 그런 결과가 된것이 아닐까요? Ladder 방식에서도 어떻게 짜느냐에 따라 SET/RESET를 사용할 수 도 있고 자기유지를 이용한 Coil 방식으로 구현할 수 있듯이.. 영상 예제의 경우 IF/ELSE방식으로 구현하면 SET/RESET 동작을 하게 되고 아래과 같이 Coil로도 표현할 수도 있습니다. M10 := M0 AND M1; MOTOR_CW := COMMAND_CW AND (NOT EMERGENCY); MOTOR_CCW := COMMAND_CCW AND (NOT EMERGENCY);
저는 개인적으로 ST는 프로그래밍 툴(PLC 기종)에 따라 프로그래밍 환경이 완전히 달라진다는 점이 제일 마음에 들지 않는 것 같습니다. Omron CX-Programmer에서 사용한 ST, Beckhoff TwinCAT3에서 사용한 ST의 경험이 너무나도 달라서 애를 먹었던 경험이 있습니다. ST를 사용하는 가장 큰 이유가 저는 '연산'과 '통신'에 있어서 데이터를 다루는데에 큰 장점을 가진다고 생각을 하거든요. Beckhoff 툴에서는 포인터와 대다수의 변수 타입 간 형 변환, 비트 변경, ST를 사용하는데에 도움되는 펑션 블록을 지원하는 반면, Omron 툴에서는 전혀 지원하지를 않습니다. 단순히 생각나는것만 나열해도 아래처럼 됩니다 ㅜㅜ Beckhoff / Omron 비트 변경: MyCoil.0 := TRUE; / MyCoil := MyCoil & 1; 비트 비교: IF MyCoil.0 THEN END_IF; / IF MyCoil & 1 THEN END_IF; 포인터: ADR(MyCoil) / 불가능 라이징 엣지(업 펄스), 폴링 엣지(다운 펄스) 감지: R_TRIG(MyCoil.0), F_TRIG(MyCoil.0) / 직접 비교 후 비트 상태 기록 후 다음 스캔 때 비트 상태 다시 확인...
북미 유럽쪽에서 ST언어가 꽤 쓰이더라구요 Reddit plc커뮤니티에 보면 미래 PLC언어는 유지보수가 쉬운 LD 복잡한 기능을 가진 장비에 유리한 ST 두개가 양분할거같다고 대부분 생각하드라구요 참고로 미쓰비시에서 ST짜는건 별로인거 같네요 백호프가 ST언어 쓰기 좋게 해놨더라구요ㅎㅎ
제가 다루는 라인에 SCL 90%정도(10%는 CFC.. )로 짜놓은 공정이 있어서.... 지나가다 한말씀 올립니다. 지멘스 SCL 에서는 MotorCW := not emergency and command_CW; MotorCCW := not Emergency and command_CCW; 이렇게 하면 됩니다. 다른 ST언어도 표준을 따르고 있으면 될것같은데.. 미쓰비시는 안되나요?
스크립트 쓰면 고수인줄 아는데 그건 아닌듯... 현장에서 스크립트 쓰고 반복 쓰고 해서 함축해놓은 래더때문에 분석 포기하고 다밀고 다시 짠게 한두번이 아님... PLC는 이벤트드리븐방식 입출력이 아니기 때문에 원래원리른 이해하고 이런 방식보단 정통적인 래더에서 장점을 끌어 올려서 방식에 맞게 프로그램 하는게 맞다고 봄.. 현직 고수라니까 질문 하나... 비젼장비 만 13년차 현직 잡붑니다... 반도체든 LCD든 검사 장비 경험이 있다면 답변 부탁 드립니다... 왜 현장에서 장비 않되면 1차적으로 기구 탓하고 2차적으로 비젼 탓함???? 그러다 제어는 쏙 빠지고 비젼엔지니어만 남아서 피똥싸다 마무리되는게 10년 넘게 계속 이어지는데 이거 설명 좀..
고생 하셨습니다....^^
감사합니다. 😁😁
ST 에서는 Function block 기반으로 프로그램을 작성하여 C++ 의 class 와 유사한 형태의 프로그램 개발이 가능합니다. 다른 분들의 말씀처럼 대용량의 프로그램을 개발할 때 매우 용이합니다. 또한, 하나의 Function block 을 잘 만들어 놓으면 코드 재사용에 매우 좋습니다. 저의 경우, Beckhoff 의 TwinCAT3 를 이용하여 프로그램을 개발하고 있습니다. 일정한 형식의 Function block 을 기반으로 프로그램을 개발하기에 프로그램 가독성이 매우 뛰어납니다. 프로그램에 대해 세부적인 분석도 쉽고, 그리고 시스템 전체를 파악하는데에도 그리 어렵지가 않습니다. 참고로, 개발된 전체 프로그램의 사이즈가 큼에도 불구하고 팀동료들과의 분업이 어렵지 않습니다.
래더의 장점도 크지만, 제대로 ST 를 활용하면 대규모 프로젝트에서는 래더보다 훨씬 강점이 있다고 말씀드릴 수 있습니다.
맞습니다. 장점이 충분히 크기에 계속 발전을 하고 있겠죠. 단 하나, 인터록을 확실히 구현해야 하는 점 때문에 주의가 필요한 단점이 있는것 같아요.
텍스트 기반 또, 변수기반 프로그램 방식이 워낙 편하기는 하죠. 특히 통신이나 데이터 다루는 부분은 래더에서는 지옥이죠 ㅎㅎ
화이팅!!
어!? 화이팅 ~^^😁
깹닙 잘 보고 있습니다
ST언어를 포함한 PC 언어는
기본적으로 SET, RESET로 동작하는게
약간 애로 사항인데
M0 := M1 OR M0 AND NOT M2;
자기유지 회로 써봤는데
이런식으로는 잘 안써요?
C언어는 잘 모르고
옛날 마스터K 니모닉 핸디로더로
넣던 느낌으로 써봤어요
PC하시는 분들은 이런식으로 안하는거 같아서요
@@서정환-z4u if 와 else 를 사용하면 되죠 ㅎ
깹님 영상 잘보고있습니다 혹시 rcpu에대해서는 교육 안하시나요?
RCPU로 만들어 볼께요.
시간이 조금 걸리긴 해요. 🤣
캡닙 늘 좋은 영상올려 주셔서 감사히 잘 보고 있습니다.
이번 영상에서 ST는 SET/RESET 방식으로만 사용 될 수 있다는 설명이 조금 오해가 될 수 있을것 같다는 생각이 들어서 의견 남깁니다.
SET/RESET 방식만 지원하는것이 아니라 SET/RESET 방식으로 프로그램을 해서 그런 결과가 된것이 아닐까요?
Ladder 방식에서도 어떻게 짜느냐에 따라 SET/RESET를 사용할 수 도 있고 자기유지를 이용한 Coil 방식으로 구현할 수 있듯이..
영상 예제의 경우 IF/ELSE방식으로 구현하면 SET/RESET 동작을 하게 되고 아래과 같이 Coil로도 표현할 수도 있습니다.
M10 := M0 AND M1;
MOTOR_CW := COMMAND_CW AND (NOT EMERGENCY);
MOTOR_CCW := COMMAND_CCW AND (NOT EMERGENCY);
좋은글 감사합니다.
말씀해주신것과 같은 처리를 할 수 있는정도의 Level이면 너무 유용하게 사용할 수 있는 프로그래밍 방법이죠.
조만간 ST로 좀 더 진지한 내용을 만들어 보려고 하는데 말씀 해 주신 내용 소중히 참고할께요. 감사합니다. 😀👍
저는 개인적으로 ST는 프로그래밍 툴(PLC 기종)에 따라 프로그래밍 환경이 완전히 달라진다는 점이 제일 마음에 들지 않는 것 같습니다.
Omron CX-Programmer에서 사용한 ST, Beckhoff TwinCAT3에서 사용한 ST의 경험이 너무나도 달라서 애를 먹었던 경험이 있습니다.
ST를 사용하는 가장 큰 이유가 저는 '연산'과 '통신'에 있어서 데이터를 다루는데에 큰 장점을 가진다고 생각을 하거든요.
Beckhoff 툴에서는 포인터와 대다수의 변수 타입 간 형 변환, 비트 변경, ST를 사용하는데에 도움되는 펑션 블록을 지원하는 반면, Omron 툴에서는 전혀 지원하지를 않습니다.
단순히 생각나는것만 나열해도 아래처럼 됩니다 ㅜㅜ
Beckhoff / Omron
비트 변경: MyCoil.0 := TRUE; / MyCoil := MyCoil & 1;
비트 비교: IF MyCoil.0 THEN END_IF; / IF MyCoil & 1 THEN END_IF;
포인터: ADR(MyCoil) / 불가능
라이징 엣지(업 펄스), 폴링 엣지(다운 펄스) 감지: R_TRIG(MyCoil.0), F_TRIG(MyCoil.0) / 직접 비교 후 비트 상태 기록 후 다음 스캔 때 비트 상태 다시 확인...
하드웨어 통신프로토콜 프로그램 케이블 어느것 하나 표준화된게 없죠. 풀어야 할 과제가 많은 곳이에요 ㅎ
@@TWINIEX 그런 의미에서 래더의 호환성은... 대단합니다 ㅋㅋㅋ
뭐지???난 다보이는데??? 포인터 빼고 그냥 스크립트 장난질..ㅋㅋ 베이직이랑 파스칼 문법 조합..ㅋ
재미있는거 뭔지 아십니까??? 현실에서는 st쓰는데 드물어요... 아니 안써요... 내가 아는 30년차 초보님도 안써요... s사
H사 엘사 등등 산전 수전 다격은 분임..
@@사영민-h7e 어느 부분이던 장단점이 있기 나름입니다. 래더는 코드가 길어지면 가독성이 엄청나게 난해해집니다. 코멘트나 주석이 없다면 그 코드를 분석하는 업무만으로도 며칠이 지나갈 정도로 복잡합니다.
@@_jisuyu ST코드가 더 난해함...요새는 옛날처럼 텍스트방식 래더가 아니라서 래더코드가 현장 트러블 대처하기 더 빠름...
깹님 말씀대로 c언어나 비슷한 언어들 만져보시면 plc 만질때 정말 도움이 많이됩니다.
저같은경우는 c랑 파이썬 취미로 만지곤했는데 plc 만지거나 지멘스 stl st언어 등등 만지거나 남이짠 프로그램 해석할떄 도움많이되었고
문자형 언어의 경우 조건문짜는게 한눈에들어오고 편해서 가끔은 LAD 형식보다 st 언어가 너무 쓰고싶긴한데
내가아닌 다른사람이 보전하고 체크해야하는 프로그램이라 그럴수없는게 아쉽습니다.
하지만 텍스트기반 프로그래밍 언어를 공부하는게 정말 큰 도움이 되요.
또 활용도 많이 되구요. 😁
북미 유럽쪽에서 ST언어가 꽤 쓰이더라구요
Reddit plc커뮤니티에 보면 미래 PLC언어는
유지보수가 쉬운 LD
복잡한 기능을 가진 장비에 유리한 ST
두개가 양분할거같다고 대부분 생각하드라구요
참고로 미쓰비시에서 ST짜는건 별로인거 같네요 백호프가 ST언어 쓰기 좋게 해놨더라구요ㅎㅎ
한번 길이가 변화하는 문자열을 잘라야 하는 프로그램을 만든적이있는데 (100~300문자)
st였으면 for if case 문자열 잘라내기 저장하면 될 일을
래더로 몇십번 돌려서 스캔타임 작살난적이....
영상에 나오는 코드를 보면 그냥 코드를 잘 못 짠 버그 같은데, 왜 ST의 단점이라고 설명하는 이해가 안되네요. 래더도 emergency 조건 잘못 잡으면 똑같은 상황이잖아요.
그렇죠. 래더도 마찬가지죠.
제가 다루는 라인에 SCL 90%정도(10%는 CFC.. )로 짜놓은 공정이 있어서.... 지나가다 한말씀 올립니다.
지멘스 SCL 에서는
MotorCW := not emergency and command_CW;
MotorCCW := not Emergency and command_CCW;
이렇게 하면 됩니다. 다른 ST언어도 표준을 따르고 있으면 될것같은데.. 미쓰비시는 안되나요?
웍스2로 복사붙여넣기하면 똑같이 작동합니다
스크립트 쓰면 고수인줄 아는데 그건 아닌듯... 현장에서 스크립트 쓰고 반복 쓰고 해서 함축해놓은 래더때문에 분석 포기하고 다밀고 다시 짠게 한두번이 아님... PLC는 이벤트드리븐방식 입출력이 아니기 때문에 원래원리른 이해하고 이런 방식보단 정통적인 래더에서 장점을 끌어 올려서 방식에 맞게 프로그램 하는게 맞다고 봄.. 현직 고수라니까 질문 하나... 비젼장비 만 13년차 현직 잡붑니다... 반도체든 LCD든 검사 장비 경험이 있다면 답변 부탁 드립니다...
왜 현장에서 장비 않되면 1차적으로 기구 탓하고 2차적으로 비젼 탓함????
그러다 제어는 쏙 빠지고 비젼엔지니어만 남아서 피똥싸다 마무리되는게 10년 넘게 계속 이어지는데 이거 설명 좀..
검사장비 해본 경험이 있긴 합니다만,
혹시 나쁜 제어 엔지니어들을 만난게 아닐까요? 원래 이게 기구 제어 비젼 소프트웨어까지 4파전의 양상은 많이 띄긴 합니다만, 탓하고 도망가는건.. PM도 문제가 있겠고, 제어도 문제가 있겠고 하겠는데요 ㅎㅎ;;
참 어이가 업소. 본인 나병신이오 하고 있는것 같소. 보아하니 비전프로그래머가 아니고 프로그래머가 프로그램 짜주면 현장에서 비전 셋업만 하시는 양반 같은데 본인 실력부터 기르시오