plc problem

Började som ett enkelt jobb. Skulle bara åka ut byta ut ett modem. Innan hade dom haft ett modem dom ringde upp till, nu montera ett 3g modem med fast ip nr. Modemet anslutet via en seriell port till en plc. Förut hade dom ett program som hette filetran som dom ringde upp och kunde ladda hem data från plc. Nu sprack ju den grejen. Behöver tips på hur ja kan ta hem dessa filer med vilket program. Har även åkt ut på plats för att via dator koppla in mig på seriel porten och försökt tanka hem. Försökt med pytty connectar men inge mer.Någon som.har någon smart idee?

Som Rikard skriver om du inte anger typ av PLC och på vilket sätt (ev modul etc) den var ansluten är det omöjligt att svara.

Insys. Förra var ett westermo. Kan kolla upp mer specifikt. Tror dom även använde hmi tools för att ladda ner. Jag har ingen mer info just ju men får kolla upp det.

Hej Christoffer!
Använder RS232C eller RS485?
Har du fått communicationen att fungera?

Hej använder rs232c
Ja står att jag lyckas connecta men sedan kommer jag ingen vart

Hej Christofer!
Om du öppnat en rs232-c port i datorn, så klarar windows inte att byta den. Datorn måste startas om.
Det finns mycket inställningar i rs232-c och min erfarenhet är, att yngre grabbar inte klarar av det. Rs 485 är enklare.

RS-232C hittar man knappast på någon dator som är vid liv idag. C-versionen av standarden infördes 1969 och ersattes av version D 1986. Idag är det revision F som gäller.

Ur operativsystemets (t ex Windows) synpunkt spelar det ingen roll om det är RS-232, RS-422 eller RS-485 , signaleringen går ju ändå via samma UART som programmeras på samma sätt. Skillnaderna finns bara i det fysiska snittet mellan UART och kontakt.

Min erfarenhet är att de flesta problem som folk råkar ut för med RS-232 är att man tar fel på signalriktningar. RS-232-enheter kan vara antingen en s k DTE (Data Terminal Equipment, det kan vara t ex en dator, skrivare eller någon slags mätinstrument) eller DCE (Data Communication Equipment, t ex ett modem). Om man ska koppla ihop en DTE och en DCE som båda följer standarden och använder samma typ av kontakt (t ex 25-polig DSUB) så är det enkelt, då behövs bara en rak kabel där varje ledare är ansluten till samma pinnummer i båda ändar. Men om man t ex ska koppla ihop två DTE så måste signalledarna korsas parvis (RXD-TXD, RTS-CTS osv).
Enligt standarden ska DTE ha hankontakt och DCE honkontakt, men den regeln syndas det ofta mot på äldre utrustning. Speciellt brukar tyska och japanska tillverkare gärna göra tvärt om. Japansk utrustning är också irriterande genom att den brukar ha M3-gänga på låsskruvarna för DSUB-kontakterna istället för den standardiserade UNC-gängan.
Någon enstaka gång kan man råka ut för snitt som kallas för RS-232 men som i själva verket är ett asynkronsnitt med TTL-nivåer (0/5 V). I så fall måste man komplettera med en RS-232-drivare/nivåomvandlare för att få apparaten att fungera ihop med standardiserad RS-232-utrustning. Jag har råkat på detta på t ex gamla ABC-datorer och CNC-styrsystem från 80-talet.

På min förra arbetsplats brukade vi säga att det måste vara AMS som låg bakom RS-232-standarden, med tanke på hur många arbetstimmar som under årens lopp har gått åt för att få inkompatibla RS-232-snitt att fungera ihop.


