Need Help!- Fanuc omd dripfeed issue

[Stebedeff]

Hi guys,

I'am having a issue with dripfeeding with fanuc omd. It seems to me that my buffer on this machine is about 3 lines instead of the approximate 10 lines.
Is this possible??? How or which parameters need to be changed?
I have set up both my mills to drip feed etc. One has no problem at all but the other with same fanuc model doesn't seem to use the entire buffer.
It will drip feed but more or less line by line even though parameters 390 bit 7 is on. I did the same settings on our other mill and drip feeding worked directly using the aprox. 10 line buffer.
I would like to get this fixed.
Thanks in advance.

Greetings, Stephan

[Stebedeff]

Still having an issue with the drip feeding. Sorry to see no one has any
ideas or wisdom for me with this trouble.
I'am still trying to solve the problem.
On my way I notice the pc sends about 14 lines as soon as I press START on the mill in TAPE mode. So this meens there is a buffer, that was empty and now full.
But after that it,s reading 1 line at the time. My suggestion is that the fanuc will not empty the buffer while program is running but just takes over the next line one at the time. So buffer stays full.
Is there a parameter for this???

Hope to see some answers.

Greetings

[tc429]

Ive seen sluggish dripfeeds where they tried to run from a floppy- assume your file is on a harddrive in the pc, but thought I'd mention anyway.

faster baudrate?

almost sounds to me like its waiting for in position check before doing the next line...check the values in parameter 500-503, normally 10 counts or so.

are you sure its not bufferring? once the buffer fills it will pull one more line at a time to try and keep the buffer ready to pull data from, ahead of axis motion. my old old old procomm I still love to use has a setting for milliseconds between characters or something like that in options too- might doublecheck your pc setup- maybe even swap pcs with one you hadnt noted the problems on, just to be certain its not on that end.
watch for extra carriage returns or line feeds in your output translation- blank lines in a fanuc are same as a g4p0 line- exact stop, and causes stopping completely between lines of gcode.

[Dan Fritz]

I don't have a 0MD manual, but I know that some later 0 models have the same parameter mapping as the 16/16/21 controls.

The 16/18/21 manual shows a paramter bit labeled "ND3" in parameter #100, bit 5 (6th bit from the right). That bit determines if the DNC operation is "Block-by-block" (0), or "read until buffer is full" (1). If you have a parameter manual, look for a bit marked "ND3" and set it to "1"

You mentioned parameter 390, bit 7. What is that bit for? I don't have it in any of my manuals.

[Stebedeff]

Hello,

Thanks for your responses. I have been trying to figure this out for a long time.
As I bought both mills second hand I don't have any Fanuc manual but a 18t.
Parameter 390 bit 7 is the ND3 I assume. When setting up both mills for dripfeeding using the buffer I changed parameter 390.7 to a 1 and it worked immediately. I got the info from CNCzone as well.
I set this up on the other mill too, but no luck.
What I am going to try tomorrow morning is to set parameter 390.7 back to 0 and check if pc still sends the 14 lines as I press START.
I'll keep you all updated.
Is it possible that the fanuc controller doesn't send a Xon or Xoff or anything that pc needs for correct dripfeeding?

http://www.cnczone.com/forums/fanuc/...drip_feed.html

Thanks already

[Stebedeff]

Here's another link for previous posts on this topic

http://www.cnczone.com/forums/fanuc/...tml#post850654

[Stebedeff]

Hello to all,

As I mentioned on previous reply I changed parameter 390.7 back to 0 instead of 1 to see what would happen. NOTHING !!! That didn't make a difference. I'am still getting the 14 lines send.
What I did find out is that I'am only getting a DC2 when sending from controller to pc at the beginning of the terminal. No DC3 or whatever at the end.
From what I've read here on posts, it's suppose to be a DC1 and DC3.
I'am getting exactly the same on the other mill where DNC works just great!
I have no clue what the differences are between DC1, DC2 and DC3.

http://www.cnczone.com/forums/fanuc/...tml#post850654

That's all for now.

Thanks

[angelw]

Originally Posted by Stebedeff Hello to all, As I mentioned on previous reply I changed parameter 390.7 back to 0 instead of 1 to see what would happen. NOTHING !!! That didn't make a difference. I'am still getting the 14 lines send. What I did find out is that I'am only getting a DC2 when sending from controller to pc at the beginning of the terminal. No DC3 or whatever at the end. From what I've read here on posts, it's suppose to be a DC1 and DC3. I'am getting exactly the same on the other mill where DNC works just great! I have no clue what the differences are between DC1, DC2 and DC3. http://www.cnczone.com/forums/fanuc/...tml#post850654 That's all for now. Thanks

Generally, if comms software is set to Software Handshaking, you won’t see DC1 (Xon) or DC3 (Xoff) in the received data stream. When the software is set to Xon Xoff handshaking, DC1 and DC3 are interpreted at system level and not by the software. You may see these characters if the software handshaking is set to None, and if these characters aren’t filtered out if the software has a control character filtering feature.

On just about every model of control except for series 5, OM and OT there is a parameter setting to have the control use, or not use characters DC1 to DC4. I’m fairly sure you don’t have the option with the OM/OT control. When the control is set to use these control characters, all of them (DC1 to DC4) are sent and read by the control. If the comms software is set to Xon Xoff handshaking then, as mentioned earlier, these characters are read at system level. Accordingly, unless you have some way of receiving and looking at these characters, and knowing for sure that DC1 and DC3 are not being sent, then I suspect that they actually are, particularly if you have been able to identify the DC2 character being sent. If DC2 is being sent, then it’s likely that DC1 through to DC4 are being sent or read by the control.

The difference between these characters is that DC1 (ASCII 17) and DC3 (ASCII 19) are the primary software handshaking control characters and DC2 (ASCII 18) and DC4 (ASCII 20) are a secondary set. The comms software would have to be specifically set to use the secondary characters for handshaking.

From what you have described, I don’t believe your problem is to do with handshaking. If so, it would be more likely that you would get a buffer overflow at the control when sending data to it rather than the slow feed that you’re experiencing. I would tend to agree with Dan, that the control is reading the data a block at a time rather than filling the buffer.

Regards,

Bill