Definitely a newbie question

[CAI_Support]

When ISY99 set VAR8 to 213, WC will see that 213. We might think that as binary or decimal, but in WC register, it is stored as a 32 bit signed number, which is 00000000000000000000000011010101 in binary.  How do you manipulate it is based on how do you see it, because you set ISY side sending over in a format you planned.
 
If you want to set all the bits in the TTL outputs immediately according to the bit pattern, that is something we can add to firmware.  However, there is no easy way if the output bits also need to use non-blocking delay, which seems to be the case in your project.  Because VAR is 32 bit and all 8 TTL outputs is 8 bits, there are 23 bits( or 24 including sign bit) not being used.

 

[rossw]

When ISY99 set VAR8 to 213, WC will see that 213. We might think that as binary or decimal, but in WC register, it is stored as a 32 bit signed number, which is 00000000000000000000000011010101 in binary.  How do you manipulate it is based on how do you see it, because you set ISY side sending over in a format you planned.
 
If you want to set all the bits in the TTL outputs immediately according to the bit pattern, that is something we can add to firmware.  However, there is no easy way if the output bits also need to use non-blocking delay, which seems to be the case in your project.  Because VAR is 32 bit and all 8 TTL outputs is 8 bits, there are 23 bits( or 24 including sign bit) not being used.

 
 
