I've included an update and a new FPM in this distribution.

The occupancy_collector FPM has been updated to correct two issues.  The first was a data initialization problem with the counters.  The second fix resets the counter immediately when an occupancy sensor goes to a non-occupied state.

A BAS_Ping FPM has been added to this set.  This FPM is intended to be used in LonMaker between two iLON's which are separated geographically.  This FPM accepts two configuration parameters: a start count and a timeout duration.  When the snvt_switch nvi_start is activated, the count is placed at the nvo_pass1 output.  nvo_pass1 should be bound to nvi_pass1 of the 2nd iLON100.  In the simplest case, nvo_pass1 of the 2nd iLON100 would then be tied to nvi_pass1_dec of the first iLON100. nvi_pass1_dec will decriment the input by one and pass that value to nvo_pass1.  (nvi_passx passes the input to nvo_passx) When the input number reaches zero then nvo_done output is turned on.  If this doesn't occur before the specified nci_timeout, then nvo_fault is set to say that the process took longer than defined.  The nvo_latency is a one second counter and will report at the one second resoultion how long the process takes.

As an extreme test, you could enter 65534 into the nci_count parameter and have all outputs tied to corresponding inputs on the 2nd iLON100.  The 2nd ilon would then have all its outputs tied to the n+1 input of the first iLON100.  (Output nvo_pass10 on the 2nd iLON100 would be tied to nvi_pass1_dec of the first iLON100).  This would result in 20 * 65534 messages being transmitted before nvo_done would be asserted.

The image included in the zip file shows two blocks bound within one iLON100.  This configuration decremented through 44,617 iterations in 4800 seconds.  That breaks down to 186 loop-back network messages in the iLON every second.  Note that the iLON did not have other loading processes at the time.

 Richard