Siemens FB dev mon/mod values in VAT for debug... and other FB dev questions.

[TurpoUrpo]

TIME is just DINT with resolution of one msec. There is easier way to achieve result of DINT PT&ET tough if you want to see, its "advanced" tough and could mix things more..

 

[Nick Birke]

Well I made a whole bunch of new variables in the STAT declarations, and went through the whole thing and just changed them all. Things are working much more in accordance with expectations... didn't have to change any rungs. I have to admit I don't understand exactly why this is I know you explained it... I will have to read all these posts more closely so I can understand it... I have quite a bit of PLC experience, so I just thought I would dive in and learn by hitting bumps in the road as I warm up to Siemens. I'll be sure to post when I am ing again.

 

[L D[AR2P#0.0]]

Here's my SFB4 wrapper using DINT's instead of TIME

 

[Nick Birke]

Oh about this....

SET and RESET do not always write to, neither does move if its conditional.

All of my MOVs with conditionals work... are you sure about the above? I am certainly not trying to debate, as you obviously know much more than I do with this product... I am just trying to make sure we are on the same and right picture.

Also my SETs and RESETS behave as expected. I could see how (and now we are just getting into basic PLC...) if you had, and it seems Siemens contacts are on or off based on the condition of the last rung they are set so say you have something like

N1
   BIT1         BIT2
----||-----------(S)
   ON
 
Nx1.... with no BIT2 CONTACTS
Nx2.... with no BIT2 CONTACTS
Nx3.... with no BIT2 CONTACTS
 
N2
   BIT4         BIT2
----||-----------( )
   OFF

My understanding is BIT2 would be off by the end of the scan... (almost certainly if N1 just had a contact on and not an (S) contact set.

 

[L D[AR2P#0.0]]

Temp variables are allocated to program blocks using a stack. With a trivial program, the areas of the stack are only used by one block and hence retain their contents. Add some more block calls into the mix and now the stack area will be written to by several blocks. Mayhem ensues.
Everyone falls into this trap and continues to believe they can use the temp area to store data between scans because they see it working with their starter programs. Eventually they learn.

 

[RMA]

Quote:
Originally Posted by TurpoUrpo
SET and RESET do not always write to, neither does move if its conditional.

All of my MOVs with conditionals work... are you sure about the above? I am certainly not trying to debate, as you obviously know much more than I do with this product... I am just trying to make sure we are on the same and right picture.

I think TurpoUrpo mixed something up here (unusal for him, maybe it was getting late ) as you say SET and RESET always execute regardless of the RLO state (not sure if MOV can be conditional offhand, I don't work in ladder that often). While you're at it, it's probably worth mentioning that the L(oad) and T(ransfer) instructions also always execute, regardless of RLO state - that's another one that often catches newbies out.

 

[TurpoUrpo]

I think TurpoUrpo mixed something up here (unusal for him, maybe it was getting late ) as you say SET and RESET always execute regardless of the RLO state (not sure if MOV can be conditional offhand, I don't work in ladder that often). While you're at it, it's probably worth mentioning that the L(oad) and T(ransfer) instructions also always execute, regardless of RLO state - that's another one that often catches newbies out.

SET and RESET (stl s & r) do not execute without regard to RLO. S sets given bit if RLO is true but if it is not then it does not execute, same for R, it resets given bit if RLO is true. That is what I said.

L & T do execute without regard to RLO. Point was conditioned move as in used in ladder. It makes jump over L & T.

Did you look at posted code?