Re: Memory Upgrade Options
hello country guy
We can consider that a poor option ...
consider talking with kurmay, the matrix key avatar guy he may be able to deliver your optional spec
i speak for him, because his post does not reveal clearly that he can deliver optional specs, and i know that he just sits and waits
Wish I could find some guys close by to shoot the poop with and have a cold one that I could learn more from
i don't really get it, but i'm in
If it does not work this way ...
you pretty much got it
the controller has a storage capacity and a load capacity
load capacity = what program size can be loaded inside the controller ( program select )
storage capacity = what total file size can exist inside the cnc, spread across available system devices ( may be more than 1 file, and not all of them have to be programs )
the storage capacity :
... can be increased ( that's what you are looking after )
... covers a few system devices : MD1, MD0, FD1, etc
... is not equal with the phisical storage capacity; for example, you may load inside a folder enough files until you fill up the hdd, but, if that folder is a system device, thus if that folder is important for the controller, then the maximum size of that folder is limited, even if there is plenty of space on the hdd
there may be more than a single system device; only one is default
if you don't specify the system device, it is considered MD1
if you wish to pin-point to another system device, use *.sdf files, and simply specify the root ( directory path ) for the system device
when the controller loads a program, it must not have a size bigger then it's load capacity
so, if your program is big, break it into paragraps that have a size smaller then the load capacity
each paragraph will be inside a file, and these files you may spread across the system devices
of course, you may spread as many files as you like, with the condition that those files should not have a total size that is bigger then how much the system device can store
actually, is not ok to fill up the system device, because the controller needs a bit of free space
for example, on osp 300L, i may put inside MD1 cca 2gb ( = storage capacity ), but the program should not be larger then 2mb ( = load capacity ); if i will fill the MD1, then i won't be able to edit my programs anymore, because editing a program requires that program to be opened into an unused portion of the storage space, and if it is filled up, not only that you won't be able to edit, but you may lose the file
on newer controls are options to manage the "load capacity" ( eq : make it equal with the "storage capacity" ), but this is another story, which involves nesting levels, choosing between conditional functions and code linearity, etc
If it does not work this way and is only loading from MD1: in sections I don't see a benefit of scheduling as we are still up against the memory size barrier
of course, if the storage capacity is low, there is no point in scheduling
scheduling on same system device is ok when there is enough storage space / otherwise, useless
and copies it into the buffer in MD1
not quite file content is loaded into a storage space = load capacity size, and from there, it is read by the controller through a buffer
if buffer size = load capacity size, then we talk about a one-shot loading
otherwise, the buffer will keep reading portions of the program, from the storage space, and so on ...
kindly
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg