Need to update Cortex PC ...

[Karam]

Just to put things in perspective I think this might be one of the largest installations coupled with the smallest computing platform . My last information was around 250 modules totalling 1088 individual networked objects and over 1500 serviced objects in all when macros and such included. Like Vivian suggested I think the polling period will probably have little impact -already starting off with a base line of a relatively long few minutes. I am aware that you will potentially have camera handling in the near future and I can tell you that there will definitely be an additional impact from these..

A couple of things you can test: stop the network and check CPU % in this state. It should be pretty near zero but if not might suggest that the 'idle' camera objects in your database are actually not being so idle. To check this you can temporarily delete camera objects in structure view eg. on AUIs and IVC digitiser object (don't save the database after such a deletion!) and see then if the CPU usage drops. Also from this position you can visit the Tools | Network supervisor | Service Tools and Temporarily disable all network nodes. Now hit the network run button and your network will run but without communicating with any physical modules - you can think of it as simulation mode. What is the CPU usage now? You probably need to try with Cortex minimised and expanded to see if any difference in each case as I think you suggested on your set up this has a significant effect.

[chris_j_hunter]

stopping network, dropped CPU usage to a few % ...

running it & then deleting both video windows gave around a 15% reduction ...

deleting both cameras, as well, gave a further 15% reduction ...

meaning it was then running at around 60% ...

so then minimising the Cortex window would presumably have brought it below 50% ...

temporarily disabling network nodes reduced the level to around 60%, or 15%, it seemed to vary, each time, and after a while, and re-enabling it seemed to need several attempts ... not sure why (we kept the network running all-through) ...

NB: we've not yet connected the cameras to the IVC card - so no actual images being processed (video windows are plain blue) ...

[Karam]

As a general comment, deleting objects and disabling/enabling network nodes is better done when the network is stopped. In the latter case if you disable the network nodes whilst the network is running it still leaves all the nodes in an initialised state i.e they will still report signal changes even though these may not then result in any output actions, whereas doing so before network start means they will be left in a 'quiet' state since Cortex de-initialises upon network shutdown (if the nodes are not disabled prior to the shutdown). So I guess disable network nodes might be better described as 'do not send messages to network nodes'.

I think even with no cameras attached elements of the video components will be taking up resources hence my suggesting that you delete the camera objects altogether just to clarify things a bit.

[chris_j_hunter]

interesting - thanks to the the insight gained from doing these experiments, and the subsequent feedback, little by little we're gradually building our mental picture of how it all works - 'though, it has to be said, we live in fear of corrupting out database (it's always a relief when we get back to the saved version) !

NB: we did fully delete the camera objects ...

[Karam]

Yes of course its always a good idea to manually back up files you have laboured on , but also Cortex will make an automatic backup before it saves a database. I suppose this doesn't prevent you from making two successive saves of a 'bad' database.

Although Cortex will prompt you to save a database before exit if it thinks changes have been made, the save must be by a deliberate user action or confirmation (though the backup creation is then automatic). So if you are in doubt about the changes that may have occured during a session then just exit Cortex without saving.

[chris_j_hunter]

Aye, as the investment in the database grows, day by day ...

now & then we rename already-saved databases before saving another, just in-case, because saving relatively often while building the database makes it all too-easy to get into the habit of automatically pressing Enter even when we shouldn't ... plus, sometimes work progresses in a direction that turns-out to be erroneous & we need to back-track ...

[Karam]

One thing to bear in mind is that a particular database file name is linked to historical data files using that name. In other words its ok to change the name of backups but to view the data you will have to change the name back to that which created the data. Hence good idea not to change the name of the active database. If you absolutely need to do that then its not impossible to link it to the history data but a case of manually renaming history data files. If you look at these you will understand how.