[gar]

060705-1035 EST USA

COMMENTS on HAAS DPRNT.

The purpose of the DPRNT function is to provide a means to output serial data from a CNC program.

You must have the MACROS option to use the DPRNT function. Also communication parameters must be properly set (baud rate, handshake, data bits, parity, & stop bits).

The HAAS manual lacks a complete discussion on DPRNT. Therefore, this discussion is intended to summarize some DPRNT information, and provide some information HAAS does not include. I have discussed some of these points in other threads.

The comments here are limited to port COM1, my term for the data input/output port. This is usually the top 25 pin female "D" connector. The location is determined by how the internal ribbon cables are connected. The second HAAS port, COM2, is used for rotary tables.

For reference in my following comments make a printout of
http://www.asciitable.com/ for an ASCII chart. Use landscape orientation.

Use of POPEN and PCLOS are not required, but these do output DC2 and DC4 respectively, and may be useful for some applications even though these do not turn on and off the HAAS serial port.

The HAAS serial port is always on.

This means that for OUTPUT without using POPEN and PCLOS that simply issuing a DPRNT command will send that data out thru the COM1 port. This assumes that no serial communication handshake is inhibiting output.

In the INPUT direction there is no HAAS function for receiving data into a running program. This is a major missing element in the HAAS design.

(edit 2) This is not quite correct. Information from Haas Apps indicates the following: Since about 2001 HAAS has included in all machines a data input capability. If setting 143 is ON, then HAAS continuously looks for incoming data on COM1. If a message like Exxxx followed by a floating point number is received, then that number is placed in the #xxxx variable. The allowed variables are #1-999. & #2001-2800. Note this is asynchronous to program execution. Thus, you would place the value in an otherwise unused location, then at an appropriate point in the program copy the value from that location to the working location. We do not have a machine new enough to check out this function. (end edit 2)

Thru COM1 you can receive programs, offset table, parameters, and settings using the keyboard key "RECV RS232". Here COM1 is always open means that the handshake signal RTS pin 4 is high (+10 V) even when the control is not in the "RECV RS232" mode, or some other state where it should be active. But if you send data to COM1 and HAAS is not in the "RECV RS232" mode the incomming data just gets thrown away. So incoming data does not cause any problems. It would be better if pin 4 was low (-10 V) when HAAS was not in an RS232 receive mode..

The character set that you can output is very limited. Another HAAS deficiency. This set is the uppercase alpha characters A thru Z (hex 41h thru 5Ah), and the symbols + (2Bh), - (2Dh), / (2Fh) also the special functions of the "space" key (20h), and * (2Ah). HAAS does not tell us why they chose to treat space and * as they have. As a user I consider the limited character set a bad design. If I knew why I might classify it differently. The chosen character set is not very efficient because it does not have contiguous elements and therefore requires a number of tests to select the elements of the character set. So why was not everything from hex 20h thru 5Ah included in the set? 20h thru 5Ah is less than 64 characters and therefore will work in 6 bits with some translation, if 7 bits are not available.

Special characteristics of the characters "*" and "space" are as follows:
If you put an * in a DPRNT statement, then it is converted to a space in the serial output. In the ASCII alphabet "*" = 2Ah and "space" = 20h.
See the previously reference asciitable.com .

Note: with 7 data bits per character you can cover the entire standard ASCII character set. This is 128 characters. I call anything in the ASCII table a character, whether printing or non-printing. If you are limited to 6 bits instead of 7, then it is not a simple translation to encompass some control characters and the above limited set.

I will get back to the "space" character later.

The general format of the DPRNT statement is
DPRNT [ anything allowed by HAAS that you want in any order up some maximum length within the square brackets ]
The allowed items are text within the limits of the above character set, and the contents of #-variables and a format definition is required with each #-variable. You might have text only, or data only, or both, and no spaces or some spaces.

At the end of each DPRNT statement HAAS sends a "carriage return" (0Dh). (edit1) Actually HAAS sends CR (0Dh) followed by LF (0Ah) at the end of each DPRNT.(end edit1) There is no way to inhibit this. HAAS could have added a new command DPRNTNCR that would not output the carriage return. But they did not do this or use some other technique to inhibit CR.

The HAAS formatting discussion is fairly complete so I won't repeat the discussion.

Some examples follow: remember each DPRNT line outputted ends with a carriage return, 0Dh.

DPRNT [THIS IS A TEST.] produces
THIS IS A TEST.