För RS-422 och RS-485 finns inga standardiserade kontakttyper eller pinkonfigurationer, utan där MÅSTE man läsa på i dokumentation för precis den utrustning man ska använda. Det är också vanligt att apparattillverkare blandar ihop dessa två standarder med varandra och t ex skriver RS-485 i manualen fastän det i själva verket är ett RS-422-snitt. Om snittet bara består av en enda parledning så är det RS-485 , om det är flera par som har signalnamn som tyder på var sin signalriktning (t ex RXD-TXD) så är det RS-422.
Man måste hålla reda på vilken som är vilken av de båda ledarna i ett RS-422 eller RS-485 -par. Tyvärr förekommer det många olika sätt att ange den saken. Ibland kallas de + och - , ibland A och B, ibland Y och Z.

Man bör komma ihåg att RS-422 är en punkt-till-punktförbindelse med balanserade par, det krävs alltså två ledare för varje signal (till skillnad från RS-232 som är obalanserat och där det räcker med en gemensam jord samt en ledare per signal). Alla olika signaler som finns i ett RS-232-snitt KAN också förekomma i RS-422, även om det är sällsynt att de mer udda signalerna som är specifika för telefonmodem används där.
RS-422 ska normalt termineras i båda ändar, åtminstone vid högre överföringshastigheter och/eller lång kabel. Ofta är termineringsmotstånden inbyggda i ändutrustningarna. I en del fall där man kör med låg överföringshastighet och där det är mycket viktigt med låg strömförbrukning/värmeutveckling kan det hända att snittet används utan terminering. T ex batteridriven utrustning eller en RS-422-ansluten tempgivare där man vill ha minimal egen värmeutveckling.

På RS-485 kan man hänga på många enheter (från 8 till 256 beroende på hur hårt de belastar ledningen mm) parallellt på en enda parledning. Dock får som regel inga avgreningar, eller möjligen mycket korta avgreningar (på sin höjd ett par dm) förekomma. Vanligtvis ska RS-485 termineras med ett 120 ohm motstånd i vardera änden av ledningen. Det ska alltså finnas exakt två termineringsmotstånd på en RS-485-buss, och varken mer eller mindre. Om det är kritiskt att spara ström kan man terminera med motstånd + kondensator i serie, men det är komplicerat, komponentvärdena måste beräknas beroende på både överföringshastighet, kabellängd och kabeltyp. När man ställer in kommunikationsprogramvaror för RS-485 så måste man komma ihåg att RS-485 inte stödjer full duplex. En RS-485-enhet kan alltså inte sända och ta emot data samtidigt, och det måste finnas en styrsignal till interfacekretsen (t ex RTS) för att ange om den ska sända eller ta emot.
Det finns många seriebussar som är snarlika RS-485 men som innefattar någon slags överordnat protokoll, standardiserade kontakter mm. T ex snittet för tangentbord och mus på gamla Apple-datorer innan USB , CAN-bussen som används i bilindustrin, LON-bussen (Echelon) som man försökte få att slå igenom för smarta hem på 90-talet.

När det gäller överföringshastigheter så kan det vara bra att veta att RS-232-standarden inte kräver att utrustningen ska fungera med högre hastighet än 19200 bit/s. Men i praktiken, speciellt vid korta förbindelser, händer det att man använder den upp till 115200 bit/s och det fungerar ofta tillräckligt bra.
RS-422 och RS-485 kan köras på betydligt högre hastigheter, åtminstone med kabel av god kvalitet och i störningsfri miljö.

Hej Torbjörn!
Du missar att I IBM pc så vände dom på kontakten och satt en DCE på en DTE. Du missar också att IBM pc inte kan använda mjukvaru handskakning om pc:n egna drivrutiner används. I RS 422 i Digitalequpment datore typ PDP 11 och LSI 11/23 så användes mjukvaru handskakning. Du förkalarar ej skillnaden mellan RS232 och V24. Ett tips i Yasnac MX1 MX2 och MX3, parameter 6021 bit 4 och 5 ställer om mellan den standarden. Om du inte klarar av att svara på det här faller dina andra agument.

