Smart Cities Are No Longer Optional

[fa icon='calendar'] Oct 31, 2016 11:30:59 AM / by Brittney Borowicz posted in Cisco, General, Intel, Internet of Things, IoT, San Francisco, Siemens, smart cities, Smart City, smart tech, smart technology, tech, technology

[fa icon="comment"] 0 Comments

By Nathan Rockershousen, Technical Writer

The invasion of connectivity has influenced large cities around the globe to embrace the Internet of Things (IoT) as the all-purpose solution for improving the quality of life. As the population of people living in cities continues to grow, the multitude of wasted resources will increase from an already large amount. In order to support the changing infrastructure of city life, smart technology needs to be further implemented in the form of devices and vehicles in order to reduce the consumption of valuable resources such as energy, gas, and water.

Smart technology has barely reached its threshold of possibilities at this point in time. There has only been a handful of European and American cities that have begun to implement new technology. That being said, the success of combining IoT technology with the physical city infrastructure in the few existing smart cities has provided cities stuck in the past with overwhelming evidence of how the lives of citizens can be vastly improved with smart technology. The issue is not in cities not being able to access the technology; there are several industry leading companies such as Cisco, Intel, Siemens, and many more, that are creating smart solutions with innovative technological advancements. It is a matter of cities being willing to take a leap of faith towards a future full of efficient and cost-effective solutions.

The municipalities that have already embraced the IoT have drastically enhanced the quality of city life while reducing spending and easing the pain of city congestion. There are a couple of great examples of how cities in the United States have implemented this technology. San Francisco has begun to integrate sensors into their streets and parking spots to help drivers avoid traffic and find open parking spaces quickly. San Antonio has smart LED streetlights, which can alter their brightness levels in instances of fog or rain to improve the road visibility for drivers. These are among the many innovations that are making cities easier to navigate and live in while improving existing safety standards.

As more cities begin to adopt the features of what has been deemed an IoT revolution, it will be important that there are standards in place. These standards will make the most innovative tech much more synonymous solutions in cities around the globe, which will assist in distinguishing solutions that work from solutions that don’t. Ken Briodagh, writer for the IoT Evolution, describes the need for standards:

“As each city seeks to address its most pressing needs, or move toward the implementation that has the most potential for success, the leaders need to start working together with each other to share knowledge and intelligence about these projects so the successful ones can be replicated and the failures won’t be” (Read more: iotevolutionworld.com).

As IoT technology starts to become a more central part of city infrastructure, standards will begin to develop at a much more successful rate. Converting a city into a smart city will not happen overnight. It is unrealistic to expect the immediate integration of smart technology around the world, but what can be expected is cities seeking solutions in IoT for their specific and pressing needs. As time goes on there will be a global peak in the production of IoT devices; if cities continue to have success in improving the quality of life with smart technology, then the widespread adoption of the smart city is an inevitable, but necessary step in creating a more resource-efficient society.

Read More [fa icon="long-arrow-right"]

PROFIBUS Troubleshooting Tool Demonstration: Messages (14:45)

[fa icon='calendar'] Aug 3, 2016 11:55:14 AM / by Brittney Borowicz posted in General, Grid Connect, messages, Phoenix, Products, PROFIBUS, PROFIBUS/PROFINET, ProfiTrace, Rick Rockershousen, Siemens, Technical Support

[fa icon="comment"] 0 Comments

Another thing that can be done with ProfiTrace is to look at the messages that are being sent on the bus. To access these messages, click on the “Messages” tab that is above the matrix. This will be in line with the live list and statistic tabs that we have previously used. The next think to do is click on “Start message recording,” which means that ProfiTrace is going to start recording the messages that are on the bus. One thing to notice is the blue line advancing across the bottom of the window. This is representative of the memory filling up with the messages that are being recorded. It fills up relatively quickly, so it won’t be long before the blue line reaches the end and it will stop recording messages. The user has the option to set the program to record to the last amount of messages rotating out of the buffer so they can see the latest messages. However, that may not be very useful if the user actually had a problem. This is because the messages that were going on at the time of the problem will be long gone by the time the user looks at the messages tab. For the purpose of this tutorial, click the message recording button again to turn it off.

