NodeBuilder® Development Tool ReadMe File
Release 3.13A, April 2006
Copyright
© 1998 – 2006
Echelon Corporation
All Rights Reserved
This file contains important information not included in the NodeBuilder User's Guide, the Neuron® C documentation, or the NodeBuilder help file. Additional information and updates, including critical updates, may be available in Echelon’s Downloads Web page at www.echelon.com/downloads. See Echelon’s Knowledge Base at www.echelon.com/support for answers to frequently asked questions.
This file covers NodeBuilder 3.13A, which is created by applying NodeBuilder 3.1 Service Pack 3A to NodeBuilder 3.1. This service pack supersedes the NodeBuilder 3.1 Service Pack 1, Service Pack 1 Patch 1, Service Pack 2 and Service Pack 3 installations, as it installs all of the fixes in those installations in addition to the new Service Pack 3A fixes. It will automatically remove NodeBuilder 3.1 Service Pack 2 or NodeBuilder 3.1 Service Pack 3, if either is already installed on the target computer (Service Pack 1 Patch 1 was a manual installation, and does not require removal). See Release Identification for details on how to identify the release of the NodeBuilder software you are using. Note that Service Pack 3A is a later build of the Service Pack 3 installation, and has the same Windows Installer title as that installation, “Echelon NodeBuilder 3.10 Service Pack 3”.
This installation will not automatically remove NodeBuilder 3.1, Service Pack 1 due to the misleading message that would result from this action (“If you remove NodeBuilder 3.1, Service Pack 1, NodeBuilder 3.1 will no longer run…”). It is not required to remove SP 1, but it is harmless to do so—the only effect will be to remove the “Add or Remove Programs” entry for SP 1 from the Add or Remove Programs control panel.
This service pack does not install the recently released version 13 LonMark® standard resource files. The version 13 resource files are available at www.lonmark.org—click the Resource Files link and then click the link to the version 13 resource file installer. You can either select the complete installation, or if you choose to select the features installed, be sure to select the optional feature which installs the device development include files.
6 Changes in Service Pack 3A (NodeBuilder 3.13)
7 Changes in Service Pack 3 (NodeBuilder 3.13)
7.1 254 Functional Block Support
7.2 Version 2 Code Wizard Templates
7.2.2 Framework Code and Library
7.2.3 Input Network Variable Processing
7.2.4 Fblock Director Functions
8 Changes in Service Pack 2 (NodeBuilder 3.12)
8.1 RoHS-compliant FT 3120 Smart Transceiver Support
8.2 Neuron Firmware Version 16
8.3 Neuron EEPROM Linkage Improvements
9 Changes in Service Pack 1 (NodeBuilder 3.11)
9.1 CY7C53120L8 and CY7C53150L Neuron Chip Support
9.2 Neuron Firmware Version 15
10 Known Problems and Workarounds
10.2 Resource Editor and Code Wizard Resource Pane
10.5 Standard Program ID Calculator
10.9 LNS Device Plug-in Wizard
10.10 ShortStack® Compatibility
11.1 NodeBuilder Quick-Start Tutorial
11.2.1 Introduction to the Version 2 Code Wizard Template
11.2.2 Updating Existing Applications with the Version 2 Template
11.3 Neuron C Programmer’s Guide
This ReadMe file applies to the NodeBuilder 3.13 Development Tool, which is created by applying NodeBuilder 3.1 Service Pack 3A to NodeBuilder 3.1. You can verify that you have the NodeBuilder 3.13 software and Service Pack 3A installed by opening the Windows Control Panel Add or Remove Programs item. Find the entry for Echelon NodeBuilder 3.10 Service Pack 3, and click the click here for support information link. The version will be 3.13.03 for NodeBuilder 3.1 Service Pack 3A. The About window will continue to report version 3.13.02, which was also reported for NodeBuilder 3.10 Service Pack 3.
You can only install NodeBuilder 3.1 Service Pack 3A on a computer that already has NodeBuilder 3.1 installed. To apply NodeBuilder 3.1 Service Pack 3A to any NodeBuilder release prior to Release 3.1, you must first install a NodeBuilder 3.1 upgrade.
To install Service Pack 3A over any prior version of NodeBuilder 3.1, follow these steps:
NOTE: When installing SP 3A, you will be given the option of installing the Code Wizard version 2 template files. Please read section 10.3 of this file for guidance in deciding whether to install the new templates—there is a compatibility issue in the case of continuing development on NodeBuilder projects originally created with the Version 1 Code Wizard template files.
To remove NodeBuilder 3.1 Service Pack 3A after you have installed it, you must also remove NodeBuilder 3.1. To remove Service Pack 3A, follow these steps:
To use the Version 1 Code Wizard templates after installing the Version 2 Code Wizard templates, follow these steps (reverse steps 3 through 6 to go back to Version 2):
The following problems have been fixed in Service Pack 3A. Numbers in parentheses at the end of the fix descriptions are Echelon's internal problem tracking IDs.
This section lists the changes included in NodeBuilder 3.13.
You can now declare up to 254 functional blocks in Neuron C. You are still limited to 62 network variables—to declare more than 62 functional blocks you must declare the functional blocks without network variables.
The Version 2 NodeBuilder Code Wizard code templates, which are optionally installed by SP 3, provide improved efficiency and reduced memory consumption. Depending on the target hardware and a variety of related circumstances, application code that is derived from the version 2 code templates consume several hundred bytes less memory than applications derived from version 1 code wizard templates. The majority of these savings are in application code space, but smaller savings may also be made in the application’s RAM and EEPROM data space requirements. The resulting application will also execute slightly faster.
These savings have been achieved by re-structuring parts of the framework used in Code Wizard generated code, by re-writing some of the functions that are part of this framework, by re-defining some of the data types and storage types used to maintain data within that framework, and by moving some not commonly used functions into a new function library.
This section describes the changes in the version 2 templates.
The implementation of the node object has been streamlined for better performance and reduced memory requirements. The Code Wizard application framework no longer requires a node object director function. However, you can continue to use the node object’s director function if required for your application.
The Code Wizard application framework code in common.nc has been streamlined for better performance. Most functions of that framework have been repackaged into a new Code Wizard library. Available but unused framework functions will no longer be linked to the application as they were in version 1. All Code Wizard library functions are specified in the new CodeWizard.h header file and are contained in the new CodeWizard.lib library file.
The Code Wizard complete source code is available in the LonWorks NodeBuilder\ Code Wizard\LibSrc folder. The Code Wizard library is found in the LonWorks Images folder.
Code for handling input network variable updates for individual functional blocks has been streamlined for better performance and reduced memory requirements. The network variable processor function has been eliminated, and related code has been moved into the when(nv_update_occurs()) task.
The deviceState variable has also been removed; the updated application framework uses built-in Neuron C variables instead.
The default implementation of director functions for the individual modules has been updated. Commands that do not relate to LONMARK requests received through the nviRequest input network variable can now be processed quicker, allowing for an overall performance increase at reduced memory consumption.
The application framework uses two variables to maintain and store the persistent and the non-persistent state of each functional block in the device—PersistentFblockStatus and fblockData. Data type and default storage attributes of these variables have been streamlined for reduced memory consumption and improved performance.
The comment to the when(wink) task has been improved.
The clearFblockStatus()function has been updated. This function previously incorrectly preserved the failed_self_test flag. It now correctly preserves the fblock state information and the in_alarm flag, but no longer preserves the self-test failure detail.
The RQ_CLEAR_STATUS request is now fully supported by the default application framework, and no additional code is required.
The write() function used by the FTP server code now uses the eeprom_memcpy() function instead of the memcpy() function to provide compatibility with EEPROM memory.
The following problems have been fixed in NodeBuilder 3.13. Numbers in parentheses at the end of the fix descriptions are Echelon's internal problem tracking IDs.
This section lists the changes included in NodeBuilder 3.12.
Support has been added for the Restriction of Hazardous Substances (RoHS) compliant FT 3120-E4S40 (14212R-500) and FT 3120-E4P40 (14222R-800) Smart Transceivers. The firmware image in these chips is updated to version 16 as compared to version 13 in the non-RoHS compliant FT 3120 Smart Transceivers (14211-500 and 14221-800). The new RoHS compliant chips can be identified by the additional marking (described in the table below) as compared to the marking on non-RoHS-compliant chips.
|
Chip |
Change in Markings |
|
14212R-500 |
"CAT=E4" added to mark |
|
14222R-800 |
"CAT=E4" added to mark |
|
14230R-450 |
"CAT=E4" added to mark |
|
14240R |
Encircled "E3" added to mark |
To use one of these new chips, create or edit a NodeBuilder hardware template. You must select “FT 3120-E4 V16” in the Neuron Chip Model field in the NodeBuilder Hardware Template Properties dialog.
Based on customer feedback, the mix of Neuron firmware functions that are contained on-chip for the RoHS-compliant FT 3120 chips has changed from the mix in previous FT 3120 versions. Some of the firmware functions have been moved out of the on-chip Neuron firmware image to the general library and some new library functions have been moved from the general library to the on-chip Neuron firmware image.
The following library functions have been moved out of the on-chip Neuron firmware image from version 13 to version 16: bcd2bin(), bin2bcd(), crc16(), crc8(), io_edgelog_preload(), io_in() (Edgelog, Dualslope, Muxbus, Wiegand and Touch I/O models), io_out (Muxbus and Touch I/O models), io_in_request() (Dualslope), touch_bit(), touch_byte(), touch_first(), touch_next(), and touch_reset().
The following is the list of library functions that have been added to the on-chip Neuron firmware image for version 16: access_address(), access_nv(), get_nv_type(), msec_delay(), and update_config_data().
Any of the functions may still be used, but functions linked in from the library will consume some of the application code space. If you are using one or more of the removed functions in your current code, rebuilding the image for the new chips will result in more memory consumption. If you run out of memory, refer to the memory management section in the Neuron C Programmer’s Guide and modify your code to use less memory space so that you can rebuild the image.
For a complete list of the library functions supported by every variation of the Neuron 3120 Chip, see the spreadsheet entitled “Availability of Neuron C functions in Different Versions of the Neuron Firmware”, found in the Development Tools category at www.echelon.com/downloads.
An update to the Neuron firmware is included. The new update is version 16. You can use this update with all models of Neuron 3150® Chips and 3150 Smart Transceivers. Version 16 is required for the new RoHS-complaint FT 3120-E4 Smart Transceivers (see RoHS-compliant FT3120 Smart Transceiver Support) and recommended for the 3150 family of chips. Version 16 is now the default version for 3150 Neurons and 3150 Smart Transceivers. There are different versions of the version 16 firmware for different platforms. The appropriate firmware image is automatically selected when you specify the hardware platform in your hardware template.
Version 16 firmware introduces a new addendum to the Neuron read-only data structure. If your application code depends upon accessing a memory location offset from the Neuron read-only data structure, you should examine the read_only_data_struct_3 structure in the <access.h> header file for details. In addition, the read_only_data_struct_2 declaration in the same header file has been corrected in this release, as it showed one too many reserved fields, which could have resulted in an inaccurate offset calculation.
The following problems are fixed in the Version 16 firmware. Numbers in parentheses at the end of the fix descriptions are Echelon's internal problem tracking IDs:
The Neuron models contained within the neuron.xml file have been modified in order to better manage Neuron on-chip EEPROM memory.
In past versions of the neuron.xml Neuron specification file, the Neuron 3150 Chip was assumed to have 512 bytes of on-chip initialized EEPROM available for EEPROM variables, NVs and aliases. Some variants of the chip had more EEPROM space available, but it was not made available to the Neuron C linker. The new XML file makes the following amounts of EEPROM available for the following Neuron variant names. The lower-capacity variant names are renames of pre-existing Neuron types, and the higher-capacity variant names are redefinitions of the same chips to allow the extended EEPROM resources to be fully used.
|
Model Name |
Initialized EEPROM Bytes |
|
FT 3150 512 |
512 |
|
PL 3150 512 |
512 |
|
CY7C53150L 768 |
768 |
|
FT 3150 2K |
2048 |
|
PL 3150 2K |
2048 |
|
CY7C53150L 2K |
2048 |
Neuron C has a class of variable called uninit data for EEPROM variables which need not be written by an applicaiton load or reload. The new XML file makes the following amounts of uninit EEPROM available for the following Neuron variant names:
|
Model Name |
Uninitialized EEPROM Bytes |
|
FT 3150 512 |
2304 |
|
PL 3150 512 |
2304 |
|
CY7C53150 |
2304 |
|
CY7C53150L 768 |
2048 |
|
FT 3150 2K |
768 |
|
PL 3150 2K |
768 |
|
CY7C53150L 2K |
768 |
The following problems have been fixed in NodeBuilder 3.12. Numbers in parentheses at the end of the fix descriptions are Echelon's internal problem tracking IDs.
1. Open Windows Explorer and browse to the LonWorks Images\Ver13 folder where the LonWorks directory is c:\LonWorks by default, but you may have changed that.
2. Rename the “B3120E4.SYM” file to “B3120E4_20MHZ.SYM.”
3. Rename the “B3120E4_10MHZ.SYM” file to “B3120E4.SYM.”
4. Recompile your 3120 based application.
This section lists the changes included in NodeBuilder 3.11.
Support has been added for the CY7C53120L8 and CY7C53150L Neuron Chips from Cypress Semiconductor. These chips are low-power 3.3V Neuron Chips with additional on-chip memory. To use one of these new chips, create or edit a NodeBuilder hardware template and then select CY7C53120L8 or CY7C53150L in Neuron Chip Model in the NodeBuilder Hardware Template Properties dialog.
The Neuron C Compiler now accepts a “20 MHz” string value for the specify_io_clock compiler directive in addition to the values listed in the Neuron C Reference Guide, providing SCI (UART) I/O with these new Neuron Chips running at 20MHz.
New entries have been added to the <nm_model.h> include file corresponding to the new chip models.
The CY7C53150L Neuron Chip contains additional on-chip EEPROM beyond what can be used for application program and eeprom variable use. The area from 0xF300 – 0xFAFF represents a new memory area called the uninitialized data area; the Neuron Linker map file (“.map” extension) will indicate this new area for this Neuron Chip. The actual chip EEPROM memory extends to 0xFBFF, but the area from 0xFB00 to 0xFBFF is used by the Neuron firmware, and is not available to the application program. To use the uninitialized data area from a Neuron C program, write to the area using the eeprom_memcpy() function, and read in the area using pointers, address constants, or any function from the memcpy() family.
New DC33-78, DC33-625, and DC33-1250 channels have been added for use of 3.3V direct-connect 78kbps, 625kbps, and 1.25Mbps transceivers.
An update to the Neuron firmware is included. The new update is version 15. You can use this update with all models of Neuron 3150® Chips and 3150 Smart Transceivers. Version 15 is required for the new CY7C53150L and CY7C53120L8 Neuron Chips (see CY7C53120L8 and CY7C53150L Neuron Chip Support). Version 15 is now the default version. There are different versions of the version 15 firmware for different platforms. There is one version for LonBuilder emulators (nbe3150.*), one version called version 15-2 (sys3150b.*) for Cypress CY7C53150L Neuron Chips, and one version called version 15-0 (sys3150.*) for all other 3150 chips. The appropriate firmware image is automatically selected when you specify the hardware platform in your hardware template.
The version 15 firmware introduces new features to control the programmable LVI available on certain Neuron Chips. At the time of this release, only the Cypress CY7C53150L and CY7C53120L8 Neuron Chips support this feature. To control the LVI settings, use the new cvdd_lvi_enable(), reset_stretch_disable(), and set_lvi() functions in Neuron C. You can only use these new functions with a chip that has a programmable LVI and supports this feature. To use these functions, include the <control.h> header file in your Neuron C application program.
The cvdd_lvi_enable() function enables the CVdd LVI feature. There are no parameters and no return value for this function.
The reset_stretch_disable() function disables reset pulse stretching. There are no parameters and no return value for this function.
The set_lvi() function has the following associated definitions and prototype:
#define LVI_DISABLE 0
#define
LVI_FILTER16 4
#define
LVI_FILTER32 5
#define
LVI_FILTER64 6
#define
LVI_FILTER128 7
void
set_lvi(unsigned filter, unsigned trip_point);
For further information on the programmable LVI feature, please consult the datasheet for the specific Neuron Chip that implements the feature.
The following problems have been fixed in NodeBuilder 3.11. Numbers in parentheses at the end of the fix descriptions are Echelon's internal problem tracking IDs.
This section lists known problems and their workarounds for this release. Numbers in parentheses at the end of the problem/workaround descriptions are Echelon's internal problem tracking IDs.
The icons in the Project pane of the Project Manager may sometimes display the wrong image when you first start the NodeBuilder tool. Workaround: Quit and restart the NodeBuilder tool. All functions will work normally if you choose not to restart the NodeBuilder tool. (21766)
If you select more than 18 files in the project manager and try to edit them, the files are not opened, and no error is generated. Workaround: Select fewer than 18 files to open at a time. (22459)
You cannot specify a non-standard program ID that requires a string of more than 8 characters. For example, you can enter a non-standard 2-byte program ID such as “\x1\x2” since this string contains 6 characters, but you cannot specify a 3-byte (or more) program ID, where none of the bytes are text characters such as “\x1\x2\x3” since this string contains 9 characters. Workaround: Edit the program ID in the NodeBuilder device template file (.NbDt extension). Enter the program ID as hex pairs. For example, to set the program ID to “\x1\x2\x3\x4\x5\x6\x7\x8” enter 0102030405060708 for the Program ID element. This XML file is described in Viewing and Printing NodeBuilder XML Files in Chapter 4 of the NodeBuilder User’s Guide. (28985)
If you change the setting of Boot ID Generation from Automatic to Manual for a device, and then change the Boot ID to a different value, a subsequent build attempt does not perform a rebuild and load if this was the only change made. Workaround: After switching from Automatic to Manual, right-click the device template and then click Clean on the shortcut menu to force a rebuild. (30501)
The resource editor generates enhanced resource files, which are not compatible with tools or devices based on any version of the resource file API prior to version 2.3. This includes all LNS® tools not running on the same computer with the NodeBuilder 3.1 software, or embedded software running on i.Lon 100 version 1 or i.Lon 1000 version 1 Web servers. Workaround: To read the resource files on Windows clients, upgrade the resource file API to version 2.3 by installing a licensed copy of the NodeBuilder 3.1 software, by installing an upgrade to the application that includes the version 2.3 API, or by downloading and installing the version 2.3 API from www.lonmark.org. To read the resource files on non-Windows clients, or on Windows clients that have not been upgraded to the 2.3 API, you can first convert the resource files to an older format using the NodeBuilder Resource Converter Utility. To start the Resource Converter Utility, open your Windows Start menu, point to Programs>Echelon NodeBuilder Software, and then click Resource Converter Utility. The NodeBuilder User’s Guide describes how to use the utility, describes the changes in each format version of the resource files, and describes the required version of the resource file API for each format version.
A “file corrupted” error may be displayed if you attempt to create or edit functional profiles in a resource file set in a Windows offline folder (i.e. folders on a computer other than the computer running the resource editor, which you have identified as an offline folder to Windows). You may also see a Windows “blue screen” when you shut down Windows after editing a resource file set in an offline folder. Workaround: Do not create or edit resource files in offline folders. You can copy resource file sets to and from offline folders, but do all editing in local folders, or in remote online folders. (22113)
You cannot implement inherited optional members of functional profiles (inherited optional configuration properties or inherited optional network variables) by dragging from the Resource pane to the Interface pane. Workaround: To implement an inherited optional member of a functional profile, right-click the Optional NVs or Optional CPs folder in the Interface pane and then click Implement Optional NV or Implement Optional CP on the shortcut menu. (26454)
The resource editor sometimes displays the incorrect string index for a language string. When you add a new network variable or configuration property member to a functional profile and the type of the new member is defined in a different resource file set than the profile, creating a new text string or comment for that profile member may cause the resource editor to display an incorrect index for this new text. Workaround: You can ignore the incorrect display; the correct index is stored in the resource file. (22091)
You cannot change a structure or union network variable or configuration property type to a scalar type. Workaround: Delete the structure or union type and create a new scalar type. (28097)
If you change a type that is referenced by other types, the override values and display formats of the referring types may become invalid. Workaround: Verify the override values and display formats for any referring types when you change a type definition. (28148)
You cannot host reports created by the Resource Report Generator on multiple domains. Workaround: If you wish to host resource reports on a Web server, make sure to host all reported resources and the Templates folder on the same domain. (27921, 27904)
The Resource Editor attempts to detect gaps between adjacent bitfields. A gap between two adjacent bitfields b1 and b2, with width w1 and w2 and offset o1 and o2, exists if (o1+w1 != o2) and (o1+w1+w2 <= 8).
Example 1:
typedef struct {
unsigned b1 : 1; // offset 0
unsigned b2 : 1; // offset 3
} example1;
The Resource Editor detects a gap of 2 bits between b1 and b2. It will produce a related warning, and the user can have the gap be tolerated or be closed (o2 will be changed to make the gap disappear).
Example 2:
In some circumstances, the Resource Editor might incorrectly detect gaps between bitfields when there aren't any, or where those gaps exist but cannot be closed. This might be the case when an aggregate type (struct, union) includes another aggregate, where the inner aggregate's last member is a bitfield and the first (outer) member following the inner aggregate also is a bitfield.
typedef struct {
struct {
unsigned b1 : 1; // offset 0
} x;
unsigned b2 : 1; // offset 3;
} example2;
An aggregate forms a fixed compound type, and bitfields within and outside that aggregate cannot share the same byte. The same also applies to aggregates that are organized as arrays and end with a bitfield member; these, too, cannot share the same byte for storage. Workaround: When the Resource Editor incorrectly determines such a gap, make sure to respond to the message indicating you do not wish the gap to be closed by the Resource Editor. If you have requested the gap to be closed already, then you should review and re-adjust the offset values of adjacent bitfields in the type. (28376)
When marking a resource as deleted, the Resource Editor requests confirmation. It is possible to refuse that confirmation (click No to indicate the resource is not to be deleted), and it is possible to set the Don’t Show this Again checkbox at the same time. If this is done, the Resource Editor will no longer allow a resource to be deleted (as it memorizes the previous answer to the confirmation query). Workaround: Close and re-open the Resource Editor if you are using the standalone NodeBuilder Resource Editor, or close and re-open the NodeBuilder project manager if you are using the Code Wizard’s Resource pane. (28603)
No warning is shown when a language string resource is marked as deleted. Workaround: To undelete a language string resource that has been accidentally marked as deleted, but has not yet been purged, set the Show Deleted Items checkbox in the Resource Editor options and remove the tilde character (“~”) from the string. To undelete a string that you have accidentally deleted and purged, edit the language file in the Resource Editor and edit the "Purged Record~" placeholder that will be shown in place of the purged string, entering the lost content of the purged string. (28605)
The Resource Editor might show previously deleted and purged language string resources when editing the language file. Such a previously purged language string will be shown as "Purged Record~," irrespective of the current Resource Editor viewing options. This feature is provided to prevent synchronization problems between multiple language files within the same resource file set. A purged record does not consume space in the resource file, and you may use Resource Editor and simply overwrite the "Purged Record~" placeholder record with a new string in order to re-use the index position in question. Workaround: None. (28556)
When translating a language resource file that contains deleted or previously purged string resources into a language that does not yet have a non-empty string defined at the index position of such deleted or purged record, the Resource Editor will create a default string resource, marked as deleted. This feature assists with keeping multiple language resource files in sync, as it ensures that new strings can be created at the same index position for all available languages. Workaround: None. (28558)
When editing a standard enumeration, the TAB key moves the focus to read-only fields such as the minimum or maximum value fields. Workaround: Press TAB until the focus has reached the desired control, or select that control with the mouse. (28621)
The Resource Editor shows the full location and base name of the currently selected resource file set in a small informational pane above the resource hierarchy. This pane would, for example, display "C:\LonWorks\Types\Standard," when the standard resource file set is selected and installed in the default location. Sometimes, especially when being used with the NodeBuilder Code Wizard, this text display changes color. Workaround: Ignore the color change. Obtain name and location of the currently selected resource file set from the resource hierarchy, if needed. (28266)
The NodeBuilder tool might display most recent application load time and date in the Results pane, showing an entry such as "Device 'Subsystem 1.MyDevice', application last loaded Thursday, April 03, 2003 07:20:01. Application load required." The time and date given in this note are not localized and use Greenwich Mean Time (GMT) instead. The build status manager, that decides whether an application download is required, is not affected by this error. Workaround: Ignore (or manually convert) the GMT-based date and time reference. (28648)
It is not possible to insert a new data member to a structured configuration property or network variable type, if that new member is to be inserted following an existing aggregate member (struct or union), and preceding any other existing member. The Resource Editor does not allow for a new field to be inserted between field_a and field_b in the following example:
typedef struct {
struct {
…
} field_a;
unsigned field_b;
} UCPTxyz;
Workaround: Insert the new field following field_b or preceding field_a, or remove either field_a or field_b, add the new field, and re-add the previously removed field. (28783)
When editing a functional profile that includes member configuration properties that refer to unavailable configuration property types, you cannot directly remove these member configuration properties from the profile. A configuration property type might become unavailable when purging the type after adding it to the profile, or by removing the related resource files from the resource catalog. Workaround: To remove such a configuration property member from the profile, edit the profile, select the property, set its reference to any arbitrary but valid configuration property type, and then remove the property from the profile. Alternatively, correct the symptom by (re-) adding the related resource file to the resource catalog, or by re-defining the configuration property type as needed. (28817)
If you cut or copy an entire resource file set, and then paste it to a folder that already contains another resource file set, the paste operation will sometimes fail. An error message will be shown, reporting the failure. Workaround: Always paste to an empty folder when pasting an entire resource file set. (28894)
When entering a maximum value on the limits tab that applies to a signed quad network variable or configuration property type, or a signed quad field of a network variable or configuration property type, the Resource Editor may enter an endless looping condition if that maximum value exceeds the largest valid value for this type. This largest valid value is 2147483647. The endless loop condition can be recognized by a repeated warning that the value entered is incorrect, and that the Resource Editor would now correct this to the largest possible value. This correction is done incorrectly, so that the same validation and incorrect correction process recurs endlessly. Workaround: Do not enter maximum values for signed quad types in excess of the largest valid maximum value, 2147483647. If the Resource Editor enters this state, end the NodeBuilderResourceEditor.exe process from the Windows task manager (through use of Ctrl-Alt-Del, for example). (29590)
When the NodeBuilder Resource Report Generator generates a
report for network variable or configuration property types, it correctly
reports the scaling factors A, B, and C. However, the report generator
also calculates and reports the resolution, which is the smallest difference
between two values, taking the scaling factors A, B, and C into account.
The correct formula is as follows:
resolution =
A * (10^B), where (10^B) means “10 to the exponent B”
The report generator incorrectly adds value C to the resolution. This error
causes the reported resolution to be incorrect for those network variable or
configuration property types (or members of aggregated types) where the added C
is not zero (C is zero for most property types). Workaround:
Ignore the incorrect resolution value. (29514)
When an aggregate network variable or configuration property type contains members that refer to another network variable type, details of that referred type are shown when the structure or union member is selected. These details include the size of the referred-to network variable type in bytes. The reported size might show an outdated value if the referred-to type has been edited within the same resource editor session. Workaround: The size is shown for information only—you can safely ignore the outdated value. To see the correct size, exit and restart the Resource Editor. (30205)
Some of the application framework utility functions that have become members of the Version 2 Code Wizard templates CodeWizard.lib function library now require new, additional, parameters such as the index to the node object, or the total number of functional blocks implemented. Compiling an existing application with these updated prototypes may fail with “Not enough arguments passed to this function” compilation errors. Workaround: Add any missing parameters using the updated, function prototypes in the CodeWizard.h include file.
If you declare a large number of functional blocks with the NodeBuilder Code Wizard, the LonMaker® tool may report a commissioning failure and the device may appear unresponsive while executing the when(reset) task contained in the <template>.nc file. The executeOnEachFblock() function contained in common.nc services the watchdog timer, but the reset time can increase significantly due to the large number of functional blocks. Workaround: Implement an application-specific and faster reset function for devices that implement a large number of functional blocks.
When implementing a configuration property as a configuration network variable, where the configuration property type is inherited from another network variable that the property applies to, the Code Wizard does not generate the changeable_type keyword in the declaration of that configuration network variable. This causes an incorrect self-documentation string to be generated (a required question-mark character is not inserted). Workaround: Implement the configuration property in a configuration file. Alternatively, you can manually add the missing keyword to the Code Wizard-generated source code. See the NodeBuilder User's Guide for details of manual control of Code Wizard-controlled code segments. (28969)
When using the Neuron Exporter standalone (command-line) tool, NEX.EXE, and when using its --outfolder and --infolder commands, you must make sure these two commands refer to two different directories. Otherwise, the Exporter might fail with “unknown reason, NEX#101”. Workaround: Always use two different folders for --infolder and --outfolder. (28438)
The wrong window may become active when you click OK in the Standard Program ID Calculator. Workaround: Click the NodeBuilder button in the Windows taskbar to switch to the NodeBuilder window. (22388)
If you press CTRL+INSERT, the currently selected text is copied to the Clipboard, but the Overtype mode is also toggled. Similarly, if you press SHIFT+INSERT, the Clipboard is pasted at the current cursor position, but the Overtype mode is toggled again. Workaround: Use CTRL+C and CTRL+V instead of CTRL+INSERT and SHIFT+INSERT. Press INSERT to toggle Overwrite mode if you accidentally press CTRL+INSERT or SHIFT+INSERT. (22353)
If you edit code generated by the Code Wizard, it loses the Code Wizard syntax coloring and changes to the syntax coloring for non-Code Wizard generated code. Workaround: Save the file to restore the correct syntax coloring. (21662)
If a quoted string only contains backslashes, the syntax highlighting after the end quote will not display correctly. The following are examples of incorrect and correct syntax highlighting.
Incorrect: (“\\”);
Correct: (“\\”);
If characters other than backslashes are included within the quotation, the syntax coloring works properly. Workaround: Ignore the syntax coloring. (23736)
The status bar does not correctly reflect overwrite/insert mode. It always indicates overwrite mode. Workaround: None. (28233)
You cannot use a custom system image if it is not stored in the Images folder in your LonWorks® folder (c:\LonWorks\Images by default). Workaround: Always store custom system images in the LonWorks Images folder. (23217)
If compiling a program <name>.nc when the disk is full, if the <name>.bif file (an intermediate file) is created by the compiler prior to the disk full error, the compiler may fail to close the BIF file. Thus, even if additional disk space is made available, subsequent attempts to compile may fail because the existing <name>.bif file may still be open. Workaround: Close the NodeBuilder project manager after the disk full error, and then re-open it. If the problem still exists after closing and re-opening NodeBuilder project manager, restart your computer, and use the Clean command to remove all intermediate files and state information for this source file. (23609)
In Neuron C Version 2 and Neuron C Version 2.1, the declaration of a device-specific configuration property requires that the declaration also be const. With proper casting and use of the #pragma relaxed_casting_on compiler directive, you can modify the configuration property from the application program. However, the use of the const keyword with the declaration causes the configuration property (cp_family) to be put into the read-only value file. The linker may place this value file in non-writeable memory, in which case any attempt to change the memory would not succeed. Workaround: To move the read-only value file to writeable memory, use the #pragma codegen put_read_only_cps_in_data_memory compiler directive. Following is an example: (28170)
#pragma relaxed_casting_on
#pragma codegen put_read_only_cps_in_data_memory
const cp_family cp_info ( device_specific ) SCPTinvrtOut cp1;
device_properties {
cp1
};
void f(void) {
*((SCPTinvrtOut *)&(::cp1)) = 1;
}
You may see a “Fatal Trap 250” error if the stack size of a generated function exceeds 256 bytes. The stack size is determined by the cumulative size of the local data declarations within a function. Workaround: Do not declare large amounts of local data. Following is an example of a local data declaration that exceeds the Neuron stack size limit of 256 bytes: (29551)
#pragma num_alias_table_entries 1
void test() {
unsigned
long x;
for(x = 0;
x<10; x++) {
int localArea[1000];
localArea[x] = 1;
}
}
You may see a “Fatal Trap 35” error, or you may see a warning about an unterminated comment at the end of a file, if a comment ends with two or more backslash characters at the very end of the line, or the end of the file. Also, it is possible that the compiler could miss reading the next line of code altogether in a similar situation. The backslash character is generally used in the C language pre-processor to function as an “escape” character. When the backslash escape character appears at the end of a physical line in an input file, the C language specifies that the newline character be ignored, therefore the next physical line is treated as part of the same input line. The Neuron C compiler erroneously applies this rule at the end of a line-style comment. Workaround: Do not use the backspace character in this situation. Following are examples of problematic use of the backspace character in a line-style comment: (29139, 29529)
//Here is a comment, backslashes at end for “decoration”\\
int x; // This
line of code becomes part of comment!!
////// Here is a comment that causes the
compiler to fail \\\\\\
You can include the changeable_type keyword in the declaration of a configuration network variable that does not inherit its type from a network variable. This combination is not correct. Workaround: When declaring a configuration network variable, only use the changeable_type keyword if the configuration network variable inherits its type from another non-configuration network variable that is also declared with the changeable_type keyword. (28968)
The Neuron C Compiler does not accept a reference to a network variable using its fblock-member name in event expressions such as nv_update_occurs(). Workaround: Instead of writing myFblock::nvoMember, provide the actual network variable programmatic name such as nvo42. (30238)
When using the SPI I/O serial object in slave mode, you must either use pin IO7 as the slave select signal, or set up the system so that the external slave select is disabled. The easiest way to do this is by declaring pin IO7 as an input and grounding it externally. However, you can use pin IO7 as either a bit input I/O object or a bit output I/O object. For bit output, declare the IO7 pin as a bit output object and the slave select feature will automatically be disabled. For the bit input object with slave select disabled you must declare these I/O objects in this order:
IO_7
output bit io_p7_out = 1; // initialize to '1'
IO_7
input bit io_p7_in;
As long as the IO7 output bit is initialized with a 1, the slave select is disabled and IO7 can be used as an input.
When the SPI slave select signal is not used, some SPI master devices will not drive the Clock signal on IO8 when idle. Workaround: Use a pullup or pulldown resistor (based on the expected idle clock state) to avoid spurious clock signals when the SPI master is idle.
If you resize a debugger window (breakpoint list, watch list, etc), sometimes the windows are displayed incorrectly. For example, a split bar may be displayed in the wrong location. Workaround: Maximize or restore the NodeBuilder Project Manager window to redraw the Project Manager window. (21603)
If you undock the watch list window or breakpoint list window and then dock it back at the top of the Project Manager window, you may have difficulty moving its docking position back to the bottom of the window. Workaround: In order to get the window back to its original position at the bottom of the Project Manager window, quit the NodeBuilder Project Manager and use regedit to delete the key HKEY_CURRENT_USER\Software\Lonworks\NodeBuilder\WorkspaceState. (22918)
Warning: Editing the registry should be done using extreme caution. Be careful not to change any other keys.
Occasionally when you start the debugger, you may see the following messages: “Failed to write device memory. Please try again. (DBG #68)” and “An unexpected error occurred. (Proj Tree 1379).” The debug windows do not appear and the Debug menu item on the Project Manager menu are missing. Workaround: Right-click the device that you tried to debug in the Project pane, and then click Stop Debugging on the shortcut menu. Restart the debugger. (23349)
You cannot debug a device that has authentication enabled. Workaround: Disable authentication while debugging a device. To disable authentication, right-click the device in the LonMaker™ drawing, and then click Properties on the shortcut menu. The Device Properties window appears. Click the Advanced Properties tab and then change Enable Authentication to FALSE. (23415)
If you attempt to debug a device while the management mode of the underlying network is OffNet, a "Failed to read device memory. Please try again.[DBG #69]"error message is shown, and the debug session fails to start. Workaround: Set the management mode of the network to OnNet and try again. To do this, open the LonMaker drawing, open the LonMaker menu, click Network Properties, and then click the Onnet/Offnet tab on the resulting Network Properties dialog. (28719)
If you define a structure type and then declare a variable of that type with the same name as the type, as illustrated below, you will not be able to watch the variable in the debugger watch list.
struct date {
int month;
int day;
int year;
} date;
Workaround: Give the variable a name that is different from the name of the structure type. (25911)
If you set a breakpoint and then edit the source file containing the breakpoint without stopping the debugger, you may not be able to delete the breakpoint. Workaround: As recommended in the NodeBuilder User’s Guide, stop debugging a device before modifying a source file for the device. (28960)
When single-stepping into an else clause containing one or more data declarations, the debugger will appear to step to the last line of the if clause before stepping into the else clause. This behavior only appears when there are data declarations in the else clause, and can safely be ignored. For example, consider the code fragment shown below:
(1)
if (<condition>
{
(2) <stmt A>;
(3) <stmt B>;
(4) <stmt C>;
(5) } else {
(6) <declaration>;
(7) <stmt D>;
(8) <stmt E>;
(9) }
When single-stepping from line (1), if the <condition> is true, the debugger will step from line (1) to line (2); this is expected and correct behavior. However, if the <condition> is false, the debugger will step from line (1) to line (4), instead of stepping to line (6); this debugger behavior is incorrect, but it does not indicate that the code at line (4) is actually being executed. The single-stepping indicator is incorrect, but the correct code is executed. Another single-step will take the debugger to line (7), the proper line of execution. Again, this erroneous display of the single-step at line (4) instead of line (6) can safely be ignored, and another single-step beyond line (4) will resume showing execution at the correct line. This erroneous display does not indicate a problem with the actual compiled program’s execution. Workaround: Ignore the incorrect display and single-step again, or move the data declarations out of the else clause. (30776)
An "Incomplete data” message is displayed if you enter invalid or too many characters for Product Name on the Identification window. Workaround: Use valid characters for the product name. Use an alphabetic character ('A' through 'Z' or 'a' through 'z') for the first character. Do not use any of the following characters: colon (:), period (.), slash (/), backslash (\), or any type of quote (' or "). Do not exceed 32 characters. (22043)
A "The name has one or more invalid characters (Subsystem: LNS, #87)” message is displayed if you enter invalid or too many characters for any command name in the Command Table window and then try to register the plug-in in the LonMaker tool. Workaround: Use valid characters for the product name. Use an alphabetic character ('A' through 'Z' or 'a' through 'z') for the first character. Do not use any of the following characters: colon (:), period (.), slash (/), backslash (\), or any type of quote (' or "). Do not exceed 32 characters. (22043)
If you start the LNS Device Plug-in Wizard directly from Visual Basic, the Identification window appears. If you then click Back to display the Introduction window before selecting the device template on the Device Template window, the Introduction window will be blank. If you change your device template and then click Back to display the Introduction window, the Introduction window will show the information about the previously selected template. Workaround: Do not go back to the Introduction window. (22915)
When the generated plug-in imports a device template, it uses the name provided in g_commandTable(<index>).DevTemplateName. The device template in the command table may contain a [<model>] suffix if you enabled automatic program ID management for the device template in the NodeBuilder Project Manager. This suffix may be confusing to your users. Workaround: Your plug-in will work with the suffix in the name. If you would like to remove the suffix, locate the FillCommandTable function in the modFramework module and for each command, strip out the suffix. (23279)
For example, if this is the original table:
Public Sub FillCommandTable()
' The table must go from 0 to g_NumCommandsInTable-1
g_CommandTable(0).objectClassId = lcaClassIdLonMarkObject
g_CommandTable(0).commandId = lcaCommandConnect
g_CommandTable(0).Name = "Connect"
g_CommandTable(0).description = ""
g_CommandTable(0).defaultAppFlag = False
g_CommandTable(0).Scope = lcaScopeDevice
g_CommandTable(0).programId = "9000000000000004"
g_CommandTable(0).DevTemplateName = "NcTest [04]"
g_CommandTable(1).objectClassId = lcaClassIdAppDevice
g_CommandTable(1).commandId = lcaCommandCalibrate
g_CommandTable(1).Name = "Calibrate"
g_CommandTable(1).description = ""
g_CommandTable(1).defaultAppFlag = False
g_CommandTable(1).Scope = lcaScopeDevice
g_CommandTable(1).programId = "9000000000000004"
g_CommandTable(1).DevTemplateName = "NcTest [04]"
End Sub
Replace it with the following:
Public Sub FillCommandTable()
' The table must go from 0 to g_NumCommandsInTable-1
g_CommandTable(0).objectClassId = lcaClassIdLonMarkObject
g_CommandTable(0).commandId = lcaCommandConnect
g_CommandTable(0).Name = "Connect"
g_CommandTable(0).description = ""
g_CommandTable(0).defaultAppFlag = False
g_CommandTable(0).Scope = lcaScopeDevice
g_CommandTable(0).programId = "9000000000000004"
g_CommandTable(0).DevTemplateName = "NcTest"
g_CommandTable(1).objectClassId = lcaClassIdAppDevice
g_CommandTable(1).commandId = lcaCommandCalibrate
g_CommandTable(1).Name = "Calibrate"
g_CommandTable(1).description = ""
g_CommandTable(1).defaultAppFlag = False
g_CommandTable(1).Scope = lcaScopeDevice
g_CommandTable(1).programId = "9000000000000004"
g_CommandTable(1).DevTemplateName = "NcTest"
End Sub
If you restore a project containing a Plug-in Wizard-generated plug-in project on a computer other than the one you used to create the project, you cannot re-open the restored project from the NodeBuilder project manager. Workaround: To re-open the plug-in project, start Microsoft Visual Basic and then open the project directly from the Visual Basic Open Existing Project dialog. To start the Plug-In Wizard, start the tool from the Visual Basic Add-Ins menu. (27477)
The generated plug-in will not restart monitoring after an initial device failure. When the plug-in starts up, the fMain::InitDevice function tests the device and, upon failure, prevents monitoring from being started. Workaround: If you need monitoring to work after a device failure, insert calls to fMain::EnableMonitor(true) as needed. (27416)
The generated plug-in does not disable the monitoring menu when the device cannot be monitored. A device cannot be monitored if the device fails testing, or if no network interface is attached. When the plug-in determines that the device cannot be monitored, the Monitoring/Enable menu item remains enabled although clicking that function will not attempt to re-start monitoring. Workaround: If desired, you can add code to disable the Monitoring/Enable command when monitoring is not possible. (27438)
When re-opening a Plug-in Wizard project, the wizard attaches to the LNS network database using the most recently used network interface. The network interface might have been physically removed or disconnected, such as in the case of a PCC-10 or SLTA-10 network interface, or it may have been logically disconnected, as might be the case with some Internet-remote network interface (i.Lon 10, i.Lon 100). If the most recently used network interface is no longer accessible, an error occurs. Workaround: To re-open such a Plug-in Wizard project and network database, follow these steps: Attempt to open the project and accept the error message. You are then presented with the network database hierarchy. Select the desired network, and select a valid network interface from Network Interface, or clear Attached. Confirm your selection by double-clicking the desired network. To change the network interface for an existing Plug-in Wizard project and network database, open the network database with the LonMaker tool, and attach it to the desired network interface. Then, reopen the Plug-in wizard project, following the steps above. (24762)
The Neuron C Example Plug-in, installed into C:\LonWorks\NodeBuilder\Examples by default, may not operate correctly when being used with a LNS network database other than the one contained in the NodeBuilder Neuron C Example. Workaround: When using this plug-in, always restore the NodeBuilder Neuron C Example database, installed into C:\LonWorks\NodeBuilder\Examples\Database by default, using the LonMaker Database Restore command. Alternatively, use the NodeBuilder Plug-In Wizard to generate your own plug-in software, even for the NodeBuilder Neuron C Example device. Plug-in software that is newly generated by the NodeBuilder Plug-in Wizard does not suffer from this limitation; plug-ins produced in that way will function correctly. (28950)
If you install Release 2 of the ShortStack Developer’s Kit after installing the NodeBuilder 3.1 or 3.11 Development Tool, the NodeBuilder tool will no longer operate correctly. Workaround: If you install the ShortStack software after the NodeBuilder 3.1 or 3.11 software, reinstall the NodeBuilder software by first installing the NodeBuilder 3.1 software from the NodeBuilder 3.1 CD, and then reapply NodeBuilder 3.1 Service Pack 3. ShortStack 2 Service Pack 3 does not affect the NodeBuilder software and can be installed before or after the NodeBuilder software. (30942)
If you create a Neuron C model file using the Code Wizard Version 2 templates, you will see the following error when you run the ShortStack wizard:
Error: yourModelFile.NC 40( 20):
Cannot open include file: ‘CODEWIZARD.H’ [NCC#297]
1 error(s), 0 warning(s)
The Code Wizard Version 2 templates are included with NodeBuilder 3.11 Patch 1 and with NodeBuilder 3.1 Service Pack 3. Workaround: Manually specify the location of the CodeWizard.h file (C:\LonWorks\NodeBuilder\CodeWizard\Include by default) in the Include Search Path box of the ShortStack Wizard’s Neuron C Compiler Preferences page. (40155)
The FullShot screen capture application may interfere with correct operation of the NodeBuilder tool. Workaround: If you have problems running FullShot with the NodeBuilder tool, quit FullShot before using the NodeBuilder tool. (22295)
If you right-click a functional block or device shape in a LonMaker drawing and then click Edit Source on the shortcut menu, the NodeBuilder tool may display an error stating that the device template is not part of the project. Workaround: Click OK and ignore the error. (28281)
If you use the LonMaker Browser to monitor a device at the same time that you add or remove a network variable on the device, and you then rebuild and reload the device, the browser may start reporting a Data Server #200 error on one or more of the network variables on the device. Workaround: Quit and restart all LNS applications including the LonMaker tool, LonMaker Browser, and the NodeBuilder Development Tool. (22555)
If you use the LonMaker tool, the LonMaker Browser, or any other LNS application to monitor a device, and you then add new user resources to the resource catalog, and you then load a new application to the device that references the new resources, you may see Data Server errors due to the new resources not being available in the data server cache. Workaround: Quit and restart all LNS applications including the LonMaker tool, LonMaker Browser, and the NodeBuilder Development Tool. (23278)
If you override the minimum and maximum ranges of a user network variable or configuration property type (UNVT or UCPT) in a user functional profile using the resource editor, the override is not recognized by the LonMaker tool, the LonMaker Browser; or any other LNS applications. This means that when updating the value of a variable based on a UNVT or UCPT in an instance of the functional block using LNS tools, range checking is based on the range of the original data type, not the instance in the functional block. Workaround: None. (23331, 23352, 13959)
You may see an application-not-responding error if you have any pre-launch plug-ins running when you shut down Windows. The NodeBuilder Project Manager, LonMaker Browser, and LonPoint plug-in are all pre-launch plug-ins which means that they have a component that is running whenever the LonMaker tool is running, even if you have not started the plug-in. Other plug-ins may identify themselves as pre-launch plug-ins. Workaround: You can safely ignore the Windows error and allow Windows to terminate the LonMaker software. Any changes that you have made are saved before this error message is displayed, so you will not lose any updates. You can prevent the error from occurring by exiting the LonMaker tool and any other LNS applications before shutting down Windows. (23314)
If you change the device template for a device that previously did not have any network variables or functional blocks to a device template that does have network variables or functional blocks, the LonMaker tool does not correctly reflect the new device template. Workaround: Delete the device and add it again.
If you use a functional profile from the Echelon resource file set, you may get errors when you build your device template. Workaround: Do not use functional profiles from the Echelon resource file set. (23463)
To change the type of a changeable-type network variable, follow the procedure outlined in the NodeBuilder User’s Guide. When you use the LonMaker Browser to initiate the type change to a network variable that also has inheriting configuration properties associated with it, the tool might display data using inconsistent formatting rules. Workaround: Click Refresh All on the browser toolbar to force an update. (28474)
A device may implement multiple changeable-type network variables that share the same SCPTnvType configuration property, thus enforcing all these network variables to have the same, changeable type. LNS applications such as the LonMaker Browser may not reflect the type change for all network variables sharing the same SCPTnvType configuration properties. Workaround: Perform the same type change to all network variables that share a SCPTnvType network variable. This recommendation applies to type changes being initiated through the LonMaker Browser as well as to changes initiated via your LNS device plug-in. (28857)
If you create a custom hardware template for a Neuron 3150 Chip or Smart Transceiver that has flash memory starting at address 0000, the NodeBuilder Hardware Template Properties dialog will let you specify an end address for Flash that is less than 55FF; however, the Neuron firmware requires access to location 0x55FF. Workaround: Ensure that location 0x55FF is included in the address space for a flash memory. (29354)
If you remove the NodeBuilder software from your computer, and you have previously installed the NodeBuilder 3 software (even if you subsequently upgraded to NodeBuilder 3.1), you may find that NodeBuilder.exe, ReadMe.htm, and menu shortcuts do not get automatically uninstalled. Workaround: Manually remove these files and shortcuts after the uninstall. (29111)
The link to the NodeBuilder User's Guide does not work in the Quick-Start Tutorial. Workaround: Use the link in the Echelon NodeBuilder Software program folder instead. (23423)
Add the following new feature to the list of new features starting on page 2-2 (27799):
Code Wizard Static Configuration Property Support Enhancement
The code wizard has been enhanced to produce more efficient code when you apply a configuration network variable array to a functional block array and set the Static Configuration Property checkbox. For example, using the NodeBuilder 3 tool, if you applied a cpValue2 array with four members to a functional block, the code wizard generated the following code:
network input cp UCPTmyCP1 cpValue2[4];
...
fb_properties {
static cpValue2[0],
};
This code only shares the first element of the cpValue2 array among all members of the functional block array. The NodeBuilder 3.1 code wizard now generates the following code:
network input cp UCPTmyCP1 cpValue2[4];
...
fb_properties {
static cpValue2
};
This code shares the entire configuration property array as a single property among all the function blocks in the array.
Add the following statement to step 6 of Using a Changeable-Type Network Variable, on page 6-30 (28983):
“You can use the get_current_nv_length() function to determine the current length of a given network variable. This function works for both methods of changing the network variable size. See the Neuron C Reference Guide for more details.”
To see a listing of the default firmware version for each type of Neuron Chip or Smart Transceiver, see the Firmware Version Numbers … link at www.echelon.com/nodebuilder. (28435)
Add the following sections to Chapter 6:
When the NodeBuilder Code Wizard generates code for a new device, it constructs this code based on code template files. Subsequent invocations of the Code Wizard on an existing implementation will cause the generated code to be updated, but not to be re-generated from the templates.
Adding a new module (functional block or array of functional blocks) to the interface of the device causes the Code Wizard to generate code from the code templates for the new module, but not for the previously existing modules.
Removing one or more files generated by the Code Wizard also causes these files to be re-generated from the code templates.
Thus, the code templates play an important role whenever source code is generated the first time. The code templates don’t normally play an important role during the ongoing development of the device.
The following code templates are stored in the LonWorks NodeBuilder\Templates\CodeWizard folder:
root.nct, root.ht These templates control the generation of the main source and main header files.
mod1.nct, mod1.ht These templates control the generation of source and header files for the individual modules (fblocks).
filesys.ht This template controls the generation of the filesys.h header file, which is required for the file system and file directory definition used with configuration properties that are stored in files.
filesys.nct, filexfer.ht, filexfer.nct These templates control the generation of source and header files for the implementation of the file transfer protocol.
common.ht, common.nct, CodeWizard.ht These templates control the generation of source and header files for the utility functions used in the implementation of all the above.
*.txt files Used to insert file headers into the generated code.
Existing applications built with the Version 1 Code Wizard templates will not automatically benefit from the new templates. To use the new templates with an application created from the version 1 templates, create a new device in Code Wizard re-modeling the exiting device, and then manually transfer your application code from the old application into the new application.
Add the following explanation to the Overview in Chapter 1 (26900):
There are several versions of Neuron C. Neuron C version 2 was a major enhancement to the language that greatly simplified the development of devices that use functional blocks and configuration properties. Prior to version 2, developers had to manually construct self-documentation strings for each device, network variable, and configuration property. This was a time-consuming and error-prone process. Starting with Neuron C version 2, the Neuron C compiler provides the option to automatically create and manage these strings. If any of the following Neuron C keywords appear in an application, the Neuron C compiler will automatically generate and manage the self-documentation strings: fblock, fb_properties, nv_properties, device_properties, cp, and cp_family. You can still manually create the self-documentation strings by avoiding the use of any of these keywords and declaring the self-documentation strings using the Neuron C version 1 syntax. This may be useful for migrating applications created with the NodeBuilder 1.5 or LonBuilder tools to the NodeBuilder 3.1 Development Tool. Applications that do not use these keywords still get the benefit of access to resource definitions contained within resource files.
The following example on page 4-17 is incorrect (28970):
network output SNVT_count nvc[2] = {100, 100}
nv_properties { nvcp[2] = 60 };
The example should be changed to the following(changed variable name shown in bold):
network output SNVT_count nvoC[2] =
{100, 100}
nv_properties { nvcp[2] = 60 };
The documentation for the #pragma run_unconfigured compiler directive contains an incorrect statement. The Neuron C Reference Guide states “This pragma causes the application to run regardless of the device state, as long as the device is not applicationless. This means that even if the device is unconfigured or hard-offline, the application will run.” Change the statement to the following: “This pragma causes the application to run any time it is online, even if the device is in the unconfigured state. Without this directive, the application will only run if the device is both configured and online.” (28789)
The msec_delay() firmware function requires firmware version 14 or newer. It is not available on the LTM-10A platform. (30774)
The the io_out() function description on page 3-53 states that the io_out() function returns nothing (void). In the case of an i2c I/O object, the statement is not correct. The io_out() function for an i2c I/O object returns a boolean value, as documented on pages 8-16 and 8-17. (29294)
The following information clarifies the description of the SPI I/O model, and supersedes any documentation in the Neuron C Reference Guide that conflicts with the following: (30392)
Add the following to the documentation for the master|slave modifier of the SPI serial I/O object:
master|slave Determines whether the hardware is in master or slave mode, which affects the meaning of the other parameters as described below.
When using the SPI in master mode, no other masters can be used on the same bus.
Add the following to the documentation for the select(IO_7) modifier of the SPI serial I/O object:
select(IO_7) Set this option to have pin IO7 used as a slave select signal in slave mode. In slave mode, this option is used when there are multiple slaves connected to a master; however, when the device is the only slave and there is no need for the master to use a dedicated slave select (~SS) signal, then pin IO7 should be separately declared as an input pin and externally grounded , or declared as an output. To use IO7 as a regular input bit pin when a slave select (~SS) signal is not used, you must declare the IO7 I/O objects in the following order:
IO_7 output bit io_p7_out =
1; // initialize to '1'
IO_7
input bit io_p7_in;
As long as the IO7 output bit is initialized with a 1, the slave select is disabled and IO7 can be used as an input. In master mode, the select keyword is not used; thus IO7 can be used for other purposes.
Add the following to the documentation for the invert modifier of the SPI serial I/O object:
invert The default clock signal idle value is 1. Set the invert option for a default idle value of 0. This definition relates directly to the clock polarity (CPOL) parameter defined in other common SPI implementations, thus using the invert modifier equates to defining CPOL = 0; otherwise, the default declaration equates to defining CPOL = 1. Both the SPI master and the SPI slave must use the same clock polarity. See the related Neuron Chip or Smart Transceiver Data Book for more details.
Add the following to the documentation for the clockedge(+|-) modifier of the SPI serial I/O object:
clockedge(+|-) As in other SPI implementations, the clock phase (CPHA) needs to be identically specified for both the SPI master and SPI slave devices. Use the clockedge(+) modifier for in-phase interfaces (CPHA=1), and clockedge(-) otherwise. In-phase interfaces work by presenting the data bit on the first transition of the clock signal and latching it on the second transition. Out-of-phase interfaces present the data bit before the first transition of the clock signal and latch it on the first transition. The clockedge(+) is the default value if this modifier is not specified.
Add the following to the documentation for the SPI Serial I/O object:
You can call the io_set_clock( ) function as shown below to change the clock divisor and clock edge at run-time. You cannot change the master/slave or Neurowire/SPI modes at run-time.
io_set_clock(io-object-name,
clock-value, clockedge(clock-code));
io_set_clock(io-object-name, clock-value, clockedge(clock-code),
invert);
The clock-value is an integer from 0 to 7 and corresponds to the const-expr as described in the clock(const-expr) parameter. For devices using the SPI in slave mode, the clock-value should be 0. The clock-code value can either be a single plus character (“+”) or a single minus character (“–“), as described under the clockedge parameter.
You can use the io_set_clock(spi-object, ...) function for either master or slave mode in order to reset SPI hardware. For example, when SPI slave mode is used without the slave select signal, there might be a partial data frame clocked into the SPI hardware. The use of the io_set_clock(spi-object, ...) function clears this condition.
The LTM-10 Motherboard Schematic in Figure 2.2 has been re-sized to fit the page and as a result is difficult to read. You can get a full-sized schematic at the LTM-10 Motherboard Schematic link at www.echelon.com/nodebuilder. (28874)
The documentation of the GizmoReadTemperature() function states that the data returned is compatible with SNVT_temp. In fact, the function returns data that is compatible with SNVT_temp_p. (23680)