GCode-File

Discussions around the CAM Add-On of QCAD.

Moderator: andrew

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

GCode-File

Post by Norbert » Thu May 23, 2019 9:05 am

Hello,

I have a bit of trouble with GCode Files. Nornmaly I use QCAD/CAM under Ubuntu Linux. If I generate a GCODE File with QCAD/CAM (latest Version) I can not use it with my ISEL (RemoteWIN)Software. There is a problem with the endmarkers of ervery Line. RemoteWIN expects "CR/LF" at the end of every line. Unfortunately this is usally not part of GCode files generated under linux. Therefore I tried to add the missing "CR" manually. I can add it, but the file still doesn't work.

If I use QCAD/CAM under windows, all files are o.k. and work properly. The files generated under windows look exactly the same like the files generated under linux, even if the missing "CR" is added manually.

Is there any possibility to have the linux version of QCAD/CAM to add "CR/LF" at the end of the lines?

Thanks

Norbert

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Thu May 23, 2019 10:58 am

Yes, you will need your own, custom post processor for this. I don't know what post processor you are currently using, so I'm assuming "G-Code (G41/G42) [mm]", that's G-Code with G41/G42 for radius compensation and output in Millimeter.

Create a file "postprocessors/MyGCode.js" in your QCAD/CAM folder with the following contents:

Code: Select all

include("GCodeBase.js");

function MyGCode(documentInterface, newDocumentInterface) {
    GCodeBase.call(this, documentInterface, newDocumentInterface);

    this.decimals = 4;
    this.unit = RS.Millimeter;
    
    // use G41/G42 instead of calculated offsets:
    this.outputOffsetPath = false;

    // this sets the line ending to CR/LF (0x0D/0x0A):
    this.lineEnding = "\r\n";
}

MyGCode.prototype = new GCodeBase();

MyGCode.displayName = "My G-Code (G41/G42) [mm]";
Then use configuration "My G-Code (G41/G42) [mm]".

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Thu May 23, 2019 11:52 am

Hello Andrew,

than you very much for the quick reply. Unfortunately the RemoteWIN does not understand G41/42. Therefore RemoteWIN stops with Error.

By the way, I have another question. Would it be possible to build a postprocessor that works completely with RemoteWIN? I have the complete list of ordercodes used available (attached).

Unfortunately RemoteWin does not accept any other orders than the listed ones. Due to ISELs comment they use codes following a DIN, but they don't state which DIN it is. Can you help me with that?

Thank you

Norbert
Attachments
g_and_m_codes_08_2009_ger.pdf
(101.93 KiB) Downloaded 58 times

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Thu May 23, 2019 12:43 pm

Try this:

File name: "postprocessors/RemoteWin.js"
Contents:

Code: Select all

include("GCodeBase.js");

function RemoteWin(documentInterface, newDocumentInterface) {
    GCodeBase.call(this, documentInterface, newDocumentInterface);

    this.decimals = 4;
    this.unit = RS.Millimeter;
    
    // don't use G41/G42:
    this.outputOffsetPath = true;

    // this sets the line ending to CR/LF (0x0D/0x0A):
    this.lineEnding = "\r\n";
}

RemoteWin.prototype = new GCodeBase();

RemoteWin.displayName = "RemoteWin [mm]";
This does not use G41/G42. If that does not work, please do let me know which post processor you've used before, that would be most helpful.

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Thu May 23, 2019 2:53 pm

thet doesen't work either. The same as the other selfmade file: The CAM-Config is accessible but not the path configuration, Filename etc. The tool-config (Drill, Mill) are also not accessible. But they can be configured in other postprocessors.

RemoteWIN is obviously very special. Some things are handled strange. For example:

I use manual toolchange. RemoteWIN understands the command "M6/M06" for this. but it does not move the machine to the priviously configured tollchenge position. Would it be possible to build a postprocessor that handles specially RemoteWIN. That could be of interest.