DPRNT [tEST] entered as an insert in EDIT from the HAAS keyboard is 
errored as BAD CODE because of the lower case t, not because of the 
space before [.
But on insertion the space before [ is removed.

DPRNT [     1234    5678] entered form HAAS keyboard and EDIT INSERT
produces
DPRNT[     1234    5678] in the program
but if loaded with the program via "RECV RS232" the results in the program
are
DPRNT[ 1234 5678] and outputs as
1234 5678
really bad design by HAAS.

DPRNT [*****1234****5678]
will produce the desired output of 
     1234    5678

Let #500 contain +1.234, and #501 contain -1.234, then 
DPRNT [**X*#500[24] ]
DPRNT [**X*#501[24] ] will output
  X  1.234
  X - 1.234
clearly a major problem if you want to align decimal points.
Again a major HAAS design flaw.

To solve this problem you need to test the content of the variable 
and then based on negativeness do one of the two following DPRNTs:
DPRNT [**X**#500[24] ] for zero or positive values
DPRNT [**X*#500[24] ] for negative values.
.

(edit 3)In the above code where I say DPRNT [*****1234****5678] produces the correct output it does, but this forum even under code deletes leading spaces. However, it displays correctly in preview post. (end edit 3)

There is no way to inhibit the carriage return from a DPRNT so things get impossible, too many combinations, with multiple variables in a single DPRNT with the posibility of sign change.

A further problem is that I can not have string variables.

Back to the "space" problem. So many different things happen to the "space" character that you probably should not use it within the [], but only use "*".

It is my philosophy that you should be able to put anything in the basic ASCII alphabet into a comment, or within the [] of DPRNT, but HAAS does not allow that. And you should not have to contend with illogical results.

Note: there are various similar problems in comments:
You can not put a % in a comment, because that terminates program load. That is stupid. It is further stupid that the start and end delimiters for a program are both a single %. Thus you can not distinguish start from end. The % for both start and stop predates HAAS probably. However, HAAS could at least have detected the end % only if it was the first character of a record. That would solve the comment problem.

You can not put () within a comment. For a long time computer languages and other computer programs have had means to solve this problem.

If you put a lower case letter in a comment with HAAS EDIT it is converted to upper case, but no error message like the one in DPRNT.

It seems that HAAS is restricting us to something less than 6 bits worth of data in comments and DPRNT statements, but they do not tell us why.

Following is a program for experiment:

%
O4005
(060706-2030 Sample DPRNT code.)

G90
G53 Z0.0

#5 = +1.2340
#6 = -1.234
POPEN
DPRNT [---Sample DPRNT HAAS CNC Program 060706-2030---]
DPRNT []
DPRNT [****1234****5678****/]
DPRNT [    1234    5678----/]
DPRNT []
DPRNT [    X #5[24] ]
DPRNT [    X #6[24] ]
DPRNT []
DPRNT [    X#5[24] ]
DPRNT [    X#6[24] ]
DPRNT []
DPRNT [****X* #5[24] ]
DPRNT [****X #6[24] ]
DPRNT []
DPRNT [***END***Create your own experiments]
PCLOS
M30

%
.

This sent successfully at 115.2 kbaud.

In some applications you have to minimize HAAS lookahead to 1 or 2 to get correct results or prevent HAAS buffer overflow.

You would not have all these strange results in your formatted output if HAAS had done a good design job.

The output results were

---SAMPLE DPRNT HAAS CNC PROGRAM 060706-2030---

    1234    5678    /
 1234 5678----/

 X  1.2340 
 X - 1.2340 

 X 1.2340 
 X- 1.2340 

    X   1.2340 
    X - 1.2340 

   END   CREATE YOUR OWN EXPERIMENTS

.

In this forum, even under code, one can not get spaces processed properly. So the above output does not display correctly.

(edit 060708-1016) The edit1 above was to indicate that HAAS outputs CR, LF not just CR. (end edit)

(edit 060709-2029) The edit 2 above was to provides new information from Haas Apps on data input to an executing program. (end edit)

(edit 060713-1236) The edit 3 is to point out that CNCZone, even in code mode, deletes leading spaces. So my correct data in the example is printed out incorrectly. (end edit)


.

[gar]

060708-1038 EST USA

I have verified that POPEN produces DC2 (12h) in the RS232 output, and PCLOS produces DC4 (14h).

I ran my above sample progam at 9600 baud and it crashes with a buffer overflow part way thru. You can easily solve this problem with an M00 before the crash point. Otherwise you need time delays in the program, or some action that provides delays.

I think HAAS should have built-in automatic modulation of the DPRNT flow rate into the buffer, and thus eliminate the the program fault. Maybe provide a warning, but do not crash my program.

.

[cyrut2]

The information you provided was great. This has set me down a new path but have you ever done any post editting so that a cam software can create all of the dprint statements. I have mastercam and partmaker from delcam since you have experience in this wondering if you can share some light on this.

Thanks

[mejasont]

060708-1038 EST USA

I have verified that POPEN produces DC2 (12h) in the RS232 output, and PCLOS produces DC4 (14h).

I ran my above sample progam at 9600 baud and it crashes with a buffer overflow part way thru. You can easily solve this problem with an M00 before the crash point. Otherwise you need time delays in the program, or some action that provides delays.

I think HAAS should have built-in automatic modulation of the DPRNT flow rate into the buffer, and thus eliminate the the program fault. Maybe provide a warning, but do not crash my program.

.

Change the Baud rate to 115200 if your machine can do it, that fixed the buffer overflow issue for me. looks like the machine processor hates being delayed sending out serial data so the faster it can dump it the happier it is. i did google it and it came up as a suggestion on a Haas technical document