Parallellkommunikation med gammal CNC-svarv

[georg]

Jag mätte alla signaler och fick bitarna till ~5ms vilket borde ge typ 200 tecken/s. Sen kan man ju testa o se om det går att skicka in data snabbare, men det känns som att det kvittar om det tar 1 eller 10 sekunder att läsa in ett program bara det funkar... Programmen blir ju oftast väldigt korta.

Tillägg: Det går teoretiskt att skicka data snabbare än vad remsläsaren klarar av om styrsystemet klarar av att läsa av snabbare, vilket jag inte vet. Styrsystemet skickar ju bara en forward-signal när den fått en strobe-signal, så styrsystemet reglerar egentligen inte datahastigheten.

[georg]

Så här blev kortet med komponenter.



Och efter en hel del testande och lite förbättringar av koden funkar det att skicka G-kod till svarven

När vi väl hade förstått hur dessa typer av kommunikationer är uppbyggd svängde vi ihop en krets som möjliggör att skicka program från svarven till dator, vilket känns skönt om man vill småändra lite när man tankat in program.

Nu är det bara ta tag i nåt annat kul projekt

[säter]

Det var snabba ryck. Kul att det fungerar.
Vilken överföringshastighet kör du på serieporten?

Nu är det bara ta tag i nåt annat kul projekt
Hade du möjlighet att hjälpa mig med en liknande grej?

[georg]

Hastigheten mellan datorn och microprocessorn är 9600 baud, men den går att ha högre om man vill. Mellan microprocessorn och styrsystemet är det samma hastighet som remsläsaren gav, typ 2000 baud om jag inte minns fel. Det går säkert också att höja, men jag känner inget behov, och 2000 baud vet jag att styrsystemet klarar.

Vad har du för remsläsare? Vet du hur den fungerar? Det jag stött på är två typer. En som läser av strobe-hålet på remsan med fototransistor och en som har stegmotor och sköter stroben "själv", den läser alltså inte av strobe-hålet.

[säter]

Jag hoppas det är ok att jag tar min problematik i din tråd.

Grejen är att jag har ett program för PC som är utvecklat för att kopplas till NC-system. Dvs system helt utan minne.
PC-programet skickar ut ett block i taget som visas på bildskärmen.
Detta PC-program är jag väldigt nöjd med, och jag vill använda detta även till CNC.
Detta borde vara fullt möjligt genom att köra CNC-systemet i TapeMode. Då blir CNC-systemet att uppföra sig som ett NC-system.

För närvarande sitter en BTR-box monterad på styrsystemet.
Detta är ej användbart ihop med mitt PC-program, då BTR-boxen har ett buffertminne på 1Mb, som "käkar upp" hela CNC-programet, istället för att skicka blockvis till styrsystemet.

Jag antar att ditt kort inte buffrar någonting, utan fungerar som en ren serieport?
Är det möjligt att mäta remsläsarsignalerna på den befintliga BTR-boxen, utan att att ha den ansluten till CNC-systemet?

Jag ber att få återkomma med info om remsläsaren + lite bilder. Om det nu är ok att fortsätta i den här tråden?

Skriv in i profilen var du bor, det kan vara bra att veta.

[willmans]

Hej säter, jag var med och utvecklade btr:en som georg visar.
Data från PCn fylls i en buffer och när den börjar bli full stoppas dataflödet från PCn. (Det finns speciella signaler i com-porten för det). Data skickas från buffern varje gång styrsytemet skickar en forward-puls (näsa rad på remsan).
Dataflödet från PCn startas igen när buffern börjar bli tom. PCn måste skicka data i högre hastighet än styrsytemet läser av.
Det fungerar med drip-feed. Hastigheten som man kan köra begränsas av styrsytemet. Jag tror att man kan komma upp i ca 800 tecken per sekund med det styrsystem BTRen gjordes till, det motsvarar 8000 baud.

[säter]

Hej Willmans.
Bra och tydligt inlägg.

Jag har en hembyggd BTR sitter på en annan maskin än den aktuella. Den är till funktionen lik er BTR. Dock buffrar den inte full buffer, utan exakt ett block.
För mig är det en fördel om den inte buffrade något överhuvudtaget, med det kanske är omöjligt?

Anledningen till detta är att man ibland vill kunna "hoppa" i NC-programet under körning. (kom ihåg att jag har den möjligheten via mitt PC-program) Då ställer det till problem om BTR'en redan buffrat en massa block.
På min andra maskin måste jag reset'a BTR'en för att "bli av med" buffert blocket. Dom problemen har jag inte på dom maskiner som har hårdvaruinterface-parallellöverföring. Nog om mina önskemål.

