Product and Solutions Training *Now Virtual*
**All courses are currently only offered virtually.**
The critical component for the success of Lynxspring is the training, support and services we provide to our Lynxspring Technology Solutions Partners (TSPs). TSPs, National Accounts and Original Equipment Manufacturers (OEMs) are confident in the professional services they will receive support from qualified people in a timely manner both before and after the sales process.
Lynxspring University, now offered virtually, is based on a coaching methodology where participants develop skills and competence with new tools and concepts. Lynxspring University programs promote and improve the participant’s skill and comfort level through a diverse set of course offerings. Lynxspring University is a Niagara AX and Niagara 4 Certified Accredited Training Center.
Lynxspring University is located at the following address:
2900 NE Independence Ave
Lees Summit, MO 64064
For those signing up for one of the virtual training courses from now until the end of the year, Lynxspring will extend to you, a FREE 90-day access to our extensive library of Niagara computer-based training modules through our RESOURCES PARTNER PORTAL.
Schedule and Online Registration
Click Here to view our Virtual Training Schedule and Register Online
Lynxspring Onyxx BACnet to Haystack Data Pump
Lynxspring Onyxx Cellular Router
Lynxspring JENEsys Tutorial
Lynxspring Controls Green
Watch Our Channel
Visit our YouTube Channel for more support videos and interviews with the industry leaders.
Hotels Near Lynxspring
These hotels are located within 5 miles of the Lynxspring office.
Hampton Inn (Distance: 2.21 miles, 5 minutes)
1751 NE Douglas Street
Lee's Summit, Missouri, USA, 64086
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Holiday Inn Express (Distance: 2.2 miles, 7 minutes)
1201 NW Innovation Parkway
Lee's Summit, Missouri, USA, 64086
NiagraAX Security Best Practices
Subject: NiagaraAX Security Best Practices
Issue: What are the best practices in NiagraAX security?
Disable the Guest User
A station's UserService is designed so that whenever the built-in user "guest" is enabled, someone attempting to access the station will automatically be signed into the station as the Guest user--whether there is a password set for the Guest user or not. What that person is then capable of doing once inside the station is dependent on what permissions are assigned to user "guest". If the user attempts to do something that the Guest user does not have permissions to do, the user is then prompted to sign in as a different user, who does have the correct permissions.
By default, the "guest" user is disabled. We recommend keeping the "guest" user disabled. Then no one can access the station that wasn't given their own login credentials.
Use Strong Passwords
The stronger the password, the harder it will be for someone to hack into your station. From the property sheet of the UserService, you can configure to require strong passwords for all station users. See the "UserService properties" subsection in the "About Security" section of the NiagaraAX User Guide for more details.
Use the Lock Out Feature
Use the "Lock Out" feature in the UserService, enabled and configured from the service's property sheet. Then if someone is trying to "hack" into the station by constantly retrying different passwords for a user, and the specified number of incorrect login attempts occur in a set time period, that user is "locked out" for the specified time period. See the "Lockout notes" subsection in the "About Security" section of the NiagaraAX User Guide for more details.
Limit User Permissions
Only allow users access to the specific things that they need to do their jobs. This is especially important when it comes to the file system. If you give a user access to the entire file system, you have potentially given that user access to the entire station configuration.
Specifically, the config.bog file, located in the station's root directory, can be a security risk. Security should be configured to limit access permissions of the user to only folders the user is required to access such as px, images, and nav folders. To setup, create a new category using the Category Manager. Using the Category Browser assign only file folders that you need users to access such as file:^px, file:^nav, etc. to the newly created category. Setup the user permissions to only include file permissions of the newly created file category. Keep in mind that by default all objects are assigned to category index 1 (Category1, or whatever the first Category component is named).
You should also be careful about which Services you allow your users access to. Specifically the UserService and CategoryService provide security risks if allowed to be accessed by all users. For more information about the UserService, Users, Categories, and properties/permissions, see the "About Security" section in NiagaraAX Users Guide. Note a subsection "UserService security notes" explains a special permissions scheme for a station's UserService
Notice signal is bouncing on IO
Subject: Notice signal is bouncing on IO
Issue: The problem you are experiencing likely stems from two areas. First is resolution and second is noise. Let's deal with these separately.
Solution: Resolution: What is the nominal resistance of your sensor, and how much does its resistance change per degree F? The resistive mode (including temperature input mode) on the JENE UI is optimized for a 10K thermistor; meaning the JENE reads a voltage divider circuit, with an internal 10K pull-up resistor to 3.3V, and the external sensor to ground. So, nominally a 10K thermistor gives 1.65V @ 25C (77F) to the JENE and that reading is is divided into 4,096 equal steps (12 bits resolution) between 0V and 3.3V. This provides about 5 discrete readings per degree F at 77F, or 0.2F steps between readings it is able to differentiate. That means you'll be able to resolve readings well and they won't bounce much.
If however you use something that has a 1K nominal reading instead, you may be losing a lot of resolution because of that. Even if you use a properly calculated conversion table, at 1K nominal for instance, the 1/X voltage divider relationship may result in only 0.3 discrete readings per degree F, instead of 5 readings per degree F at 10K nominal. In other words, 0.3 readings per degree results in 3 degree F steps between successive readings the JENE is even able to differentiate. This is not a good situation at all, and the reason will be clear when you study the noise factors below.
Noise: An A/D converter has to quantify the analog reading into a digital value. Since the analog reading is never exactly equal to its digitized equivalent, it is expected that the reading may bounce or vary, between the two discrete digital values that most closely approximate the analog reading. This is to be expected. So you'll always have a variation due to quantization approximation regardless of how much you filter it. Now, if you've designed your circuit well there will be a small enough variation due to this that it goes unnoticed (typically 0.2 degrees F on a 10K sensor @ 77F.)
In addition to quantization noise there are other sources of noise (inductive effects between external cables, AC hum superimposed on ground wires that carry equalization currents, capacitive coupling, and RF interference.) Taken together a typical installation may experience additional bouncing, maybe even +/- 2 discrete A/D readings in either direction if several of the installation factors come into play at once.
Coupled together, you can see that if you've lost resolution due to using a sensor with other than 10K nominal value (something horrible like 3 degrees F per discrete reading), and have some installation related noise causing a +/- 2 bits of A/D variation in your readings, taken together (4 x 3 = 12) it is quite possible to get tens of degrees of variation in your readings. Therefore if you aren't easily able to minimize the noise factors in your installation, you still can get reasonably good results simply by using good resolution. Given that same noise, but with good resolution on your sensor, you would get (4 x 0.2 = 0.8F variation) and that is (probably) relatively tolerable whereas 12 degrees F is relatively intolerable.
Installation problems can be subtle. While the NDIO subsystem is extremely precise, all its inputs and outputs are referenced against a common ground at the NDIO board itself. This ground must be treated as a signal reference, and must not be used to complete the path powered, current carrying circuits. I've found that reported noise trouble often stems from disregarding this fact.
For example, analog outputs are often run to actuators whose terminals include a 24VAC hot line, a DC voltage signal wire, and a ground. If this actuator is wired with only a 3-conductor cable, this is an installation error, even though it is commonly done. One customer did this and discovered that if they unplugged these AO circuits their readings stopped bouncing. It's important to understand why.
In this case, the 24VAC current that operates the actuator necessarily will be superimposed on that ground return wire, and so it will also appear as though the DC signal line has some AC on it. The amount of AC on it will by Ohm's law be equal to the resistance of the ground wire multiplied by the actuator current, a non-zero value. (The proper way to wire it would be to run isolated power to the actuator on one pair of wires, and run a second pair of wires for the AO signal output and its ground reference, making the reference ground connect to the power ground terminal at the actuator. This keeps the actuator ground current off the signal reference wire, and in turn keeps the AC off your analog readings.)
Taking this a step further, suppose you mistakenly used a signal reference ground as a power return path, perhaps by using 3 only wires to connect a 3-terminal powered actuator, then wire some thermistor temp sensors out there and also run them back to the NDIO ground terminal using the same piece of wire that is acting as a ground return for the actuator. All of a sudden the measurement that was supposed to be resistive appears to have AC voltage on it (as seen by the NDIO input.) And in turn, you get bouncing inputs galore! And the NDIO is blamed for it...when there was nothing NDIO can do about it because it's only reading the measurement that it was actually given.
Most of the time a bouncing reading is due to superimposed AC on the signal. As the reading is sampled at phases of the AC cycle, the instantaneous DC voltage is higher or lower at that exact moment in time which appears as a bouncing input. This type of installation shortcuts, running power on signal reference grounds, or putting all the sensor lines into a single multiconductor cable is asking for trouble. I've yet to see an NDIO bouncing problem that cannot be resolved by properly wiring the I/O.
Another point that needs discussed. Some customers noted that Tridium NDIO inputs seem to be more sensitive to noise and interference than AI circuits on other brand controllers. In other words, the same wiring mistakes that cause interfering ground currents don't result in the same bouncing input reading with another brand controller that it does on a Tridium NDIO input. This is true, but why? And what can be done?
Early in the design process, it was decided, for good or for bad, that it would be an advantage to design the UI circuit to be able to do resistance, temp measurement, voltage measurement, and high speed counting all with the same physical circuit simply by setting up the input under software control. Therefore, the conditioning circuit on an NDIO input can't have, for example, a large filtering cap that cancels out AC interference that perhaps the competitor's product has, because each input has to be fast enough acting so that it can also do 20Hz pulse metering applications.
It could be that another brand controller that tolerates AC superimposed on its analog readings might not support 20Hz pulse meter reading as well with the same physical input. This is the tradeoff that we made; we figured the customer would rather have the capability to do pulse metering with any of its inputs rather than setting aside some dedicated inputs for this purpose when many customers don't need this function. It was a case of trying to be all things for all customers. Maybe because of that we missed the mark of what the customer really wanted in some applications, which was a heavily filtered, slow-acting input to compensate for a poorly wired, noisy connection.
So, there really isn't anything that can be done or changed to improve the NDIO and still allow it to do 20Hz pulse metering applications. But it perhaps helps to know exactly why nothing is able to be done, instead of wondering or wishing someone would notice the problem and do something.
NDIO's quick response time and high input impedance, or sensitivity to low signal levels, is a benefit (and wired carefully it is) but I see why it causes concern in some installations. As you may know, JAVA processing speed is the limiting factor in our control system loop response times. Sedona provides a drastic speed improvement in this area. Soon we should be able to realize the advantage of that quick response time, and enter into new high speed control applications with the same NDIO modules and circuits we use today.
What type of signals are you measuring with your inputs? Are these inputs all resistive/thermistor, voltage, or a combination of types? Are you using shielded cable? Are you passing the input signals through a multiconductor cable? If they are resistive/thermistor, is the loop isolated from external reference points that could superimpose common mode noise? Knowing that the problem only occurs when the DOs come on could be very helpful. Can you further isolate to a particular output? I suspect the problem is that you are getting AC on your reference ground because of the way the outputs are wired. Have you connected the DOs back to your analog ground (0V) terminal? Or have you connected your outputs to something that is making a continuous circuit back to the analog ground reference terminal? On further review and talking with my installer he used a multi conductor wire. Two wires for a 24 volt valve and two wires to the 10 k sensor. Would this make the sensors bounce up and down in temperature? Absolutely would cause this problem. The 10K sensor is a low current, high impedance signal and the 24VAC valve is a high current device (relatively) and so the capacitive and inductive coupling in a multiconductor cable would cause a lot of superimposed AC on your sensor anytime the valve is energized. This looks like a rapidly changing signal (bouncing) to the sensor input.
Cannot Login through remote WebUI on three different sites
Subject: Cannot Login through remote WebUI on three different sites
Issue: Attempting to access a JENE through a browser. The login in screen would show up, but after the correct credentials were entered, the browser would take me back to the login screen.
Solution: There are two main ports that need to be open to allow browser access to a JENE if you are utilizing PX graphics; the HTTP port (default: port 80) and Fox Service Port (default: port 1911). A browser client that connects to a PX Page utilizes port 80 of a NiagaraAX host running WebUI services (the port is configurable in the station’s WebService properties). Fox protocol communication occurs in a browser context only when you are using ProBuilder in the browser (wbapplet). This web workbench tool handles communication between the host and client using the Fox protocol and port 1911. If you are using the Hx (non-applet) view, then value updates in the browser are made using Hx technology, via HTTP, and not the Fox protocol.
Lynxspring Controls Green balancing with NetSensor
Subject: Lynxspring Controls Green balancing with NetSensor
Issue: How do you utilize the Lynxspring Controls Green NetSensor balancing function?
Solution: Verify what version of net sensor is connected by pressing both the temp and override buttons, the screen should indicate the version (example): 1-F
Note: 1-D works with balancer mode, 1-G and 1-H have problems; there is no firmware upgrade, if this function is required to be performed at the NetSensor only then the device will need to be replaced.
Note: to manually enter the balancing mode, instead of writing to BV8, write to AV8@8 and then RLQ AV8@8 when finished or cold start the device. Once in the balancing mode, any version NetSensor can be used to perform the balancing process.
Sharing Lynxspring Controls (LON) VAV configuration
Subject: Sharing Lynxspring Controls (LON) VAV configuration
Issue: How do you share a configuration file on a Lynxspring Controls Lon controller with the LC Wizards?
Solution: To reuse the configuration from one device to others, do the following:
Copy the device and paste it back to the network and rename the device.
Discover the new device and match it to the device you just created.
Right-click on the device and select “Action/Ping” – wait for the device status to indicate “OK”.
Right-click on the device and select “Action/Download”. This completes the configuration copy of the device.
Re-occurring update in the application director –“rtu partial message”
Subject: Re-occurring update in the application director –“rtu partial message”
Issue: Modbus RTU partial message (possible network issue – adjusted timing in ModbusAsyncNetwork).
Solution: MODBUS MESSAGE FRAMING
There are two serial transmission modes for the MODBUS protocol, ASCII or RTU (Remote Transmission Unit) framing. The instruments use the RTU framing method only. The MODBUS message is placed into a frame that has a known beginning and ending point by the transmitting device. This allows receiving devices to begin at the start of the message, read the address portion and determine which device is addressed, and know when the message is completed. Partial messages can be detected and errors can be set as a result.
JENEs cannot see Supervisor, but the Supervisor can see the JENEs
Subject: JENEs cannot see Supervisor, but the Supervisor can see the JENEs
Issue: The JENEs cannot see the Supervisor by the Supervisor can see the JENEs – Last Failure Cause, “Socket timeout exception”.
Solution: It was found the firewall on Supervisor was blocking 1911. Once the port was opened, the JENEs could see the Supervisor
Slow connection to a JENE
Subject: Slow connection to a JENE
Issue: When connecting to a JENE over HTTP using a browser, a misconfigured DNS entry can cause the JENE to respond very slowly.
Solution: This is because the HTTP daemon is inappropriately trying to resolve the hostname for the client address. The HTTP request will be handled only after the DNS resolution fails. Initiating a thread dump while the HTTP request being handled will show the following entry:
“Http:MainLoop" (ptid 53, runnable)
Previously the work aroud was to correct the JENE’s DNS configuration, which is done using ProBuilder platform connection or through a serial connection.
Subject: CCN Driver
Issue: Unable to change set points or schedules with the Carrier CCN Driver. CCN driver issues resolved in the past by Lynxspring include; not able to write to set points or schedules.
Solution: A Carrier Technician utilizing their proprietary CCN Integration Tool accessed the system and found that an integration point referenced as “OverwriteEnabled” was “false”. The tech changed the value to “true” and the CCN Schedule Tables immediately started accepting values as required. We were informed this point is only viewable and changeable through the proprietary CCN Integration Tool, which can be purchased from Carrier model number 33CNNSTKIT-01 NETWORK SERVICE TOOL VK.
Not able to use LAN2 on JENE
Subject: Not able to use LAN2 on JENE
Issue: Not able to use LAN2 on JENE to access controller with laptop when LAN1 is connected to another network.
Solution: Lan1 is setup for the buildings network but wants to be able to use Lan2 to connect directly to the JENE with a laptop. Enter a non-routable IP address for Lan2 IP setting to allow access. For example one that starts with 192.168. or 10.27
Point goes null after manual command times out.
Subject: Point goes null after manual command times out.
Issue: After manually commanding a point, the value output goes null when command times out.
Solution: The fallback value was not set, it was left at null which is an unknown state so once the point is active then expires, it will return to the fallback value @def, but null does not mean false or true. Suggest deciding what fallback values are needed for each control point and set them.
Access PX graphics on an iPhone or iPad
Subject: Access PX graphics on an iPhone or iPad
Issue: Not able to view the PX graphics on the iPhone or iPad
The Hx Web Profile type is changed in the User’s profile. This is done in the User Service located in your Station under Services. Select the user that is going to be accessing the PX graphic and go into Edit mode. There is a drop down box next to Web Profile type which is where you would select the profile type needed. The most commonly used is Basic Hx or Default Hx. Be sure to test your Px views in the appropriate browser.
Please note that certain graphics, tables or custom graphics might not show, but the Hx profile is just a scaled down PX page.
Tags: iPhone, iPad, PX, HX, User
Cannot log into the JENE thru ProBuilder
Subject: Cannot log into the JENE thru ProBuilder
Issue: Not able to log in either because of a wrong username and/or password or unknown IP address.
Solution: You can put your JENE into Serial Shell Mode and by using HyperTerminal and a RS-232 NULL modem cable you can make Platform changes.
If the username or password is unknown you can reset them back to default.
Default Username: tridium
Default Password: niagara.
You also have the ability to find out the current IP address or make changes to the IP address, Gateway and Subnet Mask.
See link for complete instructions.
Tags: Unknown, Password, Username, IP
Niagara Tech Tip released regarding Java 7 Security Issue
Subject: Niagara Tech Tip released regarding Java 7 Security Issue
It is STRONGLY recommended customers download and install Java 7 Update 11
On Monday, January 14, Oracle issued a Security Alert for CE-2013-0422. This is a response to a US-CERT Alert reporting a vulnerability that affects Java running in web browsers. Details about the Security Alert can be found at this link:
Oracle has issued Java 7 Update 11 to address this vulnerability. Lynxspring strongly recommends customers using Java 7 Update 10 or earlier download and install the patch immediately. This patch can be downloaded from Oracle at this link:
This security alert only affects customers who are using Java 7, including Java Platform Standard Edition 7 (Java SE 7), Java SE Development Kit (JDK 7), and Java SE Runtime Environment (JRE 7), in all versions through Java 7 Update 1.0. The affected Java VM is not included in any products currently offered by Lynxspring or Tridium.
Tridium has issued a Tech Tip on Niagara Central that includes this information:
Do I need to disable Java?
While using Java to access Niagara systems is safe, accessing unknown, untrusted web sites may create risk. If Java is disabled, Niagara’s hx profiles provide a non-Java, but less featured alternative to the Java-based browser interface. Tridium recommends that customers evaluate the risk of enabling Java based on how the affected PC is used. In any case, Tridium recommends that customers download and install Java 7 Update 11. The patch can be found at this link: http://www.oracle.com/technetwork/java/javase/downloads/index.html
Does this affect Niagara?
No, Niagara is not directly affected by this vulnerability. Niagara is indirectly affected when customers use Java in a web browser.
But I thought Niagara used Java?
There are no Niagara products which use the affected Java VM. However, when connecting to Niagara in a browser, Niagara does use the browser Java VM that is already installed on a client PC. That Java VM is typically installed on a PC in the factory by the manufacturer or installed and managed by the IT department responsible for the PC.
What does the update do?
Java 7 Update 11 repairs the vulnerability but also increases Java's security setting to "High" by default. With a High security setting, users will be warned prior to any unsigned applications running in order to prevent silent exploitation.
Initial Alert from US-CERT - http://www.us-cert.gov/cas/techalerts/TA13-010A.html
Vulnerability Note - http://www.kb.cert.org/vuls/id/625617
Oracle Security Alert -http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html
Java SE Downloads -http://www.oracle.com/technetwork/java/javase/downloads/index.html