We advise people to set up what is called a record trigger. There is a button just to the left of the start message recording button we referenced earlier. We can then go to the record trigger button and click on the “Enabled” box in the setup page. After this we can click on “Re-trigger,” which means if this event that we are triggering on happens again, it will record messages again. Then we can say for example, “let’s record 15 messages before the trigger, and 15 messages after the trigger.” This information can be entered on the setup trigger page directly below the enabled and re-trigger options. After all of this information is entered, click on the button on the right side of this menu that says “setup trigger.” In this case, let’s just say when the station goes lost, we want to record. Click “okay” to return to the initial trigger page, then click “okay” once more to return to the main window. Now we can click the start message recording button as we did earlier. This will clear out the buffer as it is waiting for a trigger event to happen.

To show what would happen in that event, we will power off the Phoenix device again. In a matter of seconds there will now be 15 messages before and after the event. The event being the one that is marked in the red text with the word “lost” after the last repeat message. When a device drops off of the bus, there is a bus parameter in PROFIBUS that says how many times the user would like to send a message if a device fails to respond, which is called a retry. Normally, it is defaulted to one, but we usually recommend a number a little bit higher than that. In our version, it is set to five. It really depends on the user’s PLC program, how fast it has to run, and things of that nature. If repeats are set to greater than one, it can help avoid some nuisance problems in PROFIBUS. In this case, it is set to five so the master sent the message five times after the Phoenix dropped off of the bus and on the fifth time the master said “okay you are lost.” The master would then start to send a sync message to that device on the next cycle.

If we were to cause another event, we could turn off the Siemens. If we scroll down in the message file, we can see the sync message from the device in address fifteen that was turned off. The messages are repeated to our Acme device, then the message is sent to the Siemens. There were actually three events in our situation because the Acme device follows the Siemens. In the column labeled “Service,” the user can see that the data exchange going on with the device. In the column labeled “Addr,” the user can see who sent the message and who received it. In this case, there is a message from address 2 (master) to the device in address 36. On the right in the column labeled “Data,” the 6A in hex is the data that was sent. It comes back as a bunch of zeros which is represented with the 36 coming back to the 2. Essentially it shows the write outputs followed by the read inputs all the way down the column. If everything is working fine it would do this over and over again for all five devices. In this case, we have lost one, so now it is sending a sync to that Siemens every time it’s his turn to respond in the cycle. Messages can essentially help the user figure out what is going on within their network.

[embed]https://youtu.be/oulY6e0TvlU?t=14m45s[/embed]

For product information and to purchase, visit http://gridconnect.com/industrial-protocols/profibus.html

Read More [fa icon="long-arrow-right"]

Application Adaptation - Creative Solutions for Customer Specific Applications

[fa icon='calendar'] May 10, 2012 12:00:19 PM / by Jonathan Witthoeft posted in Bluetooth, Custom, FireFly, Flow Control, General, Products, RS-232, Siemens, Technical Support

[fa icon="comment"] 0 Comments

“This product is NOT compatible with your application.” These are the dreaded words that no customer is glad to hear.  Not only were you looking forward to using the device, but now after built anticipation and empty hopes, you are told it will not work.  At Grid Connect  we try to avoid this statement at all costs.  Our technical sales advisory, expert technical support, and vast product versatility give us the tools to make our Bluetooth products work for you.

Recently a customer requested help using our firefly unit with a Siemens DDC.  The only problem was that this DDC required a loop back of hardware flow control pins CTS and RTS.  This is an option normally not supported.

End Device Flow Control Loop-Back

The flow control loop-back is a problem that is normally solved through a custom cable that would be in-between the firefly and the DDC controller.

This was not a possibility for the customer; the firefly needed to be directly plugged into the DDC.  So we tested and came up with a different solution.  We found that jumpering internal pins 6 and 7 of the firefly unit would directly loopback the RTS and CTS pins of the db9.  This is a solution within the firefly and no additional cables would be needed.

Since the jumpers will not fit in a diagonal orientation, we suggest using wire wrapping rather than soldering so not to void our one year warranty.

Content from:

Application Note - Using a Firefly with Siemens DDC Controllers

Read More [fa icon="long-arrow-right"]

Subscribe to Email Updates

Lists by Topic

see all