PLC Code How To: Webset Every 5 minutes

LarrylLix said:
Here is one basic idea how you could accomplish this. I created a time slice main routine based on a 6 second repeat / heartbeat.  Remember MOD(ulus) is your friend.
 

SEC0:
MOD CS UROM1 RAM2 # Div C)urrent S)econd by UROM1=6, remainder into RAM2
TSTNE RAM2 0 # check it for 0 remainder = timeslice 0
GOTO SEC0_DUN # not? then forget it
BNZ RAM1B1 SEC1 # Already done this timeslice? Then do next
CALLSUB CLOCK1 #
SET RAM1B1 1 # mark it as complete this timeslice
GOTO MAINLOOP # back to the PLC beginning
SEC0_DUN:
SET RAM1B1 0 # other timeslice? flag ready for next loop

SEC1:
TSTNE RAM2 1 # timeslice at 1 second mark
more PLC jobs

 
 
 
Here is my clock subroutine. I pack all the date and time together and ship it to ISY every 6 seconds and use it for a heartbeat and also to tell ISY what time it is, useable as individual elements.
 

CLOCK1:
TSTLT CYEAR 2014 # if clock isn't valid yet don't send it
GOTO CLOCK_X
MUL CMONTH 100 RAM2 # date and time format will be on integer MMDDhhmmss
ADD RAM2 CDAY RAM2
MUL RAM2 100 RAM2 #shift it left two decimal digits and keep adding LS values
ADD RAM2 CH RAM2
MUL RAM2 100 RAM2
ADD RAM2 CM RAM2
MUL RAM2 100 RAM2
ADD RAM2 CS RAM2
SETLED 1
SET VAR1 RAM2 #RAM2 is my global scratchpad variable.
WEBSET URL1 VAR1 #VAR1 is the last thing sent via WEBSET URL1
SETLED 0
CLOCK_X:
RET

When the WC8 reboots I do a WEBSET URL1 -1   to flag my ISY that the WC8 rebooted. Just for monitoring purposes to establish reliability for now.
If the heartbeat is missing too long an Insteon ON/Off module power cycles the WC8 and the bridged router sending the data to another building where my ISY resides.

If
$CAI1_DateTime <= -1

Then
code to record reboot in ISY

Else
Wait 9 seconds
code to record the first heartbeat period is missed
Wait 6 seconds
code to record the second heartbeat period is missed
Wait 6 seconds
code to record the third heartbeat period is missed
Wait 6 seconds
code to record the fourth heartbeat period is missed
Wait 60 seconds
Set 'Workshop / Shop Webcontrol Board' Off
Wait 15 seconds
Set 'Workshop / Shop Webcontrol Board' On
Hello
I was checking for mod (n*seconds) assuming that in my code it will be not returning to the line in the same second (or do wait 1)
May be a real pretty code would need also a check if the webset channel is clear, e.g. not congested...
regards
 
Hello

I was checking for mod (n*seconds) assuming that in my code it will be not returning to the line in the same second (or do wait 1)

May be a real pretty code would need also a check if the webset channel is clear, e.g. not congested...

regards


 
I don't know how you would check for Ethernet congestion. Is there a way?
 
I read in the manual that the memory can only buffer up to four WEBSET commands and then the oldest will be thrown away so I broke my WEBSET commands into 1 second time slices on a 6 second loop.
 
Also, I did some crude looping tests and found my WC8 board will execute about 1600 PLC lines of code per second.
 
 
I am not familiar with the newer "switch / case" terminology style but yes.
 
While power_is_on
  Switch (MOD CS 6)
  Case: 0
      plc routine
      exit case
  Case: 1
    plc routine
    exit case
  Case: 2
    plc routine
    exit case
  Case: 3
    plc routine
    exit case
  Case: 4
    plc routine
    exit case
  Case: 5
    plc routine
    exit case
End while
 
I am afraid there is no way for sender to know where the network congestion could be, besides, if network congestion caused by collision, sending more packets to test congestion will cause more collision.  In normal network operation, you will find out where the congestion is, then fix it.  But not all congestion can be fixed, for example, if the server is overloaded, it will not be able to respond in time.  Unless server being replaced with a more powerful one, you will have to "live" with it.  3.02.18b5 firmware extended watchdog timer, so that it can live with congestion or slow response. 
 