Other software (e.g. FlatCam) use the commands (M6/M06) too, but they also have a config file to insert those positions. Than, if the command is given, they move the machine to this position, stop the spindle and wait for an input before they move to the new position, the spindle is started and they go on with the file.

Norbert

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Thu May 23, 2019 3:09 pm

Again, please do let me know which post processor you've used before (the one you said worked under Windows), that would be most helpful.

Of course a post processor can be created once we do have all the info required... M6 for tool changes is no problem.

Perhaps you can also attach a working example file? That would be great!

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Thu May 23, 2019 5:29 pm

Excuse me, please. I thought I sent the info already, but I have a lot of problems with this forum. After a few minutes my loging is terminated, but there is no indication for that. When I send a message I'm requested to login, even if the corrct login name is shown on top of the display. When I login again, the message is deleted. I will read again which messages are sent and than complete everything to answer your questions.

Norbert

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Thu May 23, 2019 5:46 pm

The postprocessor that worked is the same than under linux. I could not use G41/42 because that did not process the radius correction of the milling tool. Therefore I had to use Gcode offset (mm).

But again: The same postprocessor that generates a correct file under windows does not generate a correct file under linux.

I had the ISEL-Programmer to check the problem out. All they could find was the missing "CR". When I added it manually to the file generated under linux it did not work.
Than I took the same postprocessor (GCode offset (mm) under Windows and the file worked. The file itself looks eactly the same than the one from the linux version. The ISEL guys could not explain that.

There are diffent softwaretools available to display the GCode files. All of them do show the correct dispaly, regardless which operation system of QCAD/CAM is used. The same happens with other software to generate GCode files like FlatCam.

That I found out that it is a differnce if I use windowsOS or linuxOS version happend accidently, because I had to manipulate a GCode file directly on the computer that is connected to the milling machine. That one has windowsOS only. When I generated the file on that computer everything worked.

I know it sounds silly, but it is true!!!

Thanks for your help.

Norbert

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Thu May 23, 2019 8:47 pm

Thanks for the details.
Please attach both files, the Windows one that does work and the Linux one that does not work, thanks.

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Thu May 23, 2019 10:39 pm

here are the files:

Rueckwand-Gleichspannung.nc is the one from WindowsOS that works
test-linux.nc is the one from LinuxOS that doesen't work

But I have to mention, that the original file from Linux was already deleted. Therefore I generated a new one. I did not attach the "CR" in this file.
Attachments
test-linux.nc
(393 Bytes) Downloaded 66 times
Rueckwand-Gleichspannung.nc
(423 Bytes) Downloaded 58 times

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Fri May 24, 2019 8:49 am

The files are identical apart from Z safety level (Z100 / Z50) and line breaks. Changing the line breaks would make them identical in terms of formatting. There is really no other invisible magic, these are simple plain text files.

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Fri May 24, 2019 9:32 am

That is true. I tried to find the problem but wasn't successful. The same to the guys from ISEL.

The intersting fact is, that this is not a problem from QCAD/CAM. As mentioned before, I have the samt rouble with other CAD/CAM Software like FlatCAM.
Obviousely nobody knows what happens with these files. I think the main problem is, that everybody developes software for windowsOS. But due to the fact that all GCode display software runnning under linuxOS I could find, has no problem with the GCode files generated under linuxOS. Therefore I think that ISEL has to make their RemoteWIN less sensitive to windows formatting procedures. They must have build in a kind of filescheck that causes the problem.

Do you see a chance to build a postprocessor for RemoteWIN. I did send the table of ordercodes ISEL uses.

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Fri May 24, 2019 9:50 am

Norbert wrote:
Fri May 24, 2019 9:32 am
They must have build in a kind of filescheck that causes the problem.
There's nothing hidden or secret about simple text files. There's the contents (i.e. the "Bytes") which would be identical after a correct conversion to CR/LF, there's the file name and path and there are file permissions (readable, writable, executable). It is not technically possible to check if a file originated from Linux or from Windows; if contents, name and permissions are the same, the files are the same.

If one file works and the other doesn't, I see four possibilities:
- the conversion to CR/LF was faulty (I have never seen the converted file, so I cannot rule that out)
- the permissions are the problem (permissions don't come across when attaching files to the forum, so I cannot check this here)
- the file name or path is the problem (check and compare for spaces, umlauts, special characters, etc.)
- the problem is something else entirely (the files were imported differently, etc.)
Norbert wrote:
Fri May 24, 2019 9:32 am
Do you see a chance to build a postprocessor for RemoteWIN. I did send the table of ordercodes ISEL uses.
I don't see why the "G-Code (Offset) [mm]" post processor wouldn't work with RemoteWin (or is it "Remote-NC"?).

However, if you cannot load G-Code files for what are "unknown reasons", it's unfortunately impossible to even know where to start.

Norbert
Junior Member
Posts: 15
Joined: Tue May 21, 2019 9:08 am

Re: GCode-File

Post by Norbert » Fri May 24, 2019 11:57 am

Well, all these reasons do not apply. I can open the file in RemoteWIN. I can start it in RemoteWIN. But RemoteWIN stops with erro at the first and every further line. Sily errors like "00" or "000" unknown. It doesn't make a differnce if I have inserted the missing "CR".

And no, I'm not talking about Remote-NC but about RemoteWIN.

I had the idea that I possibly used the wrong order to insert the "CR". Therefore I treid out to insert "\r\n" than "CR\LF" and I tried ANSI Code "0D 0A" and "0D/0A". I checked out if the codes are really there. Therefore I used Notepad+ which displays these ANSI Codes. "\r\n" diplayed the correct code only.
But the file still doesn't work. And sometimes I observed different Codes e.g. I started the file and got the errorcode "00". Than I stopped the file and got the errorcode "0" at the same place. If would have expected the same code at the same place.

And I want to amplify again, that this is not a problem of QCAD/CAM only. I have the same with FlatCAM. Therefore I thought that it is a magic thing between linux and RemoteWIN.

However, I was asking to build a RemoteWIN postprocessor because I am missing several things. One is, that the machine stops at M6 for manual toolchange. But most of the time the position of the spindle is not reachable to change the tool.

I need the machine to move to a special position, move the spindle upwarts, stop the spindle and wait for action when the toolchange is done. Than it has to go on working that GCode file. Therefore I would like to have this postprocessor.

The two suggestions you sent to insert "CR/LF" did not work, because I can not put in a filename, Path or anything else. All fields dealing with filenames or pathes are not accessible, but only for these two postprocessors you sent yesterday. Therefore I do not know if that would work.



Thanks
Norbert

User avatar
andrew
Site Admin
Posts: 6246
Joined: Fri Mar 30, 2007 6:07 am

Re: GCode-File

Post by andrew » Fri May 24, 2019 12:08 pm

Norbert wrote:
Fri May 24, 2019 11:57 am
I need the machine to move to a special position, move the spindle upwarts, stop the spindle and wait for action when the toolchange is done. Than it has to go on working that GCode file. Therefore I would like to have this postprocessor.
Sure, this is all no problem, but more a matter of preference than the particular G-Code flavour. I'd suggest to implement your own post processor with these features. I'm happy to help with that (again, please provide example files).
Norbert wrote:
Fri May 24, 2019 11:57 am
The two suggestions you sent to insert "CR/LF" did not work, because I can not put in a filename, Path or anything else. All fields dealing with filenames or pathes are not accessible, but only for these two postprocessors you sent yesterday. Therefore I do not know if that would work.
Are you referring to the user interface (e.g. a dialog)? If so, can you provide a screenshot? I don't understand what you mean by "put in a filename or path". A toolpath or file path?

Post Reply

Return to “QCAD/CAM”