Svenska ElektronikForumet

Hej. Har stött på en del problem som sätter käppar i hjulet.
Saken ligger till på detta vis. Jag sitter med ett cam-program som jag verkligen gillar. Problemet är att jag inte har en postprocessor till detta program för att skiva varken heidenhain ISO (*.I-filer)eller TNC 410 (*.H-filer) för min fräs. Fräsen är en lagun 1000-maskin med TNC 410CA.
Detta problemet trodde jag dock jag kommit runt då cam-programmet skiver G-code utefter ISO-standard utan felaktigheter. Så det jag då enkelt vill gör är att skriva mig egna *.I-filer med lite start och avslut och G-koden jag vill ha fräsen att jobba efter.
Men nu då till mitt problem. När jag skapar en fil (bajs.I) med innehållande G-kod som fräsen inte alls skall ha några problem att jobba efter. Alltså inga konstigheter då samma kod fungerar utmärkt om man knappar den direkt på frässkärmen och kör.
Ja hur som helst. Når jag då sedan vill ladda över min bajs.I med skriven kod utefter konstens alla regler så vägrar rentav fräsen att acceptera filen. Den hittar den och allt sådant. Men när jag skall föra över den så blir den korrupt typ. Eller så säger fräsen något i stil med "felaktig data" och avbryter överföringen. Så gör den även om jag försöker öppna filen direkt från extern enhet.
Blev hur som helt tokig till slut och gav mig fan på att jag skulle lösa detta. Så jag startade upp ett annat mindre omtyckt cam-program som däremot jag har en heidenhain-ISO -postprocessor till. Och då med detta program skapade filen bajs.I med bara någon skitkörning på. Å den filen har fräsen då inga klagomål på när den skall ladda in. Så jag tog då och öppnade den filen i vanliga textprogrammet "Anteckningar" och börjar små-ändra lite i G-koden i denna fil. Börjar först med att bara ändra några siffror på X och Y-axlarna sen spara, och de kunde jag göra utan att fräsens fil-läsning klagade. Därefter började jag ta bort en större mängd kodinater i G-koden. Då började fräsen klaga på "felaktig data" vid inladdning av fil. Provar då att öppna filen igen och klistra tillbaka den del av G-koden jag tidigare klippte ut och tagit bort. Men ändå fast en innehållet i filen är återställt till exakt likadant nu som då när den accepterade filen så fungerar det ändå inte. Så det hela måste ha med att jag på något vis "förstör" själva filen. ? Men hur? Jag tar ju bara spara efter jag klippt ut sparat och sen klistrat in exakt samma text och sparat igen. Va är de för något jag sabbar i filen?

Så som ni nog förstår så är målet för mig att rentav kunna skiva G-cod och skapa filer på datorn utanför mitt CAM-program då de ej har rätt postprocessor för detta. Och sen givetvis då kunna spara dessa filer utan att de blir helt trasiga/korrupta så de ej går att ladda över till fräsen sedan.

Måste vara fler än jag som velat gå tillväga på detta viset då man fått en ren G-kod över nätet av någon och behöver lägga denna i fil å skicka till fräs.
Så hoppas någon vet de magiska sättet för att skapa dessa filer rätt. Evigt tacksam är jag för all hjälp jag kan få i detta... Tack på förhand.

Kan det vara så att fräsen inte gillar windows radbrytningar som notepad petar in?
Prova att använda Notepad++ istället som håller sig till det format filen är i från början.

Jag går tillväga ungefär på liknande sätt som du beskriver, och det är inga större problem.
Dock kör jag inte Heidenhain, så jag har ingen erfarenhet av just det.

Filen verkar ju inte bli förstörd av att sparas ned, när du bara har tagit bort kod.
Därför är det långsökt att tro att texteditorn "anteckningar" skulle vara boven.

I och med att filen blir korrupt först när du lagt till kod, verkar det som att du skriver fel på något sätt.
Är du säker på att du skriver med stora bokstäver, Versaler.

Det vore bra om du kunde posta kod här, både fungerande och korrupt.

tänkbara fel. olika asciikod:

IBM 8 bitars extended ascii kod 8 bitars ger andra tecken där är alt + siffran 10 ger ◙
iso/ascii 7 bitars, där 10 LF Line feed

