1 pointHopefully you've already figured this out, but just in case you haven't.... If you want to prevent other programmers from seeing a particular screen configuration, you can right click on the screen name(in the Solution Explorer), then select "Password Protect" If you want to prevent unauthorized access to the screen during operation, you can assign a button on another screen("Main Menu", for example). Then, in the Properties Dialog box for the button, add a new "Load Screen" Action, then set the User Access property. In the Solution Explore, use the "User Access Control" to configure the different levels of access, as your application requires. I apologize for not being more detailed, but I am also a new to the UniLogic platform and just started looking into the whole password protection/user access system. The more I learn, the more I like!
1 pointAfter actually playing around a bit, it appears that the transistions in Visilogic do not function anything like I thought they did either. As Alex hints at, it appears that the memory bits associated with change of state are sampled on each and every subroutine, including the main subroutine. This means that if you call the same subroutine twice or more within one total PLC scan, any transitional within will only be evaluated true the first time through. However, that transition will still be detected by the calling subroutine and subsequent other subroutine calls within the global scan. If you then have combinations of SET and RESET on those bits outside the subroutine calls, depending on order and placement you can create anamolous and unpredictable behavior. In some cases, even disregarding subroutines, I saw evidence of transitionals being affect by changes being made to the bits within that same scan. In other instances it was not tied to the scan. For example, I put two identical --|n|--[iNC+]-- networks in consecutive networks incrementing unique integers. Both would count. However if I put a reset coil of the bit with the referenced N transition above between these two identical networks, the second of them would stop counting. It did this even though there was no difference in the change of state. Therefore just having overwritten the same state to said memory area the transition was lost. Which means it was updated immediately with the reset coil and not the subroutine. I was also able to create situations where it recogized transitions within routines, but did not recognize those transition in the main subroutine. Can we please get a concise and detailed description of exactly how and when the transitional contacts are updated and evaluated? Based on the observed behavior, the description in the help file is actually incorrect/incomplete.