1. Home
  2. ⏣ General Metalworking
  3. OT: low level file writing

OT: low level file writing

I'm using my CNC control to read a laser displacment sensor voltage then write the X Y Z and voltage to a file with a low level FILEWRITE command. I'm doing this to reverse engineer, or copy, parts I need.

My question, at the end of a reading, I want to start a new line of data. I need to write something. Carriage return and/or line feed??? I've got this out of my docs but still not sure what to do

Karl

HEXCHAR

This command permits the user to store a hex value into a public variable perhaps to be used with COMMOUT via RS232, PRINT via the printer port, OPENCHANNEL via the network, FILEWRITE via file handling or even LABEL or BUTTON to display multiple lines of text using a carriage return and line feed between lines. The hex value of the character will be stored in the variable. Keep in mind that many characters are non-printable. If you attempt to display a non-printable character, a tall box will appear instead. The range of hex values is between 0 and FF. This equates to 255 values. The special meanings of these hex codes are published in the various versions of Microsoft Windows documented as KeyCode Constants.

Some values are:

1B=ESC

11=CTRL

0D=Carriage Return

0A=Line Feed

01=Left Mouse button

09=Tab

Reply to
Karl Townsend
Loading thread data ...

Not sure what language or syntax your package is using but the standard for a new line in Windows/DOS is a carriage return line feed pair () so you want to append a 0D0A to the end of your line or the output stream.

Reply to
David Billington

LF is normal in the *nix world, CR LF in the mickeysoft world.

What are you planning to read the file with?

Wes

Reply to
Wes

Thanks, got it working. Collecting data for real right now. I'm going to try Rhino first. I've read about converting point clouds to vector format but never done it. I'm starting with a small part that is just a laser cut sheet.

Karl

Reply to
Karl Townsend

You are going to have to tell us more. My first impression is you are doing a raster scan of the test item with the goal of replicating it.

Wes

Reply to
Wes

And, for completeness, CR in the Mac world.

Reply to
Joe Pfeiffer

You don't say what OS you are using (the end-of-line sequence varies from OS to OS), but from other information below, I believe that you are doing this on Windows.

What language is using HEXCHAR? or is this a command line command?

[ ... ]

On Windows (and MS-DOS) the standard EOL sequence is , so you need to use the hexchar function to send both 0D and 0A in that order. (I don't know whether your system wants to see the hex just as the two characters stand alone, or the C practice of prefixing a hex value with "0x" (octal values are just prefixed with '0', and starting with any other numeric character is presumed to be a decimal value.))

On unix and linux systems, Line Feed (0x0A) is the standard EOL character.

On Old Macintosh systems, and on Microware's OS-9, Carriage Return (0x0D) is the standard EOL character, but when you get to Mac's OS-X, you have a unix hiding under the Mac's GUI, so you can find places where one works, the other works, or where programs simply look for either character and ignore the other once one is found.

For the comment about non-printing characters in the HEXCHAR documentation which you quoted, Standard ASCII has the first 32 characters (0x00 through 0x1F) are control characters (CR, LF, BS(Backspace) and a lot of others, including 0x07 BEL (which rings the bell on a Teletype or beeps on a computer terminal.)

Then, characters from 0x20 through 0x7E are printing characters,

0x7F is a rubout character which was used to overwrite all holes on a teletype punch, and then another 32 duplicates of the control characters (0x80 through 0x9F) except with the parity bit set, and 0xA0 through 0XFE again are printing characters, and 0xFF is the rubout with parity set.

Recently, various systems have been using one of many extended versions of ASCII which use the 0x80 through 0xFF as special characters, since parity checking is done elsewhere in net transmissions. Unfortunately, these do not agree on which characters you get with various extended sets, and at least unix system (like my Sun workstation) treat the 0x80 through 0x9F as non-printable characters, even though some other systems are using those for things like the Euro symbol ¤ (I think that should be the Euro symbol, but it is displaying here as "\244" -- the equivalent of 0xF4.

Good luck, DoN.

Reply to
DoN. Nichols

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.