From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-30-2009 05:46 PM - edited 06-30-2009 05:47 PM
Sincerely,
The National Instruments WSN Team
Robert Jackson - Senior Product Manager
Kurt Williams - LabVIEW WSN Product Manager
Jaidev Amrite - Product Support Engineer
07-21-2009 02:32 AM
07-21-2009 11:30 AM - last edited on 10-17-2024 02:38 PM by Content Cleaner
Hi Muks,
Although the NI WSN Nodes can do some digital I/O, it is really not meant for vision applications.
Thank you,
Jaidev Amrite
07-24-2009 06:50 AM
Jaidev,
Thanks for the links.
08-18-2009 05:32 PM
Can you run a PID loop on a programmable node?
08-19-2009 08:18 AM
Hi bnadeau,
You can perform simple On/Off control using the digital outputs to implement something like a thermastat.
However, deterministic closed-loop control is not an application that these nodes have been designed for.
Two main reasons:
1. There are no analog outputs on the nodes
2. You cannot be certain that the code will run deterministically because the node goes to sleep and wakes up between sample intervals
Hope this helps.
Kurt
09-24-2009 03:25 PM
In regards to the limitations of the node programming in Labview:
Is it possible to access the routing control and monitor router status at the node via embedded Labview code?
Is it possible to have a counter counting clock ticks?
Are Timed Loops available in the embedded code?
Where can I find detailed information on the operation of the node and what constraints exists?
Thanks
09-25-2009 08:06 AM - last edited on 10-17-2024 02:39 PM by Content Cleaner
Is it possible to access the routing control and monitor router status at the node via embedded Labview code?
No, currently you don't have insight into the routing behaviour. How would you use this functionality?
Is it possible to have a counter counting clock ticks?
You have 4 digital I/O lines that can be used as software timed counters, meaning you can either poll the input for edge changes, or you can configure the node to wakeup on rising/falling edges to make it event based and increment a variable each time.
If you meant count the processor clock ticks, no you cannot.
Are Timed Loops available in the embedded code?
Timed loops are not available, but you have the standard while loop and basic timing functions. It is important to note that the embedded WSN code execute sequentially in a single thread, so if you have multiple loops, the first has to completely finish before another will start (parallel loops don't run concurrently). This allows us to further optimize your code for density and extend battery life into the multi-year time frame.
Kurt
09-26-2009 08:33 PM
Kurt
Thanks for the reply and the links.
The current configuration for the WSN system is 36 recommended nodes per gateway (How many gateways per controller???) and My understanding is that only 50 nodes are allowed in MAX (Is that the limit in total per controller or per gateway???). So even if you are acquiring lets say 250bits of data per 5 min you can still only have 36 nodes to work with even though your bandwidth demands are low at 250kbits per second throughput you could theoretically have up to 3000 nodes operating on a single gateway from a bandwidth point of view (assuming that 250kbits.sec is the DATA throughput with overhead already accounted for ???). My understanding is that the lack of determinism prevents the system from doing more. So I would bypass MAX and the automatic mesh comm handling supplied by the existing hardware/software altogether in order to get the node count up to what is inline with the 250kbit throughput capability. I would develop an algorithm to create some 'fuzzy determinism' and Administrator comm path controls (eliminating true mesh capabilities while allowing for at least 1 redundant comm path at each hop to and from the controller/nodes).
If I had control over routing and access to a hardware counter counting node clock ticks then I would set up forced data path mapping for data from nodes to host controller with A(rx) and B(rx) comm paths for each hop where A(rx) is taken unless unavailable then B(rx) is taken. For comm from host controller to Nodes I would broadcast data with address at a defined time for each node. To get some 'fuzzy determinism' I would do the following as a periodic (maybe twice every 5 minutes) fuzzy determinism cal routine.
Determine the clock jitter and drift, and comm latency for every combination of comm paths established by the administrator and send this information back to the host controller in order for the controller to create a time map of the complete system and assigned times for the node to 'look' for data from the controller (the address attached with data gives a check to make sure the data is for the intended node) and assign times for node to send data back to the controller. This essentially makes a EtherCAT type protocol based on calibrated and tracked time differences between nodes and overall comm latency. If the A and B paths where stored and handled at the node but set by the controller then I would only need to have 2 nodes configured in MAX and the rest I handle. This would give me the ability to max out the number of units per gateway according to bandwidth minus the extra overhead. Also, if the data coming to the host controller has to take path B at any hop then this could be attached and sent with data to inform the host that the node X is down. Also, by having controlled comm paths from nodes to the controller then return data bandwidth could be higher because multiple return paths could be setup in each network capable of carrying the full 250kbits/sec each.
If NI limits the number of nodes to 36 then something is limiting the expansion capability and I would like to know exactly what it is. I was told it is "both hardware and software" but that doesn't tell me anything. These units would be great for an application I have but the 36 (50 in MAX) limit causes a whole array of unnecessary costs and integration issues.
09-28-2009 12:41 PM
Hey :b,
Thanks for the post. I'll try and address all your questions below:
For a large system, it would make sense to simply add additional gateways. This gets you the data acquisition functionality with very minimal effort on your part.
Please let me know if I can help with any other questions.
Regards,