Line Feed LF: dumpar man min bildskärm på fräsen ser man N10 X34 Y55 F150 LF denna syns ju inte när du redigerar i edit mfl.
Som säter säger, lägg ut filerna så kan vi testa de i våra CAM program.

En historia men kort sagt, min Emco 120 kräver att jag inte spara i *.txt utan filen skall vara utan extension och
det fixar inte alla ny editorer. Då får jag fixa det i DOS om jag är i svarven. Så jag tror att en teckentabell som inte överensstämmer med vad du skall ha skapar problemet.

Vad kräver din program att du startar och slutar med?

Heidenhain kan inte köras med "vanlig" Iso-kod som används i Fanuc.
Det är inte bara programbörjan och slut som ska vara olika.
Även I+J vi cirkelbågar anges på olika vis.

Det är kanske därför den ger felmeddelande...

CAM-program då de ej har rätt postprocessor

Vad är det för CAM?

Kanske lite hjälp här:
http://faculty.etsu.edu/hemphill/entc37 ... h-chp3.htm

Oj. Mycket tacksam för all uppmärksamhet jag fått redan. Skall prova lite av era knep i morgon. Hoppas något fungerar. Dock det där med Notepad++ borde väll vara liknande som ultraedit och de har jag provat med. men provar med Notepad++ å ser i vart fall. ALla försök och idéer till lösning är bra... Tack å hoppas de kommer fler idéer..

Minns jag rätt så var har jag haft samma problem isamband med redigering i Wordpad - Notpad (win95).
Notpad och anteckningar har alltid funkat. Båda funkar ju rent fysiskt men min maskin gav error och då troligen för
jag inte hade rätt teckentabell inladdad. Se programmet längst ned!
ISO Criteria
RS-274-D or word address (G-code) programs must:

Begin with block containing only a percent sign, the program number, a G70 (or G71), and a carriage return (CR) (no sequence number).
The program number can be any number between 01 and 499; numbers 500 and above are reserved for faculty.

The program's floppy disk filename can be the same as the program number, but it could be any valid alphanumeric combination that follows the MS-DOS 8-3 filename.ext naming rules.
End with a block containing only N9999, a percent sign, the program number, and a G70 (or G71), and CR.

Utilize the ASCII (RS-358, even parity) tape code for paper tape input.

Utilize the block format:
N4.0 G2.0 XYZIJK3.4 F3.1 S4.0 T3.0 M2.0
EXCEPTION: Circular/arc path (see below).
Parameters associated with certain G-codes use various address words such H, DR, P, and R.
Spaces are ignored.
Positive values are assumed.
Leading and trailing zeros can be omitted (zero suppression) for XYZIJK data but not for other data.
Sequence numbers should be incremented by 10s. They must not be duplicated and must be in numerical order.
Example program structure.

%250 G70 (or G71)
N10 G99 T1 L-2. R0.25
N20 G17 G00 (or G01 or G02 or G03) G90 (or G91)
Nnn PROGRAM STATEMENTS
N450 M30 N9999 %250 G70 (must match 1st line)

mrfrenzy skrev:Kan det vara så att fräsen inte gillar windows radbrytningar som notepad petar in?
Prova att använda Notepad++ istället som håller sig till det format filen är i från början.

Det är ju också en trolig felkälla.
Menar du att "anteckningar" skulle använda andra tecken för radbrytning, men inte bry sig i att ändra de tidigare skrivna vid radbrytningarna?

Ja precis, det är bara nya radbrytningar som påverkas, den ändrar inte tidigare text i filen bara för att man öppnar den och sparar om.

Vill man se alla tecken i en fil så kan man ju ladda hem TotalCommander eller något liknande, fanns som Norton Commander på DOS-tiden. Sen bara klicka på F3 Visa, gärna i HEX-format, då syns alla tecken....

sniffer skrev:Oj. Mycket tacksam för all uppmärksamhet jag fått redan. Skall prova lite av era knep i morgon. Hoppas något fungerar. Dock det där med Notepad++ borde väll vara liknande som ultraedit och de har jag provat med. men provar med Notepad++ å ser i vart fall. ALla försök och idéer till lösning är bra... Tack å hoppas de kommer fler idéer..

Du kan väl se till att posta fungerande + icke fungerande kod, så vi har något att titta på.

Oj. Fick massa att stå i idag. Jag skall försöka titta mera på detta i morgon. Så skall jag även ge er en fungerande och ej fungerande fil.