I'd just like to see an 8-bit byte we can input to read all inputs, or output to set outputs, in one hit.
The non-blocking delay being inoperative is immaterial for the majority of MY applications (that's not to say others share my view).
I got my fingers burned with non-blocking delays being hideously unreliable in early versions of the code and have avoided using them ever since.
Even on recent versions of the code, after a detailed tutorial in this form on them - and then finding that it didn't actually work quite as said - but required additional steps in between, simply leaves me (personally) reluctant to use or rely on them, so no great loss
 
Eg, you have var1-8, ram1-8, another two -  "inputs" and "outputs" would add a lot of flexability.
 
Eg,
 
     xorb  inputs 85 outputs      #  invert outputs 0, 2, 4, 6.
     set outputs 0                      # turn off all outputs
 
etc

 

[CAI_Support]

Ross,
 
Thanks for the suggestions. INPUTS and OUTPUTS can be added to PLC, that is not hard to do, it does not use any additional RAM either.  Do you agree using INPUTS and OUTPUTS as keyword for I/O?  Any word becoming keyword will not be used as user defined variable name.
 
You mentioned the recent version code non-blocking delay still required additional steps in between to make them work. Could you please elaborate on that, so that we can see what do we need to improve?
 
Thanks for all your suggestions from anyone.

 

[rossw]

Thanks for the suggestions. INPUTS and OUTPUTS can be added to PLC, that is not hard to do, it does not use any additional RAM either.  Do you agree using INPUTS and OUTPUTS as keyword for I/O?  Any word becoming keyword will not be used as user defined variable name.
 
You mentioned the recent version code non-blocking delay still required additional steps in between to make them work. Could you please elaborate on that, so that we can see what do we need to improve?

 
I don't really mind what we call them.  IN8, OUT8.  INPUTS, OUTPUTS, INB, OUTB... if we can't use the word as a label later, so be it
 
I think this thread best demonstrated (in minimal code) the inconsistent behaviour.
http://cocoontech.com/forums/topic/22898-setting-opx-on-based-on-ipx/?p=186928

 

[CAI_Support]

What about call them ALLIN and ALLOUT?  So that in the future, same program can be used on the 32bit board, since that one has 16 input and 16 output?
 
About non-blocking delay, Dr. Lou wrote this posting to detail the usage:
http://cocoontech.com/forums/topic/22849-cai-webcontrol-non-blocking-delay-function/

 

[rossw]

What about call them ALLIN and ALLOUT?  So that in the future, same program can be used on the 32bit board, since that one has 16 input and 16 output?
 
About non-blocking delay, Dr. Lou wrote this posting to detail the usage:
http://cocoontech.com/forums/topic/22849-cai-webcontrol-non-blocking-delay-function/

 
AllIN and AllOUT works for me.
 
The write-up on the non-blocking delay is either in error, or incomplete.
The thread I posted is a perfect example - the code
 
If the behavior was exactly per the description, this code would work:

  tsteq ip1[2000] 1
  set op1 1
  tsteq ip1[10000] 0
  set op1 0

 
The fact it doesn't work *reliably*, and your subsequent details about timing differences and making the code 6 times more complex to test around the conditions means clearly it isn't quite as straightforward as suggested and given the internal uncertainty, I'm not game to use it lest my critical application be one of those circumstances where it just doesn't work as described!

 

[CAI_Support]

Ross,
 
non-blocking delay only sets its timer during value change.  Each time an input being pulled by system, by PLC code, or output being set, a timer value is stored.
When you later reference to it with non-blocking delay, the delay is counted from last time value changed.
 
in TSTEQ line, the non-blocking delay merely reference current time to last value change time, not the time to compare.  IP1 is on WebControl system status checking timer. When it detected any change, a new timer value stored automatically.
 
I hope this will help clarifying non-blocking delay.

 

[rossw]

Ross,
 
non-blocking delay only sets its timer during value change.  Each time an input being pulled by system, by PLC code, or output being set, a timer value is stored.
When you later reference to it with non-blocking delay, the delay is counted from last time value changed.
 
in TSTEQ line, the non-blocking delay merely reference current time to last value change time, not the time to compare.  IP1 is on WebControl system status checking timer. When it detected any change, a new timer value stored automatically.
 
I hope this will help clarifying non-blocking delay.

 
It does, but it adds a random, unpredictable condition to the test - which means it's (almost) useless.
The description of how it works should be updated to include this caveat, and examples of the steps needed to work around it - because to be quite blunt - as it stands, the very simple, elegant, 4-line code *SHOULD* work based on the description of exactly what things do - but clearly it isn't that simple, and adding many times more code than the logic would indicate is necessary just to "work around" the limitations isn't elegant or practical.
 
Asynchronous events have always been an issue for real-time operating environments, no less so for the webcontrol boards. I like what the non-blocking delays offer, but the fact they don't behave in a predictable, consistent, reliable manner makes them of little value to me (but that may not be the case for others of course).

 

[CAI_Support]

Ross,
 
Thanks for your input.  The idea behind the original design was for example, if user wanted to turn on an output not exceeding certain amount time, he can do that with non-blocking delay, so that in case other logic failed, non-blocking delay will automatically turn it off. 
 
Non blocking delay is assiciated with I/O or VAR state change. so that program does not have to wait there for. 
 
As you and Dr. Lou pointed out, the documentation for the non-blocking delay is not enough.  That made people think this function can be used for other condition also.
 
PLC logic is looping from START to END forever, it does that many many times in each second. If
tsteq ip1[2000] 1
started timer, what could prevent PLC logic to think next loop around the timer started again?  That is the reason we set timer start at state change, which is unique for each input, output, or VAR.

 

[todster]

When ISY99 set VAR8 to 213, WC will see that 213. We might think that as binary or decimal, but in WC register, it is stored as a 32 bit signed number, which is 00000000000000000000000011010101 in binary.  How do you manipulate it is based on how do you see it, because you set ISY side sending over in a format you planned.
 
If you want to set all the bits in the TTL outputs immediately according to the bit pattern, that is something we can add to firmware.  However, there is no easy way if the output bits also need to use non-blocking delay, which seems to be the case in your project.  Because VAR is 32 bit and all 8 TTL outputs is 8 bits, there are 23 bits( or 24 including sign bit) not being used.

 
Is there any way to access the bits of a timer that runs in milliseconds?  We could create a counter or something that is toggled by the bit we want as our time base. As far as the 23 bits not being used, this is better than 30 bits x 8 not used? There is so much logic that could be reduced by changing the outputs to 1 byte. I can find something to use the other 23 bits for.

 

[CAI_Support]

WebControl CPU is on an scheduler to perfom all kinds of tasks. User PLC program does not have control in microsecond through PLC proramming.  The problem here is that if you toggle a bit when PLC execute that line the first time, how can PLC engine to distinguish next time to toggle again, since the PLC code is execute from beginging to the end all over?  It would be same problem, just changed to another way.