NI700 Problem

Charles Law

Hi all,

I have an NI-700 controller that was working fine, but all a sudden something strange happened.

Program inside this controller stuck if there is one variable (non volatile) defined in the Define Section.

If that variable is removed, the program back to normal.

Thanks for sharing opinion, if any.

Charles Law

Leon ten Brundel

Hi Charles,

You mean, just a clean program with only one variable defined in the define section?

DHawthorne

What is that variable doing? Is it a simple variable, or an array? How big is it? Does the NI-700 run at all when it is defined, or does it not even start up with it defined?

It very much sounds to me like a memory bounds overflow of some sort. Either it is using up too much non-volatile memory, or the data assigned to it is exceeding the memory space allocated. But I would need more details for a more exact opinion.

For a very quick test, Telnet the master and enter the "show mem" command. That will tell you how much non-volatile memory is being used. You may simply not have enough headroom when this variable starts being assigned data.

Charles Law

Hi,


It is just a simple program like this:

Define Device
dvTP=10001:1:0

Define Variable
Char Test[20] //Variable simply for test

Define Event
Button_Event[dvTP,1]
{
Push:
{
Do something like pulse the i/o
}
}

The program working fine after removal of the test Variable.

Charles

LegacyUser

there doesn't appear to be much there to go wrong.

but, to check, browse to the controller and go to the System window. Check the message log.

when i have over used non-volatile ram i have found in this area a notice stating that. and it stated that the program would not load/run.

so sitting around waiting for things to happen was a waste of time, the processor just simply wasn't going to do anything more.

to get around that problem i now prefix all variables with 'volatile' and i've never run out of ram since.

i use a lot of ram, almost deliberately (hey, the customer paid for it, use it), in creating a unified program that works in almost all configurations. that's how i managed to hit the volatile ram limit.

your sample code looks to simple to create this problem though, but do check the System log anyway.