Hur det är med IBM:s ur-PC vågar jag inte uttala mig om, men alla senare "PC-datorer" (XT, 286 med kloner, alla senare) följer standarden när det gäller DTE/DCE osv.
PC-arkitekturen har dock vissa grundläggande dumheter när det gäller hur UART:arna är inkopplade till de interna bussarna, men det har inget alls med RS-232 att göra. Det kommer ju att fungera på samma sätt vad man än har för fysiskt medium på andra sidan av UARTen (RS-232, RS-422, IrDA, fiber, current loop osv). Och ur datorhistorisk synpunkt är det intressant att svenska konstruktörer som tog fram produkter med x86-processorer ungefär samtidigt som IBM höll på med sin ur-PC, lyckades undvika de misstagen. Ett par exempel är Compis-datorn, och Teli (senare Ericsson) RDS-enkodrar, som har suttit i många år på de flesta svenska FM-sändare.

Beträffande mjukvaruhandskakning så har den ingenting med RS-232-standarden eller drivrutiner att göra utan det är en sak som får ske på högre nivå, exempelvis genom XON/XOFF. Det är dock sällan detta fungerar bra, och det används ännu mer sällan. Möjligen kan det ha förekommit ibland i samband med terminaler, enkla skrivare som bara ska kunna hantera ASCII-tecken mm. Behöver man handskakning så löser man det hellre genom att använda RTS/CTS-signalerna. Men, som sagt det har ingenting alls med det fysiska snittet att göra utan det är egenheter på programvarunivå. Att överföra binärdata (t ex allmän filöverföring) på ett snitt med mjukvaruhandskakning är ofta krångligt och långsamt, man brukar använda protokoll som t ex Kermit, Xmodem eller Zmodem. Man slipper många problem om man drar fram signaler för hårdvaruhandskakning när man ändå håller på. En annan lösning är att säkerställa att utrustningen i båda ändar av förbindelsen har rejält med buffertminne och säkert kan ta hand om datat i den takt det kommer utan att behöva säga stopp.

ITU-T V.24 har ingenting med just RS-232 att göra och de standarderna kan inte jämföras med varandra.
V.24 är helt enkelt en lista över de signaler som kan förekomma i ett asynkront gränssnitt, man har satt "neutrala" beteckningar i form av nummer på de olika signalerna, samt en hänvisning till andra standarder som kan vara bra att ha i sammanhanget. Den finns att hämta fritt på www.itu.int/rec/T-REC-V.24-200002-I .
Förr i tiden (80-90-tal) användes V.24-benämningarna på signalerna inom bl a svenska Televerket och Ericsson, men i de flesta andra sammanhang används de amerikanska "bokstavsbenämningarna", som har fördelen att de är lättare att komma ihåg än V.24 -numren.

Det finns en ITU-T -standard som heter V.28 , den beskriver de elektriska egenskaperna hos ett snitt som i princip är identiskt med RS-232, även om det finns detaljskillnader bl a beroende på att standarderna inte har uppdaterats samtidigt. www.itu.int/rec/T-REC-V.28-199303-I

Andra ITU-T -standarder finns, som beskriver många andra datakommunikationssnitt. V.10 och V.11 tillsammans motsvarar t ex RS-422. V.31 och V.31bis beskriver olika varianter av current loop.

Sen finns det många saker i ett asynkronsnitt som inte regleras av någon av de här standarderna utan som antingen beskrivs i helt andra dokument eller har blivit "de facto" industristandard. T ex olika överföringshastigheter, hur det ska fungera med start- och stoppbitar och ev paritet, i vilken ordning bitarna ska sändas osv.
I julas råkade jag på ett intressant fall där det gällde att ta hand om dataströmmen mellan en värmepump och dess manöverpanel. Dels visade det sig att överföringshastigheten var 100 bit/s (alltså inte 110 som är en gammal industristandardhastighet), och dels låg datat så att säga i omvänd ordning. Det krävdes en del detektivarbete och ett terminalprogram som kunde presentera datat binärt innan det gick att reda ut hur sakerna hängde ihop.

