Fanuc 0M - Prog memory limits??

Lets see if there are any Fanuc experts logged in........

Seem to be hitting some sort of memory or line limit on Fanuc 0M. Checking memory used on the control, I have

Progs used: 1; Free: 62
Mem used: 3970; Free: 28797

(I cleared out any other progs just in case they were hogging the memory and just upload each prog from the laptop)

OK, I have free memory but is there a limit on a single Prog....and is there a Param that can be upped? (anybody know the number??)
My DNC upload fail at the same line each time with an 078 or 079 Alarm. Code is OK and fails at 81% of the upload and on same line every time. BUT......if I remove say, 20 lines, from the 250 line upload it uploads NO PROBLEM.......so can't be comms related. Anybody got any ideas?

It appears you have 32K of memory installed ("turned on") and are using 3970 bytes for something in one program. The maximum memory that could be installed in the older 0M controls was 48K, but even if you had the proper chips installed, you still wouldn't be able to access all of it unless the proper parameters were set ON.

One program can use ALL the available memory.

How big is the program you are trying to load? Get this info from the computer.

If the program you are trying to load is smaller than the "available" memory as shown on the screen, than the real problem is probably that you have something embedded in the code that the control doesn't like. I don't remember what the alarm codes you are getting mean (it's been 12 years since I even looked at a 0M manual), so you should check this in the book. It might help you figure out if there is "bad" code. Some 0M's would not allow Man Readable comments of any kind.

Hope this helps.

If you take out only the line that it stops loading on will the prorgram load? The alarm indicates you may have a O (oh) like GO instead of a 0 (zero) like G0 - if the control sees a O in the middle of a program it will try and load it as a new program.

Alarm 078 - Program number not found
Alarm 079 - Program verify error

Just a thought.

Oh!
thats a ha, it struck me funny bone.
I have a Yasnac control, think it may be fashioned after
Fanuc?
Gw

Sure, I figured out how much memory is in use and how much is available, and code is good also. If I take out the line it fails on, it fails on the next line......hence my reason to think it is just failing on size or lines. Only about 15% more to load (less that 5k overall). I can get around by reducing the lines and taking a deeper cut....but it would be good to know why it's failing and how to access the full memory (32k would be as much as I ever need).

Tried it a couple more times to firm up on the alarms. Yesterday, I think I got 078 or 079 once, but error is usually 911 parity & 100/101 (but I don't need a new PCB!)....it resets after a memory dump and PWE to 0 etc.

On the comment about max 0M memory. Mine has 128k. So the limit increased at some point, if it was indeed lower for earlier models. Mine is a 0MC on a '97 Kitamura Mycenter 1.

Bruce Griffing said:

On the comment about max 0M memory. Mine has 128k. So the limit increased at some point, if it was indeed lower for earlier models. Mine is a 0MC on a '97 Kitamura Mycenter 1.

Click to expand...

Bruce, I should have said: that 48K limit was on the 0M-A, new in 1988. Nice to know Fanuc increased the ram limit (different chip size?).

Darryl, if the original file size on the computer is smaller than the memory available in the control, then by definition the download can't be failing due to file size. I don't know of any limit(s) on the number of lines except possibly the number of digits in the "N" word. Again. I don't have any 0M manuals to look at but there is a table in one that lists the limits on the range that each "word" is capable of recording. What I'm trying to say is: are the line numbers too big? I know line numbers can be Nxxxx but I don't know if they can be Nxxxxx or larger. Just a WAG.

Thanks for the thought....just over 200 lines, that's all (Nxxx). Seems that progs need to be less than 250 lines or fails consistently. I guess another Fanuc mystery glitch.

wil it except n.1,n.2,n.3................n1?
Delta/dynaPath will!
Gw

Darryl, Here are a couple more thoughts.
If all you can load are 250 lines, then either the lines are REALLY long (lots of data in each) or something is wrong because the control is built with RAM (random access memory). This means that the data are loaded into memory one byte after another until you have used all the memory.

In the early 0M (not sure about the later models), it was possible to have a parameter set to show MORE (or less) memory available than is ACTUALLY present on the board. What I mean is: it says you have 29XXX memory available, but you may only actually have 16XXX (or some other multiple of 1024) memory available due to how many chips are installed in the board (empty sockets).

In other words, you may be running out of memory even though it says the memory available is larger than the file size.

I know this to be true (at least on the early 0M's) because I actually had a similar problem with parameters after a "comprehensive meltdown" of the system board.

If you want to continue trying to figure this problem, maybe it would help if you could tell us what model control you have, how big (in BYTES) the file is, and any history of the control that you may have available. In this case, the machine make and model probably isn't pertinent because I think the problem is on the system board and not on the machine side, but you might want to include it, just because "inquiring minds want to know".

If the control will accept N250 (Nxxx) then it should go to at least N999. I know for a fact that an early 0M with only 4K memory (4098 bytes) would accept line numbers as high as N9999.

The number of places to the left and/or right of the decimal place is specified in the programming manual and I think in the operating manual.

The 0M is a something of a lame duck because it wasn't intended to be a very powerful control. If you wanted more computing power they wanted you to buy a different model ( I think 10's & 11's were the hot thing in 1987/88).

Malcolm, thanks. Makes sense. I will have to check the particulars of the control......OM is all that is labelled on the screen and I don't know if an A, B or C. I think Machine plate is 1988. Original file size is just over 4k but if I reduce to under 4k it uploads OK. I want to try to upload say, 2 (or more) 3k files to see if all I have available is a 4k memory chip.

This machine has also had a meltdown in its history and was a mess when I got it. At first I got generic OM params from another machine user but when I tried these on my machine it was total pants. Eventually, params were reloaded when I got info from a Univ. in India, who had the same machine on their plant list in their eng. dept.

I have been using the machine for about 4 years but even now it is not "factory defaults". Though still operating, Denford had no info on this machine and no longer support it. One notable anomaly is that the power inverter goes the wrong way (i.e. running at 70% is faster than 100%) but I have got used to it. I just set conservative feeds and speeds and "drop" the inverter down if I find the going too easy.

Is the Mem free space after it alarms out or before you start the transfer? If it's before check it after it alarms out. On my 0MC if the program is too big it will take as much as it can and show 0 mem free.

Some one please correct me if I'm wrong on this but my understanding is that on the 0's Fanuc still measured the memory in meters of tape not kb. Meters of tape goes back to the old paper tape days. So anyways meters of tape to kb is not a direct conversion. Just checked my manual to confirm the 0mc shows options of 10, 20, 40, 80, 120, and 320 meters. The free space being displayed is the number of free characters not kb.

I would try removing your line numbering and seeing if you get farther in the transfer. I rarely use line numbering because it takes up to much space.

I'll try that...thanks

Darryl,
You only have 80m of memory turned on at the moment and as some people have stated that the free space is not exact. A good test to see if that is indeed the problem is to reduce your file size by just enough so the control will take the program as you have already done. Now take the lines that you removed from the program and put them in a separate program and try to download that program to the control as well to see if memory is the issue. Or just split the program in half as to separate programs and if the control takes them both then memory is not the issue.

If you have tried this with programs already in the control and it alarmed out on a specific line and then you deleted the other programs to ensure that you had enough space and it alarmed out on the same line then I would assume it is a code issue because it would have allowed more code the second time with more memory free.

The alarms you say you are getting have nothing to do with memory. Why don't you post the line of code that it alarms out on along with 10 blocks before and after the problem code to see if there is something wrong with the code. I know you stated there is nothing wrong with the code but your alarms say different.

Stevo

stevo1, it's true that the books gives memory capacity in "meters of tape", but this (I think) is for the convenience of people who were used to tape readers. 1 meter of tape = 39.37 inches. ALL punch tape that uses ASCII standard coding has 10 characters (bytes) per inch of tape = 393.7 characters per meter. Punch tape is spaced .100" per character. The control uses computer style RAM for memory. This is always specified in number of bits (really small, early chips) or number of bytes. 1K of RAM is 1024 bytes.

The actual size of the memory on the 0M is controlled by the number (and size) of the RAM chips installed on the system board. If you (or whoever bought the control originally) did not pay extra, the base memory of the 0M used to be 4K = 4096 bytes = 10.30386 meters of tape. In order to get more memory in the control, it used to be necessary to have a tech physically install more RAM chips in empty sockets on the system board and then "turn on" certain parameters (not listed in the manuals the end user gets) so that the control recognizes the extra memory. The control does not actually check the size of the memory installed by "counting" bytes but by referring to the number as reported by the parameter settings.

Darryl said that while he gets the 078 & 079 errors occasionally, he usually gets a 911 or 100/101 error. If I remember correctly, the 911 parity error can be a transmission error or the control has detected a bad byte of RAM.
The 100/101 error refers (again from my 69 year old memory) to a fault on the system board.

Because the system thinks it has 32K of memory installed, it keeps trying to load incoming data to memory that isn't physically present. Since FANUC didn't anticipate this situation, the control doesn't have an error message for this condition and it gets a little scattered and doesn't always do the same thing.

There is a possibility that one of the I/O buffer chips on the system board is failing but I think this is a low probability.

If Darryl could post lines N245 thru N255 we could check the code for him, but again, I think that bad code would produce errors like 078 or 079 consistently.

Thanks for the info. I must have missed were Darryl posted he was getting 100 and 101 alarm. 100 is for the PWE bit being set and 101 is due to memory problems. I have come across this problem before. Sometimes you can delete just the program that was being loaded and sometimes the memory had to be cleared. This mainly happened to me on one of my old 10series controls. The problem was there was a bad area of memory; well that is how it was explained to me. It typically happened when I was trying to reload the entire control with the programs all at one time (1 file). If I split it up it would work.

I know the meters to byte affiliation and have installed more memory on these controls. My experience with increasing memory thru bit change only has been once the memory (bit) has exceeded the hardware/chips in the control it will show 0 memory on the control. Based on that I don’t think that the memory is exceeding the hardware……my disclaimer however is I have been wrong many times in the past.

Now as I was suggesting there is a very simple way to test this theory. You can just simply split the program and load it as 2 separate programs. I would probably take the beginning part of the program that loads good and load that twice and if it works load it a 3rd time. This will prove quite easily if it is a memory size issue.

I do agree that he should post some code though. I stated 10 lines before and after as I think the Oseies can only take 10 lines in the buffer.

Stevo

Problem identified

Identified, not solved....but at least the way ahead is clear.

Sorry it's been a while but I am in no doubt now that the memory limits/meters are the issue here. After I cleared out all progs from the control I tried to upload a 200 line prog (OK), then tried to upload the same prog again (as prog O0002) and it failed about 1/3 in, confirming my initial thoughts about the memory limits being hit at around 250 lines of code. I have experimented with some smaller progs but it all adds up to about 250 lines capacity, how ever you configure your uploads. Just to confirm also that these lines are bare bones with no line numbers in them.

My Mill is a Denford-made one and I found an identical problem from another sufferer on the forum there (here it is Denford Software & Machines • View topic - Triac Fanuc OM-B Memory Upgrade)

I am now looking at getting some memory chips.
BTW, no 900 params on my early control (OM-A?) so enabling more memory (if indeed there) isn't an option for me. Hope this info helps any other OM users in the future.

Thanks for the update. Check your PM box.

Stevo