Signalerna till och från styrsystemet har jag inte koll på.
Min tanke var att om man kan lista ut tape forward signalen, kanske ni kunde köra min befintliga BTR i "bänk" för kolla hur signalerna ser ut.(nu pratar jag inte om den hemgjorda BTR'en utan den som sitter på aktuell maskin)

Själva pin-out'en på kontakterna är ju inget problem, värre är att lista ut vilken pinne som gör vad.
Återkommer med data och bilder.

Märkligt, har du ändrat inlägget medan jag skrev svaret?

[blueint]

Tips är att implememtera någon form av checksumma på RS232 länken.
Verkstad kan vara en rätt störningsrik miljö.

[willmans]

Då ställer det till problem om BTR'en redan buffrat en massa block.
På min andra maskin måste jag reset'a BTR'en för att "bli av med" buffert blocket.

Det är så vår BTR fungerar, det som har lagts in i buffern kan man inte ändra, utan man måste resetta för att tömma buffern, och då måste man börja om från början.
Det är svårt att matcha baud in med den ut eftersom man ska skicka ut data långsammare än man får in, därför har man en buffer. Buffern behövs också eftersom PC'n inte slutar skicka direkt när man ber den, den skall tömma sin sändningsbuffer först. Eller så tar man först emot hela programmet som din andra BTR gör.

Det kan finnas en möjlighet dock, det beror på hur länge styrsytemet väntar på data efter att den har skickat forward-signalen. Den kanske väntar i all evighet, men jag tror det kan finnas någon time-out efter en viss tid.
Om den nu väntar för evigt (tills den får data) så skulle man kunna använda en BTR som direkt skickar ut det den får utan någon buffer i själva BTR lådan och ha ett program på PCn ungefär som det du har nu. Då skickar BTR'n en signal till PCn varje gång en ny forward signal kommit och programmet på PCn får agera därefter. Då kan du gå in och pausa och ändra som du vill.

Tillägg: Man kanske kan skicka null tecken under tiden man inte skickar data för att inte få time-out. Det är null tecken i början på remsorna men jag vet inte hur styrsystemet reagerar på det mitt i ett program, sådant måste man testa.

Min tanke var att om man kan lista ut tape forward signalen, kanske ni kunde köra min befintliga BTR i "bänk" för kolla hur signalerna ser ut.(nu pratar jag inte om den hemgjorda BTR'en utan den som sitter på aktuell maskin)

Det skulle man kunna göra ifall man vill göra en egen BTR som skickar direkt ut utan buffring. Väntar tills du lägger upp lite bilder och mer info om remsläsare och styrsystem.

Märkligt, har du ändrat inlägget medan jag skrev svaret?

Jag tyckte det jag skrev blev rörigt, visste inte att andra nattugglor var inne på forumet

[säter]

Tips är att implememtera någon form av checksumma på RS232 länken.

Vi hade det i tanke när gjorde den förra hemgjorda BTR'en, med det visade sig obehövligt.
Det finns paritetskontroll i styrsystemet, det får räcka.

Buffern behövs också eftersom PC'n inte slutar skicka direkt när man ber den, den skall tömma sin sändningsbuffer först.

Mitt PC-program har ingen sändningsbuffer, utan skickar "hårt" på serieporten.(eller parallellporten)

Då skickar BTR'n en signal till PCn varje gång en ny forward signal kommit och programmet på PCn får agera därefter. Då kan du gå in och pausa och ändra som du vill.

Kul, du verkar ha fattat vad jag är ute efter.
Går det att fixa på detta vis vore det kanon.

Din idé att skicka tecknet null borde också fungera.
Då tror jag det är bättre att skicka tecknet delete(alla ettor), då styrsystemen brukar vara gjorda att ignorera detta tecken.

Ang. bänktest av min befintliga BTR:
Jag ska på bilsemester inom kort. Det kanske hade varit läge att låna boxen medan jag är borta och maskinen står. Jag blir borta ett par veckor.

En fråga av annan art:
Vad tror du ett sådant här projekt kan kosta? Vi kan ta det i PM om du inte vill skriva det i tråden.

[willmans]

Det programmet som du har till NC-systemet, kopplas det till remsläsarkontakten via parallellporten? Isåfall skulle det vara bättre att modifiera det programmet lite så att det fungerar med din CNC och göra ett adapterkort från parallellporten till kontakten som sitter på remsläsaren.
Man måste då veta pin-out och hur signalerna ser ut till CNC'n från remsläsaren. Man behöver mäta på maskinen med logikanalysator. För att mäta på befintlig BTR måste man veta vilka signaler som CNC'n skickar till den.
Om man gör en BTR som fungerar utan buffer så som jag skrev så kommer man att behöva skriva ett helt nytt program till datorn, och där har jag faktiskt inte så mycket erfarenhet.

[säter]

#Det programmet som du har till NC-systemet, kopplas det till remsläsarkontakten via parallellporten?#

Jag har både och.
Två maskiner är anslutna via printerporten och ett optokopplarkort som adapter.
Signaltider och liknade styrs då från PC-programet.
Det här har en nackdel, signaltiderna blir beroende av PCn's hastighet. Det innebär att det är problem att uppdatera till en annan dator som är snabbare. Kör nu med 286-10MHz. Ingen buffring alls.

På en tredje maskin sitter den hemgjorda BTR (liknande er) som jag nämnt tidigare i tråden.
Till den används en variant av PC-programet som skickar till serieporten. Här styrs signaltider helt av BTR-boxen.
Boxen buffrar ett block.

På den nu aktuella maskinen sitter en fabrikstillverkad BTR-box med 1Mb buffert.
Det gör att jag inte kan använda PC-programet, utan laddar upp hela programet i BTR-boxen. Sedan får man köra "i blindo".
Programen är för stora för att få plats i CNC-systemets minne, så jag kör i tape mode.
Min tanke är att använda PC-programet med serieöverföring för detta projekt.

#Om man gör en BTR som fungerar utan buffer så som jag skrev så kommer man att behöva skriva ett helt nytt program till datorn#

Ok. Jag hade hoppats det skulle fungera med det jag har för serieöverföring.

Här kommer lite bilder.

Styrsystemet Fanuc-7M.


Två knappar för reset och urtankning av minne. Dessa är anslutna till BTR-boxen.


Remsläsaren.


Läshuvudet. Det ser ut att vara en helt optisk läsare. Jag kan inte se något sprockethjul. Däremot ett glas för sprockethålen.


BTR-box. Dom tre kablarna är serial, puncher, reader samt fyra trådar som går till tryckknapparna.
Kontaktdonen ser ut som vanliga datamaskinskontakter.


Flatkabel mellan BTR och styrsystem.

[säter]

Jaha, vad blir nästa steg nu då?

Jag funderar om det går att testa att "svälta" överföringen till styrsystemet utan att det blir någon form av timeout?
Jag använder nu Procomm+ för att tanka upp till befintlig BTR.

Jag är inte så hemma på alla funktioner i detta program, undrar om det går att skicka, tecken för tecken, med en tangenttryckning?

Då skulle man kunna vänta någon minut mellan tecknen, och se om maskinen hoppar igång när man läst in sista tecknet i blocket, CR/LF.

[willmans]

blir väl svårt när btr'n har en buffer. men nästa steg blir väl att köra tape-in och sedan skicka in ett block i taget och se vad som händer. tror att jag vet hur signalerna till den remsläsaren ser ut. det är en signal som går hög och hålls hög sålänge motorn ska rulla fram remsan. den har ingen stegmotor. kan styrsystemet köra dripfeed?

[säter]

#kan styrsystemet köra dripfeed?#
Om det du menar med dripfeed är samma som att köra i tapemode, ja.
Körning i tapemode:
1. Först fyller jag upp BTR-boxen med hela NCprogramet via Procomm.
2. Väljer tapemode på maskinen och trycker cyclestart.
3. Nu suger CNCsystemet i sig ett block från BTR-boxen, och utför dessa rörelser. (CNCsystemet buffrar även ett block, med det ovidkommande här.) Observera att ingenting laddas in i CNCsystemets programminne i tapemode.
4. När rörelsen är klar ropar maskinen på ett nytt block från BTR-boxen osv.

#det är en signal som går hög och hålls hög sålänge motorn ska rulla fram remsan.#
Det tror jag med. Så fungerar mina andra läsare utan stegmotor. (antar att vi menar tape-in signalen?)
Förövrigt har jag hittat en bild i manualen på tiderna för sprocket resp. datasignalerna.

#blir väl svårt när btr'n har en buffer.#
Tja, blir det det?
Så länge tape-in signalen ligger hög borde CNCsystemet suga i sig allt från BTR-boxen, ända tills det stöter på CR/LF?
Observera att detta var enbart tänkt som ett test, för att kolla om systemet har någon inbyggd timeout.
Ej avsett att användas för riktig körning.