I bilindustrin kan man också råka på märkliga överföringshastigheter. Det finns en standard som heter ISO 9141, som bl a specificerar 10,4 kbit/s, förmodligen är det ursprungligen Bosch som ligger bakom detta. Ford använder fyra gånger denna hastighet, alltså 41,6 kbit/s . Chrysler körde på 90-talet sin s k CCD-buss på 7812,5 bit/s , och GM använde i sitt diagnosprotokoll ALDL 160 bit/s på vissa modeller och 8192 bit/s på andra. Numera har väl de flesta gått över till CAN-bussar som ofta körs på 250 eller 500 kbit/s. Men det förekommer än idag 10,4 kbit/s på bl a s k LIN-buss, som används för en del underordnade ändamål.

För att lite återgå till TS problem. På bilden ser det ut att sitta en Beijer OP-panel och då ligger det kanske nära till att PLC i kapslingen där är en Mitsubishi. Var är andra änden på seriekabeln ansluten till panel eller PLC och isf till vilken port där? Och hur har du tänkt att ditt Insys modem/router ska funka i sammanhanget? Inte självklart att den direkt är översättbar till det tidigare uppringda Westermo, speciellt inte att du kommer ut via seriesnittet utan att konfigurera upp det hela.

Och är det en Mitsubishi kan du använda MCP protokoll för anslutning via egna applikationer, det du kallar connect är troligen inta annat än mot Insys-burken. Verkar underligt att du skickas ut på detta utan mer bakgrund, ofta kan det bara misslyckas då. Kom in med mer info om du vill ha hjälp.

Åter till datorhistoriken!

Oj nu fick jag lite läsa. stämmer bra att de sitter en Mitsubishi där
Den är kopplad från panelen till modemet.
Sitter från Mitsubishi till panelen. Från panelen till modemet.

Mycket skrivet här... Varför inte fokusera lite på problemet?
Som jag förstår det så har man ett "program" som tidigare via serieport ringde upp ett modem och kommunicerade med en plc.
Vad som förändrats är väl egentligen bara att man bytt ut modemen mot en IP länk (via 3G fast det kvittar ju).

Som jag ser det så är det väl egentligen själva "programmet" som är problemet? Om det inte går att konfigurera om det så att det går via en socket (nätverket) så kanske det finns en nyare version av det? Då är det ju bara attuppgradera och konfigurera det rätt.
Skulle det nu vara ett hemmapulat program, ja då har man ju förhoppningsvis källkoden kvar och kan göra ändringarna där.

Vore det så väl att allting ligger i någon form av Unixmiljö så kan man ju alltid skriva en programsnutt som öppnar en socket mot plc'n och kopplar den mot en virtuell tty, som man i sin tur anger som serieport i programmet. Funkar säkert att göra det i pc-miljö också, men jag känner mig mer hemma i Unix.

TS har ju inte direkt talat om vad det jobbas med för utrustning.
Nu vet vi att Mitsubishi PLC är kopplad till Insys-burken via loopthrough på OP-panelen med gamla seriekabeln.

Det jag ser som de steg han behöver göra är:

1. Sätt upp modemet/routern för Ethernet-Serial gateway med rätt parametrering både WAN och serieporten.
2. I andra änden installera tex Insys VCom för omlänkning av programmets COM via nätverk till ändutrustningen.
3. Kolla upp att pinconfig är rätt för D-sub vid modemet.

Värre är det inte och bara att utgå från dokumentation för de olika delarna nya/befintliga och utbytta. Insys är riktigt bra för många såna här och liknande fall.

Åter till datormuseet.

Torbjörn!
IBM monterade en DCE på första PC utan hårdisk. Borde varit en DTE. Dom har gjort lika dant så länge det fans RS232.
V24 är en europeisk verition av RS232-C. Skillnaden är att V24 använder pinne 6 och 20, istället för 4 och 5 vid hårdvaru handskakning.
Jag har program i min dator som mjukvaru handskakning fungerar lika bra som hårdvaru, det är ingen skillnad. Det programmet använder inte PC:ns drivrutin.
Det stämmer att VT52 och VT100 terminaler fungerade med mjukvaru handskakning och RS422.
Med en 286 dator och uppåt, så behövs inte någon handskakning vid kommunikation ut från maskin. En Fanuc 6 klarar inte mer än 1200 Baud.

