NX Series - "Don't Use Def_Program" and Modules

ericmedley

So, we're not supposed to use define_program anymore. I haven't used it in years anyway. But, what about modules? I happen to know I'm using several AMX written modules where I also happen to know they do use define_program in the code. What does that mean? and does it also cause issues? I imagine it would.

somekindofpond

My understanding is that simple feedback like, [dvtp,1] = SomeState is still perfectly legal. You are right that a handful of the modules incorporate the older MainLine approach, but I haven't seen it
actually cause any problems.
You will, however, encounter issues if you are changing variables e.g., flash = !flash with the NX series. The SX80 module, for instance, has some feedback that looks to be more or less harmless.
I did change it to a TL just for good measure.

ericmedley

"Legal" yes. But from what the firmware poeple told us at developers conference last summer, it's definitely not a good idea to put stuff there. There are significant performance hits if any code is executed in Def_Prog. As I understand it it has to do with some of the things going on in the Linux side. I've done some of my own testing with my NX 3200 and there is a noticeable difference in overall speed if you put anything in Def_Prog. Not so much for one or two operations. But it quickly degrades the more you add.

As I said, I haven't put anything in Def_Prog in years. But, Modules are black boxes. We have no idea what's going on in them. Perhaps AMX could come up with a little logo to indicate "This Module guaranteed to be Define_Program Free" People like logos, right?

Raphayo

I'm currently updating an old project, and right now i have create a TIMELINE[Feedback] and i drop all define_program stuff in it. All Include file who have stuff in define_program i'm doing the same thing.

tdewild

Copy and paste from: WEBCONSOLE AND PROGRAMMING GUIDE Last Revised: 8/05/2015


Differences in DEFINE_PROGRAM Program Execution Page 12,13,14

An idle application normally runs below 5% of the CPU. If your idle application shows more usage than this, then it is probable that
your application is experiencing excessive execution of the DEFINE_PROGRAM section.

You can use the following diagnostic to diagnose executions of the DEFINE_PROGRAM section:
>superuser 10
>enable interp stats
>show interp stats

-- Mainline Executions due to:
Variable Change : 0

-- Mainline Executions due to:
Variable Change : 50927

-- Mainline Executions due to:
Variable Change : 62295

-- Mainline Executions due to:
Variable Change : 72386

Notice the ?Variable Change? count is increasing rapidly.
These diagnostics will not tell you where in your application the offending code resides. Finding the offending code requires a
process of code analysis and possibly selectively commenting out sections of code to isolate the offender. Note: NetLinx modules
each have a DEFINE_PROGRAM section that must abide by the same rules as the main program, so the offending code could be in a
module.