Jump to content


UniStream & UniLogic Beta
  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Damian

  1. I just received my brand shiny new 10" Unistream brimming with excitement to start playing with it.  To my delight, included in the box were some "panel support tabs".  Definitely a cool little development tool.  The instructions say to put them in until they snap and lock in.  Yeah, they don't seem to do that.  They bottom out before they snap in.  Maybe i'm doing something wrong?  Also seems like there is not enough angle on the feet to support a reasonable finger press on the screen.  Too bad ....... would have been a great feature.  Tried them on the 5" i have and they don't snap into that one either.  Maybe something off with the injection molding.

  2. A bit of a weird situation with the unit in title.  It is installed and working as you would expect (new application, just programmed this week), but I noticed some odd noises coming from it.  I disconnected all the connectors and cables except for the 24VDC supply and it still makes the noise.  When I cycle power to it, it is quiet up until it completely finished booting and then runs the application.  As soon as the application starts running, the unit starts making the crackle sound again.  There are not any relay IO, so it can't be a chattering contact.  It is hard to tell if it is the speaker or something else.  Attached are a couple videos where hopefully you can hear the audio OK.  Any ideas on what it might be?

  3. Well ........... all of them really.  M, MI, MF, ML, DW.  It is nice to have a backup of all the operand values in a PLC.  I have had it work fine on some computers, and not at all on others.  Hard to understand why since if it is truly just creating a simple CSV file it should not have anything to do with the OS or installation.

  4. Please forgive me for reviving an old post and possibly changing its topic, But by buffering your inputs and outputs in separate subroutines are you referring to having you inputs in their own subroutine and having them activate the MB and then using the MB in a different Subroutine instead of using the actual input?

    Yes, my Main subroutine never has any code in it other than calls to other subroutines. One of the very first is the call to the "Inputs" subroutines, and one of the very last is the "Outputs" subroutine.

    If so is there any issues using Positive and negative transitions on the MB from the Inputs in the program?

    I would say first that you should specify what you regard as an issue.

    But beyond that, I would contend that there are certain caveats with positive and negative transitions that in fact make buffering inputs and outputs even more valuable, not less. It gives you much more control.

    With ladder, the traditional definition of the scan had the physical IO only updating between single scans of the program. This way you could rely on knowing that the physical Inputs would not change state while your program was in a scan cycle. Some modern controllers, (AB Compact Logix) no longer adhere to this. They have what is considered an asynchronous scan and results in the I/O possibly being updated mid scan, perhaps even multiple times per scan. At face value it may not seem like that would be all that bad of a situation, but in actuality it creates a host of complications and extra considerations that need to be made while coding. Most of us mandate buffered IO on a Compact Logix system as a result, so that we know that we are looking at one single snap shot of the IO for every single scan.

    The use of buffering has created a rift where most are usually adamantly opposed to it or fervently for it. Those that oppose it often cite extra time to code, extra memory use, and believe it adds a layer of complexity that doesn't need to be there. Those of us who are for it feel the cost of the memory and time is generally negligible and is won back over time by having a more robust system. We contend that it makes the code simpler to understand, not more complex. It also makes it nice if you blow an IO point on a card and want to move the logic over to a spare. With the buffering you simply change it in one spot and your done. The retort to that is usually that you can simply do a find/replace just as quickly. Well maybe, but what if you want to for example debounce that signal. All of a sudden find/replace falls flat. Whereas I would simply go to my buffer and put a timer between my physical IO and my buffered IO and it automatically takes effect for all instances of that signal.

    And by the same token, this is where some other nice aspects of buffering come in to play. The buffering doesn't need to be a straight one to one mapping. It can serve the function of creating ON debounce, OFF debounce, ON and OFF debounce, one shots, and signal combinations. Having this stuff in the buffer removes it from the actual code so that the code is easier to read and understand.

    I often find reason to have an input debounced in both the ON and OFF direction, and the code to do this is will just clutter the actual sequence program.

    I also often buffer things in multiple ways. For example I may have a normal instance of an input and a one-shot instance of that same input. This serves two nice functions and illustrates why I think it addresses exactly what you were alluding to with your question. For one, you will find in the documentation that Unitronics discourages overuse of P and N contacts because they have a detrimental effect on the PLC resources. If you need to use the positive transitions of the same signal several times in your program you are much better off using one transition contact to control one normal buffer bit and then just use regular contacts throughout with that buffer bit. You can make it clear with a naming convention (ex. P Control Start PB) that it is transition. The other benefit is you have complete control over how that transition is refreshed now. If you recorded that transition with the buffer bit right in the first subroutine you can count on the fact that that buffer bit will carry the same state throughout the rest of the scan, no matter how many times you jump in and out of subroutines. That is of course unless YOU modify that buffer bit elsewhere.

    And not to be forgotten, the combination signal. What is this? Well possibly it is making more inputs out of fewer. Perhaps you have three aux guard contacts coming into the PLC in separate inputs. It might be beneficial to have one single signal that tells you if all three are on. Or, perhaps you have a mulitplexed signal coming in. Maybe it is a selector switch for a product select where product one is both off, product 2 is one on, product 3 is the other on, and product 4 is both on. Now you can make four buffered inputs that decode this one for one and product one selected, product two select, etc. Again, stuff like this tends to just obfuscate the sequence code. Perhaps you have buttons on the HMI that perform the same function as physical buttons, then you combine these and have both signals controlling the same buffered bit. I could go on and on.

    The situation I have is I have similar machines with V280 controllers but different input cards. I would like to have the subroutines the same in the programs but use an I/O subroutine that would be Machine specific for the particular input card that is on the controller. I will refine a particular subroutine on one machine and will need to add that refinement to the others but the input format is different and is causing problems.

    Thank you in advance for any insight you will be able to give.


    This is again another example of where buffering is handy. It allows you to write code that is non-hardware specific and then just attach those mapping in one spot. I am not certain what you mean by the input format is different. Perhaps you could clarify? What kind of problems are you having?

    • Upvote 1
  5. In addition to what Joe points out, you also need to make sure your common fault MB and the actual individual fault bits are not continously active. Otherwise it will just continuously reinvoke the screen call and cause all sorts of problems.

    The V570 has a decent size screen. I can't imagine not just putting all four of these on one screen and let them all show simultaneously.

    Your customer may be making your job more difficult by thinking that separate screens are "simpler"

    • Upvote 1
  6. It sure is. Obviously you will need to find a wireless transmitter that is compatible with something you can get on the V570 (RS232.RS485,Ethernet, etc).

    Only word of caution is about speed. The analog inputs on the snap in modules in general have better performance. Make sure the conversion times and filtering are acceptable for your application. If you have a slow process there are no worries. If all of this happens in less than a second you will have to do your homework.

  7. Flex,

    It is definitely helpful. I myself am not a fan of how visilogic handles retentative values and especially that of timers. I would much rather see the "initial values" method completely abandoned in favor of the "current values".

    When I want to make abosolute certain I am cloning the operand values I use the "Remote Access" utility and uload all those values into a csv file. I also do not reference timers directly but instead buffer all presets using MI operands. This circumvents some of the flakey behavior you note above.

    • Upvote 1
  8. MI2 & MI3 should be able to range from 1 to 240, with MI2 being less than MI3.

    The question was, what do YOU have them set to?

    Anyhow ........

    MI0 is your encoder count. All MI have a range of -32768 to +32767.

    That means the largest value you can measure in MI0 is 32767.

    In your code you multiply that by 0.00293

    So, 0.00293 * 32767 = 96.00731

    Once it passes 32767 it will jump to -32768, so you immediately jump to negative numbers. So it is NOT counting back down. It is infact counting back up from -96.

    You need to set the encoder rollover point and then either have it automatically reset, or use the marker pulse on the encoder to reset it.

    You then need to keep track of the rollover times separately.

    For example, if you have a 1000 line encoder you will get 4000 counts/rev. Set it to roll over at 4000. Everytime it goes from 4000 to 0, increment an MI or ML integer. Your total distance will now be that integer + the fraction that remains on the encoder.

    Also, a word of caution. You have your screen set up for 9 decimal places. The floating point arithmetic in the PLC is not anywhere near that precise.

  9. After 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.

    • Upvote 1
  • Create New...