Drip mode update and new program to run

Machine Shop HAAS
#1

Hello. I played around with the baud rate and the HAAS still craps out in drip mode after about 256K bytes of download no matter what speed. After talking with Chris W. it appears that the old HAAS has an integer limit of 2^18 (256K) - meaning no matter what your program download can never be more than 256K bytes. In short we all will have to learn to break up our programs since Fusion360 is not all that efficient.

I have installed a new program (105) which starts with tool 1, pauses 2 seconds and does a tool change to the next tool. eventually it will cycle the entire tool crib. the theory here is that as the cutting fluid dries it gets sticky it can make the tool jam if it is in there too long. This program should be run at least once a week. It is on the controller and currently saved on the HAAS PC. Unlike the warmup program it can be removed from the controller if you need the extra memory (not much is used). so I prefer it not be deleted.

If your program is on the edge and you need a few extra bytes, you can try removing the block numbers (the NXXX) lines so that only the raw gcode is sent. CMEdit will do this automatically. It is one of the functions it has. the downside is that if your program dies, it is a lot harder determining where with no line numbers.

Lastly, we got another HAAS part 1 class under our belt. cheers!

5 Likes
#2

I really need to take that class before I leave the country again!

#3

Thanks for teaching the HAAS I class, I really learned a lot!

1 Like
#4

Yeah yeah yeah, its an old thread but still pertains to this exact topic. @procterc was able to run a file of 670k with no faults on Tuesday & Wednesday. He is not using F360, but Solidworks. Granted there was not any tool changes but I dont think thats an issue. I’m wondering if its an issue with the post processor itself. I’m going to experiment with some settings to see if I can find out. Do some comparisons between post processors to see if there are any notable difference.

2 Likes
#5

I wonder if there are characters, newline conversions, extra whitespace, or other issues that can cause serial errors. These are things that even if the g code were the same in effect, could cause serial connection issues and dropped data. Depending on how the protocol is handling it, the error could add up and get caught at some arbitrary page size.

Does the serial connection for drip use parity, flow control, stop bits, etc? Is all of this gibberish? If so then @malcolmputer may be able to help (because I’ll be gone for a while and he’s already signed off on the Haas unlike me still ). otherwise I don’t mind doing some serial reverse engineering

#6

I’m not sure what flow controls/parity or even baud rate are at. I haven’t looked in the book but I dont think any of it would have changed. The only thing that has changed was the CAM/Post Processor.

Just thought it was interesting/great to see Charlie load successfully, a file that large.

#7

Stupid question. … what kind of hand shaking is being implemented on the serial port and what is the buffer size?

#8

The only thing to note are looping is not permitted. So no subroutines. End with M 02 not M 30.
There is a parity check, and handshake.

#9

The buffer is quite substantial, from the operator perspective, it runs for several minutes. The handshake criteria are in the instructions, I don’t remember the options, there’s a setup that allows for a non crash fault management. I didn’t find the setting that deals with that.

#10

I have an old HP serial protocol analyzer. I used it for data buffer overruns on computers to old pen plotters. It has a 25 pin eavesdropping cable but its a simple thing to make in and out 9 pin adapter (or just buy some adapters). If anyone feels like having a look at the data stream and see if anything is happening there

#11

What I’m getting at is that serial can be sensitive to the data formatting of the output g code as it pertains to text encoding methods (traditional UNIX line endings and windows line endings for example). These are things that are invisible when you look at it in a standard text editor and the CAM tools, but serial and other low level things can have hangups with

#12

That type of error is not file size dependent is it?
I would like to find out how the parity errors are handled.
Can the code editor be programmed to do looping in the computer and send the loops to the machine sequentially?

#13

the file sizes here are dramatically different, but error can accumulate however I’d suspect the failure comes from something happening at a page boundary, like a line formatting when it hits a certain block size in a buffer.
For example the fusion post, which fails after 256k of drip, could be flushing a buffer when it hits that boundary without a clean line termination or whitespace

I can’t say for the specific software present, but in general such things are possible with serial interfaces

#14

Something in the back of my mind tells me that it’s got hardware flow control turned on, and that it actually respects the ready to received in the UART/Serial setup. I think that was from a conversation with Nick, but it may have been from inspecting the physical set up. I was really curious how it worked when I started using it.

#15

One thing for thought is the line numbers, I noticed in the G-code that the line number at the end was 4402 I believe @procterc. So I’m not sure if F360 continues in the code past 10,000. The file Charlie did started recounting the lines after N9999 to N1. So basically if you had a 24,000 lines of code, it would lapse twice.

#16

It resets at 10000 lines. The whole program was 19,000 lines and change.
I was playing with the cover for the grinder wheel and came up with a 1.5 meg file. I might try to air cut that.

2 Likes
#17

this ancient haas controller has a problem with line numbers over 9999. Easy solution - the transfer program has an option (tab) to remove all line numbers and/or white spaces. saves a little bit of memory too.