1

Topic: Maximum Script Size

One of the best features about Nware is the scripting component.

The systems that I am currently working on have very simple audio requirements but very large quantities of GPIO to manage that are very easily taken care of in a script, however there have been many times when I have come up against the maximum script size of 256 x 256.

I expect that this maximum is an arbitrary size.

Usually the script itself is doing something fairly simple, and actually not being called very often. It would be extremely useful if the maximum script size could be increased to 512x512, or better still 1024 x 1024, As trying to implement that same functionality using multiple 256 x 256 scripts is very complicated and probably uses more resources than a single script of that size would anyway.

What about having scripts with a maximum total of 2048 input/output nodes, so you could have 1024x1024, or 2047x1, or 1x2024.....

I would be quite happy if this size of script were only available on Conman, or maybe if a script size over 256x256 was set, then a message box would come up saying 'scripts of this size are better placed on Conman than a Nion'.

How about only allowing scripts of greater than 256x256 in Nware++ mode?

Should be a fairly simle change?

2

Re: Maximum Script Size

Should be doable, but I agree this would be best added as a ConMan feature only.  One thing to consider.  Scripting is nice, but if you can you should use wired logic instead of Python.  In a NION, wired logic is a lot more efficient than scripts.  It is not too hard to bring a NION to it's knees with a poorly written, or complex script, and at this point it can fail in difficult to diagnose ways (we are working on this).  It is very good, however, at handling complicated wired logic.

3

Re: Maximum Script Size

You can also solve the problem a bit more elegantly by using 'front' and 'back' multiplexer/demultiplexer. Check out the code I did for the Crest amplifiers for an example of that.

The idea is to have a concentrator that is a very simple non-threaded script with all the inputs you need, and that script 'digest' it's inputs for the main logic, in another (possibly threaded: it doesn't matter) script block.

4

Re: Maximum Script Size

Michel, I have used your multiplexer/demultiplexer idea on a current very large complicated (for control) project.

By removing traditional individual channels of control and multiplexing as much as possible to fit within the maximum script size, I have reduced the overall file size considerably, speeded up compiliation times considerably and as far as I can tell have increased sytem operational speed considerably.

The only down side is the increase in script complexity having to deal internally with the multiplexing and demultiplexing.

Thanks for the suggestion....  it has worled well