0i-MB reading large file over serial stops early (NOT memory)

[phatbob]

Hi,

I'm 100% clear on memory, lots available. When I'm transferring a file (not rally *that* large, 21kb), the file doesn't transfer all the way. Ive tried many different times, baud rates, flow control etc its NOT that and I've been transferring files to the machine for months, no issues. JUST this one file, it gets truncated. I've tried shortening the file, and can confirm "more" of it (the shortened version) goes through.

So is there some sort of file size limitation that I'm running into that I haven't seen before ? The total size of the file that does work is around 20377 bytes, and a version of the file that DOESNT work is same file with more lines, 20513 bytes on disk...

Thoughts ? Its not the command either, as I just filled the bottom with comments, they still dont go through.

Thanks

Similar Threads:

• Mach 3 quit reading machine end stops.
• Need Help!- Fadal DNC stops early....
• Reading memory stick through ethernet port?
• Problem- laser stops when doing large bitmap.
• EMC2 not reading large Gcode file???? HELP

[memoryman]

I have never heard of a file size limitation on a Fanuc control. Is there a message that come up when it happens?

[WGoyer]

How about a garbage character somewhere in the file Bill? Lower case n? Keep shortening it 5 lines at a time until it goes?

[memoryman]

Hi Warren.
Could be a 'corrupted' file.

[drdos]

Create a file of that size in the controller then punch it out and without changing anything read it back in.

[phatbob]

ok thanks for the tips, I've narrowed it down. It actually has nothing to do with the file size. It happens only on larger files - seemingly randomly (but it isn't random) - so every file I load I have to see if the last dozen (has been as high as last 40) lines made it through. For a specific file, it always get truncated in the same place. So, I think this has to do with the software that's sending the programs. I'm using the 'send' function that comes in the predator editor. I'll try a test with a known 'truncating' file with another transfer program, see if thats the issue or not.

[Shoprag]

Parameter 3201 bit 6 (NPE) will terminate the program load if an M02, M99 or M30 is read.
Bit 5 will also cause a termination if M99 is read. Might want to check these two.

[dcoupar]

Just curious... what version of Predator Editor are you using for this?

[phatbob]

Hi guys and thanks for all the ideas:

every day I regularly have to load many programs (like many per hour) in and out (effin memory limits) as we dont do production its all one-offs and usually they aren't jobs stored on the card as its all new protos. So that being said:

it happens *almost* every time. 9 times out of 10. I have tried to narrow the one time that it works, but here is as much detail as I can give:

- it doesn't happen on 'small' programs. But I regularly load 'larger' programs (200k). It seems to never do it when am in the sub 20k range. But for sure over 50k and its 9 times out of 10. Most of my programs are around 100k.

- the "amount" of data truncated is not consistent. However, it is always the end of the file, usually like 20-50 lines, just the last lines. If I load a 250k program, or a 50k program, the amount of lines truncated is always at the end and doesn't seem to vary based on file size.

- So i now have a routine of "READ" in program, switch to program, key in M30 and hit down button. If it errors out, I know the file got truncated. Then I have to look on my computer for the last line number in the program, and I start searching for the total # of lines minus 100, then minus another hundred, etc. until I get a search that doesn't error out (damnit whats the quick key to get to ~BOTTOM LoL), then I go back to my computer, delete every line up to the truncated line, hit "send" again, then READ part 2 in, then have to go to part 1 (truncated), and to a EX-EDIT MERGE and then carefully make sure I didn't miss anything. As you can see, error prone and a mother effin pain in the rear.

- It seems to happen LESS if I remove all line numbers (I have had to do this to push some memory-limited 3d contour programs in - so found this out by luck). With all line numbers removed, it happens less. It is also crazy effin annoying if it DOES happen with line numbers removed, becuase then I have to find where to patch them together and this isn't easy sometimes in a 4 axis contour LoL

- it also seems to happen LESS if I truncate all white space

- it ISNT M02 / M30 / M99 . But.. of course, its always the end of the file that is truncated, and ours all terminate with M30, so perhaps that is related, but not within the program. In any case, that param isn't set anyways.

- I have not see it happen at all with DNCFree or any other xmit program however I use Predator all the time and I am used to it and so I am stumped.

- I tried going to hardware only, hardware / software, wait for Xon, DTR / RTS enabled / disabled. Seems to work best with software, wait for Xon, no DTR/RTS. But still, no matter what that was set to, it still truncates.

- The Predator version I am using is the one that comes with CAMWorks 2019

- One last piece of data is I am sending via a ethernet / serial Nport device. However, I didn't mention this and I didn't think it was relevant because I haven't seen this issue with other software... i.e. it works from DNCFree over the Nport...

So, ideas guys ? I was able today to send a 240k 4 axis contour program no line numbers no whitespace nothing truncated (thank god). But that is really rare. Very normal to have to add 20-30 lines at a minimum... So something to do with the last packet and whitespace or line numbers or this might all just be coincidental... But I have never had a send error never had data lost midstream, only at the end of transmission. And final note: NOTHING EVER GETS DROPPED GOING THE OTHER WAY (to PC)

[zavateandu]

you can try to use the software CimcoEdit,the most stable for DNC transfer.