Are there Lookout .l4p and .lks size limitations?

[skibum019]

I have a process (client/server) with my server running Lookout 5.1 with unlimited I/O. My problem is that I have literally thousands of I/O points and objects in my process, and need to add thousands more. Currently my process takes between 5 and 10 minutes to load, and with the additional objects, it seems to hang trying to load them all. I have this on a rather robust server (multi-processor, large amount of RAM, and a large RAID 10 array for drive space). Are there limitations to Lookout's ability to load large files? The existing .l4p file is about 2.25MB and will at least triple in size once the additional objects are added.

[Khalid]

Hi,

AFAIK, there's no hardcoded limit for a Lookout process filesize. However, it can be reasonably expected that its load time will increase with size.

I strongly recommend you consider breaking up your process into multiple process files -- one (or more) Server process, and the rest Client processes (based on some modular design). This will definitely pay off in the long run. This way, you can also load and unload selected processes using the Loader Object.

Regards,

Khalid

[skibum019]

Khalid,
Thank you for your prompt reply. I also found some other issues that were causing problems. You are correct, splitting out the files improves performance and flexability. The big problem I was having was the amount of data being transferred through an OPC server to Lookout. I developed a way to reduce that data load, and everything improved dramatically.

[Khalid]

Hi,

If you do not mind, can you share with us how you dealt with the OPC data-throughput issue? That may come in handy for many of us.

Thanks in advance!

Khalid

[skibum019]

Actually, I ended up having to reduce the number of data points utilized. The problem was as follows the engineer who designed our PLC network for our latest addition utilized 16-bit word values to transmit ascii characters for product names/lot numbers/etc... At first attempt I had the OPC server transmitting each individual bit and then developed a .cbx to convert the bits to their respective nibbles/bytes/word, and then developed another .cbx to convert the byte values to their ascii character equivalents. Problem being, my I/O went from about 4000 to 40,000 (Considering every single 16-bit word transfer became 16 bit transfers). I decided to create a new object that converted the 16-bit word back to its respective bit masking and then convert
those values to bytes and then to ascii equivalent. Since the bottleneck was the comm. between the OPC Server and Lookout, reducing the number of I/O transferred worked tremendously well.