Stefan Ericson skrev: ...
Med en 286 dator och uppåt, så behövs inte någon handskakning vid kommunikation ut från maskin. En Fanuc 6 klarar inte mer än 1200 Baud.

Vad tror du om Insys som TS använder Stefan?
Har du använt dem för att bygga multidrop för remsläsarsnitten på dina äldre maskiner, eller tex gamla Stelladatas liknande system för DNC?

Finns inget som heter OT här.

Tomas!
Jag har använt ASR33, current loop. ASR43 RS232-C.
Facit 4040 stans med Facit parralle snitt. Facit 4047 med RS 232.
Vanliga dator nätverk. Navman buss i båten, och nmea 183.
RS 485 i PLC:n.
Tape remsor, data kassetband, 8 tum diskett 5,1/4 diskett. Pluss senare USB minnen och minnes kort.
DNC är inte vad du kallar för DNC. Det används fel här i Sverige.
DNC betyder att man styr maskinen med en överordnad dator.
OT är för mig ett Fanuc styrsystem till en svarv.

Hålkort. Jag säger bara hålkort... :tokig:
[Som faktiskt fortfarande används inom industrin idag på lite äldre rörbockningsmaskiner.]

Stefan Ericson skrev: Torbjörn!
IBM monterade en DCE på första PC utan hårdisk. Borde varit en DTE. Dom har gjort lika dant så länge det fans RS232.

Menar du alltså att IBM skulle ha använt en honkontakt på datorn? Så är det inte, det är en 25-polig hane precis som det ska vara på en DTE. 25-polig DSUB hona användes i den tidiga PC-världen för parallellport och möjligen för SCSI. Dock bör man såklart notera att det på senare år blev vanligare med en 9-polig DSUB, som egentligen inte hör ihop med RS-232-standarden utan definieras av en standard som heter TIA-574. Även den 9-poliga kontakten är hane på DTE och hona på DCE.

Stefan Ericson skrev: V24 är en europeisk verition av RS232-C. Skillnaden är att V24 använder pinne 6 och 20, istället för 4 och 5 vid hårdvaru handskakning.

Nej.
Titta själv i V.24 -standarden som jag länkade till ovan, det står ingenting alls i den om vilken pinne i kontakten som ska användas till vad. Du kan koppla ett asynkront snitt på vilka pinnar du vill i t ex en DSUB-kontakt och ändå hävda att den uppfyller V.24 . Möjligen kan det stå någonting om pinnummer i ISO 2110 som V.24 hänvisar till, men det hör i så fall ändå inte till V.24 -standarden. Till saken hör också att RS-232 har två olika signalpar för hårdvaruhandskakning. Dels DTR/DSR som ligger på pinne 6 och 20 och som huvudsakligen används för att tala om att utrustningen är igång och redo för kommunikation, dels RTS/CTS som ligger på 4 och 5 och som används för att säga ifrån när ena ändens utrustning inte hinner ta emot mer data.

Man bör också notera att V.24-standarden inte innehåller någonting alls om signalnivåer mm. Även om den ofta används ihop med V.28 som ungefär motsvarar RS-232 så går det lika bra att tillämpa V.24 tillsammans med t ex V.10 , V.11, V.31 eller någon helt annan definition av de elektriska parametrarna.

Tirbjörn!
Du måste läsa stadard som Fan läser bibeln. Troligtvis gjorde inte jappsen det.
I Fanuc systemet finns en spännings matning. Den går inte att kortsluta mot gjord. Annars har man inte sönder något, oavsett hur man kopplar.
Jag föreslår att du läser på om hur en DB25 kontakt till DTE ser ut och letar rätt på en gamal pc och tittar efter. Tyvärr har jag kastat mina för länge sedan. Jag har mer än 10 år och flera datorer med en ansluten till usb.