​​Netlinx Studio – Diagnostics​​

Diagnostics respects the debug level set from code.  Enable under Diagnostics, Notification Options or status bar.

Diagnostics is used to see system and program generated messages such as:

• IP_Client or IP_SERVER Online, Offline, OnError
• AMX_LOG messages and SEND_STRING 0
• FILE operations errors
• Timeline errors etc.​
  

Netlinx Studio – Notifications​

Notifications is used to see Strings, Commands, Channels, Levels, and Customer Events from devices.  You can edit what you see from Netlinx Device.  PORT 0 can be used to see information from all ports on a device or enter a port range.  Notifications must use the real system for your system.   You can choose types of notifications to show by checking/unchecking boxes next to the message type.  Enable Under Diagnostics, Notification Options, or status bar.

Netlinx Studio – Preferences

Under Diagnostics and Notifications Output Displays, it is suggested to be changed to 99.  This keeps Diagnostics or Notifications from building a bunch of messages. It lets you see messages as the come in.

Under Display As…You are able to change how messages are displayed in Diagnostics and Notifications.  If RS232 strings are coming in or being sent out with a mix of printable and non-printable characters, you can choose to display the output as all HEX which might make it easier to read.​

Netlinx Studio – Control a Device

When using Control a Device, the system number needs to be your real system number however 0 can't be used.  If you do not know your system number refer to the online tree.  If the String Expressions box is unchecked, Control a Device will only send out ASCII.  Checking the box requires the use of double and single quotes, just like Netlinx code.  You will not see a String To in notifications when using Control a Device, only a String From if the device replies.​

Netlinx Studio – Emulate a Device

Emulate a Device is used to simulate functions in the processor to make the processor think something has happened when it really has not.  When using Emulate a Device, the system number cannot be 0.  If the String Expressions box is unchecked, Emulate a Device will only send out ASCII. Checking the box requires the use of double and single quotes, just like Netlinx code.​

AMX_LOG, Alternate to SEND_STRING 0

To use SEND_STRING 0 is not ideal. We have been made aware that every SEND_STRING 0 gets written to the audit log that resides on the micro-SD card.  Therefore, every SEND_STRING 0 causes a write to the disk and could possibly shorten the life of the micro-SD card. AMX_LOG does not het written to the audit log and does not cause a write to disk.​

AMX_LOG(CONSTANT INTEGER LEVEL, CHAR MEASSAGE[])

The four valid log levels are:

• AMX_ERROR = 1
• Lowest level, will show up regardless of logging level set from code.
• Will act just like a SEND_STRING 0
• AMX_WARNING = 2
• AMX_INFO = 3
• AMX_DEBUG = 4
• Example: (These are equivalent and will act the same.)

SEND_STRING 0, "'ERROR: BUTTON ',ITOA(BUTTON.INPUT.CHANNEL),

            ' WAS PRESSED ON DEVICE ',ITOA(BUTTON.INPUT.DEVICE.NUMBER),

            ':',ITOA(BUTTON.INPUT.DEVICE.PORT)“

AMX_LOG(AMX_ERROR,"'ERROR: BUTTON ',ITOA(BUTTON.INPUT.CHANNEL),

            ' WAS PRESSED ON DEVICE ',ITOA(BUTTON.INPUT.DEVICE.NUMBER),

            ':',ITOA(BUTTON.INPUT.DEVICE.PORT)")

• You get one more character with AMX_LOG, it truncates to a length of 255 instead of send_string that truncates to 254

SET_LOG_LEVEL & GET_LOG_LEVEL

Set the logging for code. This overrides what you will see in telnet, diagnostics and usb logging.  Please be careful setting the logging level from code sine it may have the unintended consequence of keeping you from seeing messages you might need to see.​

SET_LOG_LEVEL(CONSTANT INTEGER LEVEL)

The four valid log levels are:

• INTEGER AMX_ERROR =1
• INTEGER AMX_WARNING = 2
• INTEGER AMX_INFO = 3
• INTEGER AMX_DEBUG = 4

It is recommended never using this command.  Know it exists, but in code, only specify AMX_ERROR when using AMX_LOG so the messages in your code will show up regardless of the level.  This will act identical to SEND_STRING 0.

INTEGER GET_LOG_LEVEL()

Retrieves the current log level for the program.

Where the returned value will be one of the for log levels:

• INTEGER AMX_ERROR = 1
• INTEGER AMX_WARNING = 2
• INTEGER AMX_INFO = 3
• ​​​INTEGER AMX_DEBUG = 4​

Telnet – USB Logging

The following are commands for USB Logging:

• USB LOG FRONT ENABLE
• USB LOG FRONT DISABLE
• USB LOG BACK ENABLE
• USB LOG BACK DISABLE

USB logging will receive an error message if the processor does not detect USB media plugged in.  Disable logging before removing the USB media.  If the processor is unresponsive to telnet or SSH, reboot the processor, disable logging, then remove the USB media.  The USB stick mist be formatted Windows FAT32. USB will respect debug levels set from code so be very careful with setting the debug levels.

Look for the phrase LoadConfiguration Complete. This is the first message we receive from the processor in a USB log to say it is starting up. It is easy to count how many times a processor has rebooted, by counting these messages.  You can also look right above the message for the last thing the processor said before rebooting.​

Telnet – MSG ON

You are able to filter the log messages in telnet without changing the logging level from code. This can be completed by typing “msg on" and then logging the level you wish to see. By typing “msg on" it puts the level at “warning".  If you want to see all messages always type “msg on debug".

Setting the logging level for code overrides what you will see in telnet. Diagnostics and usb logging.  Be careful setting the logging level from code since it may have unintended consequence of keeping you from seeing messages you might need to see.​

Telnet – Last 1000 Messages

You are able get the last 1000 diagnostic messages the processor produced via telnet. In telnet, type "show log all". This will list out up to 1000 messages, the oldest message being at the bottom, number 1000. You may have to log this information to a text file in order to capture all the messages depending on how your terminal program buffers information. This log is lost on a reboot.​

Alternative to Writing Files Constantly For Logging

Writing log messages to disk has always been a populat way of storing information to look at in the future  We want to get away from this methodology because of the heavy writing to the micro-SD card to prolong its life.  The recommended way to storing data without effecting the micro-SD card is in a PERSISTENT variable.

Persistent variables are not stored on the micro-SD card they are stored in Nonvolatile RAM.  Their contents are preserved though a power cycle or code load.  They will not survive the backup battery being depleted or removed.

• A brief summary
• Determine a maximum size for your log message. Let's say 64 characters.
• Determine a maximum size for your persistent variable. Let's say 10000 so your CHAR variable would look like cLOG_Messages[10000][64]
• This gives you a max number of messages, 10000/64 = 156 assuming all were 64 bytes in length but they won't be so you'll have a lot more space.​