You should not see any reboot from that, if you do, we can extend watchdog timer to a longer one.  In a way, the shorter timeout and reboot would tell the receiving side that there is a congestion somewhere.
 
CAI_Support said:
I am afraid there is no way for sender to know where the network congestion could be, besides, if network congestion caused by collision, sending more packets to test congestion will cause more collision.  In normal network operation, you will find out where the congestion is, then fix it.  But not all congestion can be fixed, for example, if the server is overloaded, it will not be able to respond in time.  Unless server being replaced with a more powerful one, you will have to "live" with it.  3.02.18b5 firmware extended watchdog timer, so that it can live with congestion or slow response. 
 
You should not see any reboot from that, if you do, we can extend watchdog timer to a longer one.  In a way, the shorter timeout and reboot would tell the receiving side that there is a congestion somewhere.
 
If only one of the receivers of Websets is down, the whole system of distributed WCs fails. But testing for WSREPLY helps to see if the unit is alive, and you could use EMn for notifying.
 
You should not see any reboot from that, if you do, we can extend watchdog timer to a longer one. In a way, the shorter timeout and reboot would tell the receiving side that there is a congestion somewhere.

Can you tell us how many seconds the WatchDog timer is set for so it can be used for troubleshooting in future considerations?
 
It hasn't cured all my 1Wire problems but it makes it livable and understandable to set up downstream allowances for data stream hiccoughs. (US=hiccups :D)
 

If only one of the receivers of Websets is down, the whole system of distributed WCs fails. But testing for WSREPLY helps to see if the unit is alive, and you could use EMn for notifying.

If my ISY, receiver of the data stream, is down the WC8 would never know it and I wouldn't care either. I don't control anything important from it.  If it became a critical input to my ISY I would have to make allowances for the lack of accurate data with a backup program  called
 
      "got along with out before I met you, gonna' get along with out you now".  :P
 
If ISY can send back a reply during WEBSET, as documented in our document,  WC will know if that side was up or down, then PLC code can act differently, sending an email alert, for example.  That is something not too hard to do on ISY side software.
 
I believe the watchdog timer increased from 2S to 4S.  but I did not read code myself, so that is just close guessing.  If during watchdog timer expecting, the other side responded even with a partial reply, it will reset the watchdog timer. so that actual network timeout can be much longer than 4s.
 
My ISY cannot transmit data out, except for email notifications.  I have not purchased the Network Module to do so and it is required to send information out from the ISY9941.
 
During each WEBSET call, WC sends out its MAC address and hostname in the HTTP request.  So the server side, in this case ISY, knows which one is sending information in.  When WC finished WEBSET call, it will read from server a reply and find string WSREPLY=, then convert the number string after "=" to number.  This is not a separate data sending process, rather the same HTTP request handling.  I am sure if you send request to UDI for adding a number to return after SET detected, they could add that.  In that way each ISY can talk to multiple WC8 boards.
 
ISY may send a response on the lower level of the http protocol but there I nothing available to the user, AFAIK. The Restful interface has been well defined by others for some time now so I doubt UDI would change the way it interacts with external stimuli. This may violate the standard API.

http://en.wikipedia.org/wiki/Representational_state_transfer

 
The ISY994i knows who sets the variables by the WC8, or others, by following polite rules and only manipulating each's own variable assignments.
 
ie. for WC8.1 I would define eight variables such as
 
WC8.1.var1    .../set/2/5/xx
WC8.1.var2    .../set/2/6/xx
...
WC8.1.var8    .../set/2/12/xx
 
Then for the next WC8.2 PLC board
WC8.2.var1    .../set/2/13/xx
WC8.2.var2    .../set/2/14/xx
...
WC8.2.var8     .../set/2/20/xx
 
All the WEBSETS must be polite and only manipulate their own variable assignments in the ISY.
 
The ISY has no way to protect external controllers like WC8 for not playing nice and corrupting other variables other than the basic user name and password to the whole ISY domain. (no sectionalising of permissions).
 
 
Programs and devices can be directly controlled with the WEBSET /Rest interface, as well as prompts for information, but where would WC8 put massive tables of text responses coming back at it?
 
Back
Top