[PMBottas]

Hi,
I'm recreating an old DOS, command line based, 2D CAD program in Windows/.NET/C#. In addition to defining geometry, the program also had the ability to write out a NC code file (or upload this code to a controller) based upon points generated by the program.

My question is this:
What ASCII character should be used to represent EOB in a CNC code file that will be sent to a disk file and/or controller; a carriage return (decimal 13, hex 0D, a '\r' in C,C++,C#), a newline (10,0A,'\n') or something else (ie \r\n) ?

or does it depend upon the controller that will ultimately use this file???

Been searching the web and I can't find anything definitive (and therein may lie my problem, is it definitive?) but there's something in the wisps of my memory that says it should be a carriage return... (then again that may only be something left over from a previous BSD unix life)

Thanks in advance,
PMB

[WayneHill]

The old NC tapes used both carriage return (13) and line feed (10) for the EOB characters of a line.

[PMBottas]

WayneHill,
By "old NC tape" do you mean punched paper tape??

(now there's a memory, programing in BASIC on timesharing system using a model 33 teletype...)

and if so, what do the "new" tapes/files use? (ie disk files)

Thanks,
Paul

[WayneHill]

Paul,

Yeap. The old NC paper tape from a model 33 teletype in ASCII. Those were the days. Glad they are over...

New file EOB depending on the control setup for the EOB.

Some like #13#10
Some #10
Some #13

Allow for one of each and both...

Wayne

[Boots]

Have you tried ; ?

[PMBottas]

Boots: I'm not referring to the on screen representation of the EOB character, but rather the ASCII code (god forbid it's in EBCDIC) in the data stream that is sent to the controller (or written to disk) which which signifies an EOB character.

Wayne: Thanks! This is exactly the solution that I was considering last night as I was shutting down the system for the night; make it a setting in my Options dialog.

And like you say - I found out to today at work that it depends on
1) the controller
2) is typically a setting on the control for what it expects to see in files that are uploaded to the controller

Downloads (controller->PC) are controller dependent as well and may not be set-able, but that's easy to handle in my program; a simple parsing algorithm.
In fact I probably don't even need to to handle it when I'm opening/displaying the file as when I assign/copy the contents of the file to a RichTextBox, .NET converts:
"free-standing" #13 to #10
#13#10 to #10
and leaves free-standing #10s alone.

I just have to deal with it when saving/uploading based upon the user's preferences set in the Option dialog.

Thanks again,
Paul

(and yes, I agree, I 'm glad they're over... no matter that things were simpler then... well other that having to write your own device drivers for that home-built bread-boarded computer, or hand assembling a program in binary, converting it to hex and and loading it via a hexidecimal keypad (or "gasp" a switch register) ... that was a much fun as:stickpoke

[johnohara]

There is no EOB on the ascii table so it has to have significance to whatever you are sending it to.

If EOB means "End of Buffer" then a number of possibilities exist.

For text files, it's generally a CR/LF (13,10) to denote end-of-line.
I think *nix systems look for the 'newline' character -- ascii 10.
For C, C++ character arrays it's a NULL ('\0') character, aka "the fencepost."

If it's old DOS then start with a CR/LF. For the record, "\r" is an ascii 13, "\n" is an ascii 10. You can also use "\x13" and "\x10" in C, C++ to send the hex value.

Hope it helps.
~John

[Al_The_Man]

The actual EIA RS-244 standard for CNC paper type did not include Line Feed, the EOB was represented by the carriage return.
The EIA RS-358 did include the LF, but the EOB was still represented by the CR.
When you printed out these tapes, the software is set to include a LF when a CR was seen, so that it printed out in viewable format.
Al.

[johnohara]

PMBottas~

Any word on the diagnosis?

~John

[PMBottas]

Al_the_Man: Thanks! your username says it all! Now that's what I call a DEFINITIVE ANSWER!

BUT I THINK I NEED TO CLARIFY SOMETHING HERE.
(methinks my earlier reference to a model 33 TTY has sown confusion...)
I'm not referring to actual paper tapes, rather the data stream of characters that is sent to and fro between a PC and a controller. Am I correct in assuming that your comments are still applicable? I would think that they would be, since it really doesn't matter what the storage media of the source file is (ie paper tape, disk, ram, etc) - once it's output to the serial (or parallel) card/chip, the format needs to be the same.
(or is the word "tape" just a generalized term used to refer to the CNC code when it is stored outside of the control)


Also, what is the spec that defines all of this. Yesterday I found RS-274 which seemed to be what I was looking for, at least until you mentioned 244 & 358.
What is the current communication/program format standard(s) for controllers in use today?

Are my statements in my post on 06-23-2010 08:13 PM correct? (& WayneHill's?)

Paul

(as some personal background info so that you know where I'm coming from, it may help to know that even though that I use to program, setup and run Matsuura & Fadal VMCs, Robodrills, Hardinge CHNC IIs, 3s, & Nakamura-Tome TWs, TMCs & Slants, I've been in QC for the better part of 25+ years; less a few years off when I worked in the semiconductor equipment mfg sector as a systems test tech. Before that I worked at Lincoln Laboratory (SDI-fringe stuff)("that's not a laser, THIS is a LASER") and at another company working on DARPA projects (IR target recognition sw). I've been writing computer software since 1978 (sometimes professionally, but lately mainly as a sideline) in over 20 languages on everything from System 370s, VAXs, PDPs, PCs, Macs, down to embedded signal processors. I'm a EE/Comp Sci major that never finished his last year. (Life got in the way, as it sometimes wonts to)
In other words, feel free to get techincal...

[Al_The_Man]

My experiences so far have been the the majority of CNC controllers only require a CR as an EOB.
When transmitting from CNC to PC, the PC s/w inserts a LF automatically.
Otherwise simple modem programs will only display verbatim.
I have a Fanuc RS232 PDF manual which I can send if you pm me an email address.
this includes the tape codes used for both ISO (ASCII) and EIA code.
These apply to modern transmission methods also.
Al.

[PMBottas]

Al_the_Man:
Assume! Thanks for the info.
I'll pm you now.