36 wsn-3202

[Kevin_H]

Hey Kolan,

These actually aren't problems.  For the first issue, each variable has an associated timestamp with it.  If you monitoring a variable and want to know if it has stopped updated, it would be best to monitor that timestamp, and have some logic when it has been 'to long' since the last update.  The gateway doesnt actually know if a module has disconnected or not, because you could simply be running a LV WSN VI on the node and programmatically changed the sample interval.  The gateway can not determine if the node is sleeping or if it is actually disconnected.  Monitoring the timestamp would be your best bet.

For the MAX issue, MAX does not automatically refresh.  You need to click refresh in order to see the updated firmware deployment status.  If you watch the activity LED on the gateway, you'll know when the firmware update starts :).  It lights up very rapidly.

Keep me posted!

Kevin

[kolan]

When I've update gateway firmware from 1.0.1f0 to 1.1.0 shared variable return error always but modules are connected and show "Excelent Signal". With 1.1.0f3 modules firmwares the same situation.

LabView 8.6.1, Wsn driver 1.1.0, gateway 9791, modules 3202, windows xp sp3.

Can You give any information on this situation, Kevin?

Thanks!

[kolan]

I'm using LabView 8.6.1 and "Show Timestamp" menu item greyed

I've pressed F5, but process have not been showing for the first time, I don't know why...

Now the main problem is why variable return an error every time.

[Kevin_H · Accepted solution]

Hey Kolan,

If you are using the shared variable structures, the timestamp is not enabled by default.  In your LabVIEW project, you can rightclick the variable and choose properties.  There you should see a checkbox that Enables Timestamp.  At that point, the timestamp will not be greyed out in that menu.

You may also need to redeploy all the variables from the project to eliminate the error you are seeing.  Right click your gateway in the project, and choose Deploy All.  Let me know if that eliminates the error.  Also, if you are still getting an error, please post the error.

On a side note, for a large system like yours, you make want to look into using the PSP Variable VIs.  The variables have a URL with this structure:

ni.var.psp://IP_OF_GATEWAY/Node#/VariableName

For example, if I want to get AI0 for node 10, I can wire this URL into the variable read VI: ni.var.psp://10.0.55.20/Node10/AI0

You can then programmatically build those URLs with strings and read the variable dynamically in a for loop.  Makes it much easier for managing a large system than just dropping variables all over the block diagram.

Kevin

[kolan]

Thanks a lot, Kevin!

"Deploy All" operation helped to avoid constant errors and got a Timestamp.

Sadly that I've not seen PSP Variable in LabView-8.6.1 So as I understand I can not choose node and it's sensor dynamically?

[kolan]

In general, I have adjusted all without PSP Variables, all works, the truth was possible to achieve a stable relation during reboots of the gateway, power failures etc. only with five routers.
Thanks Big, Kevin! Without your help I in a life have not achieved demanded result.

[Nicholas_B]

Hi Kolan,  Very happy to hear that you are up and running!  I am the marketing engineer for NI WSN, and I am curious about your application.  May I ask what you are using the WSN for, and your location or company?

[kolan]

Hi, Nicholas!

The application collects freezers system state information: temperature, supplying, autonomous supplying, power generator etc. It has web-interface, reports and informs the owner through sms.

We are using WSN modules instead of wire communication because of observable objects can be moved.

InSys Ltd, Russia...

With best regards!

Kolan

[kolan]

Hello Kevin,

We are here confronted with a hang-gateway situation.
Partly it was described here http://forums.ni.com/t5/Wireless-Sensor-Networks/wsn-gateway-9791-hangs/td-p/1297850, but I'd rather re-describe the situation with the newly hypothesized.
We have 34 (if not mistaken, or 36, but not the essence) 3202 wsn-modules, working through the network adapters on the same network 220V. Also there wsn-9791 gateway, which is powered via UPS.

The first time we encountered this situation after a month of continious work when the data stopped coming into the program freezer.exe (LabVIEW's exe). In the MAX does not display information about modules even if press Update button, but it does display gateway settings(IP, NTP etc). After rebooting the gateway in MAX operation of the system was restored, with not even required to restart the program itself (freezer.exe).

In the topic for the above link Fred_V recommended to update firmware to 1.2 version, but the situation was repeated again after 2 months and 20 days, which is almost 3 times longer.
The second time, when it happened, it was power failure, due to which all the modules in 2.5 minutes have been disconnected from the network and the signal disappeared from them. We've tested UPS (Siemens), from which the gateway is powered by the presence of any surge in moments of failure and the emergence of a common food, but nothing was found.

We have a hypothesis, though it may seem strange, but it's just another reason we do not see that in the firmware that is wrong. And in the second situation with the hanging mass loss of signal from all modules was the  twist-type trigger.  Can there be any memory leaks or anything like that in an internal program wsn-9791 gateway? We are not competent in respect of the internal structure of the device and it is only our assumption and the question, we hope for your help.

We also conducted two tests with a massive shutdown of all units, but the gateway does not hang, as we assume, due to the fact that it has  worked only a few tens of minutes. But this is again only our hypothesis. We also have a question, while testing whether such tests switched off all modules at once are done?

We welcome any assistance.

Kolan

[ZachAttack]

Kolan,

I have a few questions about your problem that will help in finding a solution.

1. Do you get an error in freezer.exe when communication is lost, or do you just lose signals?  If so, what is the error you get?

2. To clarify, by rebooting the gateway you are able to resume your host VI without restarting it?

3. During your testing of shutting down all units, did you shut down all 36 nodes and the gateway?  Once the power was restored, were they able to start collecting data again?

Thanks for your response, we'll continue to investigate this.